From andrew.dul at quark.net  Thu May  5 10:59:45 2016
From: andrew.dul at quark.net (Andrew Dul)
Date: Thu, 5 May 2016 07:59:45 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
 Policy
In-Reply-To: <CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
Message-ID: <32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>

Hello,

As part of the discussions at ARIN 37 the community considered updates
to the proposed draft policy that would allow organizations to transfer,
within ARIN, reserved pool resources provided that they met the criteria
to obtain a block from a reserved pool.

Based upon this feedback we are proposing to update the draft policy
text as follows.  The AC welcomes your feedback on this proposed text
and any other feedback on this draft policy.

Thanks,

Andrew


*Original**Policy statement:*

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

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

**Updated ***Policy statement:*

Add to Section 8.3 under the "Conditions on recipient of the transfer:"

Address resources from a reserved pool (including those designated in
Section 4.4 and 4.10) shall only be transferred to organizations which
meet the current criteria of the reserved pool from which the resource
was obtained.

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

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

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

From farmer at umn.edu  Thu May  5 11:30:42 2016
From: farmer at umn.edu (David Farmer)
Date: Thu, 5 May 2016 10:30:42 -0500
Subject: [arin-ppml] ARIN-2015-3:(remove 30-day...) Staff interpretation
	needed
In-Reply-To: <CAC4yj2Wi8Dac+5EK83W=STcz67fUCdTDqsKgHW6GdzgHkar+9w@mail.gmail.com>
References: <CAN-Dau2TiyphbwW3c-wLCKgEJuBpcWsJQEi3c6dq6aBomvA92Q@mail.gmail.com>
	<CAC4yj2Wi8Dac+5EK83W=STcz67fUCdTDqsKgHW6GdzgHkar+9w@mail.gmail.com>
Message-ID: <CAN-Dau18JRdy9uJKYRFQK5-upspFddiVWmi8qASfZi8tzq7=Hw@mail.gmail.com>

On Mon, Apr 25, 2016 at 11:47 AM, Jason Schiller <jschiller at google.com> wrote:
...

> David, I hear a lot of people such as yourself, supposing that removal of
> the 30 day need check will not change anything else.  But I believe it makes
> (pre-)approval  for transfer solely based on the 2 year need projection,
> which I am concerned could be wildly optimistic.

I'm not sure if this is directed at me or David Huberman, but I'll
respond anyway.

The staff assessment for ARIN-2015-3 says;
   This policy would more closely align with the way staff applies the
existing policy
   in relation to 8.3 transfers. Because there is no longer an IPv4
free pool and many
   IPv4 requests are likely to be satisfied by 8.3 transfers, the
adoption of this policy
   should have no major impact on operations and could be implemented
as written.

I interpret this as saying the evaluation will be based on
more-or-less the same criteria it is today just with no requirement to
use 25% in 30 days, which you and everyone seems to support.

> I am not confusing it with 2015-7: Simplified requirements for demonstrated
> need for IPv4 transfers.  I believe 2015-7 would result in two changes, 1.
> lowering the bar for ISP to match what end users need in 2015-3, and 2.
> removing any demonstration of current utilization (and by extension
> demonstration that you can and are properly managing the space you have) for
> both ISPs and end users.
>
> I can see where there could be some confusion as I have the same concern for
> both proposals, that there needs to be some tangible verifiable claim.

Thanks for clarifying.

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


From farmer at umn.edu  Thu May  5 11:45:07 2016
From: farmer at umn.edu (David Farmer)
Date: Thu, 5 May 2016 10:45:07 -0500
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <571E6439.7010801@arin.net>
References: <571E6439.7010801@arin.net>
Message-ID: <CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>

As shepherd for this policy I welcome any additional last call
feedback for this policy.  It is especially important to speak up if
you feel there are any issues remaining that need to be considered.
But, even if you simply support the policy as written that is
important and useful feedback as well.

The last call period formally continues through, Monday, May 9th, and
the AC will consider the feedback during its scheduled call on
Thursday, May 19th.

Thanks

On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net> wrote:
> The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
> send the following to last call:
>
>   Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
> requirement in end-user IPv4 policy
>
> Feedback is encouraged during the last call period. All comments should
> be provided to the Public Policy Mailing List. This last call will
> expire on 9 May 2016. After last call the AC will conduct their
> last call review.
>
> The draft policy text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Recommended Draft Policy ARIN-2015-3
> Remove 30 day utilization requirement in end-user IPv4 policy
>
> AC's assessment of conformance with the Principles of Internet Number
> Resource Policy:
>
> ARIN 2015-3 contributes to fair and impartial number resource administration
> by removing from the NRPM text that is operationally unrealistic for the
> reasons discussed in the problem statement. This proposal is technically
> sound, in that the removal of the text will more closely align with the way
> staff applies the existing policy in relation to 8.3 transfers. There was
> strong community support for the policy on PPML and at ARIN 36, which was
> confirmed at ARIN 37. There was a suggestion to replace this text with an
> alternate requirement. However, the community consensus was to move forward
> with the removal alone.
>
> The staff and legal review also suggested removing RFC2050 references and
> pointed out that 4.2.3.6 has an additional 25% immediate use clause,
> community feedback was to deal with those issues separately.
>
> Problem Statement:
>
> End-user policy is intended to provide end-users with a one year supply of
> IP addresses. Qualification for a one-year supply requires the network
> operator to utilize at least 25% of the requested addresses within 30 days.
> This text is unrealistic and should be removed.
>
> First, it often takes longer than 30 days to stage equipment and start
> actually using the addresses.
>
> Second, growth is often not that regimented; the forecast is to use X
> addresses over the course of a year, not to use 25% of X within 30 days.
>
> Third, this policy text applies to additional address space requests. It is
> incompatible with the requirements of other additional address space request
> justification which indicates that 80% utilization of existing space is
> sufficient to justify new space. If a block is at 80%, then often (almost
> always?) the remaining 80% will be used over the next 30 days and longer.
> Therefore the operator cannot honestly state they will use 25% of the
> ADDITIONAL space within 30 days of receiving it; they're still trying to use
> their older block efficiently.
>
> Fourth, in the face of ARIN exhaustion, some ISPs are starting to not give
> out /24 (or larger) blocks. So the justification for the 25% rule that
> previously existed (and in fact, applied for many years) is no longer
> germane.
>
> Policy statement:
>
> Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
>
> Resulting text:
>
> 4.3.3. Utilization rate
>
> Utilization rate of address space is a key factor in justifying a new
> assignment of IP address space. Requesters must show exactly how previous
> address assignments have been utilized and must provide appropriate details
> to verify their one-year growth projection.
>
> The basic criterion that must be met is a 50% utilization rate within one
> year.
>
> A greater utilization rate may be required based on individual network
> requirements. Please refer to RFC 2050 for more information on utilization
> guidelines.
>
> Comments:
>
> a.Timetable for implementation: Immediate
>
> b.Anything else
>
> #####
>
> ARIN STAFF ASSESSMENT
>
> Draft Policy ARIN-2015-3
> Remove 30 day utilization requirement in end-user IPv4 policy
> Date of Assessment: 16 February 2016
>
> ___
> 1. Summary (Staff Understanding)
>
> This proposal would remove the 25% utilization (within 30 days of issuance)
> criteria bullet point from NRPM 4.3.3.
>
> ___
> 2. Comments
>
> A. ARIN Staff Comments
> This policy would more closely align with the way staff applies the existing
> policy in relation to 8.3 transfers. Because there is no longer an IPv4 free
> pool and many IPv4 requests are likely to be satisfied by 8.3 transfers, the
> adoption of this policy should have no major impact on operations and could
> be implemented as written.
>
> Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to obsolete
> RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within 30
> days of issuance) requirement.
>
> Staff suggests removing the first two sentences of 4.2.3.6 to remove the
> references to RFC 2050 and the 25% requirement. Additionally, staff suggests
> removing the reference to the obsolete RFC 2050 in section 4.3.3.
>
> B. ARIN General Counsel ? Legal Assessment
> No material legal risk in this policy.
>
> ___
> 3. Resource Impact
>
> This policy would have minimal resource impact from an implementation
> aspect. It is estimated that implementation would occur immediately after
> ratification by the ARIN Board of Trustees. The following would be needed in
> order to implement:
> * Updated guidelines and internal procedures
> * Staff training
> _______________________________________________
> PPML
> You are receiving this message 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
===============================================


From jschiller at google.com  Thu May  5 14:26:03 2016
From: jschiller at google.com (Jason Schiller)
Date: Thu, 5 May 2016 14:26:03 -0400
Subject: [arin-ppml] ARIN-2015-3:(remove 30-day...) Staff interpretation
	needed
In-Reply-To: <CAN-Dau18JRdy9uJKYRFQK5-upspFddiVWmi8qASfZi8tzq7=Hw@mail.gmail.com>
References: <CAN-Dau2TiyphbwW3c-wLCKgEJuBpcWsJQEi3c6dq6aBomvA92Q@mail.gmail.com>
	<CAC4yj2Wi8Dac+5EK83W=STcz67fUCdTDqsKgHW6GdzgHkar+9w@mail.gmail.com>
	<CAN-Dau18JRdy9uJKYRFQK5-upspFddiVWmi8qASfZi8tzq7=Hw@mail.gmail.com>
Message-ID: <CAC4yj2XijngSBV2iJrgAZ5cLWcDpgJpStU9EvMCJihoiBzX75Q@mail.gmail.com>

Comments in line.

On Thu, May 5, 2016 at 11:30 AM, David Farmer <farmer at umn.edu> wrote:

> On Mon, Apr 25, 2016 at 11:47 AM, Jason Schiller <jschiller at google.com>
> wrote:
> ...
>
> > David, I hear a lot of people such as yourself, supposing that removal of
> > the 30 day need check will not change anything else.  But I believe it
> makes
> > (pre-)approval  for transfer solely based on the 2 year need projection,
> > which I am concerned could be wildly optimistic.
>
> I'm not sure if this is directed at me or David Huberman, but I'll
> respond anyway.
>
> The staff assessment for ARIN-2015-3 says;
>    This policy would more closely align with the way staff applies the
> existing policy
>    in relation to 8.3 transfers. Because there is no longer an IPv4
> free pool and many
>    IPv4 requests are likely to be satisfied by 8.3 transfers, the
> adoption of this policy
>    should have no major impact on operations and could be implemented
> as written.
>
> I interpret this as saying the evaluation will be based on
> more-or-less the same criteria it is today just with no requirement to
> use 25% in 30 days, which you and everyone seems to support.
>

yes, true, but... what does it mean to have the same criteria just with
no requirement to use 25% in 30 days?

8.3 references "demonstrating need" "under current policies"

"The recipient must demonstrate the need for up to a 24-month supply of IP
address resources under current ARIN policies and sign an RSA."

WRT ISPs "under current policy means" under 4.2.2 and 4.2.2.

which in short says roughly:
For ISP initial:
The ISP must already have at least a /24 from their provider, and
show that the space they are using is efficiently used.

They can then one for one swap their re-allocation for a direct
allocation from ARIN (gotten from ARIN or the transfer market).

If they want more IP space then what they are currently using, they
need to show 3 month [or 24 month for transfers] growth projections
"showing specifically how the requested allocation will be utilized"

For additional ISP space:
They must show 80% utilization, with no blocks less than half full.
"Determination of the appropriate allocation to be issued is based on
efficient utilization of space within this time frame, consistent with the
principles in 4.2.1."

4.2.1 includes slow start.  So if the IP space you need in the next 3 months
[24 months for transfers] is more than what you used in the previous
3 months [24 months for transfers] you get slow started.  That means,
you get double what you had the last 3 months [24 months for transfers],
you use it up, you show utilization, and double again so long as the most
recent space was utilized in less than 3 months [24 months for transfers]

There is quite a lot of teeth in there to prevent abuse.

WRT end-users "under current policy means" under 4.3.3 and 4.3.6.1

For end-user initial:

"Requesters must provide appropriate details to verify their one-year
growth projection. The basic criteria that must be met are:

- 25% immediate utilization rate, and
- 50% utilization rate within one year."
For end-user additional:
They must demonstrate 80% utilization on average, and no block less than
half full, and then use the same initial criteria.

There is no slow-start.  The only thing that limits abuse is the threat
that ARIN
might check for compliance with the requirement to use 25% in 30 days
[60 days for transfers].

Without this check you are free to make any wildly optimistic plan that
supports a wildly optimistic growth projection and then in two years time
simply say "plans changed.  We are still going to that, but over 10 years
instead."

This easily becomes:
1. make a wildly optimistic plan,
2. officer attest to it,
3. end-run around need.

Which is nearly 2015-7 for end-users which is:
1. officer attest to the statement we think we might need X in the next 2
years
2. end-run around need.

I maintain that the 30 day check has been useful in mitigating abusively
large
requests, and without it there is no teeth in the policy to prevent abuse.

If I am wrong about this, please explain what mechanisms are in place to
mitigate
an end-user asking for approval for a 10 year supply of addresses on the
grounds
that if things go really really well, it will only be a 2 year supply?

If I am not wrong about this, then did people realize that this policy is
basically an
end-run around giving out addresses based on need when they voted to move
this
policy forward?

___Jason


> > I am not confusing it with 2015-7: Simplified requirements for
> demonstrated
> > need for IPv4 transfers.  I believe 2015-7 would result in two changes,
> 1.
> > lowering the bar for ISP to match what end users need in 2015-3, and 2.
> > removing any demonstration of current utilization (and by extension
> > demonstration that you can and are properly managing the space you have)
> for
> > both ISPs and end users.
> >
> > I can see where there could be some confusion as I have the same concern
> for
> > both proposals, that there needs to be some tangible verifiable claim.
>
> Thanks for clarifying.
>
> ...
> --
> ===============================================
> 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
> ===============================================
>



-- 
_______________________________________________________
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/20160505/884139f7/attachment.htm>

From owen at delong.com  Thu May  5 15:11:49 2016
From: owen at delong.com (Owen DeLong)
Date: Thu, 5 May 2016 12:11:49 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
	Policy
In-Reply-To: <32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
Message-ID: <313F0B8E-E928-479F-B338-30AFFF77F82F@delong.com>

Speaking strictly for myself and not as a member of the AC?

I still fail to see the need for this. Here are the scenarios I can see:

1.	Transfer of an operating environment to a new organization through merger/acquisition/reorg:

		This would be handled in 8.2 and there is no restriction on these blocks in 8.2
		transfers.

2.	Creation of a new operational environment which needs resources and qualifies:

		Since these reserved pools still have resources available, I see no reason to support
		their transfer through 8.3 or 8.4.

I think the proposed change would be mostly harmless, but I also feel that it serves no useful purpose and would complicate policy unnecessarily.

Further, unlike larger blocks of resources, these blocks are assigned in very small chunks and for a very specific purpose. Once that purpose no longer exists, their return should be straightforward and we as a community should be able to expect voluntary return of these addresses as they cannot be monetized, cannot be transferred, and cannot be repurposed. (At least not without violating policy).

Owen

> On May 5, 2016, at 07:59 , Andrew Dul <andrew.dul at quark.net> wrote:
> 
> Hello,
> 
> As part of the discussions at ARIN 37 the community considered updates to the proposed draft policy that would allow organizations to transfer, within ARIN, reserved pool resources provided that they met the criteria to obtain a block from a reserved pool. 
> Based upon this feedback we are proposing to update the draft policy text as follows.  The AC welcomes your feedback on this proposed text and any other feedback on this draft policy.
> 
> Thanks,
> 
> Andrew
> 
> Original Policy statement:
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the transfer:"
> 
> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.
> 
> Updated Policy statement:
> 
> Add to Section 8.3 under the "Conditions on recipient of the transfer:"
> 
> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) shall only be transferred to organizations which meet the current criteria of the reserved pool from which the resource was obtained.
> 
> Add to Section 8.4 under the "Conditions on source of the transfer:"
> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.
> 
> _______________________________________________
> PPML
> You are receiving this message 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/20160505/1bc65da5/attachment.htm>

From jschiller at google.com  Thu May  5 16:09:38 2016
From: jschiller at google.com (Jason Schiller)
Date: Thu, 5 May 2016 16:09:38 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
	Policy
In-Reply-To: <CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
Message-ID: <CAC4yj2Uqm+xAfzXMEbXduo8rLsq-k12KsOcPaO5wf49Pj_Fnew@mail.gmail.com>

I would go s far as to direct ARIN staff to provide provisional approval.
The process would look like this:

Customer: ARIN, I have a /16.  I am currently using 200 IPs as documented
below.
I would be willing to sell my /16 and replace it with a /24 if I can be
assured that I
will be approved to get a /24.

ARIN: based on your current utilization you are pre-approved to transfer a
/24
on the condition that no longer hold the /16 and your utilization as
reported
remains unchanged.


The customer could then go off and sell the /16 contingent on buying a /24
and transferring it.  Buy the /24, renumber into the /24 and then submit
matching
transfer requests requesting the transfer of the /16 to the recipient which
should
be held up until the transfer of a /24 from the source is also approved.

(I think of this like the complicated kidney donation surgeries)

I don't think we need policy for this, just the AC to advice ARIN on
the fact that this behavior is not prohibited under policy, and is what
the community desires ARIN to do in this situation.

I do not think ARIN should maintain a pool for this.

I would support ARIN holding a transfer in escrow, but I think it is
unlikely
that a party is willing to number out of their space, be down, and then get
new space and be back up, so I don't see this being useful.

___Jason

On Tue, Apr 19, 2016 at 9:18 PM, Gary Buhrmaster <gary.buhrmaster at gmail.com>
wrote:

> On Mon, Apr 11, 2016 at 5:43 PM, Owen DeLong <owen at delong.com> wrote:
> ....
> > I?d be OK with this, but given that there is remaining free pool for
> these resources, I?m not sure that it isn?t better to have a clear policy
> that when the resources in these categories are no longer needed, voluntary
> return to ARIN is expected.
>
> On Monday, there was discussion (during policy experience report)
> about ARIN not being able to provide "theoretical" pre-qualifications
> in the case where (in the example) you transfer a /16 to someone,
> and would want to get a /24 from somewhere else.  And while most
> steeped in the ARIN process understand that qualifying is an almost
> certainty, that does not take it to the level some seem to need to feel
> entirely comfortable.
>
> As far as this proposal, I can imagine there to be cases were a transfer
> may only make sense if the receiving org can be assured that they will
> be able to get the IP numbers from a reserved pool which ARIN cannot
> make assurance on in advance.  And while (as before) everyone may be
> (almost) 100% sure that the recipient will qualify, that does not always
> make everyone sufficiently comfortable.
>
> It would seem to be nice for a 8.3 transfer which happens to include
> reserved pool space not turn into another policy experience report
> bullet for not being able to successfully transfer (worst case?) "CI"
> space if indeed the recipient would otherwise qualify (and potentially
> force a renumber of such resources for no particular policy reason).
>
> I do agree with Owen that these cases are unlikely.  And regardless
> of whether the (what I think is) better language as proposed by Scott
> is included, I would support the policy moving forward to address
> the problem statement.
> _______________________________________________
> PPML
> You are receiving this message 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/20160505/02ade952/attachment.htm>

From narten at us.ibm.com  Fri May  6 00:53:02 2016
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 06 May 2016 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201605060453.u464r2Ei029106@rotala.raleigh.ibm.com>

Total of 7 messages in the last 7 days.
 
script run at: Fri May  6 00:53:02 EDT 2016
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 28.57% |    2 | 41.82% |    38732 | jschiller at google.com
 28.57% |    2 | 24.90% |    23058 | farmer at umn.edu
 14.29% |    1 | 15.01% |    13906 | owen at delong.com
 14.29% |    1 | 10.89% |    10083 | andrew.dul at quark.net
 14.29% |    1 |  7.38% |     6837 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    7 |100.00% |    92616 | Total



From owen at delong.com  Fri May  6 02:50:35 2016
From: owen at delong.com (Owen DeLong)
Date: Thu, 5 May 2016 23:50:35 -0700
Subject: [arin-ppml] Pre approvals for transfer-in-kind transactions
Message-ID: <54AC5E4A-B6D5-4C67-9C62-50C3B7F15ED5@delong.com>

Before this goes too far down the road under a misleading subject, I?ll
politely request that people use the above subject as a new thread instead of
continuing to post under 2016-1.

Thanks,

Owen

> On May 5, 2016, at 13:09 , Jason Schiller <jschiller at google.com> wrote:
> 
> I would go s far as to direct ARIN staff to provide provisional approval.  
> The process would look like this:
> 
> Customer: ARIN, I have a /16.  I am currently using 200 IPs as documented below.  
> I would be willing to sell my /16 and replace it with a /24 if I can be assured that I 
> will be approved to get a /24.
> 
> ARIN: based on your current utilization you are pre-approved to transfer a /24 
> on the condition that no longer hold the /16 and your utilization as reported 
> remains unchanged.  
> 
> 
> The customer could then go off and sell the /16 contingent on buying a /24 
> and transferring it.  Buy the /24, renumber into the /24 and then submit matching 
> transfer requests requesting the transfer of the /16 to the recipient which should 
> be held up until the transfer of a /24 from the source is also approved.  
> 
> (I think of this like the complicated kidney donation surgeries) 
> 
> I don't think we need policy for this, just the AC to advice ARIN on 
> the fact that this behavior is not prohibited under policy, and is what
> the community desires ARIN to do in this situation.
> 
> I do not think ARIN should maintain a pool for this.
> 
> I would support ARIN holding a transfer in escrow, but I think it is unlikely 
> that a party is willing to number out of their space, be down, and then get 
> new space and be back up, so I don't see this being useful.
> 
> ___Jason
> 
> On Tue, Apr 19, 2016 at 9:18 PM, Gary Buhrmaster <gary.buhrmaster at gmail.com <mailto:gary.buhrmaster at gmail.com>> wrote:
> On Mon, Apr 11, 2016 at 5:43 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
> ....
> > I?d be OK with this, but given that there is remaining free pool for these resources, I?m not sure that it isn?t better to have a clear policy that when the resources in these categories are no longer needed, voluntary return to ARIN is expected.
> 
> On Monday, there was discussion (during policy experience report)
> about ARIN not being able to provide "theoretical" pre-qualifications
> in the case where (in the example) you transfer a /16 to someone,
> and would want to get a /24 from somewhere else.  And while most
> steeped in the ARIN process understand that qualifying is an almost
> certainty, that does not take it to the level some seem to need to feel
> entirely comfortable.
> 
> As far as this proposal, I can imagine there to be cases were a transfer
> may only make sense if the receiving org can be assured that they will
> be able to get the IP numbers from a reserved pool which ARIN cannot
> make assurance on in advance.  And while (as before) everyone may be
> (almost) 100% sure that the recipient will qualify, that does not always
> make everyone sufficiently comfortable.
> 
> It would seem to be nice for a 8.3 transfer which happens to include
> reserved pool space not turn into another policy experience report
> bullet for not being able to successfully transfer (worst case?) "CI"
> space if indeed the recipient would otherwise qualify (and potentially
> force a renumber of such resources for no particular policy reason).
> 
> I do agree with Owen that these cases are unlikely.  And regardless
> of whether the (what I think is) better language as proposed by Scott
> is included, I would support the policy moving forward to address
> the problem statement.
> _______________________________________________
> 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160505/d314dfac/attachment.htm>

From elvis at velea.eu  Fri May  6 05:58:29 2016
From: elvis at velea.eu (Elvis Daniel Velea)
Date: Fri, 6 May 2016 12:58:29 +0300
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
Message-ID: <572C6AC5.9080907@velea.eu>

I support the policy proposal as written.

regards,
elvis

On 5/5/16 6:45 PM, David Farmer wrote:
> As shepherd for this policy I welcome any additional last call
> feedback for this policy.  It is especially important to speak up if
> you feel there are any issues remaining that need to be considered.
> But, even if you simply support the policy as written that is
> important and useful feedback as well.
>
> The last call period formally continues through, Monday, May 9th, and
> the AC will consider the feedback during its scheduled call on
> Thursday, May 19th.
>
> Thanks
>
> On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net> wrote:
>> The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
>> send the following to last call:
>>
>>    Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
>> requirement in end-user IPv4 policy
>>
>> Feedback is encouraged during the last call period. All comments should
>> be provided to the Public Policy Mailing List. This last call will
>> expire on 9 May 2016. After last call the AC will conduct their
>> last call review.
>>
>> The draft policy text is below and available at:
>> https://www.arin.net/policy/proposals/
>>
>> The ARIN Policy Development Process is available at:
>> https://www.arin.net/policy/pdp.html
>>
>> Regards,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Recommended Draft Policy ARIN-2015-3
>> Remove 30 day utilization requirement in end-user IPv4 policy
>>
>> AC's assessment of conformance with the Principles of Internet Number
>> Resource Policy:
>>
>> ARIN 2015-3 contributes to fair and impartial number resource administration
>> by removing from the NRPM text that is operationally unrealistic for the
>> reasons discussed in the problem statement. This proposal is technically
>> sound, in that the removal of the text will more closely align with the way
>> staff applies the existing policy in relation to 8.3 transfers. There was
>> strong community support for the policy on PPML and at ARIN 36, which was
>> confirmed at ARIN 37. There was a suggestion to replace this text with an
>> alternate requirement. However, the community consensus was to move forward
>> with the removal alone.
>>
>> The staff and legal review also suggested removing RFC2050 references and
>> pointed out that 4.2.3.6 has an additional 25% immediate use clause,
>> community feedback was to deal with those issues separately.
>>
>> Problem Statement:
>>
>> End-user policy is intended to provide end-users with a one year supply of
>> IP addresses. Qualification for a one-year supply requires the network
>> operator to utilize at least 25% of the requested addresses within 30 days.
>> This text is unrealistic and should be removed.
>>
>> First, it often takes longer than 30 days to stage equipment and start
>> actually using the addresses.
>>
>> Second, growth is often not that regimented; the forecast is to use X
>> addresses over the course of a year, not to use 25% of X within 30 days.
>>
>> Third, this policy text applies to additional address space requests. It is
>> incompatible with the requirements of other additional address space request
>> justification which indicates that 80% utilization of existing space is
>> sufficient to justify new space. If a block is at 80%, then often (almost
>> always?) the remaining 80% will be used over the next 30 days and longer.
>> Therefore the operator cannot honestly state they will use 25% of the
>> ADDITIONAL space within 30 days of receiving it; they're still trying to use
>> their older block efficiently.
>>
>> Fourth, in the face of ARIN exhaustion, some ISPs are starting to not give
>> out /24 (or larger) blocks. So the justification for the 25% rule that
>> previously existed (and in fact, applied for many years) is no longer
>> germane.
>>
>> Policy statement:
>>
>> Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
>>
>> Resulting text:
>>
>> 4.3.3. Utilization rate
>>
>> Utilization rate of address space is a key factor in justifying a new
>> assignment of IP address space. Requesters must show exactly how previous
>> address assignments have been utilized and must provide appropriate details
>> to verify their one-year growth projection.
>>
>> The basic criterion that must be met is a 50% utilization rate within one
>> year.
>>
>> A greater utilization rate may be required based on individual network
>> requirements. Please refer to RFC 2050 for more information on utilization
>> guidelines.
>>
>> Comments:
>>
>> a.Timetable for implementation: Immediate
>>
>> b.Anything else
>>
>> #####
>>
>> ARIN STAFF ASSESSMENT
>>
>> Draft Policy ARIN-2015-3
>> Remove 30 day utilization requirement in end-user IPv4 policy
>> Date of Assessment: 16 February 2016
>>
>> ___
>> 1. Summary (Staff Understanding)
>>
>> This proposal would remove the 25% utilization (within 30 days of issuance)
>> criteria bullet point from NRPM 4.3.3.
>>
>> ___
>> 2. Comments
>>
>> A. ARIN Staff Comments
>> This policy would more closely align with the way staff applies the existing
>> policy in relation to 8.3 transfers. Because there is no longer an IPv4 free
>> pool and many IPv4 requests are likely to be satisfied by 8.3 transfers, the
>> adoption of this policy should have no major impact on operations and could
>> be implemented as written.
>>
>> Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to obsolete
>> RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within 30
>> days of issuance) requirement.
>>
>> Staff suggests removing the first two sentences of 4.2.3.6 to remove the
>> references to RFC 2050 and the 25% requirement. Additionally, staff suggests
>> removing the reference to the obsolete RFC 2050 in section 4.3.3.
>>
>> B. ARIN General Counsel ? Legal Assessment
>> No material legal risk in this policy.
>>
>> ___
>> 3. Resource Impact
>>
>> This policy would have minimal resource impact from an implementation
>> aspect. It is estimated that implementation would occur immediately after
>> ratification by the ARIN Board of Trustees. The following would be needed in
>> order to implement:
>> * Updated guidelines and internal procedures
>> * Staff training
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
>



From bill at herrin.us  Fri May  6 10:53:04 2016
From: bill at herrin.us (William Herrin)
Date: Fri, 6 May 2016 10:53:04 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
Message-ID: <CAP-guGXYUCsiVdg=R0d33xYc4ZL-EuE5hGk7qBHQB5UtGtjWkQ@mail.gmail.com>

On Thu, May 5, 2016 at 11:45 AM, David Farmer <farmer at umn.edu> wrote:
> As shepherd for this policy I welcome any additional last call
> feedback for this policy.  It is especially important to speak up if
> you feel there are any issues remaining that need to be considered.
> But, even if you simply support the policy as written that is
> important and useful feedback as well.

Hi David,

My read is that we retain just enough teeth in "justified need" that
ARIN can revoke if someone starts "flipping" addresses. Unless of
course they smuggle the addresses outregion before ARIN catches on.
The documentation process becomes functionally unverifiable until the
registrant takes a public contrary action. We then let the external
cost of transfers take primary responsibility for discouraging
inappropriate requests.

Is that about the size of it?

I worry about unintended interactions with the outregion transfer
policy. Gets slippery if a non-practicing entity can set up in the
middle.

Regards,
Bill Herrin


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


From scottleibrand at gmail.com  Fri May  6 11:04:25 2016
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 6 May 2016 15:04:25 +0000 (UTC)
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <572C6AC5.9080907@velea.eu>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<572C6AC5.9080907@velea.eu>
Message-ID: <EF501E8D91217774.99851A55-5A88-451D-A447-C2C246405125@mail.outlook.com>

+1 - I support as written.?

-Scott

    _____________________________
From: Elvis Daniel Velea <elvis at velea.eu>
Sent: Friday, May 6, 2016 4:25 AM
Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy
To:  <arin-ppml at arin.net>


I support the policy proposal as written.

regards,
elvis

On 5/5/16 6:45 PM, David Farmer wrote:
> As shepherd for this policy I welcome any additional last call
> feedback for this policy.  It is especially important to speak up if
> you feel there are any issues remaining that need to be considered.
> But, even if you simply support the policy as written that is
> important and useful feedback as well.
>
> The last call period formally continues through, Monday, May 9th, and
> the AC will consider the feedback during its scheduled call on
> Thursday, May 19th.
>
> Thanks
>
> On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net> wrote:
>> The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
>> send the following to last call:
>>
>>    Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
>> requirement in end-user IPv4 policy
>>
>> Feedback is encouraged during the last call period. All comments should
>> be provided to the Public Policy Mailing List. This last call will
>> expire on 9 May 2016. After last call the AC will conduct their
>> last call review.
>>
>> The draft policy text is below and available at:
>> https://www.arin.net/policy/proposals/
>>
>> The ARIN Policy Development Process is available at:
>> https://www.arin.net/policy/pdp.html
>>
>> Regards,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Recommended Draft Policy ARIN-2015-3
>> Remove 30 day utilization requirement in end-user IPv4 policy
>>
>> AC's assessment of conformance with the Principles of Internet Number
>> Resource Policy:
>>
>> ARIN 2015-3 contributes to fair and impartial number resource administration
>> by removing from the NRPM text that is operationally unrealistic for the
>> reasons discussed in the problem statement. This proposal is technically
>> sound, in that the removal of the text will more closely align with the way
>> staff applies the existing policy in relation to 8.3 transfers. There was
>> strong community support for the policy on PPML and at ARIN 36, which was
>> confirmed at ARIN 37. There was a suggestion to replace this text with an
>> alternate requirement. However, the community consensus was to move forward
>> with the removal alone.
>>
>> The staff and legal review also suggested removing RFC2050 references and
>> pointed out that 4.2.3.6 has an additional 25% immediate use clause,
>> community feedback was to deal with those issues separately.
>>
>> Problem Statement:
>>
>> End-user policy is intended to provide end-users with a one year supply of
>> IP addresses. Qualification for a one-year supply requires the network
>> operator to utilize at least 25% of the requested addresses within 30 days.
>> This text is unrealistic and should be removed.
>>
>> First, it often takes longer than 30 days to stage equipment and start
>> actually using the addresses.
>>
>> Second, growth is often not that regimented; the forecast is to use X
>> addresses over the course of a year, not to use 25% of X within 30 days.
>>
>> Third, this policy text applies to additional address space requests. It is
>> incompatible with the requirements of other additional address space request
>> justification which indicates that 80% utilization of existing space is
>> sufficient to justify new space. If a block is at 80%, then often (almost
>> always?) the remaining 80% will be used over the next 30 days and longer.
>> Therefore the operator cannot honestly state they will use 25% of the
>> ADDITIONAL space within 30 days of receiving it; they're still trying to use
>> their older block efficiently.
>>
>> Fourth, in the face of ARIN exhaustion, some ISPs are starting to not give
>> out /24 (or larger) blocks. So the justification for the 25% rule that
>> previously existed (and in fact, applied for many years) is no longer
>> germane.
>>
>> Policy statement:
>>
>> Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
>>
>> Resulting text:
>>
>> 4.3.3. Utilization rate
>>
>> Utilization rate of address space is a key factor in justifying a new
>> assignment of IP address space. Requesters must show exactly how previous
>> address assignments have been utilized and must provide appropriate details
>> to verify their one-year growth projection.
>>
>> The basic criterion that must be met is a 50% utilization rate within one
>> year.
>>
>> A greater utilization rate may be required based on individual network
>> requirements. Please refer to RFC 2050 for more information on utilization
>> guidelines.
>>
>> Comments:
>>
>> a.Timetable for implementation: Immediate
>>
>> b.Anything else
>>
>> #####
>>
>> ARIN STAFF ASSESSMENT
>>
>> Draft Policy ARIN-2015-3
>> Remove 30 day utilization requirement in end-user IPv4 policy
>> Date of Assessment: 16 February 2016
>>
>> ___
>> 1. Summary (Staff Understanding)
>>
>> This proposal would remove the 25% utilization (within 30 days of issuance)
>> criteria bullet point from NRPM 4.3.3.
>>
>> ___
>> 2. Comments
>>
>> A. ARIN Staff Comments
>> This policy would more closely align with the way staff applies the existing
>> policy in relation to 8.3 transfers. Because there is no longer an IPv4 free
>> pool and many IPv4 requests are likely to be satisfied by 8.3 transfers, the
>> adoption of this policy should have no major impact on operations and could
>> be implemented as written.
>>
>> Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to obsolete
>> RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within 30
>> days of issuance) requirement.
>>
>> Staff suggests removing the first two sentences of 4.2.3.6 to remove the
>> references to RFC 2050 and the 25% requirement. Additionally, staff suggests
>> removing the reference to the obsolete RFC 2050 in section 4.3.3.
>>
>> B. ARIN General Counsel ? Legal Assessment
>> No material legal risk in this policy.
>>
>> ___
>> 3. Resource Impact
>>
>> This policy would have minimal resource impact from an implementation
>> aspect. It is estimated that implementation would occur immediately after
>> ratification by the ARIN Board of Trustees. The following would be needed in
>> order to implement:
>> * Updated guidelines and internal procedures
>> * Staff training
>> _______________________________________________
>> PPML
>> You are receiving this message 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/20160506/7b70f9da/attachment.htm>

From gary.buhrmaster at gmail.com  Fri May  6 16:58:30 2016
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Fri, 6 May 2016 20:58:30 +0000
Subject: [arin-ppml] Pre approvals for transfer-in-kind transactions
In-Reply-To: <54AC5E4A-B6D5-4C67-9C62-50C3B7F15ED5@delong.com>
References: <54AC5E4A-B6D5-4C67-9C62-50C3B7F15ED5@delong.com>
Message-ID: <CAMfXtQwjpA+7xhqDvqH6PGHKxO+web4W0OCgj2WQ1Zz+VExGWw@mail.gmail.com>

On Fri, May 6, 2016 at 6:50 AM, Owen DeLong <owen at delong.com> wrote:
....
> On May 5, 2016, at 13:09 , Jason Schiller <jschiller at google.com> wrote:
>
> I would go s far as to direct ARIN staff to provide provisional approval.
> The process would look like this:
>
> Customer: ARIN, I have a /16.  I am currently using 200 IPs as documented
> below.
> I would be willing to sell my /16 and replace it with a /24 if I can be
> assured that I
> will be approved to get a /24.
>
> ARIN: based on your current utilization you are pre-approved to transfer a
> /24
> on the condition that no longer hold the /16 and your utilization as
> reported
> remains unchanged.

I think this might be a reasonably thing for ARIN to offer to its
member orgs where the resources (the /16 in this example)
are already under an appropriate RSA (so the association
with the resources has already been established).
[membership has its privileges?]

Allowing a random request off the street to utilize ARIN staff
resources for hypothetical future transfer evaluations, I am
not sure I would be in favor of.


From bill at herrin.us  Fri May  6 17:18:44 2016
From: bill at herrin.us (William Herrin)
Date: Fri, 6 May 2016 17:18:44 -0400
Subject: [arin-ppml] Pre approvals for transfer-in-kind transactions
In-Reply-To: <54AC5E4A-B6D5-4C67-9C62-50C3B7F15ED5@delong.com>
References: <54AC5E4A-B6D5-4C67-9C62-50C3B7F15ED5@delong.com>
Message-ID: <CAP-guGX35TbdqdOJ7sNGmUigG1fdup=sjGc-PDLDfkQby_KPsQ@mail.gmail.com>

> On May 5, 2016, at 13:09 , Jason Schiller <jschiller at google.com> wrote:
> ARIN: based on your current utilization you are pre-approved to transfer a
> /24
> on the condition that no longer hold the /16 and your utilization as
> reported
> remains unchanged.

Hi Jason,

At the moment, the org could "buy" the /24 with the provision that
they'll take possession, update POCs and announce it via BGP
immediately but the seller will hold the registration until ARIN
transfer is approved. Right? They then renumber, sell and transfer the
/16 and then ask ARIN to transfer the /24 on the basis that they have
no IP addresses (having disposed of the unnecessarily large block) and
have actual control of the requested block anyway.

Why would ARIN need to fiddle with conditional approvals and uncertain
timelines for the renumbering dance?

Regards,
Bill Herrin


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


From jcurran at arin.net  Sat May  7 07:15:27 2016
From: jcurran at arin.net (John Curran)
Date: Sat, 7 May 2016 11:15:27 +0000
Subject: [arin-ppml] ARIN-2015-3:(remove 30-day...) Staff interpretation
 needed
In-Reply-To: <CAC4yj2Wi8Dac+5EK83W=STcz67fUCdTDqsKgHW6GdzgHkar+9w@mail.gmail.com>
References: <CAN-Dau2TiyphbwW3c-wLCKgEJuBpcWsJQEi3c6dq6aBomvA92Q@mail.gmail.com>
	<CAC4yj2Wi8Dac+5EK83W=STcz67fUCdTDqsKgHW6GdzgHkar+9w@mail.gmail.com>
Message-ID: <F6FC2137-92BA-41D2-AC0F-F7A97FFD3E25@corp.arin.net>

On Apr 25, 2016, at 12:47 PM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>> wrote:
...
I suspect the 30 days part does (to some extent) regulate outrageously large claims, as this is a real short term verifiable commitment.  Without a possibility of a 30 day check you simply fall back to an officer attestation of a two year projected need claim.

I am trying to figure out what is the likely impact of only requiring a two year projected need claim.  So my questions are regarding to what level of push back ARIN provides against two year projected need in general, and will that be sufficient to prevent outlandishly large claims.

Maybe another way to get at this is to compare end user transfer stats to ISP transfer stats.
- what percentage of ISP specified transfers are justified by past growth?  by a two year projection?
- what percentage of end user specified transfers are justified by past growth?  by a two year projection?
- what is the average size of ISP specified transfers that are justified by past growth?  by a two year projection?
- what is the average size of end user specified transfers that are justified by past growth?  by a two year projection?
- do we see a greater gap between average ISP size between specified transfers that are justified by past growth vs. by a two year projection?
- do we see a greater percentage of ISP transfers justified by a 2 year projection than end users?

Jason -

    While we dp collect statistics on the number of requests and outcomes, we do
    not have the instrumentation of the needs-assessment process that would be
    necessary to produce the type of statistics you request.  It is also not clear that
    such instrumentation would allow us to provide an exact percentage of requests
    that are approved based on past growth vs. projections because ARIN takes
    both factors into account when evaluating operational need.

    In order to provide some insight into how the needs-assessment process operates
    with respect to past growth versus projection, we?ve provided several examples on
    how the needs-assessment process would unfold for various 8.3 specified transfer
    scenarios detailed below.

    When an existing ARIN account, ISP or End-User, requests an 8.3 Recipient
    Transfer, ARIN will look at their historical utilization and determine the organizations
    average 24-month usage trend.  We will compare that to what they are currently
    requesting to have transferred and determine if that amount aligns with their prior
    utilization trend. If it does align directly, then we consider that the justification for
    their 24-month stated need, but often we have to also give some consideration to
    the information they provide regarding future plans and potential impact on growth
    rate.

=== Example A
An existing ARIN Organization requests a /16 transfer via 8.3 transfer process.
They previously received the following IPv4 address space:
/17 in December 2015
/17 in October 2015
/18 in July 2015
/19 in June 2015
/20 in May 2015
/20 in February 2015

In this example, ARIN would request 24-month projections AND utilization information from the organization. We would verify they have utilized their previously received IPv4 blocks in accordance with policy and determine their utilization trend. In this example, the organization has fully utilized their previous allocations and we note their historical utilization of 384 /24s over the past 18 months. Even though we are also taking their future plans into consideration, their prior utilization trend is heavily weighted in justifying the newly requested /16 and they are approved. Their prior 24 months of utilization exceeds what they are requesting for the next 24 months.

=== Example B
An existing ARIN Organization requests a /16 transfer via 8.3 transfer process.
They previously received the following IPv4 address space:
/19 in December 2015
/20 in October 2015
/21 in July 2015
/22 in June 2015
/23 in May 2015

In this example, ARIN would again request 24-month projections AND utilization information from the organization.  We would verify they have utilized their previously received IPv4 blocks in accordance with policy and determine their utilization trend.  In this example, the organization has fully utilized their previous allocations and we note their historical utilization trend of 62 /24s over the past 11 months. Their prior utilization suggests a utilization trend of 136 /24s over a 24-month period (62 / 11 * 24mos = 135.3 or 136).  The organization?s 24-month utilization trend does not meet or exceed the amount of IPv4 address space they are requesting for the next 24-month period, so the information they provide regarding their future plans/need is more heavily weighted by ARIN staff. The information provided regarding future need paired with their utilization trend allows for an approval for the requested size (/16).

=== Example C
An existing ARIN Organization requests a /16 transfer via 8.3 transfer process.

Without providing the further background details, the requesting organization in this example has utilized their previously received blocks in accordance with policy and has a 24-month utilization trend of 65 /24s. The organization?s 24-month utilization trend does not meet or exceed the amount of IPv4 address space they are requesting for the next 24-month period, so the information they provide regarding their future plans/need is more heavily weighted by ARIN staff. The future need projections only slightly increase expected future utilization over their prior utilization trend and a need for 100 /24s is determined for the next 24-month period. Unfortunately, the information provided regarding future need paired with their utilization trend does not allow for the approval of the requested /16, and a /17 (closest prefix size above their demonstrated need amount) is approved instead.
===

   Similarly, if a new organization comes to ARIN for an 8.3 Recipient Transfer we
   would base their approval on any provider assigned space they are currently using
   and their projections. We would do this similar to the examples noted above.

   It is important to note that if a new organization comes to ARIN and isn't using any
   provider assigned space, we are only be able to base their approval amounts based
   on their projections.

   When we ask organization for their forward projections, we also ask them to provide
   details to show how they've arrived at their projections. We take into account factors
   such as new networks, locations, products, services they plan on offering (and this
   includes consideration of anticipated address utilization within the first 30 days for
   end-users.)

   Given we take all of these factors into account (and noting that we don?t precisely track if
   they qualified more heavily on historical usage vs. projections), we would estimate between
   50-75% of the approval decisions made are more heavily weighted by historical utilization
   trend information. It is important to note that the historical utilization trend information often
   allows for an approval size equal to or greater than what is requested by most organizations.

While this is not the level of detail that you desire, I hope it provides some useful insight
into the role of the future projections in the needs-assessment process.

Best wishes on your policy development efforts!
/John

John Curran
President and CEO
ARIN




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

From michael at linuxmagic.com  Sun May  8 18:55:11 2016
From: michael at linuxmagic.com (Michael Peddemors)
Date: Sun, 8 May 2016 15:55:11 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
 Policy
In-Reply-To: <CAC4yj2Uqm+xAfzXMEbXduo8rLsq-k12KsOcPaO5wf49Pj_Fnew@mail.gmail.com>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<CAC4yj2Uqm+xAfzXMEbXduo8rLsq-k12KsOcPaO5wf49Pj_Fnew@mail.gmail.com>
Message-ID: <572FC3CF.1050800@linuxmagic.com>

On 16-05-05 01:09 PM, Jason Schiller wrote:
> I would go s far as to direct ARIN staff to provide provisional approval.
> The process would look like this:
>
> Customer: ARIN, I have a /16.  I am currently using 200 IPs as
> documented below.
> I would be willing to sell my /16 and replace it with a /24 if I can be
> assured that I
> will be approved to get a /24.
>

That probably isn't a good example, if the person is only using 200 
IP(s) from a /16, ARIN should recover the unused IP(s)..

ARIN could in that case recover most of it, and leave him with a /22 for 
instance..


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

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


From cblecker at gmail.com  Sun May  8 21:23:55 2016
From: cblecker at gmail.com (Christoph Blecker)
Date: Sun, 8 May 2016 18:23:55 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
	Policy
In-Reply-To: <313F0B8E-E928-479F-B338-30AFFF77F82F@delong.com>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
	<313F0B8E-E928-479F-B338-30AFFF77F82F@delong.com>
Message-ID: <CADx2oGF2mNJk53o0cnqJtZp=BxVvFhQFrc2N=dfsZ+FdoPQO6Q@mail.gmail.com>

I can't quite imagine a scenario that would merit an 8.3 transfer of
reserved pool IP space. I think the community is better served to encourage
reserved pool address holders to return the space back to the reserved pool
if the need they originally requested the address space for no longer
exists. As such, I prefer the original policy text.

I'd be open to changing my opinion if someone could explain a scenario
where an 8.3 transfer is preferable to requesting space from the free pool.

Cheers,
Christoph

On 5 May 2016 at 12:11, Owen DeLong <owen at delong.com> wrote:

> Speaking strictly for myself and not as a member of the AC?
>
> I still fail to see the need for this. Here are the scenarios I can see:
>
> 1. Transfer of an operating environment to a new organization through
> merger/acquisition/reorg:
>
> This would be handled in 8.2 and there is no restriction on these blocks
> in 8.2
> transfers.
>
> 2. Creation of a new operational environment which needs resources and
> qualifies:
>
> Since these reserved pools still have resources available, I see no reason
> to support
> their transfer through 8.3 or 8.4.
>
> I think the proposed change would be mostly harmless, but I also feel that
> it serves no useful purpose and would complicate policy unnecessarily.
>
> Further, unlike larger blocks of resources, these blocks are assigned in
> very small chunks and for a very specific purpose. Once that purpose no
> longer exists, their return should be straightforward and we as a community
> should be able to expect voluntary return of these addresses as they cannot
> be monetized, cannot be transferred, and cannot be repurposed. (At least
> not without violating policy).
>
> Owen
>
> On May 5, 2016, at 07:59 , Andrew Dul <andrew.dul at quark.net> wrote:
>
> Hello,
>
> As part of the discussions at ARIN 37 the community considered updates to
> the proposed draft policy that would allow organizations to transfer,
> within ARIN, reserved pool resources provided that they met the criteria to
> obtain a block from a reserved pool.
>
> Based upon this feedback we are proposing to update the draft policy text
> as follows.  The AC welcomes your feedback on this proposed text and any
> other feedback on this draft policy.
>
> Thanks,
>
> Andrew
>
>
> *Original** Policy statement:*
>
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
> transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> *Updated **Policy statement:*
>
> Add to Section 8.3 under the "Conditions on recipient of the transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) shall only be transferred to organizations which meet
> the current criteria of the reserved pool from which the resource was
> obtained.
> Add to Section 8.4 under the "Conditions on source of the transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
> _______________________________________________
> PPML
> You are receiving this message 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/20160508/d61e7723/attachment.htm>

From lists at mtin.net  Sun May  8 23:02:19 2016
From: lists at mtin.net (Justin Wilson)
Date: Sun, 8 May 2016 23:02:19 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
	Policy
In-Reply-To: <CADx2oGF2mNJk53o0cnqJtZp=BxVvFhQFrc2N=dfsZ+FdoPQO6Q@mail.gmail.com>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
	<313F0B8E-E928-479F-B338-30AFFF77F82F@delong.com>
	<CADx2oGF2mNJk53o0cnqJtZp=BxVvFhQFrc2N=dfsZ+FdoPQO6Q@mail.gmail.com>
Message-ID: <B7BF00F0-BA78-49B3-8E42-208EF2DC9B92@mtin.net>

The key will be making it where it can not be monetized.  It?s like Real Estate and have to approach it like eminent domain.   I think it becomes a very slippery slope. IP space, has become an monetary asset to the company.  If you remove the ability to capitalize on that unused space, you still need a mechanism for forcing it?s return.


Justin Wilson
j2sw at mtin.net

---
http://www.mtin.net Owner/CEO
xISP Solutions- Consulting ? Data Centers - Bandwidth

http://www.midwest-ix.com  COO/Chairman
Internet Exchange - Peering - Distributed Fabric

> On May 8, 2016, at 9:23 PM, Christoph Blecker <cblecker at gmail.com> wrote:
> 
> I can't quite imagine a scenario that would merit an 8.3 transfer of reserved pool IP space. I think the community is better served to encourage reserved pool address holders to return the space back to the reserved pool if the need they originally requested the address space for no longer exists. As such, I prefer the original policy text.
> 
> I'd be open to changing my opinion if someone could explain a scenario where an 8.3 transfer is preferable to requesting space from the free pool.
> 
> Cheers,
> Christoph
> 
> On 5 May 2016 at 12:11, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
> Speaking strictly for myself and not as a member of the AC?
> 
> I still fail to see the need for this. Here are the scenarios I can see:
> 
> 1.	Transfer of an operating environment to a new organization through merger/acquisition/reorg:
> 
> 		This would be handled in 8.2 and there is no restriction on these blocks in 8.2
> 		transfers.
> 
> 2.	Creation of a new operational environment which needs resources and qualifies:
> 
> 		Since these reserved pools still have resources available, I see no reason to support
> 		their transfer through 8.3 or 8.4.
> 
> I think the proposed change would be mostly harmless, but I also feel that it serves no useful purpose and would complicate policy unnecessarily.
> 
> Further, unlike larger blocks of resources, these blocks are assigned in very small chunks and for a very specific purpose. Once that purpose no longer exists, their return should be straightforward and we as a community should be able to expect voluntary return of these addresses as they cannot be monetized, cannot be transferred, and cannot be repurposed. (At least not without violating policy).
> 
> Owen
> 
>> On May 5, 2016, at 07:59 , Andrew Dul <andrew.dul at quark.net <mailto:andrew.dul at quark.net>> wrote:
>> 
>> Hello,
>> 
>> As part of the discussions at ARIN 37 the community considered updates to the proposed draft policy that would allow organizations to transfer, within ARIN, reserved pool resources provided that they met the criteria to obtain a block from a reserved pool. 
>> Based upon this feedback we are proposing to update the draft policy text as follows.  The AC welcomes your feedback on this proposed text and any other feedback on this draft policy.
>> 
>> Thanks,
>> 
>> Andrew
>> 
>> Original Policy statement:
>> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the transfer:"
>> 
>> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.
>> 
>> Updated Policy statement:
>> 
>> Add to Section 8.3 under the "Conditions on recipient of the transfer:"
>> 
>> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) shall only be transferred to organizations which meet the current criteria of the reserved pool from which the resource was obtained.
>> 
>> Add to Section 8.4 under the "Conditions on source of the transfer:"
>> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.
>> 
>> _______________________________________________
>> 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/20160508/8c71f71c/attachment.htm>

From info at arin.net  Mon May  9 11:43:18 2016
From: info at arin.net (ARIN)
Date: Mon, 09 May 2016 11:43:18 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - April 2016
Message-ID: <5730B016.7050004@arin.net>

On 4/25/16 1:07 PM, ARIN wrote:
 > The AC abandoned 2015-9. 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 20 April 2016 meeting have 
been published:

https://www.arin.net/about_us/ac/ac2016_0420.html

The petition deadline is 16 May 2016.

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)


From owen at delong.com  Mon May  9 15:45:00 2016
From: owen at delong.com (Owen DeLong)
Date: Mon, 9 May 2016 12:45:00 -0700
Subject: [arin-ppml] like kind transfers
In-Reply-To: <572FC3CF.1050800@linuxmagic.com>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<CAC4yj2Uqm+xAfzXMEbXduo8rLsq-k12KsOcPaO5wf49Pj_Fnew@mail.gmail.com>
	<572FC3CF.1050800@linuxmagic.com>
Message-ID: <13B7086B-B5AC-4BA8-87DC-3BD490174AA8@delong.com>

This is a conflating of two different discussions.

The information below is about a new discussion where a resource holder wants to obtain
a smaller block pre-approval prior to transferring out their larger block.

It has nothing to do with 2016-1 or reserved pool addresses.

Owen

> On May 8, 2016, at 15:55 , Michael Peddemors <michael at linuxmagic.com> wrote:
> 
> On 16-05-05 01:09 PM, Jason Schiller wrote:
>> I would go s far as to direct ARIN staff to provide provisional approval.
>> The process would look like this:
>> 
>> Customer: ARIN, I have a /16.  I am currently using 200 IPs as
>> documented below.
>> I would be willing to sell my /16 and replace it with a /24 if I can be
>> assured that I
>> will be approved to get a /24.
>> 
> 
> That probably isn't a good example, if the person is only using 200 IP(s) from a /16, ARIN should recover the unused IP(s)..
> 
> ARIN could in that case recover most of it, and leave him with a /22 for instance..
> 
> 
> -- 
> "Catch the Magic of Linux..."
> ------------------------------------------------------------------------
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> ------------------------------------------------------------------------
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> ------------------------------------------------------------------------
> 604-682-0300 Beautiful British Columbia, Canada
> 
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
> _______________________________________________
> PPML
> You are receiving this message 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 May 10 11:22:36 2016
From: jschiller at google.com (Jason Schiller)
Date: Tue, 10 May 2016 11:22:36 -0400
Subject: [arin-ppml] like kind transfers
In-Reply-To: <13B7086B-B5AC-4BA8-87DC-3BD490174AA8@delong.com>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<CAC4yj2Uqm+xAfzXMEbXduo8rLsq-k12KsOcPaO5wf49Pj_Fnew@mail.gmail.com>
	<572FC3CF.1050800@linuxmagic.com>
	<13B7086B-B5AC-4BA8-87DC-3BD490174AA8@delong.com>
Message-ID: <CAC4yj2XTHsDRhRDzZKg4e2WD9hYN80x_Nz3X8+tn0k_xsQAsWg@mail.gmail.com>

Yes, as Owen points out this is a separate discussion, and should have it's
own thread.

on the "[arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
Policy" thread
gary.buhrmaster at gmail.com posted a discussion of setting up a reserved pool
to enable renumbering and transfers.    That email is now lost in this
thread.

I have included it here:

> On Tue, Apr 19, 2016 at 9:18 PM, Gary Buhrmaster <
gary.buhrmaster at gmail.com> wrote:
> On Mon, Apr 11, 2016 at 5:43 PM, Owen DeLong <owen at delong.com> wrote:
> ....
> > I?d be OK with this, but given that there is remaining free pool for
these resources,
>  > I?m not sure that it isn?t better to have a clear policy that when the
resources in these
>  >  categories are no longer needed, voluntary return to ARIN is expected.
>
>  On Monday, there was discussion (during policy experience report)
>  about ARIN not being able to provide "theoretical" pre-qualifications
>  in the case where (in the example) you transfer a /16 to someone,
>  and would want to get a /24 from somewhere else.  And while most
>  steeped in the ARIN process understand that qualifying is an almost
>  certainty, that does not take it to the level some seem to need to feel
>  entirely comfortable.
>
>  As far as this proposal, I can imagine there to be cases were a transfer
>  may only make sense if the receiving org can be assured that they will
>  be able to get the IP numbers from a reserved pool which ARIN cannot
>  make assurance on in advance.  And while (as before) everyone may be
>  (almost) 100% sure that the recipient will qualify, that does not always
>  make everyone sufficiently comfortable.
>
>  It would seem to be nice for a 8.3 transfer which happens to include
>  reserved pool space not turn into another policy experience report
>  bullet for not being able to successfully transfer (worst case?) "CI"
>  space if indeed the recipient would otherwise qualify (and potentially
>  force a renumber of such resources for no particular policy reason).
>
>  I do agree with Owen that these cases are unlikely.  And regardless
>  of whether the (what I think is) better language as proposed by Scott
>  is included, I would support the policy moving forward to address
>  the problem statement.


On Mon, May 9, 2016 at 3:45 PM, Owen DeLong <owen at delong.com> wrote:

> This is a conflating of two different discussions.
>
> The information below is about a new discussion where a resource holder
> wants to obtain
> a smaller block pre-approval prior to transferring out their larger block.
>
> It has nothing to do with 2016-1 or reserved pool addresses.
>
> Owen
>
> > On May 8, 2016, at 15:55 , Michael Peddemors <michael at linuxmagic.com>
> wrote:
> >
> > On 16-05-05 01:09 PM, Jason Schiller wrote:
> >> I would go s far as to direct ARIN staff to provide provisional
> approval.
> >> The process would look like this:
> >>
> >> Customer: ARIN, I have a /16.  I am currently using 200 IPs as
> >> documented below.
> >> I would be willing to sell my /16 and replace it with a /24 if I can be
> >> assured that I
> >> will be approved to get a /24.
> >>
> >
> > That probably isn't a good example, if the person is only using 200
> IP(s) from a /16, ARIN should recover the unused IP(s)..
> >
> > ARIN could in that case recover most of it, and leave him with a /22 for
> instance..
> >
> >
> > --
> > "Catch the Magic of Linux..."
> > ------------------------------------------------------------------------
> > Michael Peddemors, President/CEO LinuxMagic Inc.
> > Visit us at http://www.linuxmagic.com @linuxmagic
> > ------------------------------------------------------------------------
> > A Wizard IT Company - For More Info http://www.wizard.ca
> > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> > ------------------------------------------------------------------------
> > 604-682-0300 Beautiful British Columbia, Canada
> >
> > This email and any electronic data contained are confidential and
> intended
> > solely for the use of the individual or entity to which they are
> addressed.
> > Please note that any views or opinions presented in this email are solely
> > those of the author and are not intended to represent those of the
> company.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



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

From jschiller at google.com  Tue May 10 11:48:11 2016
From: jschiller at google.com (Jason Schiller)
Date: Tue, 10 May 2016 11:48:11 -0400
Subject: [arin-ppml] ARIN-2015-3:(remove 30-day...) Staff interpretation
	needed
In-Reply-To: <F6FC2137-92BA-41D2-AC0F-F7A97FFD3E25@corp.arin.net>
References: <CAN-Dau2TiyphbwW3c-wLCKgEJuBpcWsJQEi3c6dq6aBomvA92Q@mail.gmail.com>
	<CAC4yj2Wi8Dac+5EK83W=STcz67fUCdTDqsKgHW6GdzgHkar+9w@mail.gmail.com>
	<F6FC2137-92BA-41D2-AC0F-F7A97FFD3E25@corp.arin.net>
Message-ID: <CAC4yj2WP+=ac-KGiDfPMmwji9t5wVAUMyd532BAuZrFfe+z_bg@mail.gmail.com>

John,

Thank you for the lengthy description.  I'm not sure I understand what your
estimate means so I will attempt to restate them for clarity.

It sounds like in 50% - 75% of the requests that are approved
have historical utilization is sufficient to provide approval.  Example A &
C.

It sounds like in 25% - 50% of the requests that are approved
have historical utilization is not sufficient to provide approval.  Example
B.

It sounds like you did not provide information on how often a request
justified on a future projection is approved only in the amount justified
by historical utilization Example C, or is altogether denied or abandoned.


Do these numbers include both end-user and ISP requests?
Could you provide a similar estimate broken down between end-user and ISP
requests?

Do both ISP requests and end-user requests have the same percentage
of requests approved being more heavily weighted by historical utilization
trend information?

 Or do end-user requests have a higher percentage of approvals being
 more heavily weighted by historical utilization trend information?

Or do ISP requests have a higher percentage of approvals being
 more heavily weighted by historical utilization trend information?


Thanks,

__Jason

On Sat, May 7, 2016 at 7:15 AM, John Curran <jcurran at arin.net> wrote:

> On Apr 25, 2016, at 12:47 PM, Jason Schiller <jschiller at google.com>
> wrote:
>
> ...
> I suspect the 30 days part does (to some extent) regulate outrageously
> large claims, as this is a real short term verifiable commitment.  Without
> a possibility of a 30 day check you simply fall back to an officer
> attestation of a two year projected need claim.
>
> I am trying to figure out what is the likely impact of only requiring a
> two year projected need claim.  So my questions are regarding to what level
> of push back ARIN provides against two year projected need in general, and
> will that be sufficient to prevent outlandishly large claims.
>
> Maybe another way to get at this is to compare end user transfer stats to
> ISP transfer stats.
> - what percentage of ISP specified transfers are justified by past growth?
>  by a two year projection?
> - what percentage of end user specified transfers are justified by past
> growth?  by a two year projection?
> - what is the average size of ISP specified transfers that are justified
> by past growth?  by a two year projection?
> - what is the average size of end user specified transfers that are
> justified by past growth?  by a two year projection?
> - do we see a greater gap between average ISP size between specified
> transfers that are justified by past growth vs. by a two year projection?
> - do we see a greater percentage of ISP transfers justified by a 2 year
> projection than end users?
>
>
> Jason -
>
>     While we dp collect statistics on the number of requests and outcomes,
> we do
>     not have the instrumentation of the needs-assessment process that
> would be
>     necessary to produce the type of statistics you request.  It is also
> not clear that
>     such instrumentation would allow us to provide an exact percentage of
> requests
>     that are approved based on past growth vs. projections because ARIN
> takes
>     both factors into account when evaluating operational need.
>
>     In order to provide some insight into how the needs-assessment process
> operates
>     with respect to past growth versus projection, we?ve provided several
> examples on
>     how the needs-assessment process would unfold for various 8.3
> specified transfer
>     scenarios detailed below.
>
>     When an existing ARIN account, ISP or End-User, requests an 8.3
> Recipient
>     Transfer, ARIN will look at their historical utilization and determine
> the organizations
>     average 24-month usage trend.  We will compare that to what they are
> currently
>     requesting to have transferred and determine if that amount
> aligns with their prior
>     utilization trend. If it does align directly, then we consider that
> the justification for
>     their 24-month stated need, but often we have to also give some
> consideration to
>     the information they provide regarding future plans and potential
> impact on growth
>     rate.
>
> === Example A
> An existing ARIN Organization requests a /16 transfer via 8.3 transfer
> process.
> They previously received the following IPv4 address space:
> /17 in December 2015
> /17 in October 2015
> /18 in July 2015
> /19 in June 2015
> /20 in May 2015
> /20 in February 2015
>
> In this example, ARIN would request 24-month projections AND utilization
> information from the organization. We would verify they have utilized
> their previously received IPv4 blocks in accordance with policy and
> determine their utilization trend. In this example, the organization has
> fully utilized their previous allocations and we note their historical
> utilization of 384 /24s over the past 18 months. Even though we are also
> taking their future plans into consideration, their prior utilization trend
> is heavily weighted in justifying the newly requested /16 and they are
> approved. Their prior 24 months of utilization exceeds what they are
> requesting for the next 24 months.
>
> === Example B
> An existing ARIN Organization requests a /16 transfer via 8.3 transfer
> process.
> They previously received the following IPv4 address space:
> /19 in December 2015
> /20 in October 2015
> /21 in July 2015
> /22 in June 2015
> /23 in May 2015
>
> In this example, ARIN would again request 24-month projections AND
> utilization information from the organization.  We would verify they
> have utilized their previously received IPv4 blocks in accordance with
> policy and determine their utilization trend.  In this example, the
> organization has fully utilized their previous allocations and we note
> their historical utilization trend of 62 /24s over the past 11 months.
> Their prior utilization suggests a utilization trend of 136 /24s over a
> 24-month period (62 / 11 * 24mos = 135.3 or 136).  The organization?s
> 24-month utilization trend does not meet or exceed the amount of IPv4
> address space they are requesting for the next 24-month period, so the
> information they provide regarding their future plans/need is more heavily
> weighted by ARIN staff. The information provided regarding future need
> paired with their utilization trend allows for an approval for the
> requested size (/16).
>
> === Example C
> An existing ARIN Organization requests a /16 transfer via 8.3 transfer
> process.
>
> Without providing the further background details, the requesting
> organization in this example has utilized their previously received blocks
> in accordance with policy and has a 24-month utilization trend of 65 /24s.
> The organization?s 24-month utilization trend does not meet or exceed the
> amount of IPv4 address space they are requesting for the next 24-month
> period, so the information they provide regarding their future plans/need
> is more heavily weighted by ARIN staff. The future need projections only
> slightly increase expected future utilization over their prior utilization
> trend and a need for 100 /24s is determined for the next 24-month period.
> Unfortunately, the information provided regarding future need paired with
> their utilization trend does not allow for the approval of the requested
> /16, and a /17 (closest prefix size above their demonstrated need amount)
> is approved instead.
> ===
>
>    Similarly, if a new organization comes to ARIN for an 8.3 Recipient
> Transfer we
>    would base their approval on any provider assigned space they are
> currently using
>    and their projections. We would do this similar to the examples noted
> above.
>
>    It is important to note that if a new organization comes to ARIN and
> isn't using any
>    provider assigned space, we are only be able to base their approval
> amounts based
>    on their projections.
>
>    When we ask organization for their forward projections, we also ask
> them to provide
>    details to show how they've arrived at their projections. We take into
> account factors
>    such as new networks, locations, products, services they plan on
> offering (and this
>    includes consideration of anticipated address utilization within the
> first 30 days for
>    end-users.)
>
>    Given we take all of these factors into account (and noting that we
> don?t precisely track if
>    they qualified more heavily on historical usage vs. projections), we
> would estimate between
>    50-75% of the approval decisions made are more heavily weighted by
> historical utilization
>    trend information. It is important to note that the
> historical utilization trend information often
>    allows for an approval size equal to or greater than what is requested
> by most organizations.
>
> While this is not the level of detail that you desire, I hope it provides
> some useful insight
> into the role of the future projections in the needs-assessment process.
>
> Best wishes on your policy development efforts!
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
>
>
>


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

From jschiller at google.com  Tue May 10 12:04:03 2016
From: jschiller at google.com (Jason Schiller)
Date: Tue, 10 May 2016 12:04:03 -0400
Subject: [arin-ppml] Pre approvals for transfer-in-kind transactions
In-Reply-To: <CAP-guGX35TbdqdOJ7sNGmUigG1fdup=sjGc-PDLDfkQby_KPsQ@mail.gmail.com>
References: <54AC5E4A-B6D5-4C67-9C62-50C3B7F15ED5@delong.com>
	<CAP-guGX35TbdqdOJ7sNGmUigG1fdup=sjGc-PDLDfkQby_KPsQ@mail.gmail.com>
Message-ID: <CAC4yj2W-=VuCsnv3ruKuH1SJysTVEnZqhG0QDYJv8hoT6vGJLQ@mail.gmail.com>

Bill,

You are absolutely correct. But...

The ARIN experience report suggested that some times
the seller is uncomfortable using IP space that is not
registered to them, without an assurance that the future
transfer will be approved when at the current time, they
are not approved (as they are still holding the block they
intend to sell).

The catch 22 is they can't get the assurance they need
that they will be able to get approval to transfer in a /24
before they commit to transfer out the block they are selling.

We all know that in this example the utilization is sufficient
to justify a /24 and that they will be (pre-)approved for a
transfer in of a /24 once they no longer hold the /16.  But the
organization would like some greater assurance of this.


It was suggested that if ARIN provided that assurance then
the risk to the seller would be sufficiently reduced and more
sellers would be willing to enter the market.

__Jason





On Fri, May 6, 2016 at 5:18 PM, William Herrin <bill at herrin.us> wrote:

> > On May 5, 2016, at 13:09 , Jason Schiller <jschiller at google.com> wrote:
> > ARIN: based on your current utilization you are pre-approved to transfer
> a
> > /24
> > on the condition that no longer hold the /16 and your utilization as
> > reported
> > remains unchanged.
>
> Hi Jason,
>
> At the moment, the org could "buy" the /24 with the provision that
> they'll take possession, update POCs and announce it via BGP
> immediately but the seller will hold the registration until ARIN
> transfer is approved. Right? They then renumber, sell and transfer the
> /16 and then ask ARIN to transfer the /24 on the basis that they have
> no IP addresses (having disposed of the unnecessarily large block) and
> have actual control of the requested block anyway.
>
> Why would ARIN need to fiddle with conditional approvals and uncertain
> timelines for the renumbering dance?
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
>



-- 
_______________________________________________________
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/20160510/5192572d/attachment.htm>

From jschiller at google.com  Tue May 10 12:32:08 2016
From: jschiller at google.com (Jason Schiller)
Date: Tue, 10 May 2016 12:32:08 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
Message-ID: <CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>

I seem to have missed the this thread in last call, and hope you
will consider the discussion on the other thread: " Re: [arin-ppml]
ARIN-2015-3:(remove 30-day...) Staff interpretation needed"

 I maintain that the 30-day [60-day for transfers] check has
been useful in mitigating abusively large requests, and
without it there is no teeth in the policy to prevent abuse.


I asked if I was wrong about this, please explain what
mechanisms are in place to mitigate an end-user asking for
approval for a 10 year supply of addresses on the grounds that
if things go really really well, it will only be a 2 year supply?

I heard no response to indicate there was any mechanism.


I asked staff about information about stats that might help
determine what level of push back ARIN provides against two
year projected need in general, and if that push back would be
sufficient to prevent outlandishly large claims.

We found that 50% - 75% of all requests are approved with
past utilization more heavily weighed.

It remains unclear what level of oversight ARIN has to
question future looking projections.  John Curran provided
some text about approvals of future looking projections.

   "When we [ARIN] ask organization for their forward
    projections, we [ARIN] also ask them to provide details
   to show how they've arrived at their projections. We [ARIN]
   take into account factors such as new networks, locations,
   products, services they plan on offering (and this includes
   consideration of anticipated address utilization within the
   first 30 days for end-users.)

>From the text John provided it seems one could get IP
addresses solely on future looking plans which are
unverifiable.  As such an end-user could easily get a 10
year supply of addresses simply by providing very
optimistic deployment plans for the next 24 months.



I asked if I was not wrong about this, then did people realize
that this policy is basically an end-run around giving out
addresses based on need when they voted to move this
policy forward?

I heard no response to this.

Thanks,

__Jason


On Thu, May 5, 2016 at 11:45 AM, David Farmer <farmer at umn.edu> wrote:

> As shepherd for this policy I welcome any additional last call
> feedback for this policy.  It is especially important to speak up if
> you feel there are any issues remaining that need to be considered.
> But, even if you simply support the policy as written that is
> important and useful feedback as well.
>
> The last call period formally continues through, Monday, May 9th, and
> the AC will consider the feedback during its scheduled call on
> Thursday, May 19th.
>
> Thanks
>
> On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net> wrote:
> > The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
> > send the following to last call:
> >
> >   Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
> > requirement in end-user IPv4 policy
> >
> > Feedback is encouraged during the last call period. All comments should
> > be provided to the Public Policy Mailing List. This last call will
> > expire on 9 May 2016. After last call the AC will conduct their
> > last call review.
> >
> > The draft policy text is below and available at:
> > https://www.arin.net/policy/proposals/
> >
> > The ARIN Policy Development Process is available at:
> > https://www.arin.net/policy/pdp.html
> >
> > Regards,
> >
> > Communications and Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Recommended Draft Policy ARIN-2015-3
> > Remove 30 day utilization requirement in end-user IPv4 policy
> >
> > AC's assessment of conformance with the Principles of Internet Number
> > Resource Policy:
> >
> > ARIN 2015-3 contributes to fair and impartial number resource
> administration
> > by removing from the NRPM text that is operationally unrealistic for the
> > reasons discussed in the problem statement. This proposal is technically
> > sound, in that the removal of the text will more closely align with the
> way
> > staff applies the existing policy in relation to 8.3 transfers. There was
> > strong community support for the policy on PPML and at ARIN 36, which was
> > confirmed at ARIN 37. There was a suggestion to replace this text with an
> > alternate requirement. However, the community consensus was to move
> forward
> > with the removal alone.
> >
> > The staff and legal review also suggested removing RFC2050 references and
> > pointed out that 4.2.3.6 has an additional 25% immediate use clause,
> > community feedback was to deal with those issues separately.
> >
> > Problem Statement:
> >
> > End-user policy is intended to provide end-users with a one year supply
> of
> > IP addresses. Qualification for a one-year supply requires the network
> > operator to utilize at least 25% of the requested addresses within 30
> days.
> > This text is unrealistic and should be removed.
> >
> > First, it often takes longer than 30 days to stage equipment and start
> > actually using the addresses.
> >
> > Second, growth is often not that regimented; the forecast is to use X
> > addresses over the course of a year, not to use 25% of X within 30 days.
> >
> > Third, this policy text applies to additional address space requests. It
> is
> > incompatible with the requirements of other additional address space
> request
> > justification which indicates that 80% utilization of existing space is
> > sufficient to justify new space. If a block is at 80%, then often (almost
> > always?) the remaining 80% will be used over the next 30 days and longer.
> > Therefore the operator cannot honestly state they will use 25% of the
> > ADDITIONAL space within 30 days of receiving it; they're still trying to
> use
> > their older block efficiently.
> >
> > Fourth, in the face of ARIN exhaustion, some ISPs are starting to not
> give
> > out /24 (or larger) blocks. So the justification for the 25% rule that
> > previously existed (and in fact, applied for many years) is no longer
> > germane.
> >
> > Policy statement:
> >
> > Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
> >
> > Resulting text:
> >
> > 4.3.3. Utilization rate
> >
> > Utilization rate of address space is a key factor in justifying a new
> > assignment of IP address space. Requesters must show exactly how previous
> > address assignments have been utilized and must provide appropriate
> details
> > to verify their one-year growth projection.
> >
> > The basic criterion that must be met is a 50% utilization rate within one
> > year.
> >
> > A greater utilization rate may be required based on individual network
> > requirements. Please refer to RFC 2050 for more information on
> utilization
> > guidelines.
> >
> > Comments:
> >
> > a.Timetable for implementation: Immediate
> >
> > b.Anything else
> >
> > #####
> >
> > ARIN STAFF ASSESSMENT
> >
> > Draft Policy ARIN-2015-3
> > Remove 30 day utilization requirement in end-user IPv4 policy
> > Date of Assessment: 16 February 2016
> >
> > ___
> > 1. Summary (Staff Understanding)
> >
> > This proposal would remove the 25% utilization (within 30 days of
> issuance)
> > criteria bullet point from NRPM 4.3.3.
> >
> > ___
> > 2. Comments
> >
> > A. ARIN Staff Comments
> > This policy would more closely align with the way staff applies the
> existing
> > policy in relation to 8.3 transfers. Because there is no longer an IPv4
> free
> > pool and many IPv4 requests are likely to be satisfied by 8.3 transfers,
> the
> > adoption of this policy should have no major impact on operations and
> could
> > be implemented as written.
> >
> > Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to obsolete
> > RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within
> 30
> > days of issuance) requirement.
> >
> > Staff suggests removing the first two sentences of 4.2.3.6 to remove the
> > references to RFC 2050 and the 25% requirement. Additionally, staff
> suggests
> > removing the reference to the obsolete RFC 2050 in section 4.3.3.
> >
> > B. ARIN General Counsel ? Legal Assessment
> > No material legal risk in this policy.
> >
> > ___
> > 3. Resource Impact
> >
> > This policy would have minimal resource impact from an implementation
> > aspect. It is estimated that implementation would occur immediately after
> > ratification by the ARIN Board of Trustees. The following would be
> needed in
> > order to implement:
> > * Updated guidelines and internal procedures
> > * Staff training
> > _______________________________________________
> > PPML
> > You are receiving this message 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
> ===============================================
> _______________________________________________
> PPML
> You are receiving this message 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/20160510/4a659649/attachment.htm>

From richardj at arin.net  Tue May 10 14:43:04 2016
From: richardj at arin.net (Richard Jimmerson)
Date: Tue, 10 May 2016 18:43:04 +0000
Subject: [arin-ppml] ARIN-2015-3:(remove 30-day...) Staff interpretation
 needed
In-Reply-To: <CAC4yj2WP+=ac-KGiDfPMmwji9t5wVAUMyd532BAuZrFfe+z_bg@mail.gmail.com>
References: <CAN-Dau2TiyphbwW3c-wLCKgEJuBpcWsJQEi3c6dq6aBomvA92Q@mail.gmail.com>
	<CAC4yj2Wi8Dac+5EK83W=STcz67fUCdTDqsKgHW6GdzgHkar+9w@mail.gmail.com>
	<F6FC2137-92BA-41D2-AC0F-F7A97FFD3E25@corp.arin.net>
	<CAC4yj2WP+=ac-KGiDfPMmwji9t5wVAUMyd532BAuZrFfe+z_bg@mail.gmail.com>
Message-ID: <76F44B00-4C1D-45E6-8E26-EDE3897D793D@arin.net>

Hello Jason,

John has asked me to provide answers to your questions below.

Note that past utilization trends and future plans are both considered in every case, except in those less common cases where there is no prior utilization at all (e.g., NRPM 4.4 and 4.10). Sometimes the prior utilization is weighted more heavily, and other times the future plans are more heavily weighted. It is truly on a case-by-case basis where the weight is placed.


From: <arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>> on behalf of Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>>
John,

Thank you for the lengthy description.  I'm not sure I understand what your
estimate means so I will attempt to restate them for clarity.

It sounds like in 50% - 75% of the requests that are approved
have historical utilization is sufficient to provide approval.  Example A & C.

Correct. Many organizations are requesting a block size that is supported by the organization?s prior rate of utilization. We still review the information they provide about their future need, but can heavily rely on their demonstrated past utilization to support the block size they are requesting.

Further, we are finding that many organizations in this 50-75% category continue to request less than they could qualify for in a 24-month needs assessment. It would seem they are still adjusting to the change from a 3-month (or 12-month for end-users) needs assessment to the 24-month assessments. When it is obvious this is the case, we communicate with the organization to ensure they are fully aware of the policies.


It sounds like in 25% - 50% of the requests that are approved
have historical utilization is not sufficient to provide approval.  Example B.

It sounds like you did not provide information on how often a request
justified on a future projection is approved only in the amount justified
by historical utilization Example C, or is altogether denied or abandoned.

25% - 50% of the requests are unable to justify the block size they are requesting with the heaviest consideration weight being applied to their prior utilization trend. This results in ARIN staff giving increased weight consideration to the documentation they provide supporting their future projections. Sometimes this results in the approval of the requested block size, other times it results in ARIN staff approving a block size smaller than what was requested. Even with 24-month needs assessments, we still find we are unable to approve the requested block size for all organizations when it is not supported by prior utilization history and/or the documentation provided to support future need.



Do these numbers include both end-user and ISP requests?
Could you provide a similar estimate broken down between end-user and ISP requests?

This includes both end-users and ISPs. The percentage breakdown is very close between the two.


Do both ISP requests and end-user requests have the same percentage
of requests approved being more heavily weighted by historical utilization
trend information?

 Or do end-user requests have a higher percentage of approvals being
 more heavily weighted by historical utilization trend information?

Or do ISP requests have a higher percentage of approvals being
 more heavily weighted by historical utilization trend information?

Slightly more cases are approved based on stronger weighting of prior utilization for ISPs than for end-users. It is slightly more common for an end-user to request IPv4 from ARIN with no prior demonstrated utilization. We do note, however, that this may increase over time, as end-users find it more difficult to obtain a reassignment of IPv4 address space from providers post-depletion.

Warm regards,

Richard Jimmerson
CIO & Interim Director of Registration Services
American Registry for Internet Numbers


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

From jschiller at google.com  Tue May 10 15:30:41 2016
From: jschiller at google.com (Jason Schiller)
Date: Tue, 10 May 2016 15:30:41 -0400
Subject: [arin-ppml] ARIN-2015-3:(remove 30-day...) Staff interpretation
	needed
In-Reply-To: <76F44B00-4C1D-45E6-8E26-EDE3897D793D@arin.net>
References: <CAN-Dau2TiyphbwW3c-wLCKgEJuBpcWsJQEi3c6dq6aBomvA92Q@mail.gmail.com>
	<CAC4yj2Wi8Dac+5EK83W=STcz67fUCdTDqsKgHW6GdzgHkar+9w@mail.gmail.com>
	<F6FC2137-92BA-41D2-AC0F-F7A97FFD3E25@corp.arin.net>
	<CAC4yj2WP+=ac-KGiDfPMmwji9t5wVAUMyd532BAuZrFfe+z_bg@mail.gmail.com>
	<76F44B00-4C1D-45E6-8E26-EDE3897D793D@arin.net>
Message-ID: <CAC4yj2WQEdC1qhMqMVHRRe-p_enob=5Kq_xfyggMZMJM5fSmVQ@mail.gmail.com>

Richard,

Sorry for the continued back and forth...

Of the requests are unable to justify the block size they are
requesting with the heaviest consideration weight being
applied to their prior utilization trend, what percentage
are approved for a block larger than what their prior
utilization would have justified if that was the only
consideration?

___Jason





On Tue, May 10, 2016 at 2:43 PM, Richard Jimmerson <richardj at arin.net>
wrote:

> Hello Jason,
>
> John has asked me to provide answers to your questions below.
>
> Note that past utilization trends and future plans are both considered in
> every case, except in those less common cases where there is no prior
> utilization at all (e.g., NRPM 4.4 and 4.10). Sometimes the prior
> utilization is weighted more heavily, and other times the future plans are
> more heavily weighted. It is truly on a case-by-case basis where the weight
> is placed.
>
>
> From: <arin-ppml-bounces at arin.net> on behalf of Jason Schiller <
> jschiller at google.com>
>
> John,
>
> Thank you for the lengthy description.  I'm not sure I understand what your
> estimate means so I will attempt to restate them for clarity.
>
> It sounds like in 50% - 75% of the requests that are approved
> have historical utilization is sufficient to provide approval.  Example A
> & C.
>
>
> Correct. Many organizations are requesting a block size that is supported
> by the organization?s prior rate of utilization. We still review the
> information they provide about their future need, but can heavily rely on
> their demonstrated past utilization to support the block size they are
> requesting.
>
> Further, we are finding that many organizations in this 50-75% category
> continue to request less than they could qualify for in a 24-month needs
> assessment. It would seem they are still adjusting to the change from a
> 3-month (or 12-month for end-users) needs assessment to the 24-month
> assessments. When it is obvious this is the case, we communicate with the
> organization to ensure they are fully aware of the policies.
>
>
> It sounds like in 25% - 50% of the requests that are approved
> have historical utilization is not sufficient to provide approval.
> Example B.
>
>
> It sounds like you did not provide information on how often a request
> justified on a future projection is approved only in the amount justified
> by historical utilization Example C, or is altogether denied or abandoned.
>
>
>
> 25% - 50% of the requests are unable to justify the block size they are
> requesting with the heaviest consideration weight being applied to their
> prior utilization trend. This results in ARIN staff giving increased weight
> consideration to the documentation they provide supporting their future
> projections. Sometimes this results in the approval of the requested block
> size, other times it results in ARIN staff approving a block size smaller
> than what was requested. Even with 24-month needs assessments, we still
> find we are unable to approve the requested block size for all
> organizations when it is not supported by prior utilization history and/or
> the documentation provided to support future need.
>
>
>
> Do these numbers include both end-user and ISP requests?
> Could you provide a similar estimate broken down between end-user and ISP
> requests?
>
>
> This includes both end-users and ISPs. The percentage breakdown is very
> close between the two.
>
>
> Do both ISP requests and end-user requests have the same percentage
> of requests approved being more heavily weighted by historical utilization
> trend information?
>
>  Or do end-user requests have a higher percentage of approvals being
>  more heavily weighted by historical utilization trend information?
>
> Or do ISP requests have a higher percentage of approvals being
>  more heavily weighted by historical utilization trend information?
>
>
> Slightly more cases are approved based on stronger weighting of prior
> utilization for ISPs than for end-users. It is slightly more common for an
> end-user to request IPv4 from ARIN with no prior demonstrated utilization.
> We do note, however, that this may increase over time, as end-users find it
> more difficult to obtain a reassignment of IPv4 address space from
> providers post-depletion.
>
> Warm regards,
>
> Richard Jimmerson
> CIO & Interim Director of Registration Services
> American Registry for Internet Numbers
>
>
>


-- 
_______________________________________________________
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/20160510/d451f0e7/attachment.htm>

From daveid at panix.com  Tue May 10 18:10:17 2016
From: daveid at panix.com (David R Huberman)
Date: Tue, 10 May 2016 18:10:17 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
Message-ID: <1f09bac3c71ac0fdc783e8f455784478.squirrel@mail.panix.com>

Jason,

1) The policy in last call removes a criterion that is not being applied
today.  Staff have criteria they use to judge 24-month need, and have been
applying it for years without coming back to us and telling us there's a
problem or deficiency.

2) Most requestors (99%? 98%?) tell the truth.  They're just trying to
operate a network, and aren't attempting to defraud ARIN In any way. ARIN
staff have been fighting scammers for a very long time, and are very good
at it. They have measurable positive results in fighting fraud.

For those two reasons, I believe this policy should be adopted by the
board, and an obsolete criterion should be removed from NRPM.

David


> I seem to have missed the this thread in last call, and hope you
> will consider the discussion on the other thread: " Re: [arin-ppml]
> ARIN-2015-3:(remove 30-day...) Staff interpretation needed"
>
>  I maintain that the 30-day [60-day for transfers] check has
> been useful in mitigating abusively large requests, and
> without it there is no teeth in the policy to prevent abuse.
>
>
> I asked if I was wrong about this, please explain what
> mechanisms are in place to mitigate an end-user asking for
> approval for a 10 year supply of addresses on the grounds that
> if things go really really well, it will only be a 2 year supply?
>
> I heard no response to indicate there was any mechanism.
>
>
> I asked staff about information about stats that might help
> determine what level of push back ARIN provides against two
> year projected need in general, and if that push back would be
> sufficient to prevent outlandishly large claims.
>
> We found that 50% - 75% of all requests are approved with
> past utilization more heavily weighed.
>
> It remains unclear what level of oversight ARIN has to
> question future looking projections.  John Curran provided
> some text about approvals of future looking projections.
>
>    "When we [ARIN] ask organization for their forward
>     projections, we [ARIN] also ask them to provide details
>    to show how they've arrived at their projections. We [ARIN]
>    take into account factors such as new networks, locations,
>    products, services they plan on offering (and this includes
>    consideration of anticipated address utilization within the
>    first 30 days for end-users.)
>
>>From the text John provided it seems one could get IP
> addresses solely on future looking plans which are
> unverifiable.  As such an end-user could easily get a 10
> year supply of addresses simply by providing very
> optimistic deployment plans for the next 24 months.
>
>
>
> I asked if I was not wrong about this, then did people realize
> that this policy is basically an end-run around giving out
> addresses based on need when they voted to move this
> policy forward?
>
> I heard no response to this.
>
> Thanks,
>
> __Jason
>
>
> On Thu, May 5, 2016 at 11:45 AM, David Farmer <farmer at umn.edu> wrote:
>
>> As shepherd for this policy I welcome any additional last call
>> feedback for this policy.  It is especially important to speak up if
>> you feel there are any issues remaining that need to be considered.
>> But, even if you simply support the policy as written that is
>> important and useful feedback as well.
>>
>> The last call period formally continues through, Monday, May 9th, and
>> the AC will consider the feedback during its scheduled call on
>> Thursday, May 19th.
>>
>> Thanks
>>
>> On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net> wrote:
>> > The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
>> > send the following to last call:
>> >
>> >   Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
>> > requirement in end-user IPv4 policy
>> >
>> > Feedback is encouraged during the last call period. All comments
>> should
>> > be provided to the Public Policy Mailing List. This last call will
>> > expire on 9 May 2016. After last call the AC will conduct their
>> > last call review.
>> >
>> > The draft policy text is below and available at:
>> > https://www.arin.net/policy/proposals/
>> >
>> > The ARIN Policy Development Process is available at:
>> > https://www.arin.net/policy/pdp.html
>> >
>> > Regards,
>> >
>> > Communications and Member Services
>> > American Registry for Internet Numbers (ARIN)
>> >
>> >
>> > ## * ##
>> >
>> >
>> > Recommended Draft Policy ARIN-2015-3
>> > Remove 30 day utilization requirement in end-user IPv4 policy
>> >
>> > AC's assessment of conformance with the Principles of Internet Number
>> > Resource Policy:
>> >
>> > ARIN 2015-3 contributes to fair and impartial number resource
>> administration
>> > by removing from the NRPM text that is operationally unrealistic for
>> the
>> > reasons discussed in the problem statement. This proposal is
>> technically
>> > sound, in that the removal of the text will more closely align with
>> the
>> way
>> > staff applies the existing policy in relation to 8.3 transfers. There
>> was
>> > strong community support for the policy on PPML and at ARIN 36, which
>> was
>> > confirmed at ARIN 37. There was a suggestion to replace this text with
>> an
>> > alternate requirement. However, the community consensus was to move
>> forward
>> > with the removal alone.
>> >
>> > The staff and legal review also suggested removing RFC2050 references
>> and
>> > pointed out that 4.2.3.6 has an additional 25% immediate use clause,
>> > community feedback was to deal with those issues separately.
>> >
>> > Problem Statement:
>> >
>> > End-user policy is intended to provide end-users with a one year
>> supply
>> of
>> > IP addresses. Qualification for a one-year supply requires the network
>> > operator to utilize at least 25% of the requested addresses within 30
>> days.
>> > This text is unrealistic and should be removed.
>> >
>> > First, it often takes longer than 30 days to stage equipment and start
>> > actually using the addresses.
>> >
>> > Second, growth is often not that regimented; the forecast is to use X
>> > addresses over the course of a year, not to use 25% of X within 30
>> days.
>> >
>> > Third, this policy text applies to additional address space requests.
>> It
>> is
>> > incompatible with the requirements of other additional address space
>> request
>> > justification which indicates that 80% utilization of existing space
>> is
>> > sufficient to justify new space. If a block is at 80%, then often
>> (almost
>> > always?) the remaining 80% will be used over the next 30 days and
>> longer.
>> > Therefore the operator cannot honestly state they will use 25% of the
>> > ADDITIONAL space within 30 days of receiving it; they're still trying
>> to
>> use
>> > their older block efficiently.
>> >
>> > Fourth, in the face of ARIN exhaustion, some ISPs are starting to not
>> give
>> > out /24 (or larger) blocks. So the justification for the 25% rule that
>> > previously existed (and in fact, applied for many years) is no longer
>> > germane.
>> >
>> > Policy statement:
>> >
>> > Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
>> >
>> > Resulting text:
>> >
>> > 4.3.3. Utilization rate
>> >
>> > Utilization rate of address space is a key factor in justifying a new
>> > assignment of IP address space. Requesters must show exactly how
>> previous
>> > address assignments have been utilized and must provide appropriate
>> details
>> > to verify their one-year growth projection.
>> >
>> > The basic criterion that must be met is a 50% utilization rate within
>> one
>> > year.
>> >
>> > A greater utilization rate may be required based on individual network
>> > requirements. Please refer to RFC 2050 for more information on
>> utilization
>> > guidelines.
>> >
>> > Comments:
>> >
>> > a.Timetable for implementation: Immediate
>> >
>> > b.Anything else
>> >
>> > #####
>> >
>> > ARIN STAFF ASSESSMENT
>> >
>> > Draft Policy ARIN-2015-3
>> > Remove 30 day utilization requirement in end-user IPv4 policy
>> > Date of Assessment: 16 February 2016
>> >
>> > ___
>> > 1. Summary (Staff Understanding)
>> >
>> > This proposal would remove the 25% utilization (within 30 days of
>> issuance)
>> > criteria bullet point from NRPM 4.3.3.
>> >
>> > ___
>> > 2. Comments
>> >
>> > A. ARIN Staff Comments
>> > This policy would more closely align with the way staff applies the
>> existing
>> > policy in relation to 8.3 transfers. Because there is no longer an
>> IPv4
>> free
>> > pool and many IPv4 requests are likely to be satisfied by 8.3
>> transfers,
>> the
>> > adoption of this policy should have no major impact on operations and
>> could
>> > be implemented as written.
>> >
>> > Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to
>> obsolete
>> > RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use
>> (within
>> 30
>> > days of issuance) requirement.
>> >
>> > Staff suggests removing the first two sentences of 4.2.3.6 to remove
>> the
>> > references to RFC 2050 and the 25% requirement. Additionally, staff
>> suggests
>> > removing the reference to the obsolete RFC 2050 in section 4.3.3.
>> >
>> > B. ARIN General Counsel ??? Legal Assessment
>> > No material legal risk in this policy.
>> >
>> > ___
>> > 3. Resource Impact
>> >
>> > This policy would have minimal resource impact from an implementation
>> > aspect. It is estimated that implementation would occur immediately
>> after
>> > ratification by the ARIN Board of Trustees. The following would be
>> needed in
>> > order to implement:
>> > * Updated guidelines and internal procedures
>> > * Staff training
>> > _______________________________________________
>> > PPML
>> > You are receiving this message 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
>> ===============================================
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.




From richardj at arin.net  Tue May 10 18:18:44 2016
From: richardj at arin.net (Richard Jimmerson)
Date: Tue, 10 May 2016 22:18:44 +0000
Subject: [arin-ppml] ARIN-2015-3:(remove 30-day...) Staff interpretation
 needed
Message-ID: <C8AEF584-3D67-46F7-B18D-538765E71AAF@arin.net>

Hello Jason,

From: Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>>
Of the requests are unable to justify the block size they are
requesting with the heaviest consideration weight being
applied to their prior utilization trend, what percentage
are approved for a block larger than what their prior
utilization would have justified if that was the only
consideration?

To make sure I fully understand the question you asked, I will slightly restate the request case type I believe you are isolating before providing the answer:

ISP or end-user requests an IPv4 block as a recipient of an 8.3 or 8.4 transfer. ARIN staff conducts a needs assessment to determine the 24-month need for the organization in accordance with NRPM. The block size they are requesting is for a 24-month amount that exceeds their previous 24-month utilization trend information. Therefore, ARIN staff applies heavier consideration weight to the future plans and projections of the organization by reviewing all related documentation they provide to determine if the requested block size can be approved.

For this isolated population of request case type:

~85% receive an approval for the originally requested block size.

~15% receive an approval for a block size smaller than what was requested.

Warm regards,

Richard Jimmerson
CIO & Interim Director of Registration Services
American Registry for Internet Numbers


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

From bjones at vt.edu  Tue May 10 20:46:59 2016
From: bjones at vt.edu (Brian Jones)
Date: Tue, 10 May 2016 20:46:59 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
Message-ID: <CANyqO+FA5jYYY=4LZiAe0+2xG_do3htAe3b=dxmyT61w7v1HaA@mail.gmail.com>

I support as written.

--
Brian Jones
On May 5, 2016 11:45 AM, "David Farmer" <farmer at umn.edu> wrote:

> As shepherd for this policy I welcome any additional last call
> feedback for this policy.  It is especially important to speak up if
> you feel there are any issues remaining that need to be considered.
> But, even if you simply support the policy as written that is
> important and useful feedback as well.
>
> The last call period formally continues through, Monday, May 9th, and
> the AC will consider the feedback during its scheduled call on
> Thursday, May 19th.
>
> Thanks
>
> On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net> wrote:
> > The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
> > send the following to last call:
> >
> >   Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
> > requirement in end-user IPv4 policy
> >
> > Feedback is encouraged during the last call period. All comments should
> > be provided to the Public Policy Mailing List. This last call will
> > expire on 9 May 2016. After last call the AC will conduct their
> > last call review.
> >
> > The draft policy text is below and available at:
> > https://www.arin.net/policy/proposals/
> >
> > The ARIN Policy Development Process is available at:
> > https://www.arin.net/policy/pdp.html
> >
> > Regards,
> >
> > Communications and Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Recommended Draft Policy ARIN-2015-3
> > Remove 30 day utilization requirement in end-user IPv4 policy
> >
> > AC's assessment of conformance with the Principles of Internet Number
> > Resource Policy:
> >
> > ARIN 2015-3 contributes to fair and impartial number resource
> administration
> > by removing from the NRPM text that is operationally unrealistic for the
> > reasons discussed in the problem statement. This proposal is technically
> > sound, in that the removal of the text will more closely align with the
> way
> > staff applies the existing policy in relation to 8.3 transfers. There was
> > strong community support for the policy on PPML and at ARIN 36, which was
> > confirmed at ARIN 37. There was a suggestion to replace this text with an
> > alternate requirement. However, the community consensus was to move
> forward
> > with the removal alone.
> >
> > The staff and legal review also suggested removing RFC2050 references and
> > pointed out that 4.2.3.6 has an additional 25% immediate use clause,
> > community feedback was to deal with those issues separately.
> >
> > Problem Statement:
> >
> > End-user policy is intended to provide end-users with a one year supply
> of
> > IP addresses. Qualification for a one-year supply requires the network
> > operator to utilize at least 25% of the requested addresses within 30
> days.
> > This text is unrealistic and should be removed.
> >
> > First, it often takes longer than 30 days to stage equipment and start
> > actually using the addresses.
> >
> > Second, growth is often not that regimented; the forecast is to use X
> > addresses over the course of a year, not to use 25% of X within 30 days.
> >
> > Third, this policy text applies to additional address space requests. It
> is
> > incompatible with the requirements of other additional address space
> request
> > justification which indicates that 80% utilization of existing space is
> > sufficient to justify new space. If a block is at 80%, then often (almost
> > always?) the remaining 80% will be used over the next 30 days and longer.
> > Therefore the operator cannot honestly state they will use 25% of the
> > ADDITIONAL space within 30 days of receiving it; they're still trying to
> use
> > their older block efficiently.
> >
> > Fourth, in the face of ARIN exhaustion, some ISPs are starting to not
> give
> > out /24 (or larger) blocks. So the justification for the 25% rule that
> > previously existed (and in fact, applied for many years) is no longer
> > germane.
> >
> > Policy statement:
> >
> > Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
> >
> > Resulting text:
> >
> > 4.3.3. Utilization rate
> >
> > Utilization rate of address space is a key factor in justifying a new
> > assignment of IP address space. Requesters must show exactly how previous
> > address assignments have been utilized and must provide appropriate
> details
> > to verify their one-year growth projection.
> >
> > The basic criterion that must be met is a 50% utilization rate within one
> > year.
> >
> > A greater utilization rate may be required based on individual network
> > requirements. Please refer to RFC 2050 for more information on
> utilization
> > guidelines.
> >
> > Comments:
> >
> > a.Timetable for implementation: Immediate
> >
> > b.Anything else
> >
> > #####
> >
> > ARIN STAFF ASSESSMENT
> >
> > Draft Policy ARIN-2015-3
> > Remove 30 day utilization requirement in end-user IPv4 policy
> > Date of Assessment: 16 February 2016
> >
> > ___
> > 1. Summary (Staff Understanding)
> >
> > This proposal would remove the 25% utilization (within 30 days of
> issuance)
> > criteria bullet point from NRPM 4.3.3.
> >
> > ___
> > 2. Comments
> >
> > A. ARIN Staff Comments
> > This policy would more closely align with the way staff applies the
> existing
> > policy in relation to 8.3 transfers. Because there is no longer an IPv4
> free
> > pool and many IPv4 requests are likely to be satisfied by 8.3 transfers,
> the
> > adoption of this policy should have no major impact on operations and
> could
> > be implemented as written.
> >
> > Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to obsolete
> > RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within
> 30
> > days of issuance) requirement.
> >
> > Staff suggests removing the first two sentences of 4.2.3.6 to remove the
> > references to RFC 2050 and the 25% requirement. Additionally, staff
> suggests
> > removing the reference to the obsolete RFC 2050 in section 4.3.3.
> >
> > B. ARIN General Counsel ? Legal Assessment
> > No material legal risk in this policy.
> >
> > ___
> > 3. Resource Impact
> >
> > This policy would have minimal resource impact from an implementation
> > aspect. It is estimated that implementation would occur immediately after
> > ratification by the ARIN Board of Trustees. The following would be
> needed in
> > order to implement:
> > * Updated guidelines and internal procedures
> > * Staff training
> > _______________________________________________
> > PPML
> > You are receiving this message 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
> ===============================================
> _______________________________________________
> PPML
> You are receiving this message 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/20160510/eefc7831/attachment.htm>

From ctacit at tacitlaw.com  Wed May 11 08:58:16 2016
From: ctacit at tacitlaw.com (Christian Tacit)
Date: Wed, 11 May 2016 12:58:16 +0000
Subject: [arin-ppml] Editorial Revision to Current Text of Draft Policy
	ARIN-2015-2
Message-ID: <686e571e81b9442ab8a619d96e8605fa@S05-MBX03-12.S05.local>

Dear Community Members,

Since no feedback was received concerning the editorial changes described in my April 24, 2016 posting to PPML reproduced below, I am writing to advise that the text of the proposal has been modified accordingly. The text of that posting is:
"Dear Community Members:
I am writing to advise of some minor suggested editorial changes to the current text of Draft Policy ARIN-2015-2. The intent is to make ensure that the relationship between the source and recipient in the fourth bullet of section 8.4 of the NRPM is clearer. No substantive change is contemplated, and none has been requested following the previous text change, either on PPML or at ARIN 37. Please provide any comments you may have regarding these additional proposed changes as soon as possible. If no material objection is raised, I will modify the text of the proposal formally to reflect the wording below.

"Problem Statement:

Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt.

Policy statement:
Replace 8.4, bullet 4, to read:
"Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request, unless either the source or recipient entity owns or controls the other, or both are under common ownership or control. This restriction does not include M&A transfers."
Comments: Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt. The need to move the resources does not flow from ARIN policy, but rather from the requirement of certain registries outside the ARIN region to have the resources moved in order to be used there.
The intention of this change is to allow organizations to perform inter-RIR transfers of space received via an 8.3 transfer regardless of the date transferred to ARIN. A common example is that an organization acquires a block located in the ARIN region, transfers it to ARIN, then 3 months later, the organization announces that it wants to launch new services out of region. Under current policy, the organization is prohibited from moving some or all of those addresses to that region's Whois if there is a need to move them to satisfy the rules of the other region requiring the movement of the resources to that region in order for them to be used there. Instead, the numbers are locked in ARIN's Whois. It's important to note that 8.3 transfers are approved for a 24 month supply, and it would not be unheard of for a business model to change within the first 12 months after approval. The proposal also introduces a requirement for an affiliation relationship between the source and recipient entity, based on established corporate law principles, so as to make it reasonably likely that eliminating the 12 month anti-flip period in that situation will meet the needs of organizations that operate networks in more than one region without encouraging abuse.
a. Timetable for implementation: Immediate
b. Anything else: N/A"
Thank you."
Chris Tacit



Christian S. Tacit,
Tacit Law

P.O. Box 24210 RPO Hazeldean
Kanata, Ontario
K2M 2C3 Canada

Tel: +1 613 599 5345
Fax: +1 613 248 5175
E-mail: ctacit at tacitlaw.com

This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is subject to copyright, privileged, confidential, proprietary or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying or in any way using this message. If you have received this communication in error, please notify the sender and destroy or delete copies you may have received.
From: Christian Tacit
Sent: April-24-16 12:27 PM
To: 'arin-ppml at arin.net' <arin-ppml at arin.net>
Subject: Proposed Editorial Revision to Current Text of Draft Policy ARIN-2015-2

Dear Community Members:
I am writing to advise of some minor suggested editorial changes to the current text of Draft Policy ARIN-2015-2. The intent is to make ensure that the relationship between the source and recipient in the fourth bullet of section 8.4 of the NRPM is clearer. No substantive change is contemplated, and none has been requested following the previous text change, either on PPML or at ARIN 37. Please provide any comments you may have regarding these additional proposed changes as soon as possible. If no material objection is raised, I will modify the text of the proposal formally to reflect the wording below.

"Problem Statement:

Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt.

Policy statement:
Replace 8.4, bullet 4, to read:
"Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request, unless either the source or recipient entity owns or controls the other, or both are under common ownership or control. This restriction does not include M&A transfers."
Comments: Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt. The need to move the resources does not flow from ARIN policy, but rather from the requirement of certain registries outside the ARIN region to have the resources moved in order to be used there.
The intention of this change is to allow organizations to perform inter-RIR transfers of space received via an 8.3 transfer regardless of the date transferred to ARIN. A common example is that an organization acquires a block located in the ARIN region, transfers it to ARIN, then 3 months later, the organization announces that it wants to launch new services out of region. Under current policy, the organization is prohibited from moving some or all of those addresses to that region's Whois if there is a need to move them to satisfy the rules of the other region requiring the movement of the resources to that region in order for them to be used there. Instead, the numbers are locked in ARIN's Whois. It's important to note that 8.3 transfers are approved for a 24 month supply, and it would not be unheard of for a business model to change within the first 12 months after approval. The proposal also introduces a requirement for an affiliation relationship between the source and recipient entity, based on established corporate law principles, so as to make it reasonably likely that eliminating the 12 month anti-flip period in that situation will meet the needs of organizations that operate networks in more than one region without encouraging abuse.
a. Timetable for implementation: Immediate
b. Anything else: N/A"
Thank you.
Chris Tacit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160511/e91d24f2/attachment.htm>

From jschiller at google.com  Wed May 11 12:02:11 2016
From: jschiller at google.com (Jason Schiller)
Date: Wed, 11 May 2016 12:02:11 -0400
Subject: [arin-ppml] ARIN-2015-3:(remove 30-day...) Staff interpretation
	needed
In-Reply-To: <C8AEF584-3D67-46F7-B18D-538765E71AAF@arin.net>
References: <C8AEF584-3D67-46F7-B18D-538765E71AAF@arin.net>
Message-ID: <CAC4yj2X=QhvKYotkRJ7ExxoyKeQRbrHpzerxWFf7xfkvUUnMsg@mail.gmail.com>

Thank you.

__Jason

On Tue, May 10, 2016 at 6:18 PM, Richard Jimmerson <richardj at arin.net>
wrote:

> Hello Jason,
>
> From: Jason Schiller <jschiller at google.com>
>
> Of the requests are unable to justify the block size they are
> requesting with the heaviest consideration weight being
> applied to their prior utilization trend, what percentage
> are approved for a block larger than what their prior
> utilization would have justified if that was the only
> consideration?
>
>
> To make sure I fully understand the question you asked, I will slightly
> restate the request case type I believe you are isolating before providing
> the answer:
>
> ISP or end-user requests an IPv4 block as a recipient of an 8.3 or 8.4
> transfer. ARIN staff conducts a needs assessment to determine the 24-month
> need for the organization in accordance with NRPM. The block size they are
> requesting is for a 24-month amount that exceeds their previous 24-month
> utilization trend information. Therefore, ARIN staff applies heavier
> consideration weight to the future plans and projections of the
> organization by reviewing all related documentation they provide to
> determine if the requested block size can be approved.
>
> For this isolated population of request case type:
>
> ~85% receive an approval for the originally requested block size.
>
> ~15% receive an approval for a block size smaller than what was requested.
>
> Warm regards,
>
> Richard Jimmerson
> CIO & Interim Director of Registration Services
> American Registry for Internet Numbers
>
>
>


-- 
_______________________________________________________
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/20160511/60844146/attachment.htm>

From info at arin.net  Thu May 12 11:59:14 2016
From: info at arin.net (ARIN)
Date: Thu, 12 May 2016 11:59:14 -0400
Subject: [arin-ppml] =?utf-8?q?NRPM_2016=2E2_=E2=80=93_New_Policies_Implem?=
 =?utf-8?q?ented_=28ARIN-2015-5_and_2015-11=29?=
Message-ID: <5734A852.5090507@arin.net>

On 19 April 2016 the ARIN Board of Trustees adopted the following 
Recommended Draft Policies:

ARIN-2015-5: Out-of-Region Use

ARIN-2015-11: Remove Transfer Language Which Only Applied Pre-Exhaustion 
of v4 Pool

These new policies will be implemented no later than 31 July 2016.

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

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

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

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

Regards,

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


From jschiller at google.com  Thu May 12 16:03:33 2016
From: jschiller at google.com (Jason Schiller)
Date: Thu, 12 May 2016 16:03:33 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <1f09bac3c71ac0fdc783e8f455784478.squirrel@mail.panix.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<1f09bac3c71ac0fdc783e8f455784478.squirrel@mail.panix.com>
Message-ID: <CAC4yj2XNAuQY4J4YCw+iT=n+-dCCabr-JGZm56Qi7_FUudh+EA@mail.gmail.com>

I am surprised that staff would not apply the 30 day need (albeit extended
to 60 day need) for end-sites requesting a transfer.

My understanding is that 8.3 references "demonstrating need" "under current
policies" albeit extended to 24 months (double an ARIN assignment).

Current policy 4.3.3 defines meeting 25% utilization immediately (30 days)
and 50% within 1 year.
Extended this doubles the values.

This is also seems to be consistent with what I heard at the meeting:

"Kevin Blumberg:  The question was, to clarify for everybody, when it comes
-- this policy is in reference to free pool space. When you take into
account that almost every request will now be based on transfer via 8.3 or
8.4, which has a 24-month, can you explain how staff calculates in
transfers versus what -- when somebody is just reading and saying 25
percent over 30 days, how does that now work with a 24-month transfer?

John Curran:  It still requires them to use 25 percent of the block being
transferred. Now, this is the unfortunate circumstance of having transfer
policies which chained to needs assessment which come from allocation and
assignment policies in elsewhere in the NRPM.

When the AC has some free time, if it would like to unwind those, that
would be greatly appreciated."


I trust ARIN is very good at finding fraud and abuse, however I think this
change makes fraud and abuse (or as Owen put it simply having dreams of
grandeur [note this was wrt 2015-9 but it applies equally here].)  makes it
much harder to catch as per Jonh's comments when discussing this policy.

"John Curran:  We can go back on the present policy and confirm that
someone has done the utilization that they claim they do, but it's much
more difficult to know whether or not someone has made a fraudulent request
if we don't check shortly after we've assigned to them.

In other words, someone will find address space utilization within a year
one way or the other. But whether or not they're valid for what we assigned
is much easier to determine if they've made use of it within the first 30
days, or 30 days, 60 days, the immediate future."

Can staff comment do you apply the 25% need in 60 days to specified
transfers?  Or is this ignored and obsolete?

__Jason

On Tue, May 10, 2016 at 6:10 PM, David R Huberman <daveid at panix.com> wrote:

> Jason,
>
> 1) The policy in last call removes a criterion that is not being applied
> today.  Staff have criteria they use to judge 24-month need, and have been
> applying it for years without coming back to us and telling us there's a
> problem or deficiency.
>
> 2) Most requestors (99%? 98%?) tell the truth.  They're just trying to
> operate a network, and aren't attempting to defraud ARIN In any way. ARIN
> staff have been fighting scammers for a very long time, and are very good
> at it. They have measurable positive results in fighting fraud.
>
> For those two reasons, I believe this policy should be adopted by the
> board, and an obsolete criterion should be removed from NRPM.
>
> David
>
>
> > I seem to have missed the this thread in last call, and hope you
> > will consider the discussion on the other thread: " Re: [arin-ppml]
> > ARIN-2015-3:(remove 30-day...) Staff interpretation needed"
> >
> >  I maintain that the 30-day [60-day for transfers] check has
> > been useful in mitigating abusively large requests, and
> > without it there is no teeth in the policy to prevent abuse.
> >
> >
> > I asked if I was wrong about this, please explain what
> > mechanisms are in place to mitigate an end-user asking for
> > approval for a 10 year supply of addresses on the grounds that
> > if things go really really well, it will only be a 2 year supply?
> >
> > I heard no response to indicate there was any mechanism.
> >
> >
> > I asked staff about information about stats that might help
> > determine what level of push back ARIN provides against two
> > year projected need in general, and if that push back would be
> > sufficient to prevent outlandishly large claims.
> >
> > We found that 50% - 75% of all requests are approved with
> > past utilization more heavily weighed.
> >
> > It remains unclear what level of oversight ARIN has to
> > question future looking projections.  John Curran provided
> > some text about approvals of future looking projections.
> >
> >    "When we [ARIN] ask organization for their forward
> >     projections, we [ARIN] also ask them to provide details
> >    to show how they've arrived at their projections. We [ARIN]
> >    take into account factors such as new networks, locations,
> >    products, services they plan on offering (and this includes
> >    consideration of anticipated address utilization within the
> >    first 30 days for end-users.)
> >
> >>From the text John provided it seems one could get IP
> > addresses solely on future looking plans which are
> > unverifiable.  As such an end-user could easily get a 10
> > year supply of addresses simply by providing very
> > optimistic deployment plans for the next 24 months.
> >
> >
> >
> > I asked if I was not wrong about this, then did people realize
> > that this policy is basically an end-run around giving out
> > addresses based on need when they voted to move this
> > policy forward?
> >
> > I heard no response to this.
> >
> > Thanks,
> >
> > __Jason
> >
> >
> > On Thu, May 5, 2016 at 11:45 AM, David Farmer <farmer at umn.edu> wrote:
> >
> >> As shepherd for this policy I welcome any additional last call
> >> feedback for this policy.  It is especially important to speak up if
> >> you feel there are any issues remaining that need to be considered.
> >> But, even if you simply support the policy as written that is
> >> important and useful feedback as well.
> >>
> >> The last call period formally continues through, Monday, May 9th, and
> >> the AC will consider the feedback during its scheduled call on
> >> Thursday, May 19th.
> >>
> >> Thanks
> >>
> >> On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net> wrote:
> >> > The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
> >> > send the following to last call:
> >> >
> >> >   Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
> >> > requirement in end-user IPv4 policy
> >> >
> >> > Feedback is encouraged during the last call period. All comments
> >> should
> >> > be provided to the Public Policy Mailing List. This last call will
> >> > expire on 9 May 2016. After last call the AC will conduct their
> >> > last call review.
> >> >
> >> > The draft policy text is below and available at:
> >> > https://www.arin.net/policy/proposals/
> >> >
> >> > The ARIN Policy Development Process is available at:
> >> > https://www.arin.net/policy/pdp.html
> >> >
> >> > Regards,
> >> >
> >> > Communications and Member Services
> >> > American Registry for Internet Numbers (ARIN)
> >> >
> >> >
> >> > ## * ##
> >> >
> >> >
> >> > Recommended Draft Policy ARIN-2015-3
> >> > Remove 30 day utilization requirement in end-user IPv4 policy
> >> >
> >> > AC's assessment of conformance with the Principles of Internet Number
> >> > Resource Policy:
> >> >
> >> > ARIN 2015-3 contributes to fair and impartial number resource
> >> administration
> >> > by removing from the NRPM text that is operationally unrealistic for
> >> the
> >> > reasons discussed in the problem statement. This proposal is
> >> technically
> >> > sound, in that the removal of the text will more closely align with
> >> the
> >> way
> >> > staff applies the existing policy in relation to 8.3 transfers. There
> >> was
> >> > strong community support for the policy on PPML and at ARIN 36, which
> >> was
> >> > confirmed at ARIN 37. There was a suggestion to replace this text with
> >> an
> >> > alternate requirement. However, the community consensus was to move
> >> forward
> >> > with the removal alone.
> >> >
> >> > The staff and legal review also suggested removing RFC2050 references
> >> and
> >> > pointed out that 4.2.3.6 has an additional 25% immediate use clause,
> >> > community feedback was to deal with those issues separately.
> >> >
> >> > Problem Statement:
> >> >
> >> > End-user policy is intended to provide end-users with a one year
> >> supply
> >> of
> >> > IP addresses. Qualification for a one-year supply requires the network
> >> > operator to utilize at least 25% of the requested addresses within 30
> >> days.
> >> > This text is unrealistic and should be removed.
> >> >
> >> > First, it often takes longer than 30 days to stage equipment and start
> >> > actually using the addresses.
> >> >
> >> > Second, growth is often not that regimented; the forecast is to use X
> >> > addresses over the course of a year, not to use 25% of X within 30
> >> days.
> >> >
> >> > Third, this policy text applies to additional address space requests.
> >> It
> >> is
> >> > incompatible with the requirements of other additional address space
> >> request
> >> > justification which indicates that 80% utilization of existing space
> >> is
> >> > sufficient to justify new space. If a block is at 80%, then often
> >> (almost
> >> > always?) the remaining 80% will be used over the next 30 days and
> >> longer.
> >> > Therefore the operator cannot honestly state they will use 25% of the
> >> > ADDITIONAL space within 30 days of receiving it; they're still trying
> >> to
> >> use
> >> > their older block efficiently.
> >> >
> >> > Fourth, in the face of ARIN exhaustion, some ISPs are starting to not
> >> give
> >> > out /24 (or larger) blocks. So the justification for the 25% rule that
> >> > previously existed (and in fact, applied for many years) is no longer
> >> > germane.
> >> >
> >> > Policy statement:
> >> >
> >> > Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
> >> >
> >> > Resulting text:
> >> >
> >> > 4.3.3. Utilization rate
> >> >
> >> > Utilization rate of address space is a key factor in justifying a new
> >> > assignment of IP address space. Requesters must show exactly how
> >> previous
> >> > address assignments have been utilized and must provide appropriate
> >> details
> >> > to verify their one-year growth projection.
> >> >
> >> > The basic criterion that must be met is a 50% utilization rate within
> >> one
> >> > year.
> >> >
> >> > A greater utilization rate may be required based on individual network
> >> > requirements. Please refer to RFC 2050 for more information on
> >> utilization
> >> > guidelines.
> >> >
> >> > Comments:
> >> >
> >> > a.Timetable for implementation: Immediate
> >> >
> >> > b.Anything else
> >> >
> >> > #####
> >> >
> >> > ARIN STAFF ASSESSMENT
> >> >
> >> > Draft Policy ARIN-2015-3
> >> > Remove 30 day utilization requirement in end-user IPv4 policy
> >> > Date of Assessment: 16 February 2016
> >> >
> >> > ___
> >> > 1. Summary (Staff Understanding)
> >> >
> >> > This proposal would remove the 25% utilization (within 30 days of
> >> issuance)
> >> > criteria bullet point from NRPM 4.3.3.
> >> >
> >> > ___
> >> > 2. Comments
> >> >
> >> > A. ARIN Staff Comments
> >> > This policy would more closely align with the way staff applies the
> >> existing
> >> > policy in relation to 8.3 transfers. Because there is no longer an
> >> IPv4
> >> free
> >> > pool and many IPv4 requests are likely to be satisfied by 8.3
> >> transfers,
> >> the
> >> > adoption of this policy should have no major impact on operations and
> >> could
> >> > be implemented as written.
> >> >
> >> > Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to
> >> obsolete
> >> > RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use
> >> (within
> >> 30
> >> > days of issuance) requirement.
> >> >
> >> > Staff suggests removing the first two sentences of 4.2.3.6 to remove
> >> the
> >> > references to RFC 2050 and the 25% requirement. Additionally, staff
> >> suggests
> >> > removing the reference to the obsolete RFC 2050 in section 4.3.3.
> >> >
> >> > B. ARIN General Counsel ??? Legal Assessment
> >> > No material legal risk in this policy.
> >> >
> >> > ___
> >> > 3. Resource Impact
> >> >
> >> > This policy would have minimal resource impact from an implementation
> >> > aspect. It is estimated that implementation would occur immediately
> >> after
> >> > ratification by the ARIN Board of Trustees. The following would be
> >> needed in
> >> > order to implement:
> >> > * Updated guidelines and internal procedures
> >> > * Staff training
> >> > _______________________________________________
> >> > PPML
> >> > You are receiving this message 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
> >> ===============================================
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> >>
> >
> >
> >
> > --
> > _______________________________________________________
> > Jason Schiller|NetOps|jschiller at google.com|571-266-0006
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
>
> _______________________________________________
> PPML
> You are receiving this message 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/20160512/abf2f36b/attachment.htm>

From jcurran at arin.net  Thu May 12 16:11:29 2016
From: jcurran at arin.net (John Curran)
Date: Thu, 12 May 2016 20:11:29 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAC4yj2XNAuQY4J4YCw+iT=n+-dCCabr-JGZm56Qi7_FUudh+EA@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<1f09bac3c71ac0fdc783e8f455784478.squirrel@mail.panix.com>
	<CAC4yj2XNAuQY4J4YCw+iT=n+-dCCabr-JGZm56Qi7_FUudh+EA@mail.gmail.com>
Message-ID: <5610B132-401E-4A98-86C0-2A5A5DAE69C7@corp.arin.net>

On May 12, 2016, at 4:03 PM, Jason Schiller <jschiller at google.com> wrote:
> 
> I am surprised that staff would not apply the 30 day need (albeit extended to 60 day need) for end-sites requesting a transfer.
> 
> My understanding is that 8.3 references "demonstrating need" "under current policies" albeit extended to 24 months (double an ARIN assignment).
> 
> Current policy 4.3.3 defines meeting 25% utilization immediately (30 days) and 50% within 1 year.  
> Extended this doubles the values.
> 
> This is also seems to be consistent with what I heard at the meeting:
> 
> "Kevin Blumberg:  The question was, to clarify for everybody, when it comes -- this policy is in reference to free pool space. When you take into account that almost every request will now be based on transfer via 8.3 or 8.4, which has a 24-month, can you explain how staff calculates in transfers versus what -- when somebody is just reading and saying 25 percent over 30 days, how does that now work with a 24-month transfer?
> 
> John Curran:  It still requires them to use 25 percent of the block being transferred. Now, this is the unfortunate circumstance of having transfer policies which chained to needs assessment which come from allocation and assignment policies in elsewhere in the NRPM.
> 
> When the AC has some free time, if it would like to unwind those, that would be greatly appreciated."
> 
> I trust ARIN is very good at finding fraud and abuse, however I think this change makes fraud and abuse (or as Owen put it simply having dreams of grandeur [note this was wrt 2015-9 but it applies equally here].)  makes it much harder to catch as per Jonh's comments when discussing this policy.
> 
> "John Curran:  We can go back on the present policy and confirm that someone has done the utilization that they claim they do, but it's much more difficult to know whether or not someone has made a fraudulent request if we don't check shortly after we've assigned to them.
> 
> In other words, someone will find address space utilization within a year one way or the other. But whether or not they're valid for what we assigned is much easier to determine if they've made use of it within the first 30 days, or 30 days, 60 days, the immediate future."
> 
> Can staff comment do you apply the 25% need in 60 days to specified transfers?  Or is this ignored and obsolete? 

Jason - 
 
   ARIN does not, by default, go back to the organization afterwards and confirm that 
   they have met the 25% utilization requirement, but organizations must conform to 
   policy and thus it remains a valid criteria if we should review a request later (e.g. 
   as a a result of a fraud report.) 

Thanks,
/John

John Curran
President and CEO




From milton at gatech.edu  Thu May 12 16:58:44 2016
From: milton at gatech.edu (Mueller, Milton L)
Date: Thu, 12 May 2016 20:58:44 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAC4yj2XNAuQY4J4YCw+iT=n+-dCCabr-JGZm56Qi7_FUudh+EA@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<1f09bac3c71ac0fdc783e8f455784478.squirrel@mail.panix.com>
	<CAC4yj2XNAuQY4J4YCw+iT=n+-dCCabr-JGZm56Qi7_FUudh+EA@mail.gmail.com>
Message-ID: <BL2PR07MB240452752C019C9DEF9E8505A1730@BL2PR07MB2404.namprd07.prod.outlook.com>

Jason
It seems that the criteria you apply to demonstrated need presumes the existence of a free pool that must be ?conserved? through traditional needs assessment methods. It overlooks the fact that going forward, we will be dealing exclusively with transfers. In other words, if companies overestimate their needs, due to ?delusions of grandeur? or any other reason, they will have to pay dearly for that. Furthermore, the supply of those addresses will be coming from people who are, by definition, not in need of them at all. So on the whole, I find your arguments completely unconvincing. The only risk you have identified is that some small organization might pay for more than they turn out to need.

--MM


From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason Schiller
Sent: Thursday, May 12, 2016 4:04 PM
To: David R Huberman <daveid at panix.com>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

I am surprised that staff would not apply the 30 day need (albeit extended to 60 day need) for end-sites requesting a transfer.

My understanding is that 8.3 references "demonstrating need" "under current policies" albeit extended to 24 months (double an ARIN assignment).

Current policy 4.3.3 defines meeting 25% utilization immediately (30 days) and 50% within 1 year.
Extended this doubles the values.

This is also seems to be consistent with what I heard at the meeting:

"Kevin Blumberg:  The question was, to clarify for everybody, when it comes -- this policy is in reference to free pool space. When you take into account that almost every request will now be based on transfer via 8.3 or 8.4, which has a 24-month, can you explain how staff calculates in transfers versus what -- when somebody is just reading and saying 25 percent over 30 days, how does that now work with a 24-month transfer?

John Curran:  It still requires them to use 25 percent of the block being transferred. Now, this is the unfortunate circumstance of having transfer policies which chained to needs assessment which come from allocation and assignment policies in elsewhere in the NRPM.

When the AC has some free time, if it would like to unwind those, that would be greatly appreciated."


I trust ARIN is very good at finding fraud and abuse, however I think this change makes fraud and abuse (or as Owen put it simply having dreams of grandeur [note this was wrt 2015-9 but it applies equally here].)  makes it much harder to catch as per Jonh's comments when discussing this policy.

"John Curran:  We can go back on the present policy and confirm that someone has done the utilization that they claim they do, but it's much more difficult to know whether or not someone has made a fraudulent request if we don't check shortly after we've assigned to them.

In other words, someone will find address space utilization within a year one way or the other. But whether or not they're valid for what we assigned is much easier to determine if they've made use of it within the first 30 days, or 30 days, 60 days, the immediate future."

Can staff comment do you apply the 25% need in 60 days to specified transfers?  Or is this ignored and obsolete?

__Jason

On Tue, May 10, 2016 at 6:10 PM, David R Huberman <daveid at panix.com<mailto:daveid at panix.com>> wrote:
Jason,

1) The policy in last call removes a criterion that is not being applied
today.  Staff have criteria they use to judge 24-month need, and have been
applying it for years without coming back to us and telling us there's a
problem or deficiency.

2) Most requestors (99%? 98%?) tell the truth.  They're just trying to
operate a network, and aren't attempting to defraud ARIN In any way. ARIN
staff have been fighting scammers for a very long time, and are very good
at it. They have measurable positive results in fighting fraud.

For those two reasons, I believe this policy should be adopted by the
board, and an obsolete criterion should be removed from NRPM.

David


> I seem to have missed the this thread in last call, and hope you
> will consider the discussion on the other thread: " Re: [arin-ppml]
> ARIN-2015-3:(remove 30-day...) Staff interpretation needed"
>
>  I maintain that the 30-day [60-day for transfers] check has
> been useful in mitigating abusively large requests, and
> without it there is no teeth in the policy to prevent abuse.
>
>
> I asked if I was wrong about this, please explain what
> mechanisms are in place to mitigate an end-user asking for
> approval for a 10 year supply of addresses on the grounds that
> if things go really really well, it will only be a 2 year supply?
>
> I heard no response to indicate there was any mechanism.
>
>
> I asked staff about information about stats that might help
> determine what level of push back ARIN provides against two
> year projected need in general, and if that push back would be
> sufficient to prevent outlandishly large claims.
>
> We found that 50% - 75% of all requests are approved with
> past utilization more heavily weighed.
>
> It remains unclear what level of oversight ARIN has to
> question future looking projections.  John Curran provided
> some text about approvals of future looking projections.
>
>    "When we [ARIN] ask organization for their forward
>     projections, we [ARIN] also ask them to provide details
>    to show how they've arrived at their projections. We [ARIN]
>    take into account factors such as new networks, locations,
>    products, services they plan on offering (and this includes
>    consideration of anticipated address utilization within the
>    first 30 days for end-users.)
>
>>From the text John provided it seems one could get IP
> addresses solely on future looking plans which are
> unverifiable.  As such an end-user could easily get a 10
> year supply of addresses simply by providing very
> optimistic deployment plans for the next 24 months.
>
>
>
> I asked if I was not wrong about this, then did people realize
> that this policy is basically an end-run around giving out
> addresses based on need when they voted to move this
> policy forward?
>
> I heard no response to this.
>
> Thanks,
>
> __Jason
>
>
> On Thu, May 5, 2016 at 11:45 AM, David Farmer <farmer at umn.edu<mailto:farmer at umn.edu>> wrote:
>
>> As shepherd for this policy I welcome any additional last call
>> feedback for this policy.  It is especially important to speak up if
>> you feel there are any issues remaining that need to be considered.
>> But, even if you simply support the policy as written that is
>> important and useful feedback as well.
>>
>> The last call period formally continues through, Monday, May 9th, and
>> the AC will consider the feedback during its scheduled call on
>> Thursday, May 19th.
>>
>> Thanks
>>
>> On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net<mailto:info at arin.net>> wrote:
>> > The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
>> > send the following to last call:
>> >
>> >   Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
>> > requirement in end-user IPv4 policy
>> >
>> > Feedback is encouraged during the last call period. All comments
>> should
>> > be provided to the Public Policy Mailing List. This last call will
>> > expire on 9 May 2016. After last call the AC will conduct their
>> > last call review.
>> >
>> > The draft policy text is below and available at:
>> > https://www.arin.net/policy/proposals/
>> >
>> > The ARIN Policy Development Process is available at:
>> > https://www.arin.net/policy/pdp.html
>> >
>> > Regards,
>> >
>> > Communications and Member Services
>> > American Registry for Internet Numbers (ARIN)
>> >
>> >
>> > ## * ##
>> >
>> >
>> > Recommended Draft Policy ARIN-2015-3
>> > Remove 30 day utilization requirement in end-user IPv4 policy
>> >
>> > AC's assessment of conformance with the Principles of Internet Number
>> > Resource Policy:
>> >
>> > ARIN 2015-3 contributes to fair and impartial number resource
>> administration
>> > by removing from the NRPM text that is operationally unrealistic for
>> the
>> > reasons discussed in the problem statement. This proposal is
>> technically
>> > sound, in that the removal of the text will more closely align with
>> the
>> way
>> > staff applies the existing policy in relation to 8.3 transfers. There
>> was
>> > strong community support for the policy on PPML and at ARIN 36, which
>> was
>> > confirmed at ARIN 37. There was a suggestion to replace this text with
>> an
>> > alternate requirement. However, the community consensus was to move
>> forward
>> > with the removal alone.
>> >
>> > The staff and legal review also suggested removing RFC2050 references
>> and
>> > pointed out that 4.2.3.6 has an additional 25% immediate use clause,
>> > community feedback was to deal with those issues separately.
>> >
>> > Problem Statement:
>> >
>> > End-user policy is intended to provide end-users with a one year
>> supply
>> of
>> > IP addresses. Qualification for a one-year supply requires the network
>> > operator to utilize at least 25% of the requested addresses within 30
>> days.
>> > This text is unrealistic and should be removed.
>> >
>> > First, it often takes longer than 30 days to stage equipment and start
>> > actually using the addresses.
>> >
>> > Second, growth is often not that regimented; the forecast is to use X
>> > addresses over the course of a year, not to use 25% of X within 30
>> days.
>> >
>> > Third, this policy text applies to additional address space requests.
>> It
>> is
>> > incompatible with the requirements of other additional address space
>> request
>> > justification which indicates that 80% utilization of existing space
>> is
>> > sufficient to justify new space. If a block is at 80%, then often
>> (almost
>> > always?) the remaining 80% will be used over the next 30 days and
>> longer.
>> > Therefore the operator cannot honestly state they will use 25% of the
>> > ADDITIONAL space within 30 days of receiving it; they're still trying
>> to
>> use
>> > their older block efficiently.
>> >
>> > Fourth, in the face of ARIN exhaustion, some ISPs are starting to not
>> give
>> > out /24 (or larger) blocks. So the justification for the 25% rule that
>> > previously existed (and in fact, applied for many years) is no longer
>> > germane.
>> >
>> > Policy statement:
>> >
>> > Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
>> >
>> > Resulting text:
>> >
>> > 4.3.3. Utilization rate
>> >
>> > Utilization rate of address space is a key factor in justifying a new
>> > assignment of IP address space. Requesters must show exactly how
>> previous
>> > address assignments have been utilized and must provide appropriate
>> details
>> > to verify their one-year growth projection.
>> >
>> > The basic criterion that must be met is a 50% utilization rate within
>> one
>> > year.
>> >
>> > A greater utilization rate may be required based on individual network
>> > requirements. Please refer to RFC 2050 for more information on
>> utilization
>> > guidelines.
>> >
>> > Comments:
>> >
>> > a.Timetable for implementation: Immediate
>> >
>> > b.Anything else
>> >
>> > #####
>> >
>> > ARIN STAFF ASSESSMENT
>> >
>> > Draft Policy ARIN-2015-3
>> > Remove 30 day utilization requirement in end-user IPv4 policy
>> > Date of Assessment: 16 February 2016
>> >
>> > ___
>> > 1. Summary (Staff Understanding)
>> >
>> > This proposal would remove the 25% utilization (within 30 days of
>> issuance)
>> > criteria bullet point from NRPM 4.3.3.
>> >
>> > ___
>> > 2. Comments
>> >
>> > A. ARIN Staff Comments
>> > This policy would more closely align with the way staff applies the
>> existing
>> > policy in relation to 8.3 transfers. Because there is no longer an
>> IPv4
>> free
>> > pool and many IPv4 requests are likely to be satisfied by 8.3
>> transfers,
>> the
>> > adoption of this policy should have no major impact on operations and
>> could
>> > be implemented as written.
>> >
>> > Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to
>> obsolete
>> > RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use
>> (within
>> 30
>> > days of issuance) requirement.
>> >
>> > Staff suggests removing the first two sentences of 4.2.3.6 to remove
>> the
>> > references to RFC 2050 and the 25% requirement. Additionally, staff
>> suggests
>> > removing the reference to the obsolete RFC 2050 in section 4.3.3.
>> >
>> > B. ARIN General Counsel ??? Legal Assessment
>> > No material legal risk in this policy.
>> >
>> > ___
>> > 3. Resource Impact
>> >
>> > This policy would have minimal resource impact from an implementation
>> > aspect. It is estimated that implementation would occur immediately
>> after
>> > ratification by the ARIN Board of Trustees. The following would be
>> needed in
>> > order to implement:
>> > * Updated guidelines and internal procedures
>> > * Staff training
>> > _______________________________________________
>> > 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.
>>
>>
>>
>> --
>> ===============================================
>> 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<tel:612-626-0815>
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952<tel: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<mailto:ARIN-PPML at arin.net>).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com<mailto:jschiller at google.com>|571-266-0006<tel:571-266-0006>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.


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



--
_______________________________________________________
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/20160512/3fc0f7d8/attachment.htm>

From jcurran at arin.net  Thu May 12 17:15:09 2016
From: jcurran at arin.net (John Curran)
Date: Thu, 12 May 2016 21:15:09 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAC4yj2XNAuQY4J4YCw+iT=n+-dCCabr-JGZm56Qi7_FUudh+EA@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<1f09bac3c71ac0fdc783e8f455784478.squirrel@mail.panix.com>
	<CAC4yj2XNAuQY4J4YCw+iT=n+-dCCabr-JGZm56Qi7_FUudh+EA@mail.gmail.com>
Message-ID: <547D7971-ECB8-4580-9643-0DBE472AE321@corp.arin.net>

On May 12, 2016, at 4:03 PM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>> wrote:

I am surprised that staff would not apply the 30 day need (albeit extended to 60 day need) for end-sites requesting a transfer.

My understanding is that 8.3 references "demonstrating need" "under current policies" albeit extended to 24 months (double an ARIN assignment).

Current policy 4.3.3 defines meeting 25% utilization immediately (30 days) and 50% within 1 year.
Extended this doubles the values.

Jason -

    The present 25% utilization language of NRPM 4.3.3 assignments
    seems to be subject to several possible interpretations when being
    extrapolated to transfers sized upon a 24 month need-assessment.

    Whether the ?immediate? threshold is applied at 30 vs 60 days is
    but one example.  Another is the application of the term ?25%? -
    i.e. that can be the immediate use of transferred space which
    corresponds to 25% of 12 month need (initial usage of the same
    amount of space as would apply for receiving an assignment);
    alternatively, it could be read as 25% utilization of the entire
    transferred block.  The latter interpretation is actually a higher
    bar than 25% utilization when applied to initial assignments sized
    at 12 months need (and could be difficult for many organizations
    to satisfy.)

    As such, if ARIN-2015-3 does not proceed, it would be quite helpful
    if the community would undertake policy development to clarify
    exactly how this portion of assignment policy should apply to
    transfers of number resource to end-user organizations.

Thanks!
/John

John Curran
President and CEO
ARIN

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

From owen at delong.com  Thu May 12 17:26:21 2016
From: owen at delong.com (Owen DeLong)
Date: Thu, 12 May 2016 14:26:21 -0700
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
	Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <BL2PR07MB240452752C019C9DEF9E8505A1730@BL2PR07MB2404.namprd07.prod.outlook.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<1f09bac3c71ac0fdc783e8f455784478.squirrel@mail.panix.com>
	<CAC4yj2XNAuQY4J4YCw+iT=n+-dCCabr-JGZm56Qi7_FUudh+EA@mail.gmail.com>
	<BL2PR07MB240452752C019C9DEF9E8505A1730@BL2PR07MB2404.namprd07.prod.outlook.com>
Message-ID: <3B97BF1B-59E4-4D32-9922-EFE888253533@delong.com>

Milton,

Despite your continued assertion of this position, no, there are a number of us who believe that needs assessment remains valid in the absence of a free pool as a mechanism to ensure that resources are not going to organizations without need.

While it is clear you do not perceive this as necessary, it does not make everyone who disagrees with you inherently wrong, nor does it indicate that we are disconnected from reality.

Owen

> On May 12, 2016, at 13:58 , Mueller, Milton L <milton at gatech.edu> wrote:
> 
> Jason
> It seems that the criteria you apply to demonstrated need presumes the existence of a free pool that must be ?conserved? through traditional needs assessment methods. It overlooks the fact that going forward, we will be dealing exclusively with transfers. In other words, if companies overestimate their needs, due to ?delusions of grandeur? or any other reason, they will have to pay dearly for that. Furthermore, the supply of those addresses will be coming from people who are, by definition, not in need of them at all. So on the whole, I find your arguments completely unconvincing. The only risk you have identified is that some small organization might pay for more than they turn out to need.
>  
> --MM
>  
>  
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason Schiller
> Sent: Thursday, May 12, 2016 4:04 PM
> To: David R Huberman <daveid at panix.com>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy
>  
> I am surprised that staff would not apply the 30 day need (albeit extended to 60 day need) for end-sites requesting a transfer.
>  
> My understanding is that 8.3 references "demonstrating need" "under current policies" albeit extended to 24 months (double an ARIN assignment).
>  
> Current policy 4.3.3 defines meeting 25% utilization immediately (30 days) and 50% within 1 year.  
> Extended this doubles the values.
>  
> This is also seems to be consistent with what I heard at the meeting:
>  
> "Kevin Blumberg:  The question was, to clarify for everybody, when it comes -- this policy is in reference to free pool space. When you take into account that almost every request will now be based on transfer via 8.3 or 8.4, which has a 24-month, can you explain how staff calculates in transfers versus what -- when somebody is just reading and saying 25 percent over 30 days, how does that now work with a 24-month transfer?
>  
> John Curran:  It still requires them to use 25 percent of the block being transferred. Now, this is the unfortunate circumstance of having transfer policies which chained to needs assessment which come from allocation and assignment policies in elsewhere in the NRPM.
>  
> When the AC has some free time, if it would like to unwind those, that would be greatly appreciated."
>  
>  
> I trust ARIN is very good at finding fraud and abuse, however I think this change makes fraud and abuse (or as Owen put it simply having dreams of grandeur [note this was wrt 2015-9 but it applies equally here].)  makes it much harder to catch as per Jonh's comments when discussing this policy.
>  
> "John Curran:  We can go back on the present policy and confirm that someone has done the utilization that they claim they do, but it's much more difficult to know whether or not someone has made a fraudulent request if we don't check shortly after we've assigned to them.
>  
> In other words, someone will find address space utilization within a year one way or the other. But whether or not they're valid for what we assigned is much easier to determine if they've made use of it within the first 30 days, or 30 days, 60 days, the immediate future."
>  
> Can staff comment do you apply the 25% need in 60 days to specified transfers?  Or is this ignored and obsolete? 
>  
> __Jason
>  
> On Tue, May 10, 2016 at 6:10 PM, David R Huberman <daveid at panix.com <mailto:daveid at panix.com>> wrote:
> Jason,
> 
> 1) The policy in last call removes a criterion that is not being applied
> today.  Staff have criteria they use to judge 24-month need, and have been
> applying it for years without coming back to us and telling us there's a
> problem or deficiency.
> 
> 2) Most requestors (99%? 98%?) tell the truth.  They're just trying to
> operate a network, and aren't attempting to defraud ARIN In any way. ARIN
> staff have been fighting scammers for a very long time, and are very good
> at it. They have measurable positive results in fighting fraud.
> 
> For those two reasons, I believe this policy should be adopted by the
> board, and an obsolete criterion should be removed from NRPM.
> 
> David
> 
> 
> > I seem to have missed the this thread in last call, and hope you
> > will consider the discussion on the other thread: " Re: [arin-ppml]
> > ARIN-2015-3:(remove 30-day...) Staff interpretation needed"
> >
> >  I maintain that the 30-day [60-day for transfers] check has
> > been useful in mitigating abusively large requests, and
> > without it there is no teeth in the policy to prevent abuse.
> >
> >
> > I asked if I was wrong about this, please explain what
> > mechanisms are in place to mitigate an end-user asking for
> > approval for a 10 year supply of addresses on the grounds that
> > if things go really really well, it will only be a 2 year supply?
> >
> > I heard no response to indicate there was any mechanism.
> >
> >
> > I asked staff about information about stats that might help
> > determine what level of push back ARIN provides against two
> > year projected need in general, and if that push back would be
> > sufficient to prevent outlandishly large claims.
> >
> > We found that 50% - 75% of all requests are approved with
> > past utilization more heavily weighed.
> >
> > It remains unclear what level of oversight ARIN has to
> > question future looking projections.  John Curran provided
> > some text about approvals of future looking projections.
> >
> >    "When we [ARIN] ask organization for their forward
> >     projections, we [ARIN] also ask them to provide details
> >    to show how they've arrived at their projections. We [ARIN]
> >    take into account factors such as new networks, locations,
> >    products, services they plan on offering (and this includes
> >    consideration of anticipated address utilization within the
> >    first 30 days for end-users.)
> >
> >>From the text John provided it seems one could get IP
> > addresses solely on future looking plans which are
> > unverifiable.  As such an end-user could easily get a 10
> > year supply of addresses simply by providing very
> > optimistic deployment plans for the next 24 months.
> >
> >
> >
> > I asked if I was not wrong about this, then did people realize
> > that this policy is basically an end-run around giving out
> > addresses based on need when they voted to move this
> > policy forward?
> >
> > I heard no response to this.
> >
> > Thanks,
> >
> > __Jason
> >
> >
> > On Thu, May 5, 2016 at 11:45 AM, David Farmer <farmer at umn.edu <mailto:farmer at umn.edu>> wrote:
> >
> >> As shepherd for this policy I welcome any additional last call
> >> feedback for this policy.  It is especially important to speak up if
> >> you feel there are any issues remaining that need to be considered.
> >> But, even if you simply support the policy as written that is
> >> important and useful feedback as well.
> >>
> >> The last call period formally continues through, Monday, May 9th, and
> >> the AC will consider the feedback during its scheduled call on
> >> Thursday, May 19th.
> >>
> >> Thanks
> >>
> >> On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net <mailto:info at arin.net>> wrote:
> >> > The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
> >> > send the following to last call:
> >> >
> >> >   Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
> >> > requirement in end-user IPv4 policy
> >> >
> >> > Feedback is encouraged during the last call period. All comments
> >> should
> >> > be provided to the Public Policy Mailing List. This last call will
> >> > expire on 9 May 2016. After last call the AC will conduct their
> >> > last call review.
> >> >
> >> > The draft policy text is below and available at:
> >> > https://www.arin.net/policy/proposals/ <https://www.arin.net/policy/proposals/>
> >> >
> >> > The ARIN Policy Development Process is available at:
> >> > https://www.arin.net/policy/pdp.html <https://www.arin.net/policy/pdp.html>
> >> >
> >> > Regards,
> >> >
> >> > Communications and Member Services
> >> > American Registry for Internet Numbers (ARIN)
> >> >
> >> >
> >> > ## * ##
> >> >
> >> >
> >> > Recommended Draft Policy ARIN-2015-3
> >> > Remove 30 day utilization requirement in end-user IPv4 policy
> >> >
> >> > AC's assessment of conformance with the Principles of Internet Number
> >> > Resource Policy:
> >> >
> >> > ARIN 2015-3 contributes to fair and impartial number resource
> >> administration
> >> > by removing from the NRPM text that is operationally unrealistic for
> >> the
> >> > reasons discussed in the problem statement. This proposal is
> >> technically
> >> > sound, in that the removal of the text will more closely align with
> >> the
> >> way
> >> > staff applies the existing policy in relation to 8.3 transfers. There
> >> was
> >> > strong community support for the policy on PPML and at ARIN 36, which
> >> was
> >> > confirmed at ARIN 37. There was a suggestion to replace this text with
> >> an
> >> > alternate requirement. However, the community consensus was to move
> >> forward
> >> > with the removal alone.
> >> >
> >> > The staff and legal review also suggested removing RFC2050 references
> >> and
> >> > pointed out that 4.2.3.6 has an additional 25% immediate use clause,
> >> > community feedback was to deal with those issues separately.
> >> >
> >> > Problem Statement:
> >> >
> >> > End-user policy is intended to provide end-users with a one year
> >> supply
> >> of
> >> > IP addresses. Qualification for a one-year supply requires the network
> >> > operator to utilize at least 25% of the requested addresses within 30
> >> days.
> >> > This text is unrealistic and should be removed.
> >> >
> >> > First, it often takes longer than 30 days to stage equipment and start
> >> > actually using the addresses.
> >> >
> >> > Second, growth is often not that regimented; the forecast is to use X
> >> > addresses over the course of a year, not to use 25% of X within 30
> >> days.
> >> >
> >> > Third, this policy text applies to additional address space requests.
> >> It
> >> is
> >> > incompatible with the requirements of other additional address space
> >> request
> >> > justification which indicates that 80% utilization of existing space
> >> is
> >> > sufficient to justify new space. If a block is at 80%, then often
> >> (almost
> >> > always?) the remaining 80% will be used over the next 30 days and
> >> longer.
> >> > Therefore the operator cannot honestly state they will use 25% of the
> >> > ADDITIONAL space within 30 days of receiving it; they're still trying
> >> to
> >> use
> >> > their older block efficiently.
> >> >
> >> > Fourth, in the face of ARIN exhaustion, some ISPs are starting to not
> >> give
> >> > out /24 (or larger) blocks. So the justification for the 25% rule that
> >> > previously existed (and in fact, applied for many years) is no longer
> >> > germane.
> >> >
> >> > Policy statement:
> >> >
> >> > Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
> >> >
> >> > Resulting text:
> >> >
> >> > 4.3.3. Utilization rate
> >> >
> >> > Utilization rate of address space is a key factor in justifying a new
> >> > assignment of IP address space. Requesters must show exactly how
> >> previous
> >> > address assignments have been utilized and must provide appropriate
> >> details
> >> > to verify their one-year growth projection.
> >> >
> >> > The basic criterion that must be met is a 50% utilization rate within
> >> one
> >> > year.
> >> >
> >> > A greater utilization rate may be required based on individual network
> >> > requirements. Please refer to RFC 2050 for more information on
> >> utilization
> >> > guidelines.
> >> >
> >> > Comments:
> >> >
> >> > a.Timetable for implementation: Immediate
> >> >
> >> > b.Anything else
> >> >
> >> > #####
> >> >
> >> > ARIN STAFF ASSESSMENT
> >> >
> >> > Draft Policy ARIN-2015-3
> >> > Remove 30 day utilization requirement in end-user IPv4 policy
> >> > Date of Assessment: 16 February 2016
> >> >
> >> > ___
> >> > 1. Summary (Staff Understanding)
> >> >
> >> > This proposal would remove the 25% utilization (within 30 days of
> >> issuance)
> >> > criteria bullet point from NRPM 4.3.3.
> >> >
> >> > ___
> >> > 2. Comments
> >> >
> >> > A. ARIN Staff Comments
> >> > This policy would more closely align with the way staff applies the
> >> existing
> >> > policy in relation to 8.3 transfers. Because there is no longer an
> >> IPv4
> >> free
> >> > pool and many IPv4 requests are likely to be satisfied by 8.3
> >> transfers,
> >> the
> >> > adoption of this policy should have no major impact on operations and
> >> could
> >> > be implemented as written.
> >> >
> >> > Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to
> >> obsolete
> >> > RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use
> >> (within
> >> 30
> >> > days of issuance) requirement.
> >> >
> >> > Staff suggests removing the first two sentences of 4.2.3.6 to remove
> >> the
> >> > references to RFC 2050 and the 25% requirement. Additionally, staff
> >> suggests
> >> > removing the reference to the obsolete RFC 2050 in section 4.3.3.
> >> >
> >> > B. ARIN General Counsel ??? Legal Assessment
> >> > No material legal risk in this policy.
> >> >
> >> > ___
> >> > 3. Resource Impact
> >> >
> >> > This policy would have minimal resource impact from an implementation
> >> > aspect. It is estimated that implementation would occur immediately
> >> after
> >> > ratification by the ARIN Board of Trustees. The following would be
> >> needed in
> >> > order to implement:
> >> > * Updated guidelines and internal procedures
> >> > * Staff training
> >> > _______________________________________________
> >> > 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 <tel:612-626-0815>
> >> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <tel: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 <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 <tel:571-266-0006>
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml <http://lists.arin.net/mailman/listinfo/arin-ppml>
> > Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <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/20160512/b0c35165/attachment.htm>

From matthew at matthew.at  Thu May 12 17:34:15 2016
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 12 May 2016 21:34:15 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <3B97BF1B-59E4-4D32-9922-EFE888253533@delong.com>
Message-ID: <em46d83fb1-957b-4783-8ab8-c2995c14bbc4@matthew-t5500>


From: "Owen DeLong" <owen at delong.com>
>Milton,
>
>Despite your continued assertion of this position, no, there are a 
>number of us who believe that needs assessment remains valid in the 
>absence of a free pool as a mechanism to ensure that resources are not 
>going to organizations without need.

You and others may believe that, but as far as I know, nobody has 
produced evidence that shows that needs assessment in fact provides that 
mechanism. Whereas there is significant evidence that - despite needs 
assessment continuing to be supported as policy - resources are in fact 
being locked up by organizations that do not meet the NRPM needs test 
(both existing organizations that no longer meet it, and therefore have 
addresses for sale - and organizations which are using mechanisms 
outside of transfer to assure that their longer-term future needs will 
be adequately met.)

>
>While it is clear you do not perceive this as necessary, it does not 
>make everyone who disagrees with you inherently wrong, nor does it 
>indicate that we are disconnected from reality.

Until evidence is provided that the needs assessment that you and others 
so vehemently argue to continue as policy does in fact perform the 
function that you claim it does at this point in the IPv4 lifecycle, I 
will continue to take that as an indication that you are "disconnected 
from reality", as you put it.

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

From jcurran at arin.net  Thu May 12 17:41:49 2016
From: jcurran at arin.net (John Curran)
Date: Thu, 12 May 2016 21:41:49 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <em46d83fb1-957b-4783-8ab8-c2995c14bbc4@matthew-t5500>
References: <em46d83fb1-957b-4783-8ab8-c2995c14bbc4@matthew-t5500>
Message-ID: <DB2FB4BA-9414-4074-992C-DD719A664031@corp.arin.net>

Folks -

    Please keep the discussion focused on the merits of the various policy positions,
    *rather than characterizations of the participants themselves)

Thanks,
/John

On May 12, 2016, at 5:34 PM, Matthew Kaufman <matthew at matthew.at<mailto:matthew at matthew.at>> wrote:

From: "Owen DeLong" <owen at delong.com<mailto:owen at delong.com>>
Milton,

Despite your continued assertion of this position, no, there are a number of us who believe that needs assessment remains valid in the absence of a free pool as a mechanism to ensure that resources are not going to organizations without need.

You and others may believe that, but as far as I know, nobody has produced evidence that shows that needs assessment in fact provides that mechanism. Whereas there is significant evidence that - despite needs assessment continuing to be supported as policy - resources are in fact being locked up by organizations that do not meet the NRPM needs test (both existing organizations that no longer meet it, and therefore have addresses for sale - and organizations which are using mechanisms outside of transfer to assure that their longer-term future needs will be adequately met.)


While it is clear you do not perceive this as necessary, it does not make everyone who disagrees with you inherently wrong, nor does it indicate that we are disconnected from reality.

Until evidence is provided that the needs assessment that you and others so vehemently argue to continue as policy does in fact perform the function that you claim it does at this point in the IPv4 lifecycle, I will continue to take that as an indication that you are "disconnected from reality", as you put it.

Matthew Kaufman

_______________________________________________
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/20160512/228dde87/attachment.htm>

From daveid at panix.com  Thu May 12 17:56:36 2016
From: daveid at panix.com (David Huberman)
Date: Thu, 12 May 2016 17:56:36 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
	Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <5610B132-401E-4A98-86C0-2A5A5DAE69C7@corp.arin.net>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<1f09bac3c71ac0fdc783e8f455784478.squirrel@mail.panix.com>
	<CAC4yj2XNAuQY4J4YCw+iT=n+-dCCabr-JGZm56Qi7_FUudh+EA@mail.gmail.com>
	<5610B132-401E-4A98-86C0-2A5A5DAE69C7@corp.arin.net>
Message-ID: <4663BA9A-B248-4BE3-BDC1-8ADC8645E7A9@panix.com>

John,

1) how many 8.3 transfers have been approved as of 30 April 2016?

2) of those, how many were reviewed and verified with the explicit requirement that 25% of the requested space to be transferred-in would be used immediately?

David

> On May 12, 2016, at 4:11 PM, John Curran <jcurran at arin.net> wrote:
> 
>> On May 12, 2016, at 4:03 PM, Jason Schiller <jschiller at google.com> wrote:
>> 
>> I am surprised that staff would not apply the 30 day need (albeit extended to 60 day need) for end-sites requesting a transfer.
>> 
>> My understanding is that 8.3 references "demonstrating need" "under current policies" albeit extended to 24 months (double an ARIN assignment).
>> 
>> Current policy 4.3.3 defines meeting 25% utilization immediately (30 days) and 50% within 1 year.  
>> Extended this doubles the values.
>> 
>> This is also seems to be consistent with what I heard at the meeting:
>> 
>> "Kevin Blumberg:  The question was, to clarify for everybody, when it comes -- this policy is in reference to free pool space. When you take into account that almost every request will now be based on transfer via 8.3 or 8.4, which has a 24-month, can you explain how staff calculates in transfers versus what -- when somebody is just reading and saying 25 percent over 30 days, how does that now work with a 24-month transfer?
>> 
>> John Curran:  It still requires them to use 25 percent of the block being transferred. Now, this is the unfortunate circumstance of having transfer policies which chained to needs assessment which come from allocation and assignment policies in elsewhere in the NRPM.
>> 
>> When the AC has some free time, if it would like to unwind those, that would be greatly appreciated."
>> 
>> I trust ARIN is very good at finding fraud and abuse, however I think this change makes fraud and abuse (or as Owen put it simply having dreams of grandeur [note this was wrt 2015-9 but it applies equally here].)  makes it much harder to catch as per Jonh's comments when discussing this policy.
>> 
>> "John Curran:  We can go back on the present policy and confirm that someone has done the utilization that they claim they do, but it's much more difficult to know whether or not someone has made a fraudulent request if we don't check shortly after we've assigned to them.
>> 
>> In other words, someone will find address space utilization within a year one way or the other. But whether or not they're valid for what we assigned is much easier to determine if they've made use of it within the first 30 days, or 30 days, 60 days, the immediate future."
>> 
>> Can staff comment do you apply the 25% need in 60 days to specified transfers?  Or is this ignored and obsolete?
> 
> Jason - 
> 
>   ARIN does not, by default, go back to the organization afterwards and confirm that 
>   they have met the 25% utilization requirement, but organizations must conform to 
>   policy and thus it remains a valid criteria if we should review a request later (e.g. 
>   as a a result of a fraud report.) 
> 
> Thanks,
> /John
> 
> John Curran
> President and CEO
> 
> 



From SRyerse at eclipse-networks.com  Thu May 12 18:01:25 2016
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Thu, 12 May 2016 22:01:25 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <em46d83fb1-957b-4783-8ab8-c2995c14bbc4@matthew-t5500>
References: <3B97BF1B-59E4-4D32-9922-EFE888253533@delong.com>
	<em46d83fb1-957b-4783-8ab8-c2995c14bbc4@matthew-t5500>
Message-ID: <51d64e4f5a8b413fa3cf29382458c6bd@eclipse-networks.com>

I agree with Matthew & Milton.  I?m seeing large legacy holders sell off parts of their blocks small chunks at a time. That is the result of supply and demand and in this case the exhaustion has led to demand from organizations that hold Legacy blocks larger than they need.  This is how the marketplace really works as they see an opportunity to make money filling the demand. The market will reach equilibrium at some point and then true shortages will arise which will increase the price per IP. Pure supply and demand economics. The haves already have cornered the market and the have nots now have to buy from them. Hard to see how any policy will ever stop this normal business cycle.

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

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

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Kaufman
Sent: Thursday, May 12, 2016 5:34 PM
To: Owen DeLong <owen at delong.com>; Mueller, Milton L <milton at gatech.edu>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy


From: "Owen DeLong" <owen at delong.com<mailto:owen at delong.com>>
Milton,

Despite your continued assertion of this position, no, there are a number of us who believe that needs assessment remains valid in the absence of a free pool as a mechanism to ensure that resources are not going to organizations without need.

You and others may believe that, but as far as I know, nobody has produced evidence that shows that needs assessment in fact provides that mechanism. Whereas there is significant evidence that - despite needs assessment continuing to be supported as policy - resources are in fact being locked up by organizations that do not meet the NRPM needs test (both existing organizations that no longer meet it, and therefore have addresses for sale - and organizations which are using mechanisms outside of transfer to assure that their longer-term future needs will be adequately met.)


While it is clear you do not perceive this as necessary, it does not make everyone who disagrees with you inherently wrong, nor does it indicate that we are disconnected from reality.

Until evidence is provided that the needs assessment that you and others so vehemently argue to continue as policy does in fact perform the function that you claim it does at this point in the IPv4 lifecycle, I will continue to take that as an indication that you are "disconnected from reality", as you put it.

Matthew Kaufman

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

From jcurran at arin.net  Thu May 12 18:37:57 2016
From: jcurran at arin.net (John Curran)
Date: Thu, 12 May 2016 22:37:57 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <4663BA9A-B248-4BE3-BDC1-8ADC8645E7A9@panix.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<1f09bac3c71ac0fdc783e8f455784478.squirrel@mail.panix.com>
	<CAC4yj2XNAuQY4J4YCw+iT=n+-dCCabr-JGZm56Qi7_FUudh+EA@mail.gmail.com>
	<5610B132-401E-4A98-86C0-2A5A5DAE69C7@corp.arin.net>
	<4663BA9A-B248-4BE3-BDC1-8ADC8645E7A9@panix.com>
Message-ID: <63F5869C-81AB-47B0-9BC7-9D8C23B27BF6@arin.net>

On May 12, 2016, at 5:56 PM, David Huberman <daveid at panix.com<mailto:daveid at panix.com>> wrote:

John,

1) how many 8.3 transfers have been approved as of 30 April 2016?

Do you mean transfers since IPv4 transfer policy inception, or simply in 2015?
(They are all listed here:  https://www.arin.net/knowledge/statistics/transfers.html)

2) of those, how many were reviewed and verified with the explicit requirement that 25% of the requested space to be transferred-in would be used immediately?

Such a requirement could only be applicable transfers to end-users who were demonstrating
their 24-month need using NRPM 4.3.3, and there is no clear interpretation for application of
the  "25% immediate utilization rate? language.   As such, it is not directly considered during
the process (as elaborated by Richard Jimmerson on the list); therefore none were ?reviewed
and verified explicitly? for that purpose.

Note that the language remains applicable (and organizations that attempt to transfer without
having immediate utilization do run the risk of number resource fraud), but is not integrated
into the end-user transfer review process as its extrapolation into that context is unclear.
This is also why the staff and legal review for draft policy 2015-3 notes - "This policy would
more closely align with the way staff applies the existing policy in relation to 8.3 transfers.?

Thanks!
/John

John Curran
President and CEO
ARIN

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

From daveid at panix.com  Thu May 12 18:42:56 2016
From: daveid at panix.com (David Huberman)
Date: Thu, 12 May 2016 18:42:56 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
	Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <63F5869C-81AB-47B0-9BC7-9D8C23B27BF6@arin.net>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<1f09bac3c71ac0fdc783e8f455784478.squirrel@mail.panix.com>
	<CAC4yj2XNAuQY4J4YCw+iT=n+-dCCabr-JGZm56Qi7_FUudh+EA@mail.gmail.com>
	<5610B132-401E-4A98-86C0-2A5A5DAE69C7@corp.arin.net>
	<4663BA9A-B248-4BE3-BDC1-8ADC8645E7A9@panix.com>
	<63F5869C-81AB-47B0-9BC7-9D8C23B27BF6@arin.net>
Message-ID: <12162F05-2543-4B01-AC6C-9F80BE457505@panix.com>

Thank you John.

I reiterate my last post.  The criterion is obsolete and this recommended draft policy should proceed through PDP.

> On May 12, 2016, at 6:37 PM, John Curran <jcurran at arin.net> wrote:
> 
>> On May 12, 2016, at 5:56 PM, David Huberman <daveid at panix.com> wrote:
>> 
>> John,
>> 
>> 1) how many 8.3 transfers have been approved as of 30 April 2016?
> 
> Do you mean transfers since IPv4 transfer policy inception, or simply in 2015?
> (They are all listed here:  https://www.arin.net/knowledge/statistics/transfers.html)
> 
>> 2) of those, how many were reviewed and verified with the explicit requirement that 25% of the requested space to be transferred-in would be used immediately?
> 
> Such a requirement could only be applicable transfers to end-users who were demonstrating 
> their 24-month need using NRPM 4.3.3, and there is no clear interpretation for application of
> the  "25% immediate utilization rate? language.   As such, it is not directly considered during
> the process (as elaborated by Richard Jimmerson on the list); therefore none were ?reviewed
> and verified explicitly? for that purpose.
> 
> Note that the language remains applicable (and organizations that attempt to transfer without
> having immediate utilization do run the risk of number resource fraud), but is not integrated 
> into the end-user transfer review process as its extrapolation into that context is unclear.  
> This is also why the staff and legal review for draft policy 2015-3 notes - "This policy would 
> more closely align with the way staff applies the existing policy in relation to 8.3 transfers.?
> 
> Thanks!
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160512/2a4ffc62/attachment.htm>

From farmer at umn.edu  Thu May 12 20:46:03 2016
From: farmer at umn.edu (David Farmer)
Date: Thu, 12 May 2016 19:46:03 -0500
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <DB2FB4BA-9414-4074-992C-DD719A664031@corp.arin.net>
References: <em46d83fb1-957b-4783-8ab8-c2995c14bbc4@matthew-t5500>
	<DB2FB4BA-9414-4074-992C-DD719A664031@corp.arin.net>
Message-ID: <CAN-Dau3oo+-M6_LWoyGovucsWP+ZrUZgT2ffkhhyvdrQ3jMbmw@mail.gmail.com>

Matthew, Steven, Owen, and Milton,

Since, ARIN-2015-3 is in last call, it would also be helpful if you
could comment more directly on the specific merits of or issues with
this policy, and take discussion of other more generic issues to
another thread.  Furthermore, since you commented on the last call
thread for this policy, would you please clarify do your position on
that policy.  Is it ready to go to the board for adoption or are there
issues that need additional work?

Thanks.

On Thu, May 12, 2016 at 4:41 PM, John Curran <jcurran at arin.net> wrote:
> Folks -
>
>     Please keep the discussion focused on the merits of the various policy
> positions,
>     *rather than characterizations of the participants themselves)
>
> Thanks,
> /John


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


From matthew at matthew.at  Thu May 12 20:51:25 2016
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 12 May 2016 17:51:25 -0700
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
	Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAN-Dau3oo+-M6_LWoyGovucsWP+ZrUZgT2ffkhhyvdrQ3jMbmw@mail.gmail.com>
References: <em46d83fb1-957b-4783-8ab8-c2995c14bbc4@matthew-t5500>
	<DB2FB4BA-9414-4074-992C-DD719A664031@corp.arin.net>
	<CAN-Dau3oo+-M6_LWoyGovucsWP+ZrUZgT2ffkhhyvdrQ3jMbmw@mail.gmail.com>
Message-ID: <193984AC-9002-43A8-A498-2E06428AF2E4@matthew.at>

I support the policy as written.
I also agree with staff suggestions to remove additional outdated language, but history suggests that we can only get a few words removed with each policy proposal.

I would also support removal of all needs assessment language for the transfer cases.

Matthew Kaufman

(Sent from my iPhone)

> On May 12, 2016, at 5:46 PM, David Farmer <farmer at umn.edu> wrote:
> 
> Matthew, Steven, Owen, and Milton,
> 
> Since, ARIN-2015-3 is in last call, it would also be helpful if you
> could comment more directly on the specific merits of or issues with
> this policy, and take discussion of other more generic issues to
> another thread.  Furthermore, since you commented on the last call
> thread for this policy, would you please clarify do your position on
> that policy.  Is it ready to go to the board for adoption or are there
> issues that need additional work?
> 
> Thanks.
> 
>> On Thu, May 12, 2016 at 4:41 PM, John Curran <jcurran at arin.net> wrote:
>> Folks -
>> 
>>    Please keep the discussion focused on the merits of the various policy
>> positions,
>>    *rather than characterizations of the participants themselves)
>> 
>> Thanks,
>> /John
> 
> 
> -- 
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================



From farmer at umn.edu  Thu May 12 21:53:08 2016
From: farmer at umn.edu (David Farmer)
Date: Thu, 12 May 2016 20:53:08 -0500
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
Message-ID: <CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>

Jason,

Even though the last call period formally ended May 9th, I try my best
to consider all feedback received for a policy even following the
formal last call deadline, and while I can't speak for directly for
other AC members, I believe most of them do the same.  However, when
feedback comes in late sometimes it might not get full consideration,
especially if it comes in immediately prior to one of our conference
calls.  To help avoid this I explicitly noted when AC would be
considering the feedback.  I will additionally note at this point it
is extremely important to get any additional feedback in ASAP to allow
the AC due time for its consideration prior to its May 19th conference
call.

As for the issues and questions you have raise, I believe John and
Richard have been answering your questions.  Further, I believe the
community consensus remains to move forward with removing the 25%
Immediate (30 day) use requirement for end users as this policy
suggests.  I would specifically ask anyone who disagrees and thinks we
need to consider the issues more to speak up ASAP.

Thanks.

On Tue, May 10, 2016 at 11:32 AM, Jason Schiller <jschiller at google.com> wrote:
> I seem to have missed the this thread in last call, and hope you
> will consider the discussion on the other thread: " Re: [arin-ppml]
> ARIN-2015-3:(remove 30-day...) Staff interpretation needed"
>
>  I maintain that the 30-day [60-day for transfers] check has
> been useful in mitigating abusively large requests, and
> without it there is no teeth in the policy to prevent abuse.
>
>
> I asked if I was wrong about this, please explain what
> mechanisms are in place to mitigate an end-user asking for
> approval for a 10 year supply of addresses on the grounds that
> if things go really really well, it will only be a 2 year supply?
>
> I heard no response to indicate there was any mechanism.
>
>
> I asked staff about information about stats that might help
> determine what level of push back ARIN provides against two
> year projected need in general, and if that push back would be
> sufficient to prevent outlandishly large claims.
>
> We found that 50% - 75% of all requests are approved with
> past utilization more heavily weighed.
>
> It remains unclear what level of oversight ARIN has to
> question future looking projections.  John Curran provided
> some text about approvals of future looking projections.
>
>    "When we [ARIN] ask organization for their forward
>     projections, we [ARIN] also ask them to provide details
>    to show how they've arrived at their projections. We [ARIN]
>    take into account factors such as new networks, locations,
>    products, services they plan on offering (and this includes
>    consideration of anticipated address utilization within the
>    first 30 days for end-users.)
>
> From the text John provided it seems one could get IP
> addresses solely on future looking plans which are
> unverifiable.  As such an end-user could easily get a 10
> year supply of addresses simply by providing very
> optimistic deployment plans for the next 24 months.
>
>
>
> I asked if I was not wrong about this, then did people realize
> that this policy is basically an end-run around giving out
> addresses based on need when they voted to move this
> policy forward?
>
> I heard no response to this.
>
> Thanks,
>
> __Jason
>
>
> On Thu, May 5, 2016 at 11:45 AM, David Farmer <farmer at umn.edu> wrote:
>>
>> As shepherd for this policy I welcome any additional last call
>> feedback for this policy.  It is especially important to speak up if
>> you feel there are any issues remaining that need to be considered.
>> But, even if you simply support the policy as written that is
>> important and useful feedback as well.
>>
>> The last call period formally continues through, Monday, May 9th, and
>> the AC will consider the feedback during its scheduled call on
>> Thursday, May 19th.
>>
>> Thanks
>>
>> On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net> wrote:
>> > The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
>> > send the following to last call:
>> >
>> >   Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
>> > requirement in end-user IPv4 policy
>> >
>> > Feedback is encouraged during the last call period. All comments should
>> > be provided to the Public Policy Mailing List. This last call will
>> > expire on 9 May 2016. After last call the AC will conduct their
>> > last call review.
>> >
>> > The draft policy text is below and available at:
>> > https://www.arin.net/policy/proposals/
>> >
>> > The ARIN Policy Development Process is available at:
>> > https://www.arin.net/policy/pdp.html
>> >
>> > Regards,
>> >
>> > Communications and Member Services
>> > American Registry for Internet Numbers (ARIN)
>> >
>> >
>> > ## * ##
>> >
>> >
>> > Recommended Draft Policy ARIN-2015-3
>> > Remove 30 day utilization requirement in end-user IPv4 policy
>> >
>> > AC's assessment of conformance with the Principles of Internet Number
>> > Resource Policy:
>> >
>> > ARIN 2015-3 contributes to fair and impartial number resource
>> > administration
>> > by removing from the NRPM text that is operationally unrealistic for the
>> > reasons discussed in the problem statement. This proposal is technically
>> > sound, in that the removal of the text will more closely align with the
>> > way
>> > staff applies the existing policy in relation to 8.3 transfers. There
>> > was
>> > strong community support for the policy on PPML and at ARIN 36, which
>> > was
>> > confirmed at ARIN 37. There was a suggestion to replace this text with
>> > an
>> > alternate requirement. However, the community consensus was to move
>> > forward
>> > with the removal alone.
>> >
>> > The staff and legal review also suggested removing RFC2050 references
>> > and
>> > pointed out that 4.2.3.6 has an additional 25% immediate use clause,
>> > community feedback was to deal with those issues separately.
>> >
>> > Problem Statement:
>> >
>> > End-user policy is intended to provide end-users with a one year supply
>> > of
>> > IP addresses. Qualification for a one-year supply requires the network
>> > operator to utilize at least 25% of the requested addresses within 30
>> > days.
>> > This text is unrealistic and should be removed.
>> >
>> > First, it often takes longer than 30 days to stage equipment and start
>> > actually using the addresses.
>> >
>> > Second, growth is often not that regimented; the forecast is to use X
>> > addresses over the course of a year, not to use 25% of X within 30 days.
>> >
>> > Third, this policy text applies to additional address space requests. It
>> > is
>> > incompatible with the requirements of other additional address space
>> > request
>> > justification which indicates that 80% utilization of existing space is
>> > sufficient to justify new space. If a block is at 80%, then often
>> > (almost
>> > always?) the remaining 80% will be used over the next 30 days and
>> > longer.
>> > Therefore the operator cannot honestly state they will use 25% of the
>> > ADDITIONAL space within 30 days of receiving it; they're still trying to
>> > use
>> > their older block efficiently.
>> >
>> > Fourth, in the face of ARIN exhaustion, some ISPs are starting to not
>> > give
>> > out /24 (or larger) blocks. So the justification for the 25% rule that
>> > previously existed (and in fact, applied for many years) is no longer
>> > germane.
>> >
>> > Policy statement:
>> >
>> > Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
>> >
>> > Resulting text:
>> >
>> > 4.3.3. Utilization rate
>> >
>> > Utilization rate of address space is a key factor in justifying a new
>> > assignment of IP address space. Requesters must show exactly how
>> > previous
>> > address assignments have been utilized and must provide appropriate
>> > details
>> > to verify their one-year growth projection.
>> >
>> > The basic criterion that must be met is a 50% utilization rate within
>> > one
>> > year.
>> >
>> > A greater utilization rate may be required based on individual network
>> > requirements. Please refer to RFC 2050 for more information on
>> > utilization
>> > guidelines.
>> >
>> > Comments:
>> >
>> > a.Timetable for implementation: Immediate
>> >
>> > b.Anything else
>> >
>> > #####
>> >
>> > ARIN STAFF ASSESSMENT
>> >
>> > Draft Policy ARIN-2015-3
>> > Remove 30 day utilization requirement in end-user IPv4 policy
>> > Date of Assessment: 16 February 2016
>> >
>> > ___
>> > 1. Summary (Staff Understanding)
>> >
>> > This proposal would remove the 25% utilization (within 30 days of
>> > issuance)
>> > criteria bullet point from NRPM 4.3.3.
>> >
>> > ___
>> > 2. Comments
>> >
>> > A. ARIN Staff Comments
>> > This policy would more closely align with the way staff applies the
>> > existing
>> > policy in relation to 8.3 transfers. Because there is no longer an IPv4
>> > free
>> > pool and many IPv4 requests are likely to be satisfied by 8.3 transfers,
>> > the
>> > adoption of this policy should have no major impact on operations and
>> > could
>> > be implemented as written.
>> >
>> > Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to
>> > obsolete
>> > RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within
>> > 30
>> > days of issuance) requirement.
>> >
>> > Staff suggests removing the first two sentences of 4.2.3.6 to remove the
>> > references to RFC 2050 and the 25% requirement. Additionally, staff
>> > suggests
>> > removing the reference to the obsolete RFC 2050 in section 4.3.3.
>> >
>> > B. ARIN General Counsel ? Legal Assessment
>> > No material legal risk in this policy.
>> >
>> > ___
>> > 3. Resource Impact
>> >
>> > This policy would have minimal resource impact from an implementation
>> > aspect. It is estimated that implementation would occur immediately
>> > after
>> > ratification by the ARIN Board of Trustees. The following would be
>> > needed in
>> > order to implement:
>> > * Updated guidelines and internal procedures
>> > * Staff training
>> > _______________________________________________
>> > PPML
>> > You are receiving this message 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
>> ===============================================
>> _______________________________________________
>> PPML
>> You are receiving this message 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
>



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


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

Total of 39 messages in the last 7 days.
 
script run at: Fri May 13 00:53:03 EDT 2016
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 17.95% |    7 | 23.31% |   175629 | jschiller at google.com
 12.82% |    5 | 12.72% |    95851 | jcurran at arin.net
  7.69% |    3 | 12.25% |    92303 | owen at delong.com
  7.69% |    3 |  4.77% |    35927 | daveid at panix.com
  2.56% |    1 |  8.62% |    64937 | milton at gatech.edu
  5.13% |    2 |  5.10% |    38448 | richardj at arin.net
  5.13% |    2 |  3.68% |    27693 | farmer at umn.edu
  5.13% |    2 |  2.35% |    17741 | matthew at matthew.at
  5.13% |    2 |  1.84% |    13833 | bill at herrin.us
  5.13% |    2 |  1.50% |    11314 | info at arin.net
  2.56% |    1 |  3.73% |    28101 | sryerse at eclipse-networks.com
  2.56% |    1 |  3.73% |    28090 | ctacit at tacitlaw.com
  2.56% |    1 |  3.44% |    25933 | scottleibrand at gmail.com
  2.56% |    1 |  3.30% |    24851 | bjones at vt.edu
  2.56% |    1 |  2.81% |    21134 | lists at mtin.net
  2.56% |    1 |  2.22% |    16716 | cblecker at gmail.com
  2.56% |    1 |  1.80% |    13577 | elvis at velea.eu
  2.56% |    1 |  0.99% |     7473 | gary.buhrmaster at gmail.com
  2.56% |    1 |  0.92% |     6937 | narten at us.ibm.com
  2.56% |    1 |  0.91% |     6885 | michael at linuxmagic.com
--------+------+--------+----------+------------------------
100.00% |   39 |100.00% |   753373 | Total



From owen at delong.com  Fri May 13 01:04:39 2016
From: owen at delong.com (Owen DeLong)
Date: Thu, 12 May 2016 22:04:39 -0700
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
	Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <em46d83fb1-957b-4783-8ab8-c2995c14bbc4@matthew-t5500>
References: <em46d83fb1-957b-4783-8ab8-c2995c14bbc4@matthew-t5500>
Message-ID: <2289AAB2-A2D4-4414-B457-F1DF51FE3E34@delong.com>


> On May 12, 2016, at 14:34 , Matthew Kaufman <matthew at matthew.at> wrote:
> 
>  
> From: "Owen DeLong" <owen at delong.com <mailto:owen at delong.com>>
>> Milton, 
>> 
>> Despite your continued assertion of this position, no, there are a number of us who believe that needs assessment remains valid in the absence of a free pool as a mechanism to ensure that resources are not going to organizations without need.
>  
> You and others may believe that, but as far as I know, nobody has produced evidence that shows that needs assessment in fact provides that mechanism. Whereas there is significant evidence that - despite needs assessment continuing to be supported as policy - resources are in fact being locked up by organizations that do not meet the NRPM needs test (both existing organizations that no longer meet it, and therefore have addresses for sale - and organizations which are using mechanisms outside of transfer to assure that their longer-term future needs will be adequately met.)

Noone denies that bad actors can be bad actors in a system which is 100% dependent on voluntary compliance.

The question is whether you abandon all hope of useful policy in favor of accepting those actions or you continue to hope that the majority of people will act honestly within the system and according to the guidelines developed by the consensus of the community.

>> While it is clear you do not perceive this as necessary, it does not make everyone who disagrees with you inherently wrong, nor does it indicate that we are disconnected from reality.
>  
> Until evidence is provided that the needs assessment that you and others so vehemently argue to continue as policy does in fact perform the function that you claim it does at this point in the IPv4 lifecycle, I will continue to take that as an indication that you are "disconnected from reality", as you put it.

While it does not perform that function 100% effectively, as no policy in our entire system can be 100% effective so long as there are bad actors willing to circumvent that policy and we ave no enforcement mechanism, it is at least as effective as any other policy in the NRPM.

I suppose you can claim that attempting to have community developed policy without an enforcement mechanism is somehow disconnected from reality, but if that is the case, then, your argument is that the entire multi-stakeholder process and NRPM are disconnected from reality. You?re welcome to make that argument, but if you wish to do so, I would suggest you will find a more sympathetic audience in the ITU.

Owen

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

From owen at delong.com  Fri May 13 01:06:48 2016
From: owen at delong.com (Owen DeLong)
Date: Thu, 12 May 2016 22:06:48 -0700
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
	Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
Message-ID: <C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>

I see the policy itself largely as a no-op. I have no objection for it going to the board,
nor do I have any significant support for it to do so.

Owen

> On May 12, 2016, at 18:53 , David Farmer <farmer at umn.edu> wrote:
> 
> Jason,
> 
> Even though the last call period formally ended May 9th, I try my best
> to consider all feedback received for a policy even following the
> formal last call deadline, and while I can't speak for directly for
> other AC members, I believe most of them do the same.  However, when
> feedback comes in late sometimes it might not get full consideration,
> especially if it comes in immediately prior to one of our conference
> calls.  To help avoid this I explicitly noted when AC would be
> considering the feedback.  I will additionally note at this point it
> is extremely important to get any additional feedback in ASAP to allow
> the AC due time for its consideration prior to its May 19th conference
> call.
> 
> As for the issues and questions you have raise, I believe John and
> Richard have been answering your questions.  Further, I believe the
> community consensus remains to move forward with removing the 25%
> Immediate (30 day) use requirement for end users as this policy
> suggests.  I would specifically ask anyone who disagrees and thinks we
> need to consider the issues more to speak up ASAP.
> 
> Thanks.
> 
> On Tue, May 10, 2016 at 11:32 AM, Jason Schiller <jschiller at google.com <mailto:jschiller at google.com>> wrote:
>> I seem to have missed the this thread in last call, and hope you
>> will consider the discussion on the other thread: " Re: [arin-ppml]
>> ARIN-2015-3:(remove 30-day...) Staff interpretation needed"
>> 
>> I maintain that the 30-day [60-day for transfers] check has
>> been useful in mitigating abusively large requests, and
>> without it there is no teeth in the policy to prevent abuse.
>> 
>> 
>> I asked if I was wrong about this, please explain what
>> mechanisms are in place to mitigate an end-user asking for
>> approval for a 10 year supply of addresses on the grounds that
>> if things go really really well, it will only be a 2 year supply?
>> 
>> I heard no response to indicate there was any mechanism.
>> 
>> 
>> I asked staff about information about stats that might help
>> determine what level of push back ARIN provides against two
>> year projected need in general, and if that push back would be
>> sufficient to prevent outlandishly large claims.
>> 
>> We found that 50% - 75% of all requests are approved with
>> past utilization more heavily weighed.
>> 
>> It remains unclear what level of oversight ARIN has to
>> question future looking projections.  John Curran provided
>> some text about approvals of future looking projections.
>> 
>>   "When we [ARIN] ask organization for their forward
>>    projections, we [ARIN] also ask them to provide details
>>   to show how they've arrived at their projections. We [ARIN]
>>   take into account factors such as new networks, locations,
>>   products, services they plan on offering (and this includes
>>   consideration of anticipated address utilization within the
>>   first 30 days for end-users.)
>> 
>> From the text John provided it seems one could get IP
>> addresses solely on future looking plans which are
>> unverifiable.  As such an end-user could easily get a 10
>> year supply of addresses simply by providing very
>> optimistic deployment plans for the next 24 months.
>> 
>> 
>> 
>> I asked if I was not wrong about this, then did people realize
>> that this policy is basically an end-run around giving out
>> addresses based on need when they voted to move this
>> policy forward?
>> 
>> I heard no response to this.
>> 
>> Thanks,
>> 
>> __Jason
>> 
>> 
>> On Thu, May 5, 2016 at 11:45 AM, David Farmer <farmer at umn.edu> wrote:
>>> 
>>> As shepherd for this policy I welcome any additional last call
>>> feedback for this policy.  It is especially important to speak up if
>>> you feel there are any issues remaining that need to be considered.
>>> But, even if you simply support the policy as written that is
>>> important and useful feedback as well.
>>> 
>>> The last call period formally continues through, Monday, May 9th, and
>>> the AC will consider the feedback during its scheduled call on
>>> Thursday, May 19th.
>>> 
>>> Thanks
>>> 
>>> On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net> wrote:
>>>> The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
>>>> send the following to last call:
>>>> 
>>>>  Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
>>>> requirement in end-user IPv4 policy
>>>> 
>>>> Feedback is encouraged during the last call period. All comments should
>>>> be provided to the Public Policy Mailing List. This last call will
>>>> expire on 9 May 2016. After last call the AC will conduct their
>>>> last call review.
>>>> 
>>>> The draft policy text is below and available at:
>>>> https://www.arin.net/policy/proposals/
>>>> 
>>>> The ARIN Policy Development Process is available at:
>>>> https://www.arin.net/policy/pdp.html
>>>> 
>>>> Regards,
>>>> 
>>>> Communications and Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>> 
>>>> 
>>>> ## * ##
>>>> 
>>>> 
>>>> Recommended Draft Policy ARIN-2015-3
>>>> Remove 30 day utilization requirement in end-user IPv4 policy
>>>> 
>>>> AC's assessment of conformance with the Principles of Internet Number
>>>> Resource Policy:
>>>> 
>>>> ARIN 2015-3 contributes to fair and impartial number resource
>>>> administration
>>>> by removing from the NRPM text that is operationally unrealistic for the
>>>> reasons discussed in the problem statement. This proposal is technically
>>>> sound, in that the removal of the text will more closely align with the
>>>> way
>>>> staff applies the existing policy in relation to 8.3 transfers. There
>>>> was
>>>> strong community support for the policy on PPML and at ARIN 36, which
>>>> was
>>>> confirmed at ARIN 37. There was a suggestion to replace this text with
>>>> an
>>>> alternate requirement. However, the community consensus was to move
>>>> forward
>>>> with the removal alone.
>>>> 
>>>> The staff and legal review also suggested removing RFC2050 references
>>>> and
>>>> pointed out that 4.2.3.6 has an additional 25% immediate use clause,
>>>> community feedback was to deal with those issues separately.
>>>> 
>>>> Problem Statement:
>>>> 
>>>> End-user policy is intended to provide end-users with a one year supply
>>>> of
>>>> IP addresses. Qualification for a one-year supply requires the network
>>>> operator to utilize at least 25% of the requested addresses within 30
>>>> days.
>>>> This text is unrealistic and should be removed.
>>>> 
>>>> First, it often takes longer than 30 days to stage equipment and start
>>>> actually using the addresses.
>>>> 
>>>> Second, growth is often not that regimented; the forecast is to use X
>>>> addresses over the course of a year, not to use 25% of X within 30 days.
>>>> 
>>>> Third, this policy text applies to additional address space requests. It
>>>> is
>>>> incompatible with the requirements of other additional address space
>>>> request
>>>> justification which indicates that 80% utilization of existing space is
>>>> sufficient to justify new space. If a block is at 80%, then often
>>>> (almost
>>>> always?) the remaining 80% will be used over the next 30 days and
>>>> longer.
>>>> Therefore the operator cannot honestly state they will use 25% of the
>>>> ADDITIONAL space within 30 days of receiving it; they're still trying to
>>>> use
>>>> their older block efficiently.
>>>> 
>>>> Fourth, in the face of ARIN exhaustion, some ISPs are starting to not
>>>> give
>>>> out /24 (or larger) blocks. So the justification for the 25% rule that
>>>> previously existed (and in fact, applied for many years) is no longer
>>>> germane.
>>>> 
>>>> Policy statement:
>>>> 
>>>> Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
>>>> 
>>>> Resulting text:
>>>> 
>>>> 4.3.3. Utilization rate
>>>> 
>>>> Utilization rate of address space is a key factor in justifying a new
>>>> assignment of IP address space. Requesters must show exactly how
>>>> previous
>>>> address assignments have been utilized and must provide appropriate
>>>> details
>>>> to verify their one-year growth projection.
>>>> 
>>>> The basic criterion that must be met is a 50% utilization rate within
>>>> one
>>>> year.
>>>> 
>>>> A greater utilization rate may be required based on individual network
>>>> requirements. Please refer to RFC 2050 for more information on
>>>> utilization
>>>> guidelines.
>>>> 
>>>> Comments:
>>>> 
>>>> a.Timetable for implementation: Immediate
>>>> 
>>>> b.Anything else
>>>> 
>>>> #####
>>>> 
>>>> ARIN STAFF ASSESSMENT
>>>> 
>>>> Draft Policy ARIN-2015-3
>>>> Remove 30 day utilization requirement in end-user IPv4 policy
>>>> Date of Assessment: 16 February 2016
>>>> 
>>>> ___
>>>> 1. Summary (Staff Understanding)
>>>> 
>>>> This proposal would remove the 25% utilization (within 30 days of
>>>> issuance)
>>>> criteria bullet point from NRPM 4.3.3.
>>>> 
>>>> ___
>>>> 2. Comments
>>>> 
>>>> A. ARIN Staff Comments
>>>> This policy would more closely align with the way staff applies the
>>>> existing
>>>> policy in relation to 8.3 transfers. Because there is no longer an IPv4
>>>> free
>>>> pool and many IPv4 requests are likely to be satisfied by 8.3 transfers,
>>>> the
>>>> adoption of this policy should have no major impact on operations and
>>>> could
>>>> be implemented as written.
>>>> 
>>>> Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to
>>>> obsolete
>>>> RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within
>>>> 30
>>>> days of issuance) requirement.
>>>> 
>>>> Staff suggests removing the first two sentences of 4.2.3.6 to remove the
>>>> references to RFC 2050 and the 25% requirement. Additionally, staff
>>>> suggests
>>>> removing the reference to the obsolete RFC 2050 in section 4.3.3.
>>>> 
>>>> B. ARIN General Counsel ? Legal Assessment
>>>> No material legal risk in this policy.
>>>> 
>>>> ___
>>>> 3. Resource Impact
>>>> 
>>>> This policy would have minimal resource impact from an implementation
>>>> aspect. It is estimated that implementation would occur immediately
>>>> after
>>>> ratification by the ARIN Board of Trustees. The following would be
>>>> needed in
>>>> order to implement:
>>>> * Updated guidelines and internal procedures
>>>> * Staff training
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message 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
>>> ===============================================
>>> _______________________________________________
>>> PPML
>>> You are receiving this message 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
>> 
> 
> 
> 
> -- 
> ===============================================
> David Farmer               Email:farmer at umn.edu <mailto:farmer at umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <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/20160512/5ac2b31d/attachment.htm>

From milton at gatech.edu  Fri May 13 10:38:36 2016
From: milton at gatech.edu (Mueller, Milton L)
Date: Fri, 13 May 2016 14:38:36 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAN-Dau3oo+-M6_LWoyGovucsWP+ZrUZgT2ffkhhyvdrQ3jMbmw@mail.gmail.com>
References: <em46d83fb1-957b-4783-8ab8-c2995c14bbc4@matthew-t5500>
	<DB2FB4BA-9414-4074-992C-DD719A664031@corp.arin.net>
	<CAN-Dau3oo+-M6_LWoyGovucsWP+ZrUZgT2ffkhhyvdrQ3jMbmw@mail.gmail.com>
Message-ID: <BY2PR07MB240889439D78347CB7908BEDA1740@BY2PR07MB2408.namprd07.prod.outlook.com>

David
I am sorry if it was not clear that I support passage of 2015-3. 
I did comment directly on the policy by refuting the only argument that was made against it. 
--MM

> -----Original Message-----
> Matthew, Steven, Owen, and Milton,
> 
> Since, ARIN-2015-3 is in last call, it would also be helpful if you could
> comment more directly on the specific merits of or issues with this policy, and
> take discussion of other more generic issues to another thread.  Furthermore,
> since you commented on the last call thread for this policy, would you please
> clarify do your position on that policy.  Is it ready to go to the board for
> adoption or are there issues that need additional work?
> 
> Thanks.
> 
> On Thu, May 12, 2016 at 4:41 PM, John Curran <jcurran at arin.net> wrote:
> > Folks -
> >
> >     Please keep the discussion focused on the merits of the various
> > policy positions,
> >     *rather than characterizations of the participants themselves)
> >
> > Thanks,
> > /John
> 
> 
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================

From jrdelacruz at acm.org  Fri May 13 15:14:12 2016
From: jrdelacruz at acm.org (Jose R. de la Cruz III)
Date: Fri, 13 May 2016 15:14:12 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
	Policy
In-Reply-To: <CADx2oGF2mNJk53o0cnqJtZp=BxVvFhQFrc2N=dfsZ+FdoPQO6Q@mail.gmail.com>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
	<313F0B8E-E928-479F-B338-30AFFF77F82F@delong.com>
	<CADx2oGF2mNJk53o0cnqJtZp=BxVvFhQFrc2N=dfsZ+FdoPQO6Q@mail.gmail.com>
Message-ID: <CAKrxPqdUOMfdfp2vz464N1sS5rfsH99R0yRATeXZvXfgpBp1Sw@mail.gmail.com>

I agree with Christopher.

Jos?

On Sun, May 8, 2016 at 9:23 PM, Christoph Blecker <cblecker at gmail.com>
wrote:

> I can't quite imagine a scenario that would merit an 8.3 transfer of
> reserved pool IP space. I think the community is better served to encourage
> reserved pool address holders to return the space back to the reserved pool
> if the need they originally requested the address space for no longer
> exists. As such, I prefer the original policy text.
>
> I'd be open to changing my opinion if someone could explain a scenario
> where an 8.3 transfer is preferable to requesting space from the free pool.
>
> Cheers,
> Christoph
>
> On 5 May 2016 at 12:11, Owen DeLong <owen at delong.com> wrote:
>
>> Speaking strictly for myself and not as a member of the AC?
>>
>> I still fail to see the need for this. Here are the scenarios I can see:
>>
>> 1. Transfer of an operating environment to a new organization through
>> merger/acquisition/reorg:
>>
>> This would be handled in 8.2 and there is no restriction on these blocks
>> in 8.2
>> transfers.
>>
>> 2. Creation of a new operational environment which needs resources and
>> qualifies:
>>
>> Since these reserved pools still have resources available, I see no
>> reason to support
>> their transfer through 8.3 or 8.4.
>>
>> I think the proposed change would be mostly harmless, but I also feel
>> that it serves no useful purpose and would complicate policy unnecessarily.
>>
>> Further, unlike larger blocks of resources, these blocks are assigned in
>> very small chunks and for a very specific purpose. Once that purpose no
>> longer exists, their return should be straightforward and we as a community
>> should be able to expect voluntary return of these addresses as they cannot
>> be monetized, cannot be transferred, and cannot be repurposed. (At least
>> not without violating policy).
>>
>> Owen
>>
>> On May 5, 2016, at 07:59 , Andrew Dul <andrew.dul at quark.net> wrote:
>>
>> Hello,
>>
>> As part of the discussions at ARIN 37 the community considered updates to
>> the proposed draft policy that would allow organizations to transfer,
>> within ARIN, reserved pool resources provided that they met the criteria to
>> obtain a block from a reserved pool.
>>
>> Based upon this feedback we are proposing to update the draft policy text
>> as follows.  The AC welcomes your feedback on this proposed text and any
>> other feedback on this draft policy.
>>
>> Thanks,
>>
>> Andrew
>>
>>
>> *Original** Policy statement:*
>>
>> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
>> transfer:"
>>
>> Address resources from a reserved pool (including those designated in
>> Section 4.4 and 4.10) are not eligible for transfer.
>>
>> *Updated **Policy statement:*
>>
>> Add to Section 8.3 under the "Conditions on recipient of the transfer:"
>>
>> Address resources from a reserved pool (including those designated in
>> Section 4.4 and 4.10) shall only be transferred to organizations which meet
>> the current criteria of the reserved pool from which the resource was
>> obtained.
>> Add to Section 8.4 under the "Conditions on source of the transfer:"
>>
>> Address resources from a reserved pool (including those designated in
>> Section 4.4 and 4.10) are not eligible for transfer.
>> _______________________________________________
>> PPML
>> You are receiving this message 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/20160513/4c996f63/attachment.htm>

From jschiller at google.com  Fri May 13 15:38:13 2016
From: jschiller at google.com (Jason Schiller)
Date: Fri, 13 May 2016 15:38:13 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
Message-ID: <CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>

I am highly confused now.

We have the 25% utilization check which really is the only verifiable
check to rate-limit aggressively optimistic requests.

On one hand, ARIN does not check this figure.  As such the policy
change is a no-op.

On the other hand the 25% utilization goal remains part of the
policy and having no intention of complying is fraud.

ARIN could make random checks, or check all of them.

ARIN should check if they have reason to suspect there might
be fraud.

I know I worked very hard to get my recent end-user assignment
over 25% by the deadline.

I know in my case the 25% number limited the size of the block.

I suspect there are a lot of honest organizations / people who are
trying to do the right thing while maximizing their requested size
within the constraints of policy.

So in that respect the policy change is not a no-op.
It would make it easier for end-sites who want to stay
in compliance with policy to get more IP space by
simply optimistically and aggressively accelerating their
deployment plans by compressing a 5 or 10 year plan into
two years.  Noting there is no harm, no foul if in two years
time the plans have changed, or a simply not achieved.


On another topic...
Arguments that IPs are being locked up outside of the
needs assessment and therefor we should remove the
needs assessment all together suggests we should
remove speed limits because so many people speed.

Ignoring the fraud aspect for a moment, stockpiling IP
addresses that are registered to you is very different
than a future in terms of risk profile.  Lowering the risk
will encourage this behavior.


If the IPs are in the free pool, or available on the transfer
market doesn't change the fact that the numbers are a
limited and shared resource whose value comes from
the insurance that the resource holder has exclusive
claim to a unique set of numbers.  In fact I would argue
that the supply of IPs are more limited now then they
ever were, especially for large blocks, and especially
for organizations that have been priced out of the
market and as such stewardship is even more
important.


Organizations that have "delusions of grandeur" and
purchase "extra" IPs will not necessarily "pay dearly".

Sure it is a costly mistake to buy what turns out to be
a 50 year supply of addresses.  But the real window
is between the two years which is currently permitted
and the day when IPv6 has wide spread adoption
such that a transit provider can offer IPv6-only service
and their customers are not inconvenienced, and
content providers can offer IPv6-only service and not
risk losing customers that cannot reach them.

The goal is to have enough IPv4 addresses to get
through the transition period to when there is wide
spread support of IPv6, and if you can't secure that
much, than at least more that your competition in a
given market segment such that you don't have a
competitive disadvantage of offering a service that
can reach "most of the internet" and if it can reach
the IPv4-only Internet is will be through costly, and
possibly performance and security impacting
translation middle boxes.

A small overage such as buying an 8 year supply
when you only need a 4 year supply is easily
justified as an insurance policy and preferable
to having bought a 4 year supply when you needed
an 8 year supply.

Nobody complains at the end of the year that they
wasted a bunch of money on health insurance and
didn't get sick all year.

___Jason


On Fri, May 13, 2016 at 1:06 AM, Owen DeLong <owen at delong.com> wrote:

> I see the policy itself largely as a no-op. I have no objection for it
> going to the board,
> nor do I have any significant support for it to do so.
>
> Owen
>
> On May 12, 2016, at 18:53 , David Farmer <farmer at umn.edu> wrote:
>
> Jason,
>
> Even though the last call period formally ended May 9th, I try my best
> to consider all feedback received for a policy even following the
> formal last call deadline, and while I can't speak for directly for
> other AC members, I believe most of them do the same.  However, when
> feedback comes in late sometimes it might not get full consideration,
> especially if it comes in immediately prior to one of our conference
> calls.  To help avoid this I explicitly noted when AC would be
> considering the feedback.  I will additionally note at this point it
> is extremely important to get any additional feedback in ASAP to allow
> the AC due time for its consideration prior to its May 19th conference
> call.
>
> As for the issues and questions you have raise, I believe John and
> Richard have been answering your questions.  Further, I believe the
> community consensus remains to move forward with removing the 25%
> Immediate (30 day) use requirement for end users as this policy
> suggests.  I would specifically ask anyone who disagrees and thinks we
> need to consider the issues more to speak up ASAP.
>
> Thanks.
>
> On Tue, May 10, 2016 at 11:32 AM, Jason Schiller <jschiller at google.com>
> wrote:
>
> I seem to have missed the this thread in last call, and hope you
> will consider the discussion on the other thread: " Re: [arin-ppml]
> ARIN-2015-3:(remove 30-day...) Staff interpretation needed"
>
> I maintain that the 30-day [60-day for transfers] check has
> been useful in mitigating abusively large requests, and
> without it there is no teeth in the policy to prevent abuse.
>
>
> I asked if I was wrong about this, please explain what
> mechanisms are in place to mitigate an end-user asking for
> approval for a 10 year supply of addresses on the grounds that
> if things go really really well, it will only be a 2 year supply?
>
> I heard no response to indicate there was any mechanism.
>
>
> I asked staff about information about stats that might help
> determine what level of push back ARIN provides against two
> year projected need in general, and if that push back would be
> sufficient to prevent outlandishly large claims.
>
> We found that 50% - 75% of all requests are approved with
> past utilization more heavily weighed.
>
> It remains unclear what level of oversight ARIN has to
> question future looking projections.  John Curran provided
> some text about approvals of future looking projections.
>
>   "When we [ARIN] ask organization for their forward
>    projections, we [ARIN] also ask them to provide details
>   to show how they've arrived at their projections. We [ARIN]
>   take into account factors such as new networks, locations,
>   products, services they plan on offering (and this includes
>   consideration of anticipated address utilization within the
>   first 30 days for end-users.)
>
> From the text John provided it seems one could get IP
> addresses solely on future looking plans which are
> unverifiable.  As such an end-user could easily get a 10
> year supply of addresses simply by providing very
> optimistic deployment plans for the next 24 months.
>
>
>
> I asked if I was not wrong about this, then did people realize
> that this policy is basically an end-run around giving out
> addresses based on need when they voted to move this
> policy forward?
>
> I heard no response to this.
>
> Thanks,
>
> __Jason
>
>
> On Thu, May 5, 2016 at 11:45 AM, David Farmer <farmer at umn.edu> wrote:
>
>
> As shepherd for this policy I welcome any additional last call
> feedback for this policy.  It is especially important to speak up if
> you feel there are any issues remaining that need to be considered.
> But, even if you simply support the policy as written that is
> important and useful feedback as well.
>
> The last call period formally continues through, Monday, May 9th, and
> the AC will consider the feedback during its scheduled call on
> Thursday, May 19th.
>
> Thanks
>
> On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net> wrote:
>
> The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
> send the following to last call:
>
>  Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
> requirement in end-user IPv4 policy
>
> Feedback is encouraged during the last call period. All comments should
> be provided to the Public Policy Mailing List. This last call will
> expire on 9 May 2016. After last call the AC will conduct their
> last call review.
>
> The draft policy text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Recommended Draft Policy ARIN-2015-3
> Remove 30 day utilization requirement in end-user IPv4 policy
>
> AC's assessment of conformance with the Principles of Internet Number
> Resource Policy:
>
> ARIN 2015-3 contributes to fair and impartial number resource
> administration
> by removing from the NRPM text that is operationally unrealistic for the
> reasons discussed in the problem statement. This proposal is technically
> sound, in that the removal of the text will more closely align with the
> way
> staff applies the existing policy in relation to 8.3 transfers. There
> was
> strong community support for the policy on PPML and at ARIN 36, which
> was
> confirmed at ARIN 37. There was a suggestion to replace this text with
> an
> alternate requirement. However, the community consensus was to move
> forward
> with the removal alone.
>
> The staff and legal review also suggested removing RFC2050 references
> and
> pointed out that 4.2.3.6 has an additional 25% immediate use clause,
> community feedback was to deal with those issues separately.
>
> Problem Statement:
>
> End-user policy is intended to provide end-users with a one year supply
> of
> IP addresses. Qualification for a one-year supply requires the network
> operator to utilize at least 25% of the requested addresses within 30
> days.
> This text is unrealistic and should be removed.
>
> First, it often takes longer than 30 days to stage equipment and start
> actually using the addresses.
>
> Second, growth is often not that regimented; the forecast is to use X
> addresses over the course of a year, not to use 25% of X within 30 days.
>
> Third, this policy text applies to additional address space requests. It
> is
> incompatible with the requirements of other additional address space
> request
> justification which indicates that 80% utilization of existing space is
> sufficient to justify new space. If a block is at 80%, then often
> (almost
> always?) the remaining 80% will be used over the next 30 days and
> longer.
> Therefore the operator cannot honestly state they will use 25% of the
> ADDITIONAL space within 30 days of receiving it; they're still trying to
> use
> their older block efficiently.
>
> Fourth, in the face of ARIN exhaustion, some ISPs are starting to not
> give
> out /24 (or larger) blocks. So the justification for the 25% rule that
> previously existed (and in fact, applied for many years) is no longer
> germane.
>
> Policy statement:
>
> Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
>
> Resulting text:
>
> 4.3.3. Utilization rate
>
> Utilization rate of address space is a key factor in justifying a new
> assignment of IP address space. Requesters must show exactly how
> previous
> address assignments have been utilized and must provide appropriate
> details
> to verify their one-year growth projection.
>
> The basic criterion that must be met is a 50% utilization rate within
> one
> year.
>
> A greater utilization rate may be required based on individual network
> requirements. Please refer to RFC 2050 for more information on
> utilization
> guidelines.
>
> Comments:
>
> a.Timetable for implementation: Immediate
>
> b.Anything else
>
> #####
>
> ARIN STAFF ASSESSMENT
>
> Draft Policy ARIN-2015-3
> Remove 30 day utilization requirement in end-user IPv4 policy
> Date of Assessment: 16 February 2016
>
> ___
> 1. Summary (Staff Understanding)
>
> This proposal would remove the 25% utilization (within 30 days of
> issuance)
> criteria bullet point from NRPM 4.3.3.
>
> ___
> 2. Comments
>
> A. ARIN Staff Comments
> This policy would more closely align with the way staff applies the
> existing
> policy in relation to 8.3 transfers. Because there is no longer an IPv4
> free
> pool and many IPv4 requests are likely to be satisfied by 8.3 transfers,
> the
> adoption of this policy should have no major impact on operations and
> could
> be implemented as written.
>
> Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to
> obsolete
> RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within
> 30
> days of issuance) requirement.
>
> Staff suggests removing the first two sentences of 4.2.3.6 to remove the
> references to RFC 2050 and the 25% requirement. Additionally, staff
> suggests
> removing the reference to the obsolete RFC 2050 in section 4.3.3.
>
> B. ARIN General Counsel ? Legal Assessment
> No material legal risk in this policy.
>
> ___
> 3. Resource Impact
>
> This policy would have minimal resource impact from an implementation
> aspect. It is estimated that implementation would occur immediately
> after
> ratification by the ARIN Board of Trustees. The following would be
> needed in
> order to implement:
> * Updated guidelines and internal procedures
> * Staff training
> _______________________________________________
> PPML
> You are receiving this message 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
> ===============================================
> _______________________________________________
> PPML
> You are receiving this message 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
>
>
>
>
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>


-- 
_______________________________________________________
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/20160513/ffaff6f6/attachment.htm>

From rjacobs at pslightwave.com  Fri May 13 16:05:35 2016
From: rjacobs at pslightwave.com (Robert Jacobs)
Date: Fri, 13 May 2016 20:05:35 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
Message-ID: <BN1PR06MB2326DBB437EB074B0587A50A9740@BN1PR06MB232.namprd06.prod.outlook.com>

Boy did you hit the nail on the head? thanks Jason as we are one of those who are hoping to ride out this transition period and continue to have IPV4 ip?s to feed our sales and expansion efforts?It is not a fun process right now keeping a steady supply of /22?s or /21?s coming in

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason Schiller
Sent: Friday, May 13, 2016 2:38 PM
To: Owen DeLong <owen at delong.com>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

I am highly confused now.

We have the 25% utilization check which really is the only verifiable
check to rate-limit aggressively optimistic requests.

On one hand, ARIN does not check this figure.  As such the policy
change is a no-op.

On the other hand the 25% utilization goal remains part of the
policy and having no intention of complying is fraud.

ARIN could make random checks, or check all of them.

ARIN should check if they have reason to suspect there might
be fraud.

I know I worked very hard to get my recent end-user assignment
over 25% by the deadline.

I know in my case the 25% number limited the size of the block.

I suspect there are a lot of honest organizations / people who are
trying to do the right thing while maximizing their requested size
within the constraints of policy.

So in that respect the policy change is not a no-op.
It would make it easier for end-sites who want to stay
in compliance with policy to get more IP space by
simply optimistically and aggressively accelerating their
deployment plans by compressing a 5 or 10 year plan into
two years.  Noting there is no harm, no foul if in two years
time the plans have changed, or a simply not achieved.


On another topic...
Arguments that IPs are being locked up outside of the
needs assessment and therefor we should remove the
needs assessment all together suggests we should
remove speed limits because so many people speed.

Ignoring the fraud aspect for a moment, stockpiling IP
addresses that are registered to you is very different
than a future in terms of risk profile.  Lowering the risk
will encourage this behavior.


If the IPs are in the free pool, or available on the transfer
market doesn't change the fact that the numbers are a
limited and shared resource whose value comes from
the insurance that the resource holder has exclusive
claim to a unique set of numbers.  In fact I would argue
that the supply of IPs are more limited now then they
ever were, especially for large blocks, and especially
for organizations that have been priced out of the
market and as such stewardship is even more
important.


Organizations that have "delusions of grandeur" and
purchase "extra" IPs will not necessarily "pay dearly".

Sure it is a costly mistake to buy what turns out to be
a 50 year supply of addresses.  But the real window
is between the two years which is currently permitted
and the day when IPv6 has wide spread adoption
such that a transit provider can offer IPv6-only service
and their customers are not inconvenienced, and
content providers can offer IPv6-only service and not
risk losing customers that cannot reach them.

The goal is to have enough IPv4 addresses to get
through the transition period to when there is wide
spread support of IPv6, and if you can't secure that
much, than at least more that your competition in a
given market segment such that you don't have a
competitive disadvantage of offering a service that
can reach "most of the internet" and if it can reach
the IPv4-only Internet is will be through costly, and
possibly performance and security impacting
translation middle boxes.

A small overage such as buying an 8 year supply
when you only need a 4 year supply is easily
justified as an insurance policy and preferable
to having bought a 4 year supply when you needed
an 8 year supply.

Nobody complains at the end of the year that they
wasted a bunch of money on health insurance and
didn't get sick all year.

___Jason


On Fri, May 13, 2016 at 1:06 AM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:
I see the policy itself largely as a no-op. I have no objection for it going to the board,
nor do I have any significant support for it to do so.

Owen

On May 12, 2016, at 18:53 , David Farmer <farmer at umn.edu<mailto:farmer at umn.edu>> wrote:

Jason,

Even though the last call period formally ended May 9th, I try my best
to consider all feedback received for a policy even following the
formal last call deadline, and while I can't speak for directly for
other AC members, I believe most of them do the same.  However, when
feedback comes in late sometimes it might not get full consideration,
especially if it comes in immediately prior to one of our conference
calls.  To help avoid this I explicitly noted when AC would be
considering the feedback.  I will additionally note at this point it
is extremely important to get any additional feedback in ASAP to allow
the AC due time for its consideration prior to its May 19th conference
call.

As for the issues and questions you have raise, I believe John and
Richard have been answering your questions.  Further, I believe the
community consensus remains to move forward with removing the 25%
Immediate (30 day) use requirement for end users as this policy
suggests.  I would specifically ask anyone who disagrees and thinks we
need to consider the issues more to speak up ASAP.

Thanks.

On Tue, May 10, 2016 at 11:32 AM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>> wrote:

I seem to have missed the this thread in last call, and hope you
will consider the discussion on the other thread: " Re: [arin-ppml]
ARIN-2015-3:(remove 30-day...) Staff interpretation needed"

I maintain that the 30-day [60-day for transfers] check has
been useful in mitigating abusively large requests, and
without it there is no teeth in the policy to prevent abuse.


I asked if I was wrong about this, please explain what
mechanisms are in place to mitigate an end-user asking for
approval for a 10 year supply of addresses on the grounds that
if things go really really well, it will only be a 2 year supply?

I heard no response to indicate there was any mechanism.


I asked staff about information about stats that might help
determine what level of push back ARIN provides against two
year projected need in general, and if that push back would be
sufficient to prevent outlandishly large claims.

We found that 50% - 75% of all requests are approved with
past utilization more heavily weighed.

It remains unclear what level of oversight ARIN has to
question future looking projections.  John Curran provided
some text about approvals of future looking projections.

  "When we [ARIN] ask organization for their forward
   projections, we [ARIN] also ask them to provide details
  to show how they've arrived at their projections. We [ARIN]
  take into account factors such as new networks, locations,
  products, services they plan on offering (and this includes
  consideration of anticipated address utilization within the
  first 30 days for end-users.)

From the text John provided it seems one could get IP
addresses solely on future looking plans which are
unverifiable.  As such an end-user could easily get a 10
year supply of addresses simply by providing very
optimistic deployment plans for the next 24 months.



I asked if I was not wrong about this, then did people realize
that this policy is basically an end-run around giving out
addresses based on need when they voted to move this
policy forward?

I heard no response to this.

Thanks,

__Jason


On Thu, May 5, 2016 at 11:45 AM, David Farmer <farmer at umn.edu<mailto:farmer at umn.edu>> wrote:


As shepherd for this policy I welcome any additional last call
feedback for this policy.  It is especially important to speak up if
you feel there are any issues remaining that need to be considered.
But, even if you simply support the policy as written that is
important and useful feedback as well.

The last call period formally continues through, Monday, May 9th, and
the AC will consider the feedback during its scheduled call on
Thursday, May 19th.

Thanks

On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net<mailto:info at arin.net>> wrote:

The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
send the following to last call:

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

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. This last call will
expire on 9 May 2016. After last call the AC will conduct their
last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

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


## * ##


Recommended Draft Policy ARIN-2015-3
Remove 30 day utilization requirement in end-user IPv4 policy

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

ARIN 2015-3 contributes to fair and impartial number resource
administration
by removing from the NRPM text that is operationally unrealistic for the
reasons discussed in the problem statement. This proposal is technically
sound, in that the removal of the text will more closely align with the
way
staff applies the existing policy in relation to 8.3 transfers. There
was
strong community support for the policy on PPML and at ARIN 36, which
was
confirmed at ARIN 37. There was a suggestion to replace this text with
an
alternate requirement. However, the community consensus was to move
forward
with the removal alone.

The staff and legal review also suggested removing RFC2050 references
and
pointed out that 4.2.3.6 has an additional 25% immediate use clause,
community feedback was to deal with those issues separately.

Problem Statement:

End-user policy is intended to provide end-users with a one year supply
of
IP addresses. Qualification for a one-year supply requires the network
operator to utilize at least 25% of the requested addresses within 30
days.
This text is unrealistic and should be removed.

First, it often takes longer than 30 days to stage equipment and start
actually using the addresses.

Second, growth is often not that regimented; the forecast is to use X
addresses over the course of a year, not to use 25% of X within 30 days.

Third, this policy text applies to additional address space requests. It
is
incompatible with the requirements of other additional address space
request
justification which indicates that 80% utilization of existing space is
sufficient to justify new space. If a block is at 80%, then often
(almost
always?) the remaining 80% will be used over the next 30 days and
longer.
Therefore the operator cannot honestly state they will use 25% of the
ADDITIONAL space within 30 days of receiving it; they're still trying to
use
their older block efficiently.

Fourth, in the face of ARIN exhaustion, some ISPs are starting to not
give
out /24 (or larger) blocks. So the justification for the 25% rule that
previously existed (and in fact, applied for many years) is no longer
germane.

Policy statement:

Remove the 25% utilization criteria bullet point from NRPM 4.3.3.

Resulting text:

4.3.3. Utilization rate

Utilization rate of address space is a key factor in justifying a new
assignment of IP address space. Requesters must show exactly how
previous
address assignments have been utilized and must provide appropriate
details
to verify their one-year growth projection.

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

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

Comments:

a.Timetable for implementation: Immediate

b.Anything else

#####

ARIN STAFF ASSESSMENT

Draft Policy ARIN-2015-3
Remove 30 day utilization requirement in end-user IPv4 policy
Date of Assessment: 16 February 2016

___
1. Summary (Staff Understanding)

This proposal would remove the 25% utilization (within 30 days of
issuance)
criteria bullet point from NRPM 4.3.3.

___
2. Comments

A. ARIN Staff Comments
This policy would more closely align with the way staff applies the
existing
policy in relation to 8.3 transfers. Because there is no longer an IPv4
free
pool and many IPv4 requests are likely to be satisfied by 8.3 transfers,
the
adoption of this policy should have no major impact on operations and
could
be implemented as written.

Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to
obsolete
RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within
30
days of issuance) requirement.

Staff suggests removing the first two sentences of 4.2.3.6 to remove the
references to RFC 2050 and the 25% requirement. Additionally, staff
suggests
removing the reference to the obsolete RFC 2050 in section 4.3.3.

B. ARIN General Counsel ? Legal Assessment
No material legal risk in this policy.

___
3. Resource Impact

This policy would have minimal resource impact from an implementation
aspect. It is estimated that implementation would occur immediately
after
ratification by the ARIN Board of Trustees. The following would be
needed in
order to implement:
* Updated guidelines and internal procedures
* Staff training
_______________________________________________
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.



--
===============================================
David Farmer               Email:farmer at umn.edu<http://umn.edu>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815<tel:612-626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952<tel: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<mailto:ARIN-PPML at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.




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



--
===============================================
David Farmer               Email:farmer at umn.edu<mailto:farmer at umn.edu>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815<tel:612-626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952<tel: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<mailto:ARIN-PPML at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.




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

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

From jcurran at arin.net  Fri May 13 16:11:14 2016
From: jcurran at arin.net (John Curran)
Date: Fri, 13 May 2016 20:11:14 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
Message-ID: <3B13A871-286A-4113-9246-E2151703BE3E@corp.arin.net>

On May 13, 2016, at 3:38 PM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>> wrote:

I am highly confused now.

We have the 25% utilization check which really is the only verifiable
check to rate-limit aggressively optimistic requests.

On one hand, ARIN does not check this figure.  As such the policy
change is a no-op.

On the other hand the 25% utilization goal remains part of the
policy and having no intention of complying is fraud.

ARIN could make random checks, or check all of them.
...

Jason -

   Are you referring to assignments or transfers?  The above discussion
   appears to mix requests of both types.

   ARIN does check that end-user _assignment_ requests meet the
   25% immediate utilization requirement (as called for in the end-user
   assignment policy.)

   ARIN does not have clear guidance how the assignment criteria for
   25% immediate use is to be applied to transfers.  ARIN can apply the
   criteria with respect to transfer requests, but that would require some
   additional policy clarity from the community to do so.

So in that respect the policy change is not a no-op.

   The policy change will not materially affected transfer requests, as noted
   above.  The change would effect processing of any end-user assignments
   requests.  (It is probably worth noting that end-users who presently qualify
   for assignment of an IPv4 block are being added to a waiting list with a
   rather low probability of timely fulfillment.)

Thanks,
/John

John Curran
President and CEO
ARIN





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

From alyssa.moore at cybera.ca  Fri May 13 18:42:22 2016
From: alyssa.moore at cybera.ca (Alyssa Moore)
Date: Fri, 13 May 2016 22:42:22 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <3B13A871-286A-4113-9246-E2151703BE3E@corp.arin.net>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<3B13A871-286A-4113-9246-E2151703BE3E@corp.arin.net>
Message-ID: <CALdayyEoLV9i+YAyOZhjCd1Y+4GRxabP2veL79v=Doyhspq-Rg@mail.gmail.com>

Apologies in advance for jumping in at the last minute on a policy that's
in recommended form, but I have a few questions and observations.

1)  The problem statement says:
> First, it often takes longer than 30 days to stage equipment and
start actually using the addresses.

Earlier on, Jason says:
> "I know I worked very hard to get my recent end-user assignment over 25%
by the deadline."

It is my understanding, Jason, that you're a proponent of some form of
verification with teeth - presumably something more aggressive than the 1
year/50% that would still be included if 2015-3 passes muster, but you also
concede that you had a difficult time meeting the current 30 day
"deadline."

I could be completely off base because I haven't been following 2015-3
since its inception, but has there been any discussion of a test that sits
somewhere between 25%/30 days and 50%/1 year?

2) It seems 4.3.3 in its current incarnation *doesn't have teeth to begin
with *as it applies to transfers (which are really the only option in a
post-depletion world.) John Curran says:

Such a requirement could only be applicable transfers to end-users who were
demonstrating their 24-month need using NRPM 4.3.3, and *there is no clear
interpretation for application of **the  "25% immediate utilization rate?
language*. As such, it is not directly considered during the process (as
elaborated by Richard Jimmerson on the list); therefore none were ?reviewed and
verified explicitly? for that purpose.

Note that the language remains applicable (and organizations that attempt
to transfer without having immediate utilization do run the risk of number
resource fraud), but is not integrated into the end-user transfer review
process as its extrapolation into that context is unclear.  *This is also
why the staff and legal review for draft policy 2015-3 notes - "This policy
would **more closely align with the way staff applies the existing policy
in relation to 8.3 transfers.?*


[emphasis my own]

My understanding from these comments is that ARIN has not been doing 30 day
check ups on transfers because *staff has not received direction on how to
apply the existing policy to transfers, *which would be the reason behind
the staff assessment, "This policy would more closely align with the way
staff applies existing policy." To that end, then, the policy in its
current incarnation is not completely obsolete as some folks have claimed
on the PPML. Staff simply don't have direction for application of the
utilization rates.

It seems there needs to be clearer consensus around what the action of ARIN
staff ought to be a) in pursuing verification in the first place re:
transfers and b) in cases where verification tests aren't met. Should ARIN
be automatically checking in at the 30 day or 1 year mark? If so, what does
ARIN do if the 25%/30 days or 50%/1year tests aren't met? Should ARIN
revoke the address space? Serve the offender notice? Are either of these
ethical in a post-depletion world where folks have paid for address space?

If the community is to give direction in these areas, should it be included
in 2015-3, or in a separate problem statement?

Feel free to set me straight on all of this 'cause I'm a giant nooooob.
- Alyssa

On Fri, May 13, 2016 at 4:19 PM John Curran <jcurran at arin.net> wrote:

> On May 13, 2016, at 3:38 PM, Jason Schiller <jschiller at google.com> wrote:
>
>
> I am highly confused now.
>
> We have the 25% utilization check which really is the only verifiable
> check to rate-limit aggressively optimistic requests.
>
> On one hand, ARIN does not check this figure.  As such the policy
> change is a no-op.
>
> On the other hand the 25% utilization goal remains part of the
> policy and having no intention of complying is fraud.
>
> ARIN could make random checks, or check all of them.
>
> ...
>
>
> Jason -
>
>    Are you referring to assignments or transfers?  The above discussion
>    appears to mix requests of both types.
>
>    ARIN does check that end-user _assignment_ requests meet the
>    25% immediate utilization requirement (as called for in the end-user
>    assignment policy.)
>
>    ARIN does not have clear guidance how the assignment criteria for
>    25% immediate use is to be applied to transfers.  ARIN can apply the
>    criteria with respect to transfer requests, but that would require some
>    additional policy clarity from the community to do so.
>
> So in that respect the policy change is not a no-op.
>
>
>    The policy change will not materially affected transfer requests, as
> noted
>    above.  The change would effect processing of any end-user assignments
>    requests.  (It is probably worth noting that end-users who presently
> qualify
>    for assignment of an IPv4 block are being added to a waiting list with
> a
>    rather low probability of timely fulfillment.)
>
> Thanks,
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160513/af0e96f3/attachment.htm>

From scottleibrand at gmail.com  Sat May 14 20:49:49 2016
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Sun, 15 May 2016 00:49:49 +0000 (UTC)
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <1f09bac3c71ac0fdc783e8f455784478.squirrel@mail.panix.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<1f09bac3c71ac0fdc783e8f455784478.squirrel@mail.panix.com>
Message-ID: <EF501E8D91217774.D08A631F-4B25-4403-BC00-BC571643221A@mail.outlook.com>

Well put, David. +1
-Scott

    _____________________________
From: David R Huberman <daveid at panix.com>
Sent: Saturday, May 14, 2016 5:08 PM
Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy
To:  <arin-ppml at arin.net>


Jason,

1) The policy in last call removes a criterion that is not being applied
today.  Staff have criteria they use to judge 24-month need, and have been
applying it for years without coming back to us and telling us there's a
problem or deficiency.

2) Most requestors (99%? 98%?) tell the truth.  They're just trying to
operate a network, and aren't attempting to defraud ARIN In any way. ARIN
staff have been fighting scammers for a very long time, and are very good
at it. They have measurable positive results in fighting fraud.

For those two reasons, I believe this policy should be adopted by the
board, and an obsolete criterion should be removed from NRPM.

David


> I seem to have missed the this thread in last call, and hope you
> will consider the discussion on the other thread: " Re: [arin-ppml]
> ARIN-2015-3:(remove 30-day...) Staff interpretation needed"
>
>  I maintain that the 30-day [60-day for transfers] check has
> been useful in mitigating abusively large requests, and
> without it there is no teeth in the policy to prevent abuse.
>
>
> I asked if I was wrong about this, please explain what
> mechanisms are in place to mitigate an end-user asking for
> approval for a 10 year supply of addresses on the grounds that
> if things go really really well, it will only be a 2 year supply?
>
> I heard no response to indicate there was any mechanism.
>
>
> I asked staff about information about stats that might help
> determine what level of push back ARIN provides against two
> year projected need in general, and if that push back would be
> sufficient to prevent outlandishly large claims.
>
> We found that 50% - 75% of all requests are approved with
> past utilization more heavily weighed.
>
> It remains unclear what level of oversight ARIN has to
> question future looking projections.  John Curran provided
> some text about approvals of future looking projections.
>
>    "When we [ARIN] ask organization for their forward
>     projections, we [ARIN] also ask them to provide details
>    to show how they've arrived at their projections. We [ARIN]
>    take into account factors such as new networks, locations,
>    products, services they plan on offering (and this includes
>    consideration of anticipated address utilization within the
>    first 30 days for end-users.)
>
>>From the text John provided it seems one could get IP
> addresses solely on future looking plans which are
> unverifiable.  As such an end-user could easily get a 10
> year supply of addresses simply by providing very
> optimistic deployment plans for the next 24 months.
>
>
>
> I asked if I was not wrong about this, then did people realize
> that this policy is basically an end-run around giving out
> addresses based on need when they voted to move this
> policy forward?
>
> I heard no response to this.
>
> Thanks,
>
> __Jason
>
>
> On Thu, May 5, 2016 at 11:45 AM, David Farmer <farmer at umn.edu> wrote:
>
>> As shepherd for this policy I welcome any additional last call
>> feedback for this policy.  It is especially important to speak up if
>> you feel there are any issues remaining that need to be considered.
>> But, even if you simply support the policy as written that is
>> important and useful feedback as well.
>>
>> The last call period formally continues through, Monday, May 9th, and
>> the AC will consider the feedback during its scheduled call on
>> Thursday, May 19th.
>>
>> Thanks
>>
>> On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net> wrote:
>> > The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
>> > send the following to last call:
>> >
>> >   Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
>> > requirement in end-user IPv4 policy
>> >
>> > Feedback is encouraged during the last call period. All comments
>> should
>> > be provided to the Public Policy Mailing List. This last call will
>> > expire on 9 May 2016. After last call the AC will conduct their
>> > last call review.
>> >
>> > The draft policy text is below and available at:
>> > https://www.arin.net/policy/proposals/
>> >
>> > The ARIN Policy Development Process is available at:
>> > https://www.arin.net/policy/pdp.html
>> >
>> > Regards,
>> >
>> > Communications and Member Services
>> > American Registry for Internet Numbers (ARIN)
>> >
>> >
>> > ## * ##
>> >
>> >
>> > Recommended Draft Policy ARIN-2015-3
>> > Remove 30 day utilization requirement in end-user IPv4 policy
>> >
>> > AC's assessment of conformance with the Principles of Internet Number
>> > Resource Policy:
>> >
>> > ARIN 2015-3 contributes to fair and impartial number resource
>> administration
>> > by removing from the NRPM text that is operationally unrealistic for
>> the
>> > reasons discussed in the problem statement. This proposal is
>> technically
>> > sound, in that the removal of the text will more closely align with
>> the
>> way
>> > staff applies the existing policy in relation to 8.3 transfers. There
>> was
>> > strong community support for the policy on PPML and at ARIN 36, which
>> was
>> > confirmed at ARIN 37. There was a suggestion to replace this text with
>> an
>> > alternate requirement. However, the community consensus was to move
>> forward
>> > with the removal alone.
>> >
>> > The staff and legal review also suggested removing RFC2050 references
>> and
>> > pointed out that 4.2.3.6 has an additional 25% immediate use clause,
>> > community feedback was to deal with those issues separately.
>> >
>> > Problem Statement:
>> >
>> > End-user policy is intended to provide end-users with a one year
>> supply
>> of
>> > IP addresses. Qualification for a one-year supply requires the network
>> > operator to utilize at least 25% of the requested addresses within 30
>> days.
>> > This text is unrealistic and should be removed.
>> >
>> > First, it often takes longer than 30 days to stage equipment and start
>> > actually using the addresses.
>> >
>> > Second, growth is often not that regimented; the forecast is to use X
>> > addresses over the course of a year, not to use 25% of X within 30
>> days.
>> >
>> > Third, this policy text applies to additional address space requests.
>> It
>> is
>> > incompatible with the requirements of other additional address space
>> request
>> > justification which indicates that 80% utilization of existing space
>> is
>> > sufficient to justify new space. If a block is at 80%, then often
>> (almost
>> > always?) the remaining 80% will be used over the next 30 days and
>> longer.
>> > Therefore the operator cannot honestly state they will use 25% of the
>> > ADDITIONAL space within 30 days of receiving it; they're still trying
>> to
>> use
>> > their older block efficiently.
>> >
>> > Fourth, in the face of ARIN exhaustion, some ISPs are starting to not
>> give
>> > out /24 (or larger) blocks. So the justification for the 25% rule that
>> > previously existed (and in fact, applied for many years) is no longer
>> > germane.
>> >
>> > Policy statement:
>> >
>> > Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
>> >
>> > Resulting text:
>> >
>> > 4.3.3. Utilization rate
>> >
>> > Utilization rate of address space is a key factor in justifying a new
>> > assignment of IP address space. Requesters must show exactly how
>> previous
>> > address assignments have been utilized and must provide appropriate
>> details
>> > to verify their one-year growth projection.
>> >
>> > The basic criterion that must be met is a 50% utilization rate within
>> one
>> > year.
>> >
>> > A greater utilization rate may be required based on individual network
>> > requirements. Please refer to RFC 2050 for more information on
>> utilization
>> > guidelines.
>> >
>> > Comments:
>> >
>> > a.Timetable for implementation: Immediate
>> >
>> > b.Anything else
>> >
>> > #####
>> >
>> > ARIN STAFF ASSESSMENT
>> >
>> > Draft Policy ARIN-2015-3
>> > Remove 30 day utilization requirement in end-user IPv4 policy
>> > Date of Assessment: 16 February 2016
>> >
>> > ___
>> > 1. Summary (Staff Understanding)
>> >
>> > This proposal would remove the 25% utilization (within 30 days of
>> issuance)
>> > criteria bullet point from NRPM 4.3.3.
>> >
>> > ___
>> > 2. Comments
>> >
>> > A. ARIN Staff Comments
>> > This policy would more closely align with the way staff applies the
>> existing
>> > policy in relation to 8.3 transfers. Because there is no longer an
>> IPv4
>> free
>> > pool and many IPv4 requests are likely to be satisfied by 8.3
>> transfers,
>> the
>> > adoption of this policy should have no major impact on operations and
>> could
>> > be implemented as written.
>> >
>> > Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to
>> obsolete
>> > RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use
>> (within
>> 30
>> > days of issuance) requirement.
>> >
>> > Staff suggests removing the first two sentences of 4.2.3.6 to remove
>> the
>> > references to RFC 2050 and the 25% requirement. Additionally, staff
>> suggests
>> > removing the reference to the obsolete RFC 2050 in section 4.3.3.
>> >
>> > B. ARIN General Counsel ??? Legal Assessment
>> > No material legal risk in this policy.
>> >
>> > ___
>> > 3. Resource Impact
>> >
>> > This policy would have minimal resource impact from an implementation
>> > aspect. It is estimated that implementation would occur immediately
>> after
>> > ratification by the ARIN Board of Trustees. The following would be
>> needed in
>> > order to implement:
>> > * Updated guidelines and internal procedures
>> > * Staff training
>> > _______________________________________________
>> > PPML
>> > You are receiving this message 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
>> ===============================================
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


_______________________________________________
PPML
You are receiving this message 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/20160515/b1824984/attachment.htm>

From owen at delong.com  Sun May 15 05:40:00 2016
From: owen at delong.com (Owen DeLong)
Date: Sun, 15 May 2016 02:40:00 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
	Policy
In-Reply-To: <B7BF00F0-BA78-49B3-8E42-208EF2DC9B92@mtin.net>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
	<313F0B8E-E928-479F-B338-30AFFF77F82F@delong.com>
	<CADx2oGF2mNJk53o0cnqJtZp=BxVvFhQFrc2N=dfsZ+FdoPQO6Q@mail.gmail.com>
	<B7BF00F0-BA78-49B3-8E42-208EF2DC9B92@mtin.net>
Message-ID: <9D28B4A8-2CA5-4E54-BC9F-0BA9AE189424@delong.com>

While I understand that this applies in the general case, I think that with these reserved blocks, the situation is somewhat different.

First, the reserved blocks are limited to a very select set of purposes (high-level nameservers, internet exchange points, etc.).
With the exception of 4.10 (IPv6 transition), they are not even available to the average business under most circumstances.

Further, they are not issued as large blocks. IIRC, the largest possible allocation for any of the blocks is a /22.

If ARIN won?t process a transfer, then there?s virtually no ability to monetize the space in any useful way. Especially if the theoretical recipient is able to come to ARIN and get equivalent space essentially for free.

If the exchange point ceases to exist or the high-level nameserver is eliminated, that?s a fairly visible event which would allow ARIN sufficient verifiable information on which to base a decision to return the addresses to the free pool.

Owen

> On May 8, 2016, at 20:02 , Justin Wilson <lists at mtin.net> wrote:
> 
> The key will be making it where it can not be monetized.  It?s like Real Estate and have to approach it like eminent domain.   I think it becomes a very slippery slope. IP space, has become an monetary asset to the company.  If you remove the ability to capitalize on that unused space, you still need a mechanism for forcing it?s return.
> 
> 
> Justin Wilson
> j2sw at mtin.net <mailto:j2sw at mtin.net>
> 
> ---
> http://www.mtin.net <http://www.mtin.net/> Owner/CEO
> xISP Solutions- Consulting ? Data Centers - Bandwidth
> 
> http://www.midwest-ix.com <http://www.midwest-ix.com/>  COO/Chairman
> Internet Exchange - Peering - Distributed Fabric
> 
>> On May 8, 2016, at 9:23 PM, Christoph Blecker <cblecker at gmail.com <mailto:cblecker at gmail.com>> wrote:
>> 
>> I can't quite imagine a scenario that would merit an 8.3 transfer of reserved pool IP space. I think the community is better served to encourage reserved pool address holders to return the space back to the reserved pool if the need they originally requested the address space for no longer exists. As such, I prefer the original policy text.
>> 
>> I'd be open to changing my opinion if someone could explain a scenario where an 8.3 transfer is preferable to requesting space from the free pool.
>> 
>> Cheers,
>> Christoph
>> 
>> On 5 May 2016 at 12:11, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
>> Speaking strictly for myself and not as a member of the AC?
>> 
>> I still fail to see the need for this. Here are the scenarios I can see:
>> 
>> 1.	Transfer of an operating environment to a new organization through merger/acquisition/reorg:
>> 
>> 		This would be handled in 8.2 and there is no restriction on these blocks in 8.2
>> 		transfers.
>> 
>> 2.	Creation of a new operational environment which needs resources and qualifies:
>> 
>> 		Since these reserved pools still have resources available, I see no reason to support
>> 		their transfer through 8.3 or 8.4.
>> 
>> I think the proposed change would be mostly harmless, but I also feel that it serves no useful purpose and would complicate policy unnecessarily.
>> 
>> Further, unlike larger blocks of resources, these blocks are assigned in very small chunks and for a very specific purpose. Once that purpose no longer exists, their return should be straightforward and we as a community should be able to expect voluntary return of these addresses as they cannot be monetized, cannot be transferred, and cannot be repurposed. (At least not without violating policy).
>> 
>> Owen
>> 
>>> On May 5, 2016, at 07:59 , Andrew Dul <andrew.dul at quark.net <mailto:andrew.dul at quark.net>> wrote:
>>> 
>>> Hello,
>>> 
>>> As part of the discussions at ARIN 37 the community considered updates to the proposed draft policy that would allow organizations to transfer, within ARIN, reserved pool resources provided that they met the criteria to obtain a block from a reserved pool. 
>>> Based upon this feedback we are proposing to update the draft policy text as follows.  The AC welcomes your feedback on this proposed text and any other feedback on this draft policy.
>>> 
>>> Thanks,
>>> 
>>> Andrew
>>> 
>>> Original Policy statement:
>>> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the transfer:"
>>> 
>>> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.
>>> 
>>> Updated Policy statement:
>>> 
>>> Add to Section 8.3 under the "Conditions on recipient of the transfer:"
>>> 
>>> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) shall only be transferred to organizations which meet the current criteria of the reserved pool from which the resource was obtained.
>>> 
>>> Add to Section 8.4 under the "Conditions on source of the transfer:"
>>> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.
>>> 
>>> _______________________________________________
>>> 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 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/20160515/943d804a/attachment.htm>

From milton at gatech.edu  Sun May 15 17:32:16 2016
From: milton at gatech.edu (Mueller, Milton L)
Date: Sun, 15 May 2016 21:32:16 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
Message-ID: <BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>



If the IPs are in the free pool, or available on the transfer
market doesn't change the fact that the numbers are a
limited and shared resource whose value comes from
the insurance that the resource holder has exclusive
claim to a unique set of numbers.  In fact I would argue
that the supply of IPs are more limited now then they
ever were, especially for large blocks, and especially
for organizations that have been priced out of the
market and as such stewardship is even more
important.

MM: whether we are dealing with a free pool or a transfer market makes a world of difference.
Would you please address the two straightforward arguments that have already been made about that, instead of ignoring them and hoping they will go away?


1.       Transfers are rationed by price. Free pool assignments are not. Stringent needs assessment can be justified when there is no price, because there is no other way of conserving. As for your comment about those ?priced out of the market,? superimposing stringent needs assessment does NOT lower the price for anyone. It probably raises it.


2.       Numbers that are put into the transfer market are not, by definition, truly needed by the holder. Therefore, (as long as a network operator is involved) a transfer implies a movement from a less-needed to a more-needed use ? regardless of whether some kind of administrative needs assessment was performed by ARIN.

I look forward to your engagement on the real issues. I really am curious as to what answer you might make to these.


Dr. Milton L. Mueller
Professor, School of Public Policy
Georgia Institute of Technology



Organizations that have "delusions of grandeur" and
purchase "extra" IPs will not necessarily "pay dearly".

Sure it is a costly mistake to buy what turns out to be
a 50 year supply of addresses.  But the real window
is between the two years which is currently permitted
and the day when IPv6 has wide spread adoption
such that a transit provider can offer IPv6-only service
and their customers are not inconvenienced, and
content providers can offer IPv6-only service and not
risk losing customers that cannot reach them.

The goal is to have enough IPv4 addresses to get
through the transition period to when there is wide
spread support of IPv6, and if you can't secure that
much, than at least more that your competition in a
given market segment such that you don't have a
competitive disadvantage of offering a service that
can reach "most of the internet" and if it can reach
the IPv4-only Internet is will be through costly, and
possibly performance and security impacting
translation middle boxes.

A small overage such as buying an 8 year supply
when you only need a 4 year supply is easily
justified as an insurance policy and preferable
to having bought a 4 year supply when you needed
an 8 year supply.

Nobody complains at the end of the year that they
wasted a bunch of money on health insurance and
didn't get sick all year.

___Jason


On Fri, May 13, 2016 at 1:06 AM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:
I see the policy itself largely as a no-op. I have no objection for it going to the board,
nor do I have any significant support for it to do so.

Owen

On May 12, 2016, at 18:53 , David Farmer <farmer at umn.edu<mailto:farmer at umn.edu>> wrote:

Jason,

Even though the last call period formally ended May 9th, I try my best
to consider all feedback received for a policy even following the
formal last call deadline, and while I can't speak for directly for
other AC members, I believe most of them do the same.  However, when
feedback comes in late sometimes it might not get full consideration,
especially if it comes in immediately prior to one of our conference
calls.  To help avoid this I explicitly noted when AC would be
considering the feedback.  I will additionally note at this point it
is extremely important to get any additional feedback in ASAP to allow
the AC due time for its consideration prior to its May 19th conference
call.

As for the issues and questions you have raise, I believe John and
Richard have been answering your questions.  Further, I believe the
community consensus remains to move forward with removing the 25%
Immediate (30 day) use requirement for end users as this policy
suggests.  I would specifically ask anyone who disagrees and thinks we
need to consider the issues more to speak up ASAP.

Thanks.

On Tue, May 10, 2016 at 11:32 AM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>> wrote:

I seem to have missed the this thread in last call, and hope you
will consider the discussion on the other thread: " Re: [arin-ppml]
ARIN-2015-3:(remove 30-day...) Staff interpretation needed"

I maintain that the 30-day [60-day for transfers] check has
been useful in mitigating abusively large requests, and
without it there is no teeth in the policy to prevent abuse.


I asked if I was wrong about this, please explain what
mechanisms are in place to mitigate an end-user asking for
approval for a 10 year supply of addresses on the grounds that
if things go really really well, it will only be a 2 year supply?

I heard no response to indicate there was any mechanism.


I asked staff about information about stats that might help
determine what level of push back ARIN provides against two
year projected need in general, and if that push back would be
sufficient to prevent outlandishly large claims.

We found that 50% - 75% of all requests are approved with
past utilization more heavily weighed.

It remains unclear what level of oversight ARIN has to
question future looking projections.  John Curran provided
some text about approvals of future looking projections.

  "When we [ARIN] ask organization for their forward
   projections, we [ARIN] also ask them to provide details
  to show how they've arrived at their projections. We [ARIN]
  take into account factors such as new networks, locations,
  products, services they plan on offering (and this includes
  consideration of anticipated address utilization within the
  first 30 days for end-users.)

From the text John provided it seems one could get IP
addresses solely on future looking plans which are
unverifiable.  As such an end-user could easily get a 10
year supply of addresses simply by providing very
optimistic deployment plans for the next 24 months.



I asked if I was not wrong about this, then did people realize
that this policy is basically an end-run around giving out
addresses based on need when they voted to move this
policy forward?

I heard no response to this.

Thanks,

__Jason


On Thu, May 5, 2016 at 11:45 AM, David Farmer <farmer at umn.edu<mailto:farmer at umn.edu>> wrote:


As shepherd for this policy I welcome any additional last call
feedback for this policy.  It is especially important to speak up if
you feel there are any issues remaining that need to be considered.
But, even if you simply support the policy as written that is
important and useful feedback as well.

The last call period formally continues through, Monday, May 9th, and
the AC will consider the feedback during its scheduled call on
Thursday, May 19th.

Thanks

On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net<mailto:info at arin.net>> wrote:

The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
send the following to last call:

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

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. This last call will
expire on 9 May 2016. After last call the AC will conduct their
last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

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


## * ##


Recommended Draft Policy ARIN-2015-3
Remove 30 day utilization requirement in end-user IPv4 policy

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

ARIN 2015-3 contributes to fair and impartial number resource
administration
by removing from the NRPM text that is operationally unrealistic for the
reasons discussed in the problem statement. This proposal is technically
sound, in that the removal of the text will more closely align with the
way
staff applies the existing policy in relation to 8.3 transfers. There
was
strong community support for the policy on PPML and at ARIN 36, which
was
confirmed at ARIN 37. There was a suggestion to replace this text with
an
alternate requirement. However, the community consensus was to move
forward
with the removal alone.

The staff and legal review also suggested removing RFC2050 references
and
pointed out that 4.2.3.6 has an additional 25% immediate use clause,
community feedback was to deal with those issues separately.

Problem Statement:

End-user policy is intended to provide end-users with a one year supply
of
IP addresses. Qualification for a one-year supply requires the network
operator to utilize at least 25% of the requested addresses within 30
days.
This text is unrealistic and should be removed.

First, it often takes longer than 30 days to stage equipment and start
actually using the addresses.

Second, growth is often not that regimented; the forecast is to use X
addresses over the course of a year, not to use 25% of X within 30 days.

Third, this policy text applies to additional address space requests. It
is
incompatible with the requirements of other additional address space
request
justification which indicates that 80% utilization of existing space is
sufficient to justify new space. If a block is at 80%, then often
(almost
always?) the remaining 80% will be used over the next 30 days and
longer.
Therefore the operator cannot honestly state they will use 25% of the
ADDITIONAL space within 30 days of receiving it; they're still trying to
use
their older block efficiently.

Fourth, in the face of ARIN exhaustion, some ISPs are starting to not
give
out /24 (or larger) blocks. So the justification for the 25% rule that
previously existed (and in fact, applied for many years) is no longer
germane.

Policy statement:

Remove the 25% utilization criteria bullet point from NRPM 4.3.3.

Resulting text:

4.3.3. Utilization rate

Utilization rate of address space is a key factor in justifying a new
assignment of IP address space. Requesters must show exactly how
previous
address assignments have been utilized and must provide appropriate
details
to verify their one-year growth projection.

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

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

Comments:

a.Timetable for implementation: Immediate

b.Anything else

#####

ARIN STAFF ASSESSMENT

Draft Policy ARIN-2015-3
Remove 30 day utilization requirement in end-user IPv4 policy
Date of Assessment: 16 February 2016

___
1. Summary (Staff Understanding)

This proposal would remove the 25% utilization (within 30 days of
issuance)
criteria bullet point from NRPM 4.3.3.

___
2. Comments

A. ARIN Staff Comments
This policy would more closely align with the way staff applies the
existing
policy in relation to 8.3 transfers. Because there is no longer an IPv4
free
pool and many IPv4 requests are likely to be satisfied by 8.3 transfers,
the
adoption of this policy should have no major impact on operations and
could
be implemented as written.

Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to
obsolete
RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within
30
days of issuance) requirement.

Staff suggests removing the first two sentences of 4.2.3.6 to remove the
references to RFC 2050 and the 25% requirement. Additionally, staff
suggests
removing the reference to the obsolete RFC 2050 in section 4.3.3.

B. ARIN General Counsel ? Legal Assessment
No material legal risk in this policy.

___
3. Resource Impact

This policy would have minimal resource impact from an implementation
aspect. It is estimated that implementation would occur immediately
after
ratification by the ARIN Board of Trustees. The following would be
needed in
order to implement:
* Updated guidelines and internal procedures
* Staff training
_______________________________________________
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.



--
===============================================
David Farmer               Email:farmer at umn.edu<http://umn.edu>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815<tel:612-626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952<tel: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<mailto:ARIN-PPML at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.




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



--
===============================================
David Farmer               Email:farmer at umn.edu<mailto:farmer at umn.edu>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815<tel:612-626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952<tel: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<mailto:ARIN-PPML at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.




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

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

From owen at delong.com  Sun May 15 22:32:15 2016
From: owen at delong.com (Owen DeLong)
Date: Sun, 15 May 2016 19:32:15 -0700
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
	Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
Message-ID: <1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>


> On May 15, 2016, at 14:32 , Mueller, Milton L <milton at gatech.edu> wrote:
> 
>  
> ? <>
> If the IPs are in the free pool, or available on the transfer
> market doesn't change the fact that the numbers are a 
> limited and shared resource whose value comes from 
> the insurance that the resource holder has exclusive 
> claim to a unique set of numbers.  In fact I would argue
> that the supply of IPs are more limited now then they 
> ever were, especially for large blocks, and especially
> for organizations that have been priced out of the 
> market and as such stewardship is even more 
> important.
>  
> MM: whether we are dealing with a free pool or a transfer market makes a world of difference.
> Would you please address the two straightforward arguments that have already been made about that, instead of ignoring them and hoping they will go away?

I won?t presume to speak for Jason, however, both of the issues below have been repeatedly asked and answered. Since you have apparently missed some previous answers, I will reiterate mine here for you?

> 1.       Transfers are rationed by price. Free pool assignments are not. Stringent needs assessment can be justified when there is no price, because there is no other way of conserving. As for your comment about those ?priced out of the market,? superimposing stringent needs assessment does NOT lower the price for anyone. It probably raises it.

Transfers are not rationed by price? Repeating this fallacy doesn?t make it inherently true.

Price does not ensure that the purchaser has actual need for the resources, it merely insures that they have monetary resources that they are willing to trade for number resources. I realize that in the religion of Ayn Rand and the Kato Institute, this is indistinguishable from optimal resource management. You?ve presented no evidence whatsoever to support your conclusion that stringent needs assessment raises the price or even that it doesn?t prevent prices from being artificially raised.

In fact, in the RIPE region where there are virtually no needs-based controls, according to the brokers I have discussed things with, prices are rising more rapidly than in the ARIN region, which would in fact appear to suggest that our needs-assessment regime is, in fact, holding prices down.

> 
> 2.       Numbers that are put into the transfer market are not, by definition, truly needed by the holder. Therefore, (as long as a network operator is involved) a transfer implies a movement from a less-needed to a more-needed use ? regardless of whether some kind of administrative needs assessment was performed by ARIN.

If we eliminate needs assessment, what mechanism assures that the transferee is actually a network operator? Further, how does it in any way assure that the transfer is from a place of less need to a place of greater need rather than a place of limited need to a place of greater monetary resources?

You start with an assumption that you are correct in your conjecture and then act as if it is everyone else?s duty to provide evidence that your speculation is not correct. The reality is that these are judgment calls based on limited experience and while we do know that needs assessment does, in fact, work to some extent, there is very limited experience without it. Unfortunately, once it is eliminated, it will be virtually impossible to put the genie back in the bottle, so people are understandably cautious about opening the bottle all at once.

Owen


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

From jschiller at google.com  Mon May 16 09:54:36 2016
From: jschiller at google.com (Jason Schiller)
Date: Mon, 16 May 2016 09:54:36 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <3B13A871-286A-4113-9246-E2151703BE3E@corp.arin.net>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<3B13A871-286A-4113-9246-E2151703BE3E@corp.arin.net>
Message-ID: <CAC4yj2X4H0caXcwGreVo0j2ETohd9ozKYXU7hHACu9mYO18Csg@mail.gmail.com>

John,

I am referring to both ARIN assignments and specified transfers to end-users
WRT policy.

It is my understanding that Specifies transfers to end-users  per 8.3
"The recipient must demonstrate the need for up to a 24-month supply
of IP address resources under current ARIN policies and sign an RSA."

My understanding is that the current ARIN policies, 4.3.3 and 4.3.6
apply equally to ARIN assignments and Specified transfers,
except that the time horizon of specified transfers is two years
(which happens to be double the time horizon of ARIN assignments).

I interpret this to mean that specified transfers are justified by 50%
utilization
in two years (instead of one).

With a doubling of the time horizon I think it is charitable and reasonable
to also double the 25% time horizon to 60 days (although one could argue
that number is based on immediate need, whose definition does not change
WRT specified transfers).

WRT checking, I am referring specifically to specified transfers.
(Thank you for making me clarify that, I see now how that is confusing).

It seems ARIN does not make the 25% check for specified transfers
making this policy a no-op.

At the same time there are organizations, who what to do the right thing,
who limit there end-user transfer requests to only four times what they can
deploy in 60 days.  Without the 25% check, those organizations will be able
to remain in policy, and transfer much more address space.  So in that sense
is NOT a no-op.

My real concern is that the possibility of a 30 or 60 day check is
sufficient to
limit wildly optimistic two year projections.

I am only going to ask for what I can commit to deploy in 60 days.  That
time horizon is sufficiently close that things have to be in motion to meet
it.  In the case of two years there can be a lot of hand waviness and
promise to commit resources in future quarters.  These promises are
easily made (and hence attest to) and easily broken (oh the plan changed).

Without some check (the 25% check or something else) then organizations
are free to make wildly optimistic  plans.  As long as the plan has a
possibility
of being completed within 2 years, then it is within policy.

As such a wildly optmistic plan for a 2 year deployment could easily result
in a 10 year supply of addresses for a reasonable growth.

___Jason





On Fri, May 13, 2016 at 4:11 PM, John Curran <jcurran at arin.net> wrote:

> On May 13, 2016, at 3:38 PM, Jason Schiller <jschiller at google.com> wrote:
>
>
> I am highly confused now.
>
> We have the 25% utilization check which really is the only verifiable
> check to rate-limit aggressively optimistic requests.
>
> On one hand, ARIN does not check this figure.  As such the policy
> change is a no-op.
>
> On the other hand the 25% utilization goal remains part of the
> policy and having no intention of complying is fraud.
>
> ARIN could make random checks, or check all of them.
>
> ...
>
>
> Jason -
>
>    Are you referring to assignments or transfers?  The above discussion
>    appears to mix requests of both types.
>
>    ARIN does check that end-user _assignment_ requests meet the
>    25% immediate utilization requirement (as called for in the end-user
>    assignment policy.)
>
>    ARIN does not have clear guidance how the assignment criteria for
>    25% immediate use is to be applied to transfers.  ARIN can apply the
>    criteria with respect to transfer requests, but that would require some
>    additional policy clarity from the community to do so.
>
> So in that respect the policy change is not a no-op.
>
>
>    The policy change will not materially affected transfer requests, as
> noted
>    above.  The change would effect processing of any end-user assignments
>    requests.  (It is probably worth noting that end-users who presently
> qualify
>    for assignment of an IPv4 block are being added to a waiting list with
> a
>    rather low probability of timely fulfillment.)
>
> Thanks,
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
>
>
>
>


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

From jschiller at google.com  Mon May 16 11:10:14 2016
From: jschiller at google.com (Jason Schiller)
Date: Mon, 16 May 2016 11:10:14 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CALdayyEoLV9i+YAyOZhjCd1Y+4GRxabP2veL79v=Doyhspq-Rg@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<3B13A871-286A-4113-9246-E2151703BE3E@corp.arin.net>
	<CALdayyEoLV9i+YAyOZhjCd1Y+4GRxabP2veL79v=Doyhspq-Rg@mail.gmail.com>
Message-ID: <CAC4yj2XnXXxTXJnkCGust2J9mgeEB0VezpnTtVDFgKG=_3g8Uw@mail.gmail.com>

Alyssa,

I agree with the general will of the community that a 30 day check for
ARIN allocations, and a 30 or 60 day check for specified transfers is
an unreasonably difficult metric to meet.

I suggested "Removing the 25% / 30 day [60 day for transfers]
requirement without some added test based on a current or past
measure of need to deflate a purely future looking projection
seems too liberal."

This would roughly amount to slow start, you get a two year supply
based on double what you used last year.  This is what ISPs are
held to.

I suggested that the 25% provision "is the only provision that has
a real, tangible, and verifiable claim.  Without this check justified
need for end users simply becomes a 1 [2 year for transfers] year
future looking projection, and with sufficient arm waving an easy
end run around justified need for any end user with no IP space
or if they are efficiently using what they currently hold."

I further suggested that "I could get on board if the maximum sized
block permitted on a purely future looking projection was a /24 and
you had to use it prior to getting more."

This would support an initial assignment for organization that have
no history of growth in the last two years.  This would be the starting
point for slow start, and then would double is used in less than a year.

I also said I could get on board if the following text was added to the
policy:

"there must be some tangible and verifiable claim to show there was a
real commitment to use half the address space within one year and not
just a future projection or business case"

And suggested we should have a discussion about if that provision should
be vague (as is above), specific (listing types of proof acceptable), or
opened ended (listing some of the types of proof as guidance).

Response was:

1. - Why add text to IPv4 policy.
    - You already have to pay for IPv4, that should be sufficient to avoid
abuse.
    - Besides we should all only care about IPv6
    - prefer as written

2. - I am leaning towards an open ended verifiable claims.
     - Specific claims could also work.
     - We really need some guidance about what ARIN takes as acceptable
        justification in order to move forward on getting an allocation
approved

3. support as written

4. support as written

5. oppose as written
    - needs teeth

two support as written
one prefer as written
one leaning towards open ended tangible proof
one opposed as written without teeth


What is truly concerning to me is this belief that
the policy change is a no-op on the following
grounds:

1. It does change the rules for ARIN allocations
    but who cares, there is a long waiting list and
    a trickle of space coming out there.

2. It doesn't change anything for transfers as
    staff ignores this check anyway.

I was surprised that ARIN feels they cannot
complete a 25% check wrt specified transfers
due to lack of guidance.

I was further confused by the staff comment that
the 25% check is still part of policy and intentionally
violating it is fraud.

I further believe this change is not a no-op.

1. Current policy prevents organizations who do not
    want to commit fraud from asking for too much.

2. Current policy prevents organizations who are
    afraid of a possible audit of the 25% number
    is likely to show them out of compliance from
   asking for to much.

3. if it is a no-op then just leave the text in until
    we can find new text to prevent aggressively
    optimistic projections that circumvent need
    based policy.


Without this text, or some other provision to limit
wildly optimistic growth claims, there is no way
to keep an end-user organization that wants to
remain in compliance with policy from asking for
what is likely much more than a two year supply.

Essentially the policy will be:
"End-users can get as much IP space as they want
  as long as they meet the 3 following requirements:
1. The average of their current holdings (if any)
     are above 80% used.
2. An officer of the company attests that the plan to
    use half the requested addresses in two years
    is not impossible to achieve.
3. They can afford to buy the addresses."


Alyssa, your questions about what advice to give ARIN
about current policy is a very interesting question.

Unfortunately it crosses the transfer without needs
justification discussion, which complicates everything.

I don't know how you can craft the question to get at
the answer of what checks ARIN should do, without
falling into the wider discussion of should there be a
needs basis check at all.

The original proposal was to remove the 30 day check as
it was a burden.

It seems people who support specified transfers without
a needs based justification support this policy as this
moves things far along in that direction.

It seems others support this policy as it makes it possible
for an end-user organization to get addresses without
first using an up-streams IPs.

It seems yet another group believe the 30 day check to
be unreasonable, and taking it out is a no-op
(when it appears to actually limit requests in its current
form even with ARIN's current operating practices)

Unfortunately this is very complicated.

__Jason














On Fri, May 13, 2016 at 6:42 PM, Alyssa Moore <alyssa.moore at cybera.ca>
wrote:

> Apologies in advance for jumping in at the last minute on a policy that's
> in recommended form, but I have a few questions and observations.
>
> 1)  The problem statement says:
> > First, it often takes longer than 30 days to stage equipment and
> start actually using the addresses.
>
> Earlier on, Jason says:
> > "I know I worked very hard to get my recent end-user assignment over
> 25% by the deadline."
>
> It is my understanding, Jason, that you're a proponent of some form of
> verification with teeth - presumably something more aggressive than the 1
> year/50% that would still be included if 2015-3 passes muster, but you also
> concede that you had a difficult time meeting the current 30 day
> "deadline."
>
> I could be completely off base because I haven't been following 2015-3
> since its inception, but has there been any discussion of a test that sits
> somewhere between 25%/30 days and 50%/1 year?
>
> 2) It seems 4.3.3 in its current incarnation *doesn't have teeth to begin
> with *as it applies to transfers (which are really the only option in a
> post-depletion world.) John Curran says:
>
> Such a requirement could only be applicable transfers to end-users who
> were demonstrating their 24-month need using NRPM 4.3.3, and *there is no
> clear interpretation for application of **the  "25% immediate utilization
> rate? language*. As such, it is not directly considered during the
> process (as elaborated by Richard Jimmerson on the list); therefore none
> were ?reviewed and verified explicitly? for that purpose.
>
> Note that the language remains applicable (and organizations that attempt
> to transfer without having immediate utilization do run the risk of
> number resource fraud), but is not integrated into the end-user transfer
> review process as its extrapolation into that context is unclear.  *This
> is also why the staff and legal review for draft policy 2015-3 notes -
> "This policy would **more closely align with the way staff applies the
> existing policy in relation to 8.3 transfers.?*
>
>
> [emphasis my own]
>
> My understanding from these comments is that ARIN has not been doing 30
> day check ups on transfers because *staff has not received direction on
> how to apply the existing policy to transfers, *which would be the reason
> behind the staff assessment, "This policy would more closely align with
> the way staff applies existing policy." To that end, then, the policy in
> its current incarnation is not completely obsolete as some folks have
> claimed on the PPML. Staff simply don't have direction for application of
> the utilization rates.
>
> It seems there needs to be clearer consensus around what the action of
> ARIN staff ought to be a) in pursuing verification in the first place re:
> transfers and b) in cases where verification tests aren't met. Should
> ARIN be automatically checking in at the 30 day or 1 year mark? If so, what
> does ARIN do if the 25%/30 days or 50%/1year tests aren't met? Should
> ARIN revoke the address space? Serve the offender notice? Are either of
> these ethical in a post-depletion world where folks have paid for address
> space?
>
> If the community is to give direction in these areas, should it be
> included in 2015-3, or in a separate problem statement?
>
> Feel free to set me straight on all of this 'cause I'm a giant nooooob.
> - Alyssa
>
> On Fri, May 13, 2016 at 4:19 PM John Curran <jcurran at arin.net> wrote:
>
>> On May 13, 2016, at 3:38 PM, Jason Schiller <jschiller at google.com> wrote:
>>
>>
>> I am highly confused now.
>>
>> We have the 25% utilization check which really is the only verifiable
>> check to rate-limit aggressively optimistic requests.
>>
>> On one hand, ARIN does not check this figure.  As such the policy
>> change is a no-op.
>>
>> On the other hand the 25% utilization goal remains part of the
>> policy and having no intention of complying is fraud.
>>
>> ARIN could make random checks, or check all of them.
>>
>> ...
>>
>>
>> Jason -
>>
>>    Are you referring to assignments or transfers?  The above discussion
>>    appears to mix requests of both types.
>>
>>    ARIN does check that end-user _assignment_ requests meet the
>>    25% immediate utilization requirement (as called for in the end-user
>>    assignment policy.)
>>
>>    ARIN does not have clear guidance how the assignment criteria for
>>    25% immediate use is to be applied to transfers.  ARIN can apply the
>>    criteria with respect to transfer requests, but that would require
>> some
>>    additional policy clarity from the community to do so.
>>
>> So in that respect the policy change is not a no-op.
>>
>>
>>    The policy change will not materially affected transfer requests, as
>> noted
>>    above.  The change would effect processing of any end-user assignments
>>    requests.  (It is probably worth noting that end-users who presently
>> qualify
>>    for assignment of an IPv4 block are being added to a waiting list with
>> a
>>    rather low probability of timely fulfillment.)
>>
>> Thanks,
>> /John
>>
>> John Curran
>> President and CEO
>> ARIN
>>
>>
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
>


-- 
_______________________________________________________
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/20160516/56269565/attachment.htm>

From jschiller at google.com  Mon May 16 11:27:52 2016
From: jschiller at google.com (Jason Schiller)
Date: Mon, 16 May 2016 11:27:52 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
	Policy
In-Reply-To: <32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
Message-ID: <CAC4yj2VkRyXBXemPHLovMpmYkvKN_raVqNWDMcUwr4RRk5a55Q@mail.gmail.com>

Andrew,

Can you clarify where this policy stands?

I can't tell from your email if you are asking for feed back
on a possible change to the policy.  Or if you have actually
rewritten the policy and the AC is requesting comments on
the newly re-written policy.

If the latter, can Sean please update the text at:
https://www.arin.net/policy/proposals/2016_1.html

to show it has been re-written, post the new text there
and a pointer to the now archived older revision?

(e.g. https://www.arin.net/policy/proposals/2015_9.html)

Thanks,

__Jason



On Thu, May 5, 2016 at 10:59 AM, Andrew Dul <andrew.dul at quark.net> wrote:

> Hello,
>
> As part of the discussions at ARIN 37 the community considered updates to
> the proposed draft policy that would allow organizations to transfer,
> within ARIN, reserved pool resources provided that they met the criteria to
> obtain a block from a reserved pool.
>
> Based upon this feedback we are proposing to update the draft policy text
> as follows.  The AC welcomes your feedback on this proposed text and any
> other feedback on this draft policy.
>
> Thanks,
>
> Andrew
>
>
> *Original** Policy statement:*
>
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
> transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> *Updated **Policy statement:*
>
> Add to Section 8.3 under the "Conditions on recipient of the transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) shall only be transferred to organizations which meet
> the current criteria of the reserved pool from which the resource was
> obtained.
> Add to Section 8.4 under the "Conditions on source of the transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> _______________________________________________
> PPML
> You are receiving this message 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/20160516/96077b58/attachment.htm>

From andrew.dul at quark.net  Mon May 16 12:39:03 2016
From: andrew.dul at quark.net (Andrew Dul)
Date: Mon, 16 May 2016 09:39:03 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
 Policy
In-Reply-To: <CAC4yj2VkRyXBXemPHLovMpmYkvKN_raVqNWDMcUwr4RRk5a55Q@mail.gmail.com>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
	<CAC4yj2VkRyXBXemPHLovMpmYkvKN_raVqNWDMcUwr4RRk5a55Q@mail.gmail.com>
Message-ID: <4fbaf18a-d972-7a35-32cf-e8301c2d0dc2@quark.net>

The shepherds have requested feedback on a proposed update to the
draft.  The draft has not yet been formally updated.

Andrew

On 5/16/2016 8:27 AM, Jason Schiller wrote:
> Andrew, 
>
> Can you clarify where this policy stands?
>
> I can't tell from your email if you are asking for feed back 
> on a possible change to the policy.  Or if you have actually
> rewritten the policy and the AC is requesting comments on 
> the newly re-written policy.
>
> If the latter, can Sean please update the text at:
> https://www.arin.net/policy/proposals/2016_1.html
>
> to show it has been re-written, post the new text there
> and a pointer to the now archived older revision?
>
> (e.g. https://www.arin.net/policy/proposals/2015_9.html)
>
> Thanks,
>
> __Jason
>
>
>
> On Thu, May 5, 2016 at 10:59 AM, Andrew Dul <andrew.dul at quark.net
> <mailto:andrew.dul at quark.net>> wrote:
>
>     Hello,
>
>     As part of the discussions at ARIN 37 the community considered
>     updates to the proposed draft policy that would allow
>     organizations to transfer, within ARIN, reserved pool resources
>     provided that they met the criteria to obtain a block from a
>     reserved pool.
>
>     Based upon this feedback we are proposing to update the draft
>     policy text as follows.  The AC welcomes your feedback on this
>     proposed text and any other feedback on this draft policy.
>
>     Thanks,
>
>     Andrew
>
>
>     *Original**Policy statement:*
>
>     Add to Section 8.3 and Section 8.4 under the "Conditions on source
>     of the transfer:"
>
>     Address resources from a reserved pool (including those designated
>     in Section 4.4 and 4.10) are not eligible for transfer.
>
>     **Updated ***Policy statement:*
>
>     Add to Section 8.3 under the "Conditions on recipient of the
>     transfer:"
>
>     Address resources from a reserved pool (including those designated
>     in Section 4.4 and 4.10) shall only be transferred to
>     organizations which meet the current criteria of the reserved pool
>     from which the resource was obtained.
>
>     Add to Section 8.4 under the "Conditions on source of the transfer:"
>
>     Address resources from a reserved pool (including those designated
>     in Section 4.4 and 4.10) are not eligible for transfer.
>
>
>     _______________________________________________
>     PPML
>     You are receiving this message because you are subscribed to
>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>     <mailto:ARIN-PPML at arin.net>).
>     Unsubscribe or manage your mailing list subscription at:
>     http://lists.arin.net/mailman/listinfo/arin-ppml
>     Please contact info at arin.net <mailto:info at arin.net> if you
>     experience any issues.
>
>
>
>
> -- 
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com
> <mailto:jschiller at google.com>|571-266-0006
>

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

From dogwallah at gmail.com  Mon May 16 13:36:01 2016
From: dogwallah at gmail.com (McTim)
Date: Mon, 16 May 2016 13:36:01 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
Message-ID: <CACAaNxj77+7qPT_uoWXd9BFvRhuHCR48cjaOfFVoyXiSP6SKNA@mail.gmail.com>

On Sun, May 15, 2016 at 10:32 PM, Owen DeLong <owen at delong.com> wrote:

<SNIP>


>
> If we eliminate needs assessment, what mechanism assures that the transferee
> is actually a network operator?

This, to my mind is the central question.  Do we, as a community want
to allocate/assign resources to folks who will speculate in address
resources for fun and profit or not?


 Further, how does it in any way assure that
> the transfer is from a place of less need to a place of greater need rather
> than a place of limited need to a place of greater monetary resources?
>


it does not.


-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel


From scottleibrand at gmail.com  Mon May 16 13:38:56 2016
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 16 May 2016 17:38:56 +0000 (UTC)
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <BN1PR06MB2326DBB437EB074B0587A50A9740@BN1PR06MB232.namprd06.prod.outlook.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BN1PR06MB2326DBB437EB074B0587A50A9740@BN1PR06MB232.namprd06.prod.outlook.com>
Message-ID: <EF501E8D91217774.21752E5B-CEEC-4A97-B69C-704B3EF557E3@mail.outlook.com>

Robert,
Do you support or oppose ARIN-2015-3?

-Scott

    _____________________________
From: Robert Jacobs <rjacobs at pslightwave.com>
Sent: Monday, May 16, 2016 10:32 AM
Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy
To: Owen DeLong <owen at delong.com>, Jason Schiller <jschiller at google.com>
Cc:  <arin-ppml at arin.net>




Boy did you hit the nail on the head? thanks Jason as we are one of those who are hoping to ride out this transition period and continue to have IPV4 ip?s to feed our sales and expansion efforts?It is not a fun process right now keeping a steady supply of /22?s or /21?s coming in

?

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]On Behalf Of Jason Schiller
Sent: Friday, May 13, 2016 2:38 PM
To: Owen DeLong <owen at delong.com>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

?

I am highly confused now.

?

We have the 25% utilization check which really is the only verifiable?

check to rate-limit aggressively optimistic requests.

?

On one hand, ARIN does not check this figure.? As such the policy?

change is a no-op.

?

On the other hand the 25% utilization goal remains part of the?

policy and having no intention of complying is fraud.

?

ARIN could make random checks, or check all of them.

?

ARIN should check if they have reason to suspect there might

be fraud.

?

I know I worked very hard to get my recent end-user assignment

over 25% by the deadline. ??

?

I know in my case the 25% number limited the size of the block.

?

I suspect there are a lot of honest organizations / people who are

trying to do the right thing while maximizing their requested size

within the constraints of policy.

?

So in that respect the policy change is not a no-op.

It would make it easier for end-sites who want to stay?

in compliance with policy to get more IP space by?

simply optimistically and aggressively accelerating their?

deployment plans by compressing a 5 or 10 year plan into?

two years.? Noting there is no harm, no foul if in two years

time the plans have changed, or a simply not achieved.

?

?

On another topic... ?

Arguments that IPs are being locked up outside of the?

needs assessment and therefor we should remove the?

needs assessment all together suggests we should?

remove speed limits because so many people speed.

?

Ignoring the fraud aspect for a moment, stockpiling IP?

addresses that are registered to you is very different?

than a future in terms of risk profile.? Lowering the risk?

will encourage this behavior.?

?

?

If the IPs are in the free pool, or available on the transfer

market doesn't change the fact that the numbers are a?

limited and shared resource whose value comes from?

the insurance that the resource holder has exclusive?

claim to a unique set of numbers.? In fact I would argue

that the supply of IPs are more limited now then they?

ever were, especially for large blocks, and especially

for organizations that have been priced out of the?

market and as such stewardship is even more?

important.

?

?

Organizations that have "delusions of grandeur" and?

purchase "extra" IPs will not necessarily "pay dearly".

?

Sure it is a costly mistake to buy what turns out to be

a 50 year supply of addresses.? But the real window

is between the two years which is currently permitted

and the day when IPv6 has wide spread adoption?

such that a transit provider can offer IPv6-only service

and their customers are not inconvenienced, and?

content providers can offer IPv6-only service and not?

risk losing customers that cannot reach them.

?

The goal is to have enough IPv4 addresses to get?

through the transition period to when there is wide

spread support of IPv6, and if you can't secure that

much, than at least more that your competition in a?

given market segment such that you don't have a?

competitive disadvantage of offering a service that

can reach "most of the internet" and if it can reach

the IPv4-only Internet is will be through costly, and

possibly performance and security impacting?

translation middle boxes.

?

A small overage such as buying an 8 year supply?

when you only need a 4 year supply is easily?

justified as an insurance policy and preferable

to having bought a 4 year supply when you needed

an 8 year supply.

?

Nobody complains at the end of the year that they?

wasted a bunch of money on health insurance and?

didn't get sick all year.

?

___Jason

?

?

On Fri, May 13, 2016 at 1:06 AM, Owen DeLong <owen at delong.com> wrote:

I see the policy itself largely as a no-op. I have no objection for it going to the board,

nor do I have any significant support for it to do so.

?

Owen

?

On May 12, 2016, at 18:53 , David Farmer <farmer at umn.edu> wrote:

?

Jason,

Even though the last call period formally ended May 9th, I try my best
to consider all feedback received for a policy even following the
formal last call deadline, and while I can't speak for directly for
other AC members, I believe most of them do the same.? However, when
feedback comes in late sometimes it might not get full consideration,
especially if it comes in immediately prior to one of our conference
calls.? To help avoid this I explicitly noted when AC would be
considering the feedback.? I will additionally note at this point it
is extremely important to get any additional feedback in ASAP to allow
the AC due time for its consideration prior to its May 19th conference
call.

As for the issues and questions you have raise, I believe John and
Richard have been answering your questions.? Further, I believe the
community consensus remains to move forward with removing the 25%
Immediate (30 day) use requirement for end users as this policy
suggests.? I would specifically ask anyone who disagrees and thinks we
need to consider the issues more to speak up ASAP.

Thanks.

On Tue, May 10, 2016 at 11:32 AM, Jason Schiller <jschiller at google.com> wrote:



I seem to have missed the this thread in last call, and hope you
will consider the discussion on the other thread: " Re: [arin-ppml]
ARIN-2015-3:(remove 30-day...) Staff interpretation needed"

I maintain that the 30-day [60-day for transfers] check has
been useful in mitigating abusively large requests, and
without it there is no teeth in the policy to prevent abuse.


I asked if I was wrong about this, please explain what
mechanisms are in place to mitigate an end-user asking for
approval for a 10 year supply of addresses on the grounds that
if things go really really well, it will only be a 2 year supply?

I heard no response to indicate there was any mechanism.


I asked staff about information about stats that might help
determine what level of push back ARIN provides against two
year projected need in general, and if that push back would be
sufficient to prevent outlandishly large claims.

We found that 50% - 75% of all requests are approved with
past utilization more heavily weighed.

It remains unclear what level of oversight ARIN has to
question future looking projections.? John Curran provided
some text about approvals of future looking projections.

??"When we [ARIN] ask organization for their forward
???projections, we [ARIN] also ask them to provide details
??to show how they've arrived at their projections. We [ARIN]
??take into account factors such as new networks, locations,
??products, services they plan on offering (and this includes
??consideration of anticipated address utilization within the
??first 30 days for end-users.)

>From the text John provided it seems one could get IP
addresses solely on future looking plans which are
unverifiable.? As such an end-user could easily get a 10
year supply of addresses simply by providing very
optimistic deployment plans for the next 24 months.



I asked if I was not wrong about this, then did people realize
that this policy is basically an end-run around giving out
addresses based on need when they voted to move this
policy forward?

I heard no response to this.

Thanks,

__Jason


On Thu, May 5, 2016 at 11:45 AM, David Farmer <farmer at umn.edu> wrote:




As shepherd for this policy I welcome any additional last call
feedback for this policy.? It is especially important to speak up if
you feel there are any issues remaining that need to be considered.
But, even if you simply support the policy as written that is
important and useful feedback as well.

The last call period formally continues through, Monday, May 9th, and
the AC will consider the feedback during its scheduled call on
Thursday, May 19th.

Thanks

On Mon, Apr 25, 2016 at 1:38 PM, ARIN <info at arin.net> wrote:



The ARIN Advisory Council (AC) met on 20 April 2016 and decided to
send the following to last call:

?Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization
requirement in end-user IPv4 policy

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. This last call will
expire on 9 May 2016. After last call the AC will conduct their
last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

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


## * ##


Recommended Draft Policy ARIN-2015-3
Remove 30 day utilization requirement in end-user IPv4 policy

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

ARIN 2015-3 contributes to fair and impartial number resource
administration
by removing from the NRPM text that is operationally unrealistic for the
reasons discussed in the problem statement. This proposal is technically
sound, in that the removal of the text will more closely align with the
way
staff applies the existing policy in relation to 8.3 transfers. There
was
strong community support for the policy on PPML and at ARIN 36, which
was
confirmed at ARIN 37. There was a suggestion to replace this text with
an
alternate requirement. However, the community consensus was to move
forward
with the removal alone.

The staff and legal review also suggested removing RFC2050 references
and
pointed out that 4.2.3.6 has an additional 25% immediate use clause,
community feedback was to deal with those issues separately.

Problem Statement:

End-user policy is intended to provide end-users with a one year supply
of
IP addresses. Qualification for a one-year supply requires the network
operator to utilize at least 25% of the requested addresses within 30
days.
This text is unrealistic and should be removed.

First, it often takes longer than 30 days to stage equipment and start
actually using the addresses.

Second, growth is often not that regimented; the forecast is to use X
addresses over the course of a year, not to use 25% of X within 30 days.

Third, this policy text applies to additional address space requests. It
is
incompatible with the requirements of other additional address space
request
justification which indicates that 80% utilization of existing space is
sufficient to justify new space. If a block is at 80%, then often
(almost
always?) the remaining 80% will be used over the next 30 days and
longer.
Therefore the operator cannot honestly state they will use 25% of the
ADDITIONAL space within 30 days of receiving it; they're still trying to
use
their older block efficiently.

Fourth, in the face of ARIN exhaustion, some ISPs are starting to not
give
out /24 (or larger) blocks. So the justification for the 25% rule that
previously existed (and in fact, applied for many years) is no longer
germane.

Policy statement:

Remove the 25% utilization criteria bullet point from NRPM 4.3.3.

Resulting text:

4.3.3. Utilization rate

Utilization rate of address space is a key factor in justifying a new
assignment of IP address space. Requesters must show exactly how
previous
address assignments have been utilized and must provide appropriate
details
to verify their one-year growth projection.

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

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

Comments:

a.Timetable for implementation: Immediate

b.Anything else

#####

ARIN STAFF ASSESSMENT

Draft Policy ARIN-2015-3
Remove 30 day utilization requirement in end-user IPv4 policy
Date of Assessment: 16 February 2016

___
1. Summary (Staff Understanding)

This proposal would remove the 25% utilization (within 30 days of
issuance)
criteria bullet point from NRPM 4.3.3.

___
2. Comments

A. ARIN Staff Comments
This policy would more closely align with the way staff applies the
existing
policy in relation to 8.3 transfers. Because there is no longer an IPv4
free
pool and many IPv4 requests are likely to be satisfied by 8.3 transfers,
the
adoption of this policy should have no major impact on operations and
could
be implemented as written.

Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to
obsolete
RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within
30
days of issuance) requirement.

Staff suggests removing the first two sentences of 4.2.3.6 to remove the
references to RFC 2050 and the 25% requirement. Additionally, staff
suggests
removing the reference to the obsolete RFC 2050 in section 4.3.3.

B. ARIN General Counsel ? Legal Assessment
No material legal risk in this policy.

___
3. Resource Impact

This policy would have minimal resource impact from an implementation
aspect. It is estimated that implementation would occur immediately
after
ratification by the ARIN Board of Trustees. The following would be
needed in
order to implement:
* Updated guidelines and internal procedures
* Staff training
_______________________________________________
PPML
You are receiving this message 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
===============================================
_______________________________________________
PPML
You are receiving this message 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




--?
===============================================
David Farmer ??????????????Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE ???????Phone: 612-626-0815
Minneapolis, MN 55414-3029 ??Cell: 612-812-9952
===============================================
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact?info at arin.net?if you experience any issues.

?





?

-- 

_______________________________________________________

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/20160516/39717214/attachment.htm>

From bcornett at servlet.com  Mon May 16 13:45:59 2016
From: bcornett at servlet.com (Bruce Cornett)
Date: Mon, 16 May 2016 13:45:59 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <EF501E8D91217774.21752E5B-CEEC-4A97-B69C-704B3EF557E3@mail.outlook.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BN1PR06MB2326DBB437EB074B0587A50A9740@BN1PR06MB232.namprd06.prod.outlook.com>
	<EF501E8D91217774.21752E5B-CEEC-4A97-B69C-704B3EF557E3@mail.outlook.com>
Message-ID: <573A0757.1090501@servlet.com>

All

For what it is worth, we support ARIN-2015-3.  It seems that it will 
help the little guys. Not many of us left...

Bruce Cornett
Servlet Internet Services



From scottleibrand at gmail.com  Mon May 16 13:46:19 2016
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 16 May 2016 10:46:19 -0700
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
	Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CACAaNxj77+7qPT_uoWXd9BFvRhuHCR48cjaOfFVoyXiSP6SKNA@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
	<CACAaNxj77+7qPT_uoWXd9BFvRhuHCR48cjaOfFVoyXiSP6SKNA@mail.gmail.com>
Message-ID: <7FD2E2C5-EC59-4540-977B-080A757B5EBD@gmail.com>


> On May 16, 2016, at 10:36 AM, McTim <dogwallah at gmail.com> wrote:
> 
> On Sun, May 15, 2016 at 10:32 PM, Owen DeLong <owen at delong.com> wrote:
> 
> <SNIP>
> 
> 
>> 
>> If we eliminate needs assessment, what mechanism assures that the transferee
>> is actually a network operator?
> 
> This, to my mind is the central question.  Do we, as a community want
> to allocate/assign resources to folks who will speculate in address
> resources for fun and profit or not?

I don't think the implications of full elimination of needs assessment are on topic for this thread. If anyone  believes that ARIN-2015-3 would allow organizations who do not operate a network and do not have any need for addresses to acquire them for speculative purposes, I think they are mistaken, so I would need to see a lot more justification to consider that as a valid last call objection to 2015-3. As Jason mentioned, this proposal relaxes needs requirements somewhat, but does not eliminate them. 

-Scott

> 
> 
> Further, how does it in any way assure that
>> the transfer is from a place of less need to a place of greater need rather
>> than a place of limited need to a place of greater monetary resources?
> 
> 
> it does not.
> 
> 
> -- 
> Cheers,
> 
> McTim
> "A name indicates what we seek. An address indicates where it is. A
> route indicates how we get there."  Jon Postel
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From owen at delong.com  Mon May 16 14:07:06 2016
From: owen at delong.com (Owen DeLong)
Date: Mon, 16 May 2016 11:07:06 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
	Policy
In-Reply-To: <4fbaf18a-d972-7a35-32cf-e8301c2d0dc2@quark.net>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
	<CAC4yj2VkRyXBXemPHLovMpmYkvKN_raVqNWDMcUwr4RRk5a55Q@mail.gmail.com>
	<4fbaf18a-d972-7a35-32cf-e8301c2d0dc2@quark.net>
Message-ID: <095908B3-D045-4D37-8D83-0DF236B0EC45@delong.com>

Overall, I do not think that the proposed changes have the support of the community and I would advocate leaving the policy as written.

Owen

> On May 16, 2016, at 09:39 , Andrew Dul <andrew.dul at quark.net> wrote:
> 
> The shepherds have requested feedback on a proposed update to the draft.  The draft has not yet been formally updated.
> 
> Andrew
> 
> On 5/16/2016 8:27 AM, Jason Schiller wrote:
>> Andrew, 
>> 
>> Can you clarify where this policy stands?
>> 
>> I can't tell from your email if you are asking for feed back 
>> on a possible change to the policy.  Or if you have actually
>> rewritten the policy and the AC is requesting comments on 
>> the newly re-written policy.
>> 
>> If the latter, can Sean please update the text at:
>> https://www.arin.net/policy/proposals/2016_1.html <https://www.arin.net/policy/proposals/2016_1.html>
>> 
>> to show it has been re-written, post the new text there
>> and a pointer to the now archived older revision?
>> 
>> (e.g. https://www.arin.net/policy/proposals/2015_9.html <https://www.arin.net/policy/proposals/2015_9.html>)
>> 
>> Thanks,
>> 
>> __Jason
>> 
>> 
>> 
>> On Thu, May 5, 2016 at 10:59 AM, Andrew Dul <andrew.dul at quark.net <mailto:andrew.dul at quark.net>> wrote:
>> Hello,
>> 
>> As part of the discussions at ARIN 37 the community considered updates to the proposed draft policy that would allow organizations to transfer, within ARIN, reserved pool resources provided that they met the criteria to obtain a block from a reserved pool. 
>> Based upon this feedback we are proposing to update the draft policy text as follows.  The AC welcomes your feedback on this proposed text and any other feedback on this draft policy.
>> 
>> Thanks,
>> 
>> Andrew
>> 
>> Original Policy statement:
>> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the transfer:"
>> 
>> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.
>> 
>> Updated Policy statement:
>> 
>> Add to Section 8.3 under the "Conditions on recipient of the transfer:"
>> 
>> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) shall only be transferred to organizations which meet the current criteria of the reserved pool from which the resource was obtained.
>> 
>> Add to Section 8.4 under the "Conditions on source of the transfer:"
>> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.
>> 
>> 
>> _______________________________________________
>> 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 <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/20160516/f84b83fb/attachment.htm>

From gary.buhrmaster at gmail.com  Mon May 16 14:37:26 2016
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Mon, 16 May 2016 18:37:26 +0000
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
	Policy
In-Reply-To: <4fbaf18a-d972-7a35-32cf-e8301c2d0dc2@quark.net>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
	<CAC4yj2VkRyXBXemPHLovMpmYkvKN_raVqNWDMcUwr4RRk5a55Q@mail.gmail.com>
	<4fbaf18a-d972-7a35-32cf-e8301c2d0dc2@quark.net>
Message-ID: <CAMfXtQw_aWEu9Gj_-f6Fv_86jNEPUkx-=NaLTLLOmmbiBu9Czw@mail.gmail.com>

On Mon, May 16, 2016 at 4:39 PM, Andrew Dul <andrew.dul at quark.net> wrote:
> The shepherds have requested feedback on a proposed update to the draft.
> The draft has not yet been formally updated.

I support the proposed changes to allow continued
use of reserved pool numbers in the same manor for
which they were initially made available, but would
support the policy moving forward with or without
the changes.


From andrew.dul at quark.net  Tue May 17 11:35:11 2016
From: andrew.dul at quark.net (Andrew Dul)
Date: Tue, 17 May 2016 08:35:11 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
 Policy
In-Reply-To: <095908B3-D045-4D37-8D83-0DF236B0EC45@delong.com>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
	<CAC4yj2VkRyXBXemPHLovMpmYkvKN_raVqNWDMcUwr4RRk5a55Q@mail.gmail.com>
	<4fbaf18a-d972-7a35-32cf-e8301c2d0dc2@quark.net>
	<095908B3-D045-4D37-8D83-0DF236B0EC45@delong.com>
Message-ID: <90af5813-3821-d843-23db-2107d2a775ae@quark.net>

Owen, I don't know what data you are using to base your opinion on, but 
by my count of PPML & the PPM.  We have the following number of 
statements regarding the adding of transfer ability (when it is 
restricted to same use).

Support 5

Don't Support 3

Undecided 2

I don't know if 10 individual comments accurately represents the entire 
community regardless of the subject, but that is the public data as I 
counted it.  Additionally, a number of those who were "don't support" 
also noted that they would be "OK" with the transfer addition of the 
text, which as a policy shepherd would generally make the case toward 
support of the changes.

Andrew


On 5/16/2016 11:07 AM, Owen DeLong wrote:
> Overall, I do not think that the proposed changes have the support of 
> the community and I would advocate leaving the policy as written.
>
> Owen
>
>> On May 16, 2016, at 09:39 , Andrew Dul <andrew.dul at quark.net 
>> <mailto:andrew.dul at quark.net>> wrote:
>>
>> The shepherds have requested feedback on a proposed update to the 
>> draft. The draft has not yet been formally updated.
>>
>> Andrew
>>
>> On 5/16/2016 8:27 AM, Jason Schiller wrote:
>>> Andrew,
>>>
>>> Can you clarify where this policy stands?
>>>
>>> I can't tell from your email if you are asking for feed back
>>> on a possible change to the policy. Or if you have actually
>>> rewritten the policy and the AC is requesting comments on
>>> the newly re-written policy.
>>>
>>> If the latter, can Sean please update the text at:
>>> https://www.arin.net/policy/proposals/2016_1.html
>>>
>>> to show it has been re-written, post the new text there
>>> and a pointer to the now archived older revision?
>>>
>>> (e.g. https://www.arin.net/policy/proposals/2015_9.html)
>>>
>>> Thanks,
>>>
>>> __Jason
>>>
>>>
>>>
>>> On Thu, May 5, 2016 at 10:59 AM, Andrew Dul <andrew.dul at quark.net 
>>> <mailto:andrew.dul at quark.net>> wrote:
>>>
>>>     Hello,
>>>
>>>     As part of the discussions at ARIN 37 the community considered
>>>     updates to the proposed draft policy that would allow
>>>     organizations to transfer, within ARIN, reserved pool resources
>>>     provided that they met the criteria to obtain a block from a
>>>     reserved pool.
>>>
>>>     Based upon this feedback we are proposing to update the draft
>>>     policy text as follows.  The AC welcomes your feedback on this
>>>     proposed text and any other feedback on this draft policy.
>>>
>>>     Thanks,
>>>
>>>     Andrew
>>>
>>>
>>>     *Original**Policy statement:*
>>>
>>>     Add to Section 8.3 and Section 8.4 under the "Conditions on
>>>     source of the transfer:"
>>>
>>>     Address resources from a reserved pool (including those
>>>     designated in Section 4.4 and 4.10) are not eligible for transfer.
>>>
>>>     **Updated ***Policy statement:*
>>>
>>>     Add to Section 8.3 under the "Conditions on recipient of the
>>>     transfer:"
>>>
>>>     Address resources from a reserved pool (including those
>>>     designated in Section 4.4 and 4.10) shall only be transferred to
>>>     organizations which meet the current criteria of the reserved
>>>     pool from which the resource was obtained.
>>>
>>>     Add to Section 8.4 under the "Conditions on source of the
>>>     transfer:"
>>>
>>>     Address resources from a reserved pool (including those
>>>     designated in Section 4.4 and 4.10) are not eligible for transfer.
>>>
>>>
>>>     _______________________________________________
>>>     PPML
>>>     You are receiving this message 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 <mailto:info at arin.net> if you
>>>     experience any issues.
>>>
>>>
>>>
>>>
>>> -- 
>>> _______________________________________________________
>>> Jason Schiller|NetOps|jschiller at google.com 
>>> <mailto:jschiller at google.com>|571-266-0006
>>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net 
>> <mailto:ARIN-PPML at arin.net>).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> 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/20160517/f7e908ef/attachment.htm>

From daveid at panix.com  Tue May 17 11:57:38 2016
From: daveid at panix.com (David Huberman)
Date: Tue, 17 May 2016 11:57:38 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
	Policy
In-Reply-To: <90af5813-3821-d843-23db-2107d2a775ae@quark.net>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
	<CAC4yj2VkRyXBXemPHLovMpmYkvKN_raVqNWDMcUwr4RRk5a55Q@mail.gmail.com>
	<4fbaf18a-d972-7a35-32cf-e8301c2d0dc2@quark.net>
	<095908B3-D045-4D37-8D83-0DF236B0EC45@delong.com>
	<90af5813-3821-d843-23db-2107d2a775ae@quark.net>
Message-ID: <4159C554-E683-4102-BC79-D0807FF82541@panix.com>

Count me in the support as-is category, please. I don't (presently) buy the case for allowing reserved space to go via 8.3

> On May 17, 2016, at 11:35 AM, Andrew Dul <andrew.dul at quark.net> wrote:
> 
> Owen, I don't know what data you are using to base your opinion on, but by my count of PPML & the PPM.  We have the following number of statements regarding the adding of transfer ability (when it is restricted to same use).
> 
> Support 5
> 
> Don't Support 3
> 
> Undecided 2
> I don't know if 10 individual comments accurately represents the entire community regardless of the subject, but that is the public data as I counted it.  Additionally, a number of those who were "don't support" also noted that they would be "OK" with the       transfer addition of the text, which as a policy shepherd would generally make the case toward support of the changes.
> Andrew
> 
>> On 5/16/2016 11:07 AM, Owen DeLong wrote:
>> Overall, I do not think that the proposed changes have the support of the community and I would advocate leaving the policy as written.
>> 
>> Owen
>> 
>>> On May 16, 2016, at 09:39 , Andrew Dul <andrew.dul at quark.net> wrote:
>>> 
>>> The shepherds have requested feedback on a proposed update to the draft.  The draft has not yet been formally updated.
>>> 
>>> Andrew
>>> 
>>>> On 5/16/2016 8:27 AM, Jason Schiller wrote:
>>>> Andrew, 
>>>> 
>>>> Can you clarify where this policy stands?
>>>> 
>>>> I can't tell from your email if you are asking for feed back 
>>>> on a possible change to the policy.  Or if you have actually
>>>> rewritten the policy and the AC is requesting comments on 
>>>> the newly re-written policy.
>>>> 
>>>> If the latter, can Sean please update the text at:
>>>> https://www.arin.net/policy/proposals/2016_1.html
>>>> 
>>>> to show it has been re-written, post the new text there
>>>> and a pointer to the now archived older revision?
>>>> 
>>>> (e.g. https://www.arin.net/policy/proposals/2015_9.html)
>>>> 
>>>> Thanks,
>>>> 
>>>> __Jason
>>>> 
>>>> 
>>>> 
>>>> On Thu, May 5, 2016 at 10:59 AM, Andrew Dul <andrew.dul at quark.net> wrote:
>>>>> Hello,
>>>>> 
>>>>> As part of the discussions at ARIN 37 the community considered updates to the proposed draft policy that would allow organizations to transfer, within ARIN, reserved pool resources provided that they met the criteria to obtain a block from a reserved pool. 
>>>>> Based upon this feedback we are proposing to update the draft policy text as follows.  The AC welcomes your feedback on this proposed text and any other feedback on this draft policy.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Andrew
>>>>> 
>>>>> Original Policy statement:
>>>>> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the transfer:"
>>>>> 
>>>>> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.
>>>>> 
>>>>> Updated Policy statement:
>>>>> 
>>>>> Add to Section 8.3 under the "Conditions on recipient of the transfer:"
>>>>> 
>>>>> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) shall only be transferred to organizations which meet the current criteria of the reserved pool from which the resource was obtained.
>>>>> 
>>>>> Add to Section 8.4 under the "Conditions on source of the transfer:"
>>>>> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> PPML
>>>>> You are receiving this message because you are subscribed to
>>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>>> Please contact info at arin.net if you experience any issues.
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> _______________________________________________________
>>>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>>> 
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message 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/20160517/3a895269/attachment.htm>

From alyssa.moore at cybera.ca  Tue May 17 16:16:37 2016
From: alyssa.moore at cybera.ca (Alyssa Moore)
Date: Tue, 17 May 2016 20:16:37 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <7FD2E2C5-EC59-4540-977B-080A757B5EBD@gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
	<CACAaNxj77+7qPT_uoWXd9BFvRhuHCR48cjaOfFVoyXiSP6SKNA@mail.gmail.com>
	<7FD2E2C5-EC59-4540-977B-080A757B5EBD@gmail.com>
Message-ID: <CALdayyF6vxwAt1PJN6nh7fOEtvT6UWZKKpB9ZSSNYrDm+obfKA@mail.gmail.com>

Thanks for that thoughtful response and recap, Jason. I really appreciate
it.

I agree with Bruce that 2015-3 helps the little guy (coming from a 'little
guy' myself) in that the 30 days is onerous, however at the other end of
the spectrum this could end up hurting the little guy unable to pay for
space at inflated prices, if the, uhh, speculation re: speculation proves
true.

While, as Scott mentioned, 2015-3 does not represent full elimination of
needs assessment and arguments to that end fall prey to the slippery slope
fallacy, it does relax needs assessment. Or at least* perceived *needs
assessment under the current operational practices re: transfers at the 30
day mark.

I agree with Jason that the current policy is not no-op, even without staff
checking up at 30 days, so long as the possibility of one committing fraud
by non-compliance is present.

At this time, I support the removal of the 30 days provision, but would
like to see another mechanism for limiting overly optimistic transfers.

On Mon, May 16, 2016 at 11:46 AM Scott Leibrand <scottleibrand at gmail.com>
wrote:

>
> > On May 16, 2016, at 10:36 AM, McTim <dogwallah at gmail.com> wrote:
> >
> > On Sun, May 15, 2016 at 10:32 PM, Owen DeLong <owen at delong.com> wrote:
> >
> > <SNIP>
> >
> >
> >>
> >> If we eliminate needs assessment, what mechanism assures that the
> transferee
> >> is actually a network operator?
> >
> > This, to my mind is the central question.  Do we, as a community want
> > to allocate/assign resources to folks who will speculate in address
> > resources for fun and profit or not?
>
> I don't think the implications of full elimination of needs assessment are
> on topic for this thread. If anyone  believes that ARIN-2015-3 would allow
> organizations who do not operate a network and do not have any need for
> addresses to acquire them for speculative purposes, I think they are
> mistaken, so I would need to see a lot more justification to consider that
> as a valid last call objection to 2015-3. As Jason mentioned, this proposal
> relaxes needs requirements somewhat, but does not eliminate them.
>
> -Scott
>
> >
> >
> > Further, how does it in any way assure that
> >> the transfer is from a place of less need to a place of greater need
> rather
> >> than a place of limited need to a place of greater monetary resources?
> >
> >
> > it does not.
> >
> >
> > --
> > Cheers,
> >
> > McTim
> > "A name indicates what we seek. An address indicates where it is. A
> > route indicates how we get there."  Jon Postel
> > _______________________________________________
> > PPML
> > You are receiving this message 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/20160517/9dd13162/attachment.htm>

From daveid at panix.com  Tue May 17 16:24:06 2016
From: daveid at panix.com (David Huberman)
Date: Tue, 17 May 2016 16:24:06 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
	Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CALdayyF6vxwAt1PJN6nh7fOEtvT6UWZKKpB9ZSSNYrDm+obfKA@mail.gmail.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
	<CACAaNxj77+7qPT_uoWXd9BFvRhuHCR48cjaOfFVoyXiSP6SKNA@mail.gmail.com>
	<7FD2E2C5-EC59-4540-977B-080A757B5EBD@gmail.com>
	<CALdayyF6vxwAt1PJN6nh7fOEtvT6UWZKKpB9ZSSNYrDm+obfKA@mail.gmail.com>
Message-ID: <B9BF94C6-5100-4F19-9BF5-3B080FFBA3BB@panix.com>



> On May 17, 2016, at 4:16 PM, Alyssa Moore <alyssa.moore at cybera.ca> wrote: 
> 
> At this time, I support the removal of the 30 days provision, but would like to see another mechanism for limiting overly optimistic transfers.


My response to this is, "What problem are you trying to solve?" There is no evidence in the record from ARIN staff (or otherwise) that existing processes and procedures are insufficient wrt "overly optimistic transfers", or any evidence that any such problem exists.  

I am all for improving policy however and wherever we can, but this topic baffles me as I don't see any data that would generate this discussion. 


From alyssa.moore at cybera.ca  Tue May 17 18:15:32 2016
From: alyssa.moore at cybera.ca (Alyssa Moore)
Date: Tue, 17 May 2016 22:15:32 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <B9BF94C6-5100-4F19-9BF5-3B080FFBA3BB@panix.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
	<CACAaNxj77+7qPT_uoWXd9BFvRhuHCR48cjaOfFVoyXiSP6SKNA@mail.gmail.com>
	<7FD2E2C5-EC59-4540-977B-080A757B5EBD@gmail.com>
	<CALdayyF6vxwAt1PJN6nh7fOEtvT6UWZKKpB9ZSSNYrDm+obfKA@mail.gmail.com>
	<B9BF94C6-5100-4F19-9BF5-3B080FFBA3BB@panix.com>
Message-ID: <CALdayyGMRhhk32S0FjZfcRzogbL1OiQEdKVm_o3nCD5v6vLhuA@mail.gmail.com>

> On Tue, May 17, 2016 at 2:24 PM David Huberman <daveid at panix.com wrote:

> My response to this is, "What problem are you trying to solve?"

I understand your reasoning, but also don't think that it's unreasonable to
enact policy that prevents a problem from occurring. It may very well be
that there have been no problems on record to date because 4.3 currently
lays out the 25% / 30 day test, which is a deterrent for grand
overestimations.

Eliminating the 25% leaves only the 50% at 1 year needs test.

A mechanism could be as simple as self-reporting at an interval before the
50% / 1 year test, but that may be getting too deep into the day to day
operations of the organization than is necessary for PPML. I'm not keen on
turning ARIN into the numbers police, but I am keen to see utilization
rates remain a major factor in needs justification. Policy language plays a
role in that.

On Tue, May 17, 2016 at 2:24 PM David Huberman <daveid at panix.com> wrote:

>
>
> > On May 17, 2016, at 4:16 PM, Alyssa Moore <alyssa.moore at cybera.ca>
> wrote:
> >
> > At this time, I support the removal of the 30 days provision, but would
> like to see another mechanism for limiting overly optimistic transfers.
>
>
>


> There is no evidence in the record from ARIN staff (or otherwise) that
> existing processes and procedures are insufficient wrt "overly optimistic
> transfers", or any evidence that any such problem exists.
>
> I am all for improving policy however and wherever we can, but this topic
> baffles me as I don't see any data that would generate this discussion.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160517/e3958e40/attachment.htm>

From rbf+arin-ppml at panix.com  Tue May 17 19:31:29 2016
From: rbf+arin-ppml at panix.com (Brett Frankenberger)
Date: Tue, 17 May 2016 18:31:29 -0500
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <CALdayyGMRhhk32S0FjZfcRzogbL1OiQEdKVm_o3nCD5v6vLhuA@mail.gmail.com>
References: <CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
	<CACAaNxj77+7qPT_uoWXd9BFvRhuHCR48cjaOfFVoyXiSP6SKNA@mail.gmail.com>
	<7FD2E2C5-EC59-4540-977B-080A757B5EBD@gmail.com>
	<CALdayyF6vxwAt1PJN6nh7fOEtvT6UWZKKpB9ZSSNYrDm+obfKA@mail.gmail.com>
	<B9BF94C6-5100-4F19-9BF5-3B080FFBA3BB@panix.com>
	<CALdayyGMRhhk32S0FjZfcRzogbL1OiQEdKVm_o3nCD5v6vLhuA@mail.gmail.com>
Message-ID: <20160517233129.GA22613@panix.com>

On Tue, May 17, 2016 at 10:15:32PM +0000, Alyssa Moore wrote:
> 
> I understand your reasoning, but also don't think that it's unreasonable to
> enact policy that prevents a problem from occurring. It may very well be
> that there have been no problems on record to date because 4.3 currently
> lays out the 25% / 30 day test, which is a deterrent for grand
> overestimations.
> 
> Eliminating the 25% leaves only the 50% at 1 year needs test.

Was anyone is seriously applying the 25% rule with the same definition
of utilization as the 50% rule?  Assuming linear (or higher) growth,
25% at 30 days is 100% at 120 days.  I don't think that entities with
linear growth were (prior to the free-pool exhausting), coming back
every 120 days?

My sense is that the 30-day requirement has always been must less
strictly interpreted, both by those seeking address space and by ARIN.

I would be interested in John's insight as to how the rule was applied
for 12-month requests prior to run-out.  Were organizations routinely
submitting plans that showed 25% after 30 days and 50-100% after 12
months and ARIN was routinely accepting that a there were a bunch of
organizations kept experiencing the sort of growth that spikes for 30
days and then continues at a lower rate?  Was there a lot of "well,
close enough" reasoning applied by ARIN to the 30 day requirement? 
More broadly: In ARIN's experience, how was the apparent contradiction
between policy that implicitly talked about 25% utilization in 30 days
but then only about 3% to 7% per month additional utilization after
that, and the reality that few organizations actually grow that way,
worked out in practice?

     -- Brett


From jrdelacruz at acm.org  Wed May 18 07:07:33 2016
From: jrdelacruz at acm.org (Jose R. de la Cruz III)
Date: Wed, 18 May 2016 07:07:33 -0400
Subject: [arin-ppml] Fwd: Draft Policy ARIN-2016-1: Reserved Pool Transfer
	Policy
In-Reply-To: <CAKrxPqcFppL9TuEds6UE9UxSveJOwRSokaTAeZk9LdhDqjn54A@mail.gmail.com>
References: <56F178F9.7020608@arin.net>
	<CAKrxPqcFppL9TuEds6UE9UxSveJOwRSokaTAeZk9LdhDqjn54A@mail.gmail.com>
Message-ID: <CAKrxPqdeLxN6zRh-5e2z+T1_3zjfNP2-VSwEhUJmwy3Bvs+ROQ@mail.gmail.com>

I support the policy changes as written.

Jos?

On Tue, Mar 22, 2016 at 12:55 PM, ARIN <info at arin.net> wrote:

> Draft Policy ARIN-2016-1
> Reserved Pool Transfer Policy
>
> On 17 March 2016 the ARIN Advisory Council (AC) accepted "ARIN-prop-226
> Reserved Pool Transfer Policy" as a Draft Policy.
>
> Draft Policy ARIN-2016-1 is below and can be found at:
> https://www.arin.net/policy/proposals/2016_1.html
>
> You are encouraged to discuss the merits and your concerns of Draft
> Policy 2016-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-2016-1
> Reserved Pool Transfer Policy
>
> Date: 22 March 2016
>
> Problem Statement:
>
> Section 8 of the current NRPM does not distinguish between the transfer of
> blocks from addresses that have been reserved for specific uses and other
> addresses that can be transferred. In sections 4.4 and 4.10 there are
> specific address blocks set aside, based on the need for critical
> infrastructure and IPv6 transitions. Two issues arise if transfers of
> reserved address space occur under the current language of section 8.
> First, if transfers of 4.4 or 4.10 space occur under the current policy
> requirements set forth in sections 8.3 and 8.4, the recipients will be able
> to acquire space that was originally reserved for a specific purpose
> without ever providing evidence that they will be using the space for
> either critical infrastructure or IPv6 transition. Second, if we allow an
> allocation or assignment from the block reserved in section 4.10 to be
> transferred out of the region, it would complicate the single aggregate
> from which providers are being asked to allow in block sizes smaller than a
> /24. This policy would limit the transfer of addresses from reserved pools.
>
> Policy statement:
>
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
> transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> Timetable for implementation: Immediate
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160518/875f5025/attachment.htm>

From kevinb at thewire.ca  Wed May 18 07:56:01 2016
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Wed, 18 May 2016 11:56:01 +0000
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
 Policy
In-Reply-To: <32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
Message-ID: <7E7773B523E82C478734E793E58F69E78E1009BE@SBS2011.thewireinc.local>

Andrew,



I support the proposal as written without the additional transfer language.

I believe that adding in transfers complicates the proposal and based on the 
current available space, will not be needed for a number of years.



Thanks,


Kevin Blumberg





From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf 
Of Andrew Dul
Sent: May 5, 2016 11:00 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer 
Policy



Hello,

As part of the discussions at ARIN 37 the community considered updates to the 
proposed draft policy that would allow organizations to transfer, within ARIN, 
reserved pool resources provided that they met the criteria to obtain a block 
from a reserved pool.

Based upon this feedback we are proposing to update the draft policy text as 
follows.  The AC welcomes your feedback on this proposed text and any other 
feedback on this draft policy.

Thanks,

Andrew



Original Policy statement:

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

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

Updated Policy statement:

Add to Section 8.3 under the "Conditions on recipient of the transfer:"

Address resources from a reserved pool (including those designated in Section 
4.4 and 4.10) shall only be transferred to organizations which meet the 
current criteria of the reserved pool from which the resource was obtained.

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160518/ff2c5946/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4825 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160518/ff2c5946/attachment.p7s>

From bjones at vt.edu  Wed May 18 14:30:48 2016
From: bjones at vt.edu (Brian Jones)
Date: Wed, 18 May 2016 14:30:48 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer
	Policy
In-Reply-To: <7E7773B523E82C478734E793E58F69E78E1009BE@SBS2011.thewireinc.local>
References: <56F178F9.7020608@arin.net>
	<CAMfXtQyC6n5E3Uezz77FhY1DZxDOHTkURmRhoFvm1F6FVMFZYQ@mail.gmail.com>
	<26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com>
	<CAMfXtQzTOkhHBg-CFu0vkEfQk+rvbZDNtioBBrmsDaRkueN2dA@mail.gmail.com>
	<32d48a21-97e6-0483-ee15-1b6b6782bea9@quark.net>
	<7E7773B523E82C478734E793E58F69E78E1009BE@SBS2011.thewireinc.local>
Message-ID: <CANyqO+EsoQRRU1GohdCetUmFxjWdqt5e-uSbr-1t6yWDuxmUOA@mail.gmail.com>

I support as is.

--
Brian
? E Jones
Virginia Tech?

--
Brian

On Wed, May 18, 2016 at 7:56 AM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> Andrew,
>
>
>
> I support the proposal as written without the additional transfer language.
>
> I believe that adding in transfers complicates the proposal and based on
> the current available space, will not be needed for a number of years.
>
>
>
> Thanks,
>
>
> Kevin Blumberg
>
>
>
>
>
> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On
> Behalf Of *Andrew Dul
> *Sent:* May 5, 2016 11:00 AM
> *To:* arin-ppml at arin.net
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool
> Transfer Policy
>
>
>
> Hello,
>
> As part of the discussions at ARIN 37 the community considered updates to
> the proposed draft policy that would allow organizations to transfer,
> within ARIN, reserved pool resources provided that they met the criteria to
> obtain a block from a reserved pool.
>
> Based upon this feedback we are proposing to update the draft policy text
> as follows.  The AC welcomes your feedback on this proposed text and any
> other feedback on this draft policy.
>
> Thanks,
>
> Andrew
>
>
>
> *Original Policy statement:*
>
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
> transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> *Updated Policy statement:*
>
> Add to Section 8.3 under the "Conditions on recipient of the transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) shall only be transferred to organizations which meet
> the current criteria of the reserved pool from which the resource was
> obtained.
>
> Add to Section 8.4 under the "Conditions on source of the transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> _______________________________________________
> PPML
> You are receiving this message 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/20160518/700636cc/attachment.htm>

From milton at gatech.edu  Thu May 19 10:33:01 2016
From: milton at gatech.edu (Mueller, Milton L)
Date: Thu, 19 May 2016 14:33:01 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
Message-ID: <BY2PR07MB2408E4FDF74769AC01297292A14A0@BY2PR07MB2408.namprd07.prod.outlook.com>



From: Owen DeLong [mailto:owen at delong.com]


Transfers are not rationed by price?

MM: False. This is like saying white is black. Transfers involve a payment by the receiving party. They are, therefore, rationed by price. Not much room for debate here.

Price does not ensure that the purchaser has actual need for the resources, it merely insures that they have monetary resources that they are willing to trade for number resources.

MM: It means that they value the resources and thus have some kind of need for them. There are 1,000 other things they could spend that money on but the buyer has determined that the value they will get out of the numbers is at least equal to the value of the money they spend.

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

From milton at gatech.edu  Thu May 19 10:41:57 2016
From: milton at gatech.edu (Mueller, Milton L)
Date: Thu, 19 May 2016 14:41:57 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
Message-ID: <BY2PR07MB2408862693DDFA316B2379A8A14A0@BY2PR07MB2408.namprd07.prod.outlook.com>



From: Owen DeLong [mailto:owen at delong.com]


Transfers are not rationed by price?

MM: False. This is like saying white is black. Transfers involve a payment by the receiving party. They are, therefore, rationed by price. Not much room for debate here. You?re just wrong.

Price does not ensure that the purchaser has actual need for the resources, it merely insures that they have monetary resources that they are willing to trade for number resources.

MM: It means that they value the resources and thus have some kind of need for them. There are 1,000 other things they could spend that money on but the buyer has determined that the value they will get out of the numbers is at least equal to the value of the money they spend.

You?ve presented no evidence whatsoever to support your conclusion that stringent needs assessment raises the price

In fact, in the RIPE region where there are virtually no needs-based controls, according to the brokers I have discussed things with, prices are rising more rapidly than in the ARIN region, which would in fact appear to suggest that our needs-assessment regime is, in fact, holding prices down.

MM: Facts? Citations to specific transactions? I am always open to evidence.

If we eliminate needs assessment, what mechanism assures that the transferee is actually a network operator? Further, how does it in any way assure that the transfer is from a place of less need to a place of greater need rather than a place of limited need to a place of greater monetary resources?

MM: This is not the place to rectify your general lack of familiarity with economics. But you seem to think that people with ?greater monetary resources? simply throw them at anything that moves. In fact, in the real world, everyone tries to maximize the value they get from whatever resources they have. So if someone pays for addresses, it is a very reliable indicator that they need them for something. Most if not all of the organizations that can derive value from numbers are network operators.  The threat of massive speculation is a bogeyman you have invented ? there is no evidence that it exists. The only ?speculation and hoarding? that currently exists is the holding of number resources by current assignees who don?t need them. And stringent needs assessment freezes that problem into place. Sorry to say it, but you, Owen, are one of the greatest defenders of hoarding.

You start with an assumption that you are correct in your conjecture and then act as if it is everyone else?s duty to provide evidence that your speculation is not correct. The reality is that these are judgment calls based on limited experience and while we do know that needs assessment does, in fact, work to some extent, there is very limited experience without it. Unfortunately, once it is eliminated, it will be virtually impossible to put the genie back in the bottle, so people are understandably cautious about opening the bottle all at once.

Owen


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

From mike at iptrading.com  Thu May 19 12:17:32 2016
From: mike at iptrading.com (Mike Burns)
Date: Thu, 19 May 2016 12:17:32 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
	Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <BY2PR07MB2408862693DDFA316B2379A8A14A0@BY2PR07MB2408.namprd07.prod.outlook.com>
References: <571E6439.7010801@arin.net>	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
	<BY2PR07MB2408862693DDFA316B2379A8A14A0@BY2PR07MB2408.namprd07.prod.outlook.com>
Message-ID: <037d01d1b1e9$f28a9600$d79fc200$@iptrading.com>

For what it?s worth to this discussion, we have as much access to pricing information as anybody, and we do not see prices rising more rapidly in RIPE.

 

Pricing in this market is opaque. The only ones with access to this information are brokers.

Anybody but brokers only can see information on a small number of transfers. We have pricing information on hundreds of transfers.

 

ARIN pricing is still lowest, but not by much, and not due to the retention of the archaic needs test. It?s due to supply.  The ARIN region has 5 addresses per capita. Other regions of the world are orders of magnitude smaller. The fact that abundant supply changes prices is evident in the unusual truth that per-address prices are lowest at the /16 level.  Larger blocks cost more due to lack of supply. Smaller blocks cost more due to economies of scale. But because the old classful allocation regime handed out /16s to anybody with 257 devices or more, we find many old colleges, defunct corporations, long-closed ISPs with available /16s. 

 

So supply impacts price in a detectable way, but the needs test is irrelevant. Anybody who wants to buy, but who has problems with justifying their need, can simply use RIPE as their registry of choice and use their addresses wherever they want.  

 

The ARIN needs test is perversely driving transfers out of ARIN. Why suffer through an ARIN 30-day utilization ordeal or an ARIN 24 month needs test when the same ARIN-originated purchased addresses can be transferred to RIPE, where a 5 year test is applied?  For the difference in cost between a RIPE membership and an ARIN one, any buyer can neatly sidestep the issue.

 

Fortunately for ARIN, nearly every buyer is able to justify their need, because speculators don?t really exist. But the 80% requirement is onerous and RIPE is the escape hatch.

 

Geoff Huston did some stats showing that dusty old blocks make up a large chunk of transferred space. Some of his data was presented at the recent LACNIC meeting. This is evidence that the transfer market is actually more efficient at conserving address space than the needs-test regime ever was.  Because needs-tests and utilization requirements and revocation threats did not bring these addresses into productive use, but the market did.

 

Policy in ARIN has been held hostage for years to the boogeyman of speculators capable of harmfully manipulating the market.  Never has evidence supporting the existence of these people been offered. And certain unavoidable facts are avoided:

1.       Any such speculation will drive IPv6 and could render IPv4 worthless

2.       Supply has been fragmented through a quarter century of worldwide RIR allocations

3.       Every policy-compliant transfer is publicly recorded

4.       Prices have not changed dramatically in five years of trading

 

These conditions make it all but impossible for any market manipulation to occur, because due to fragmentation, the acquisition of enough blocks to manipulate the market would take years, in my educated opinion, and would have to involve a very rich speculator who was willing to engage in a series of transfers under assumed names, with the speculated asset marching towards a zero value.  It?s ludicrous to believe that any such speculator exists, willing to risk not only the loss of his investments, but worldwide opprobrium.

 

Regards,
Mike

 

 

 

 

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mueller, Milton L
Sent: Thursday, May 19, 2016 10:42 AM
To: Owen DeLong <owen at delong.com>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

 

 

 

From: Owen DeLong [mailto:owen at delong.com] 

 

Transfers are not rationed by price?

 

MM: False. This is like saying white is black. Transfers involve a payment by the receiving party. They are, therefore, rationed by price. Not much room for debate here. You?re just wrong. 

 

Price does not ensure that the purchaser has actual need for the resources, it merely insures that they have monetary resources that they are willing to trade for number resources.

 

MM: It means that they value the resources and thus have some kind of need for them. There are 1,000 other things they could spend that money on but the buyer has determined that the value they will get out of the numbers is at least equal to the value of the money they spend. 

 

You?ve presented no evidence whatsoever to support your conclusion that stringent needs assessment raises the price 

 

In fact, in the RIPE region where there are virtually no needs-based controls, according to the brokers I have discussed things with, prices are rising more rapidly than in the ARIN region, which would in fact appear to suggest that our needs-assessment regime is, in fact, holding prices down.

 

MM: Facts? Citations to specific transactions? I am always open to evidence. 


If we eliminate needs assessment, what mechanism assures that the transferee is actually a network operator? Further, how does it in any way assure that the transfer is from a place of less need to a place of greater need rather than a place of limited need to a place of greater monetary resources?

 

MM: This is not the place to rectify your general lack of familiarity with economics. But you seem to think that people with ?greater monetary resources? simply throw them at anything that moves. In fact, in the real world, everyone tries to maximize the value they get from whatever resources they have. So if someone pays for addresses, it is a very reliable indicator that they need them for something. Most if not all of the organizations that can derive value from numbers are network operators.  The threat of massive speculation is a bogeyman you have invented ? there is no evidence that it exists. The only ?speculation and hoarding? that currently exists is the holding of number resources by current assignees who don?t need them. And stringent needs assessment freezes that problem into place. Sorry to say it, but you, Owen, are one of the greatest defenders of hoarding.  

 

You start with an assumption that you are correct in your conjecture and then act as if it is everyone else?s duty to provide evidence that your speculation is not correct. The reality is that these are judgment calls based on limited experience and while we do know that needs assessment does, in fact, work to some extent, there is very limited experience without it. Unfortunately, once it is eliminated, it will be virtually impossible to put the genie back in the bottle, so people are understandably cautious about opening the bottle all at once.

 

Owen

 

 

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

From jcurran at arin.net  Thu May 19 14:28:01 2016
From: jcurran at arin.net (John Curran)
Date: Thu, 19 May 2016 18:28:01 +0000
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy
	ARIN-2015-3:	Remove 30 day utilization requirement in
	end-user IPv4 policy
In-Reply-To: <037d01d1b1e9$f28a9600$d79fc200$@iptrading.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
	<BY2PR07MB2408862693DDFA316B2379A8A14A0@BY2PR07MB2408.namprd07.prod.outlook.com>
	<037d01d1b1e9$f28a9600$d79fc200$@iptrading.com>
Message-ID: <4F6ED3D1-D4F5-475B-8A1B-E6A85C7AE4BD@corp.arin.net>

On May 19, 2016, at 6:17 PM, Mike Burns <mike at iptrading.com<mailto:mike at iptrading.com>> wrote:

Geoff Huston did some stats showing that dusty old blocks make up a large chunk of transferred space. Some of his data was presented at the recent LACNIC meeting.

This is correct with respect to transferred address space from the ARIN region.

This is evidence that the transfer market is actually more efficient at conserving address space than the needs-test regime ever was.  Because needs-tests and utilization requirements and revocation threats did not bring these addresses into productive use, but the market did.

It is uncertain if that conclusion can be drawn from Geoff?s data, as it did not include
any direct measure or comparison of relative ?conservation? for transfers in the ARIN
region vis-a-vis allocations/assignments in the ARIN region...

I would not be surprised if your hypothesis is correct (as the ability to bring address
space back into productive use was recognized as a benefit during introduction of ARIN?s
specified transfer policy), but at best any validation based on actual data can only be applied
to the actual circumstances -  it would be ?The needs-based transfer market is actually
more efficient at conserving address space than the needs-based free-pool assignment
based model ever was?, i.e. it can?t provide any validation of a transfer market absent
needs-based testing, since there?s operating data in the ARIN region such a policy.

/John

John Curran
President and CEO
ARIN


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

From mike at iptrading.com  Thu May 19 14:52:50 2016
From: mike at iptrading.com (Mike Burns)
Date: Thu, 19 May 2016 14:52:50 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy
	ARIN-2015-3:	Remove 30 day utilization requirement in
	end-user IPv4 policy
In-Reply-To: <4F6ED3D1-D4F5-475B-8A1B-E6A85C7AE4BD@corp.arin.net>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
	<BY2PR07MB2408862693DDFA316B2379A8A14A0@BY2PR07MB2408.namprd07.prod.outlook.com>
	<037d01d1b1e9$f28a9600$d79fc200$@iptrading.com>
	<4F6ED3D1-D4F5-475B-8A1B-E6A85C7AE4BD@corp.arin.net>
Message-ID: <03fb01d1b1ff$a69b56b0$f3d20410$@iptrading.com>

 

This is evidence that the transfer market is actually more efficient at conserving address space than the needs-test regime ever was.  Because needs-tests and utilization requirements and revocation threats did not bring these addresses into productive use, but the market did.

 

It is uncertain if that conclusion can be drawn from Geoff?s data, as it did not include

any direct measure or comparison of relative ?conservation? for transfers in the ARIN

region vis-a-vis allocations/assignments in the ARIN region...

 

I would not be surprised if your hypothesis is correct (as the ability to bring address

space back into productive use was recognized as a benefit during introduction of ARIN?s 

specified transfer policy), but at best any validation based on actual data can only be applied

to the actual circumstances -  it would be ?The needs-based transfer market is actually 

more efficient at conserving address space than the needs-based free-pool assignment

based model ever was?, i.e. it can?t provide any validation of a transfer market absent 

needs-based testing, since there?s operating data in the ARIN region such a policy. 

 

/John

 

Hi John,

 

Thanks for your reply.

 

You are right about the difficulty in validating my hypothesis, which is why I used weasel words like Geoff?s data ?is evidence? for this hypothesis, but not definitive.

Just food for thought for those who seem to view the transfer market as a dangerous snake. But as you said, this movement of unutilized addresses into productive use was an overt purpose of the creation of the market, not an unintended consequence.

I want community members to understand that this is evidence that the market is a natural conserver of valuable resources, and naturally elevates them to a higher and better use.

Thus reducing the actual importance of these ?angels-on-the-heads-of-pins? discussions about utilization periods or parsing the application of free pool allocation language in its application to transfers.

 

Regards,

Mike

 

 

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

From jcurran at arin.net  Thu May 19 15:28:02 2016
From: jcurran at arin.net (John Curran)
Date: Thu, 19 May 2016 19:28:02 +0000
Subject: [arin-ppml] Dynamics of a transfer environment without operational
 need assessment
Message-ID: <A5B71170-C5C0-47ED-A064-716FD9B09FA2@arin.net>

On May 19, 2016, at 8:52 PM, Mike Burns <mike at iptrading.com<mailto:mike at iptrading.com>> wrote:
...
I want community members to understand that this is evidence that the market is a natural conserver of valuable resources, and naturally elevates them to a higher and better use.

Mike -

There is little doubt that having an IP address transfer market has enabled unused or
otherwise ?fallow? IP address blocks to come back to productive use.

Thus reducing the actual importance of these ?angels-on-the-heads-of-pins? discussions about utilization periods or parsing the application of free pool allocation language in its application to transfers.

Given that all of our experience has been with needs-based transfer policies (which
provide some back pressure to speculation, whether via the direct prohibition that is
implied or the convolutions that is necessary to work around same), it is rather unclear
if financial speculation would have occurred over the past five years in absence of the
needs-based assessment model.   In an early message, you characterize it as such -

Policy in ARIN has been held hostage for years to the boogeyman of speculators capable of harmfully manipulating the market.  Never has evidence supporting the existence of these people been offered. And certain unavoidable facts are avoided:
1.       Any such speculation will drive IPv6 and could render IPv4 worthless
2.       Supply has been fragmented through a quarter century of worldwide RIR allocations
3.       Every policy-compliant transfer is publicly recorded
4.       Prices have not changed dramatically in five years of trading

These conditions make it all but impossible for any market manipulation to occur, because due to fragmentation, the acquisition of enough blocks to manipulate the market would take years, in my educated opinion, and would have to involve a very rich speculator who was willing to engage in a series of transfers under assumed names, with the speculated asset marching towards a zero value.  It?s ludicrous to believe that any such speculator exists, willing to risk not only the loss of his investments, but worldwide opprobrium.

While the circumstances you describe does inhibit speculation, it is unclear if it they
would still be latent in a transfer market environment which allowed and effectively
endorsed speculation.  For example, it is unclear if a short-term market squeeze in
IPv4 (e.g. 3 months) would materially impact deployment of IPv6 (which has many
other factors that businesses face in making such decisions.)  Similarly, we?ve seen
greatly accelerated recovery of unused IPv4 blocks since the IPv4 free pool runout
in the ARIN region in September 2015 (effectively describing fragmentation of the
marketplace over time) and absence of operational need could bring many more
actors into seeking underutilized IPv4 number resources blocks.  If the community
decides to make IPv4 address block rights transferable to any party, regardless of
operational need, then they are likely to be considered an investable asset class
and analyzed very differently by financial firms going forward.  Whether that would
be a good outcome (or not( is a matter of judgement regarding the functioning of
markets and resulting impact/benefit to this community.

In any case, the proposed policy 2015-3 does not directly touch on these merits
of needs-based transfers or otherwise, as it describes removal of a criteria whose
definition is unclear to operational need assessment for transfers (and thus not
operational today), and thus my reason for moving this more general discussion
of a transfer market without operational need-assessment to a separate thread
and subject.

Thanks!
/John

John Curran
President and CEO
ARIN




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

From woody at pch.net  Thu May 19 16:13:42 2016
From: woody at pch.net (Bill Woodcock)
Date: Thu, 19 May 2016 13:13:42 -0700
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy
	ARIN-2015-3:	Remove 30 day utilization requirement in
	end-user IPv4 policy
In-Reply-To: <03fb01d1b1ff$a69b56b0$f3d20410$@iptrading.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
	<BY2PR07MB2408862693DDFA316B2379A8A14A0@BY2PR07MB2408.namprd07.prod.outlook.com>
	<037d01d1b1e9$f28a9600$d79fc200$@iptrading.com>
	<4F6ED3D1-D4F5-475B-8A1B-E6A85C7AE4BD@corp.arin.net>
	<03fb01d1b1ff$a69b56b0$f3d20410$@iptrading.com>
Message-ID: <C9AEB491-4E80-4D26-88C3-82D3C46EB58B@pch.net>


> On May 19, 2016, at 11:52 AM, Mike Burns <mike at iptrading.com> wrote:
> I want community members to understand that this is evidence that the market is a natural conserver of valuable resources.

Help me understand what evidence you see that any market has ever conserved expensive FIB slots.

> ...and naturally elevates them to a higher and better use.

It seems to me that this is the same fallacy upon which inter-provider QoS ran aground.  Just because something was valuable and expensive to Party A, and Party A exchanges traffic with Party B, there?s no reason why the same thing would be valued by Party B, who has their own concerns.  Thus, the fact that Party A buys an address block for a lot of money may make routing that address block very important to Party A, but that?s independent of Party B?s interest in receiving that routing announcement or wasting a FIB slot on it.  Thus, the money has been spent, but nothing has been elevated to a higher or better use; it may in fact not be usable at all, outside the context of needs-based allocation of FIB slots.

> Thus reducing the actual importance of these ?angels-on-the-heads-of-pins? discussions about utilization periods or parsing the application of free pool allocation language in its application to transfers.

I agree that there?s a lot of cruft that?s built up by people who weren?t intent upon using concise language in policy development, and who failed to remove or update language before slathering more over the top of it.  However, that in no way invalidates the basic requirement for regulation to defend the commons (global routing table size) against the competing interests of individuals (more smaller prefixes routed).

Both are valuable.  They?re naturally opposed interests.  Any useful discussion of either one must be in terms of the trade-off against the other.  You?re discussing only one of the two; only half of an inextricably linked conversation.

                                -Bill




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

From mike at iptrading.com  Thu May 19 16:26:18 2016
From: mike at iptrading.com (Mike Burns)
Date: Thu, 19 May 2016 16:26:18 -0400
Subject: [arin-ppml] Dynamics of a transfer environment without
	operational need assessment
In-Reply-To: <A5B71170-C5C0-47ED-A064-716FD9B09FA2@arin.net>
References: <A5B71170-C5C0-47ED-A064-716FD9B09FA2@arin.net>
Message-ID: <045a01d1b20c$b3699d90$1a3cd8b0$@iptrading.com>

Hi John,

 

Given that all of our experience has been with needs-based transfer policies (which 

provide some back pressure to speculation, whether via the direct prohibition that is

implied or the convolutions that is necessary to work around same), it is rather unclear 

if financial speculation would have occurred over the past five years in absence of the

needs-based assessment model.   

 

On the contrary we now have a good deal of experience with the most vibrant and active market, which has no needs test. And the absence of speculation grows clearer every day in the RIPE region. I see more and smaller transfers happening over there, but to be sure there might be some noise in the data related to their final /8 policy. Still I don?t see evidence that any single agency is buying up addresses for speculation, and personally I have not been contacted by any speculator issuing a blanket buy order, which is what would be required to begin assembling a hoard of addresses. As a daily participant in this market I have to shake my head at any reasonable belief that the needs test is what is holding back speculation. We all know that speculation can occur already in many forms, and there is a back door to avoid the needs-test anyway. What is this paper shield of a needs-test that can hold back these mighty and insidious speculators?  Yet we argue over a 30 day utilization period that everybody knows is and has been a no-op?  Do we really believe it?s the utilization requirement and not the price that buyers are concerned with?  It?s silly, IMO.  Drop the needs test and finally drop these sorts of discussions. 

 

What?s more, ARIN seems to be depicted poorly in other regions as having failed to create a reserve pool for new entrants, like they have. They think the ARIN region is in a bad state, particularly for new entrants. What we should be doing is demonstrating the vitality of our market, which would enable new entrants to participate through the reliable purchase of IP addresses just like they purchase equipment, man-hours, and every other component of their new business.

Eliminating barriers to trade will help to create a vibrant and reliable market to benefit new and old companies, and demonstrate to the world that a reserve pool for new entrants is just another way of keeping addresses fallow for years, whereas the ARIN policy provides the incentive for trade that naturally brings addresses into productive use.

 

 

In an early message, you characterize it as such - 

 

Policy in ARIN has been held hostage for years to the boogeyman of speculators capable of harmfully manipulating the market.  Never has evidence supporting the existence of these people been offered. And certain unavoidable facts are avoided:

1.       Any such speculation will drive IPv6 and could render IPv4 worthless

2.       Supply has been fragmented through a quarter century of worldwide RIR allocations

3.       Every policy-compliant transfer is publicly recorded

4.       Prices have not changed dramatically in five years of trading

 

These conditions make it all but impossible for any market manipulation to occur, because due to fragmentation, the acquisition of enough blocks to manipulate the market would take years, in my educated opinion, and would have to involve a very rich speculator who was willing to engage in a series of transfers under assumed names, with the speculated asset marching towards a zero value.  It?s ludicrous to believe that any such speculator exists, willing to risk not only the loss of his investments, but worldwide opprobrium.

 

While the circumstances you describe does inhibit speculation, it is unclear if it they

would still be latent in a transfer market environment which allowed and effectively 

endorsed speculation.  For example, it is unclear if a short-term market squeeze in

IPv4 (e.g. 3 months) would materially impact deployment of IPv6 (which has many

other factors that businesses face in making such decisions.) 

 

There is no way for a bad actor to create any squeeze in the market due to the inability to acquire enough space to affect price. Remember as price rises, so does available supply, since CGN provide some supply elasticity and there are still hundreds of millions of un-routed addresses*. But granted IPv6 deployment is not just a market-squeeze away, whether it?s short or long-term. Still it?s the Sword of Damocles to a market manipulator and provides a huge disincentive for what would have to be a yearslong project for that would-be manipulator. *Yes I know un-routed doesn?t mean unused, but c?mon we?re talking 20% of the universe of ipv4 space!

 

If it is unclear that an IPv4 squeeze would materially impact IPv6 deployment, it is at least as unclear that speculators would be a detriment to the market, even if they did exist.  This community is one of network operators primarily. Maybe some education on the role of speculation in a market would be appropriate, since the fear of speculation seems always to be at the root of objections to removing the needs test.  

 

 Similarly, we?ve seen

greatly accelerated recovery of unused IPv4 blocks since the IPv4 free pool runout

in the ARIN region in September 2015 (effectively describing fragmentation of the

marketplace over time) and absence of operational need could bring many more 

actors into seeking underutilized IPv4 number resources blocks.  If the community

decides to make IPv4 address block rights transferable to any party, regardless of

operational need, then they are likely to be considered an investable asset class

and analyzed very differently by financial firms going forward.  Whether that would 

be a good outcome (or not( is a matter of judgement regarding the functioning of 

markets and resulting impact/benefit to this community.

 

Yes, maybe we should talk about the benefits of aligning policy with the real-world treatment of valuable assets.

Because in the real-world the general analysis that every business applies is really the same (largely Net Present Value), the only difference is their own judgements of things like how long IPv4 will last, how much CGN the Internet can take, as well as normal factors like their growth rates and risk aversion.  Why not let them use their own determination of these things in their decision to purchase addresses?  Must they subordinate their decisions to ARIN policy designed in a free-pool environment?

 

 

In any case, the proposed policy 2015-3 does not directly touch on these merits 

of needs-based transfers or otherwise, as it describes removal of a criteria whose 

definition is unclear to operational need assessment for transfers (and thus not 

operational today), and thus my reason for moving this more general discussion 

of a transfer market without operational need-assessment to a separate thread 

and subject.

 

That?s a good idea for anybody who wants to pursue the general discussion. I?m reasonably sure Professor Mueller would be willing to provide relevant economic theory and maybe I can add something from my perspective with direct knowledge of hundreds of transfers around the world. I know there are other listening brokers who can challenge or support my observations.  Personally I am not aware of any broker who supports the continuance of the needs test as a means to conserve space.

 

Maybe the community should avail themselves of the information that only brokers have. Put a handful of brokers together and you have information covering a thousand transfers.  What other handful of community members has experienced a thousand transfers/allocations?  Probably only ARIN staff and David Huberman. ;-)  If we brokers speak with a unified voice about our experience with (the lack of) evidence of speculation, perhaps the community will credit our perspective.

 

Regards,
Mike

 

 

Thanks!

/John

 

John Curran

President and CEO

ARIN

 

 

 

 

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

From SRyerse at eclipse-networks.com  Thu May 19 16:21:31 2016
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Thu, 19 May 2016 20:21:31 +0000
Subject: [arin-ppml] Dynamics of a transfer environment without
 operational need assessment
In-Reply-To: <A5B71170-C5C0-47ED-A064-716FD9B09FA2@arin.net>
References: <A5B71170-C5C0-47ED-A064-716FD9B09FA2@arin.net>
Message-ID: <a93ec7a51c32478393fd2e0caece76d4@eclipse-networks.com>

I would add to Mike?s and your comments that needs based policies are probably having a different effect now that runout is here than they did before runout. That is why some of these policies need to be changed towards less needs based testing.

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

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

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran
Sent: Thursday, May 19, 2016 3:28 PM
To: Mike Burns <mike at iptrading.com>
Cc: ARIN PPML <ppml at arin.net>
Subject: [arin-ppml] Dynamics of a transfer environment without operational need assessment

On May 19, 2016, at 8:52 PM, Mike Burns <mike at iptrading.com<mailto:mike at iptrading.com>> wrote:
...
I want community members to understand that this is evidence that the market is a natural conserver of valuable resources, and naturally elevates them to a higher and better use.

Mike -

There is little doubt that having an IP address transfer market has enabled unused or
otherwise ?fallow? IP address blocks to come back to productive use.


Thus reducing the actual importance of these ?angels-on-the-heads-of-pins? discussions about utilization periods or parsing the application of free pool allocation language in its application to transfers.

Given that all of our experience has been with needs-based transfer policies (which
provide some back pressure to speculation, whether via the direct prohibition that is
implied or the convolutions that is necessary to work around same), it is rather unclear
if financial speculation would have occurred over the past five years in absence of the
needs-based assessment model.   In an early message, you characterize it as such -

Policy in ARIN has been held hostage for years to the boogeyman of speculators capable of harmfully manipulating the market.  Never has evidence supporting the existence of these people been offered. And certain unavoidable facts are avoided:
1.       Any such speculation will drive IPv6 and could render IPv4 worthless
2.       Supply has been fragmented through a quarter century of worldwide RIR allocations
3.       Every policy-compliant transfer is publicly recorded
4.       Prices have not changed dramatically in five years of trading

These conditions make it all but impossible for any market manipulation to occur, because due to fragmentation, the acquisition of enough blocks to manipulate the market would take years, in my educated opinion, and would have to involve a very rich speculator who was willing to engage in a series of transfers under assumed names, with the speculated asset marching towards a zero value.  It?s ludicrous to believe that any such speculator exists, willing to risk not only the loss of his investments, but worldwide opprobrium.

While the circumstances you describe does inhibit speculation, it is unclear if it they
would still be latent in a transfer market environment which allowed and effectively
endorsed speculation.  For example, it is unclear if a short-term market squeeze in
IPv4 (e.g. 3 months) would materially impact deployment of IPv6 (which has many
other factors that businesses face in making such decisions.)  Similarly, we?ve seen
greatly accelerated recovery of unused IPv4 blocks since the IPv4 free pool runout
in the ARIN region in September 2015 (effectively describing fragmentation of the
marketplace over time) and absence of operational need could bring many more
actors into seeking underutilized IPv4 number resources blocks.  If the community
decides to make IPv4 address block rights transferable to any party, regardless of
operational need, then they are likely to be considered an investable asset class
and analyzed very differently by financial firms going forward.  Whether that would
be a good outcome (or not( is a matter of judgement regarding the functioning of
markets and resulting impact/benefit to this community.

In any case, the proposed policy 2015-3 does not directly touch on these merits
of needs-based transfers or otherwise, as it describes removal of a criteria whose
definition is unclear to operational need assessment for transfers (and thus not
operational today), and thus my reason for moving this more general discussion
of a transfer market without operational need-assessment to a separate thread
and subject.

Thanks!
/John

John Curran
President and CEO
ARIN




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

From mike at iptrading.com  Thu May 19 16:50:46 2016
From: mike at iptrading.com (Mike Burns)
Date: Thu, 19 May 2016 16:50:46 -0400
Subject: [arin-ppml] Dynamics of a transfer environment without
	operational need assessment
In-Reply-To: <A5B71170-C5C0-47ED-A064-716FD9B09FA2@arin.net>
References: <A5B71170-C5C0-47ED-A064-716FD9B09FA2@arin.net>
Message-ID: <047201d1b210$1deb0f20$59c12d60$@iptrading.com>

I am answering Mr. Woodcock using the new subject line, I hope that is okay.

 

Hi Bill,

 

> On May 19, 2016, at 11:52 AM, Mike Burns < <mailto:mike at iptrading.com> mike at iptrading.com> wrote:

> I want community members to understand that this is evidence that the market is a natural conserver of valuable resources.

 

Bill wrote: Help me understand what evidence you see that any market has ever conserved expensive FIB slots.

> ...and naturally elevates them to a higher and better use.

 

It seems to me that this is the same fallacy upon which inter-provider QoS ran aground.  Just because something was valuable and expensive to Party A, and Party A exchanges traffic with Party B, there?s no reason why the same thing would be valued by Party B, who has their own concerns.  Thus, the fact that Party A buys an address block for a lot of money may make routing that address block very important to Party A, but that?s independent of Party B?s interest in receiving that routing announcement or wasting a FIB slot on it.  Thus, the money has been spent, but nothing has been elevated to a higher or better use; it may in fact not be usable at all, outside the context of needs-based allocation of FIB slots.

 

I?m not sure I understand, can you tie this to an example where a valuable asset is traded, as in the transfer market?

I am not trying to make a blanket statement that markets are perfect in every case, every where. I am saying that the natural tendency of a market is to elevate valuable assets to a higher and better use.  It seems like in your example, there is an element of utility for both Party A and Party B in the use of FIB slots.

 

 

> Thus reducing the actual importance of these ?angels-on-the-heads-of-pins? discussions about utilization periods or parsing the application of free pool allocation language in its application to transfers.

 

I agree that there?s a lot of cruft that?s built up by people who weren?t intent upon using concise language in policy development, and who failed to remove or update language before slathering more over the top of it.  However, that in no way invalidates the basic requirement for regulation to defend the commons (global routing table size) against the competing interests of individuals (more smaller prefixes routed).

 

There is no regulation anywhere that mandates prefix size that I am aware of. I have seen /32s in the table. It?s not regulation but mutual shared interest in the utility of the table that drives things. 

 

 

Both are valuable.  They?re naturally opposed interests.  Any useful discussion of either one must be in terms of the trade-off against the other.  You?re discussing only one of the two; only half of an inextricably linked conversation.

 

                                -Bill

I can see the commons argument applying to free pool addresses, but I don?t see it as applicable to priced resources, which FIB slots are not.

 

Regards,
Mike

 

 

 

 

 

From: John Curran [mailto:jcurran at arin.net] 
Sent: Thursday, May 19, 2016 3:28 PM
To: Mike Burns <mike at iptrading.com>
Cc: ARIN PPML <ppml at arin.net>
Subject: Dynamics of a transfer environment without operational need assessment 

 

On May 19, 2016, at 8:52 PM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:

...

I want community members to understand that this is evidence that the market is a natural conserver of valuable resources, and naturally elevates them to a higher and better use.

 

Mike - 

 

There is little doubt that having an IP address transfer market has enabled unused or

otherwise ?fallow? IP address blocks to come back to productive use.





Thus reducing the actual importance of these ?angels-on-the-heads-of-pins? discussions about utilization periods or parsing the application of free pool allocation language in its application to transfers.

 

Given that all of our experience has been with needs-based transfer policies (which 

provide some back pressure to speculation, whether via the direct prohibition that is

implied or the convolutions that is necessary to work around same), it is rather unclear 

if financial speculation would have occurred over the past five years in absence of the

needs-based assessment model.   In an early message, you characterize it as such - 

 

Policy in ARIN has been held hostage for years to the boogeyman of speculators capable of harmfully manipulating the market.  Never has evidence supporting the existence of these people been offered. And certain unavoidable facts are avoided:

1.       Any such speculation will drive IPv6 and could render IPv4 worthless

2.       Supply has been fragmented through a quarter century of worldwide RIR allocations

3.       Every policy-compliant transfer is publicly recorded

4.       Prices have not changed dramatically in five years of trading

 

These conditions make it all but impossible for any market manipulation to occur, because due to fragmentation, the acquisition of enough blocks to manipulate the market would take years, in my educated opinion, and would have to involve a very rich speculator who was willing to engage in a series of transfers under assumed names, with the speculated asset marching towards a zero value.  It?s ludicrous to believe that any such speculator exists, willing to risk not only the loss of his investments, but worldwide opprobrium.

 

While the circumstances you describe does inhibit speculation, it is unclear if it they

would still be latent in a transfer market environment which allowed and effectively 

endorsed speculation.  For example, it is unclear if a short-term market squeeze in

IPv4 (e.g. 3 months) would materially impact deployment of IPv6 (which has many

other factors that businesses face in making such decisions.)  Similarly, we?ve seen

greatly accelerated recovery of unused IPv4 blocks since the IPv4 free pool runout

in the ARIN region in September 2015 (effectively describing fragmentation of the

marketplace over time) and absence of operational need could bring many more 

actors into seeking underutilized IPv4 number resources blocks.  If the community

decides to make IPv4 address block rights transferable to any party, regardless of

operational need, then they are likely to be considered an investable asset class

and analyzed very differently by financial firms going forward.  Whether that would 

be a good outcome (or not( is a matter of judgement regarding the functioning of 

markets and resulting impact/benefit to this community.

 

In any case, the proposed policy 2015-3 does not directly touch on these merits 

of needs-based transfers or otherwise, as it describes removal of a criteria whose 

definition is unclear to operational need assessment for transfers (and thus not 

operational today), and thus my reason for moving this more general discussion 

of a transfer market without operational need-assessment to a separate thread 

and subject.

 

Thanks!

/John

 

John Curran

President and CEO

ARIN

 

 

 

 

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

From jcurran at arin.net  Thu May 19 17:23:34 2016
From: jcurran at arin.net (John Curran)
Date: Thu, 19 May 2016 21:23:34 +0000
Subject: [arin-ppml] Dynamics of a transfer environment without
 operational need assessment
In-Reply-To: <045a01d1b20c$b3699d90$1a3cd8b0$@iptrading.com>
References: <A5B71170-C5C0-47ED-A064-716FD9B09FA2@arin.net>
	<045a01d1b20c$b3699d90$1a3cd8b0$@iptrading.com>
Message-ID: <8C60060E-01E1-4093-96CE-1724283CF311@arin.net>

On May 19, 2016, at 10:26 PM, Mike Burns <mike at iptrading.com<mailto:mike at iptrading.com>> wrote:

Hi John,

Given that all of our experience has been with needs-based transfer policies (which
provide some back pressure to speculation, whether via the direct prohibition that is
implied or the convolutions that is necessary to work around same), it is rather unclear
if financial speculation would have occurred over the past five years in absence of the
needs-based assessment model.

On the contrary we now have a good deal of experience with the most vibrant and active market, which has no needs test.

That may not be at all indicative, since a very significant proportion of readily IPv4 address
space is in the ARIN region and thus subject to operational needs-testing.  This alters the
potential benefits of speculation in all markets, since it is not clear that the supply in the
ARIN region can be mitigated if one wished to take on a major position in the supply of
IPv4 address space.

And the absence of speculation grows clearer every day in the RIPE region. I see more and smaller transfers happening over there, but to be sure there might be some noise in the data related to their final /8 policy. Still I don?t see evidence that any single agency is buying up addresses for speculation, and personally I have not been contacted by any speculator issuing a blanket buy order, which is what would be required to begin assembling a hoard of addresses. As a daily participant in this market I have to shake my head at any reasonable belief that the needs test is what is holding back speculation. We all know that speculation can occur already in many forms, and there is a back door to avoid the needs-test anyway. What is this paper shield of a needs-test that can hold back these mighty and insidious speculators?   ...

There are investment funds for all sorts of interesting assets, but the ability to establish a
fund for investment in IPv4 address space will not pass the risk management phase if it is
not clear that they can be legally held free and clear & independent of operational need.
(Yes, there are many organizations that pay enormous details to such legal niceties when
it comes to building financial investment vehicles.)

What?s more, ARIN seems to be depicted poorly in other regions as having failed to create a reserve pool for new entrants, like they have. They think the ARIN region is in a bad state, particularly for new entrants. What we should be doing is demonstrating the vitality of our market, which would enable new entrants to participate through the reliable purchase of IP addresses just like they purchase equipment, man-hours, and every other component of their new business.

That is the option being exercised by new entrants, and we should certainly make plain
to the global community that it is a reasonable and predictable path.   I can work on this
in the immediate future.

Eliminating barriers to trade will help to create a vibrant and reliable market to benefit new and old companies, and demonstrate to the world that a reserve pool for new entrants is just another way of keeping addresses fallow for years, whereas the ARIN policy provides the incentive for trade that naturally brings addresses into productive use.

I am uncertain that the present needs-assessment provides any significant hurdle to
new entrants, but leave it to the community to consider the merits of changing needs
assessment so as to eliminate barriers.

There is no way for a bad actor to create any squeeze in the market due to the inability to acquire enough space to affect price. Remember as price rises, so does available supply, since CGN provide some supply elasticity and there are still hundreds of millions of un-routed addresses*. But granted IPv6 deployment is not just a market-squeeze away, whether it?s short or long-term. Still it?s the Sword of Damocles to a market manipulator and provides a huge disincentive for what would have to be a yearslong project for that would-be manipulator. *Yes I know un-routed doesn?t mean unused, but c?mon we?re talking 20% of the universe of ipv4 space!

Agreed - any significant squeeze would entice organizations to consider whether they
have unused IPv4 resources (or can make efficiencies to obtain same) and liberate the
result to the market.

Note that such responses take significant time (e.g. 6 months or great for many orgs),
whereas most firms going to market have pressing business needs that they are trying
to satisfy? If the largest mobile and content firms are attempting to obtain space in a
market that has an determined investment firm operating, there will likely be a period
of time that will be rather challenging for everyone (and particularly the smaller startups
that you reference above?)   Will such market correct itself?  Almost certainly, but the
question is how long and at what impact to those unable to participate in the interim.
Ultimately, it is up to the community?s to decide how it values the benefits that would
be obtained against such potential risks.

Yes, maybe we should talk about the benefits of aligning policy with the real-world treatment of valuable assets.
Because in the real-world the general analysis that every business applies is really the same (largely Net Present Value), the only difference is their own judgements of things like how long IPv4 will last, how much CGN the Internet can take, as well as normal factors like their growth rates and risk aversion.  Why not let them use their own determination of these things in their decision to purchase addresses?  Must they subordinate their decisions to ARIN policy designed in a free-pool environment?

Entirely up to the community, but please note that even in the "real world?, there are classes
of assets that are restricted to only operating companies (one can find examples in spectrum,
telephony numbers, certain prospecting/mining/drilling rights and other fairly specialized asset
classes.)    I will note that some of these have very interesting (and potentially highly undesirable
side-effects (e.g. spectrum) but simply wanted to point out that the restriction to organizations
which will operationally use the address space is not an exotic restriction, and occurs in other
situations in the real world.

That?s a good idea for anybody who wants to pursue the general discussion. I?m reasonably sure Professor Mueller would be willing to provide relevant economic theory and maybe I can add something from my perspective with direct knowledge of hundreds of transfers around the world. I know there are other listening brokers who can challenge or support my observations.  Personally I am not aware of any broker who supports the continuance of the needs test as a means to conserve space.

Maybe the community should avail themselves of the information that only brokers have. Put a handful of brokers together and you have information covering a thousand transfers.  What other handful of community members has experienced a thousand transfers/allocations?  Probably only ARIN staff and David Huberman. ;-)  If we brokers speak with a unified voice about our experience with (the lack of) evidence of speculation, perhaps the community will credit our perspective.

I believe sharing information is always a good idea, as it provides for a better informed
policy development process.   You may want to distinguish actual observations from
beliefs, particularly since "past performance is not a reliable indicator of future results?
(and doubly so if the underlying conditions change going forward as a result of number
resource policy changes.)

Thanks,
/John

John Curran
President and CEO
ARIN


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

From owen at delong.com  Thu May 19 23:48:33 2016
From: owen at delong.com (Owen DeLong)
Date: Thu, 19 May 2016 20:48:33 -0700
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
	Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <BY2PR07MB2408862693DDFA316B2379A8A14A0@BY2PR07MB2408.namprd07.prod.outlook.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
	<BY2PR07MB2408862693DDFA316B2379A8A14A0@BY2PR07MB2408.namprd07.prod.outlook.com>
Message-ID: <A92EC59A-D2F8-44C4-A880-C0A6458D269F@delong.com>


> On May 19, 2016, at 07:41 , Mueller, Milton L <milton at gatech.edu> wrote:
> 
>  
> ? <>
> From: Owen DeLong [mailto:owen at delong.com <mailto:owen at delong.com>] 
> 
>  
> Transfers are not rationed by price?
>  
> MM: False. This is like saying white is black. Transfers involve a payment by the receiving party. They are, therefore, rationed by price. Not much room for debate here. You?re just wrong. 

Rationed: a fixed allowance of provisions or food, especially for soldiers or sailors or for civilians during a shortage: a daily ration of meat and bread. 2. an allotted amount: They finally saved up enough gas rations for the trip.

I simply do not agree with you that price constitutes any sort of limitation on the amount of resources that can be acquired by an organization with sufficiently deep pockets.

Therefore, you are simply wrong.

> Price does not ensure that the purchaser has actual need for the resources, it merely insures that they have monetary resources that they are willing to trade for number resources.
>  
> MM: It means that they value the resources and thus have some kind of need for them. There are 1,000 other things they could spend that money on but the buyer has determined that the value they will get out of the numbers is at least equal to the value of the money they spend.

It means that they believe the resources have value. That is different from having need for them or from valuing them. This is the sophistry in which you consistently engage hoping nobody will notice the inaccuracy in your statement.

For example, I may perceive that a stock has value or will have a greater value in the future. I may purchase the stock on that basis. It does not mean that I value the particular stock or the company it represents. It further does not mean that I have any need whatsoever for the stock other than my hope that its value will increase and that I can sell it at a gain.

> You?ve presented no evidence whatsoever to support your conclusion that stringent needs assessment raises the price
>  
> In fact, in the RIPE region where there are virtually no needs-based controls, according to the brokers I have discussed things with, prices are rising more rapidly than in the ARIN region, which would in fact appear to suggest that our needs-assessment regime is, in fact, holding prices down.
>  
> MM: Facts? Citations to specific transactions? I am always open to evidence.

These are facts. Feel free to discuss the pricing trends in RIPE vs. ARIN regions with any of the brokers. I cannot cite specific transactions because I am not directly familiar with the details of most of them and I am under NDA for the ones that I do know about. However, that does not discredit my general claim that both the transactions of which I am aware of the specifics, and the discussions I have had with several brokers have indicated that prices are generally higher in the RIPE region than in the ARIN region.

> If we eliminate needs assessment, what mechanism assures that the transferee is actually a network operator? Further, how does it in any way assure that the transfer is from a place of less need to a place of greater need rather than a place of limited need to a place of greater monetary resources?
>  
> MM: This is not the place to rectify your general lack of familiarity with economics. But you seem to think that people with ?greater monetary resources? simply throw them at anything that moves. In fact, in the real world, everyone tries to maximize the value they get from whatever resources they have. So if someone pays for addresses, it is a very reliable indicator that they need them for something. Most if not all of the organizations that can derive value from numbers are network operators.  The threat of massive speculation is a bogeyman you have invented ? there is no evidence that it exists. The only ?speculation and hoarding? that currently exists is the holding of number resources by current assignees who don?t need them. And stringent needs assessment freezes that problem into place. Sorry to say it, but you, Owen, are one of the greatest defenders of hoarding.  

I am not alone in thinking that this is often true. As cases in point, I give you the Pet Rock, several of P.T. Barnum?s exploits, John Travolta?s personal 727, the Fry Brothers (of Fry?s Electronics fame) personal 747.

If someone pays for addresses, it is an indicator that one of two things is true? 1. They have a use for the addresses that they believe is at least as valuable as the price paid, or, 2. They have a belief that the market value of the addresses in the future will exceed the cost of obtaining and holding them until that time.

Your continuing to insist that the second of these two possibilities does not exist is absurd. If it were not true, we would not have stock markets, day traders, mutual funds, or most of the other things regulated by the securities and exchange commission.

This is not my general lack of familiarity with economics and your continued ad hominem attacks do nothing to change the falsity of your argument.

> You start with an assumption that you are correct in your conjecture and then act as if it is everyone else?s duty to provide evidence that your speculation is not correct. The reality is that these are judgment calls based on limited experience and while we do know that needs assessment does, in fact, work to some extent, there is very limited experience without it. Unfortunately, once it is eliminated, it will be virtually impossible to put the genie back in the bottle, so people are understandably cautious about opening the bottle all at once.

Where, exactly, do you see conjecture? It is a fact that if we commoditize IPv4 addresses, we will enable them to be treated as an investment vehicle, just like many other forms of property both real and personal. You?ve provided no reasoning whatsoever that distinguishes IPv4 address registrations from real estate, collectibles, or any of a host of other forms of property in this regard.

It is not conjecture when I say that there are people who invest in these other things in a variety of ways, some of which are speculative. I have no reason whatsoever to believe that commoditizing IPv4 addresses would not enable similar forms of speculation in addresses.

Your continued claims to the contrary appear to ignore the realities of other unregulated commodities.

If you need further examples, I point you to the Chicago Merchantile Exchange.

Owen

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

From narten at us.ibm.com  Fri May 20 00:53:04 2016
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 20 May 2016 00:53:04 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201605200453.u4K4r4Ki003731@rotala.raleigh.ibm.com>

Total of 44 messages in the last 7 days.
 
script run at: Fri May 20 00:53:04 EDT 2016
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 13.64% |    6 | 16.06% |   175483 | owen at delong.com
  9.09% |    4 | 12.93% |   141340 | jschiller at google.com
  9.09% |    4 | 10.91% |   119175 | milton at gatech.edu
  9.09% |    4 | 10.18% |   111214 | mike at iptrading.com
  9.09% |    4 |  8.49% |    92802 | jcurran at arin.net
  6.82% |    3 |  9.58% |   104731 | scottleibrand at gmail.com
  6.82% |    3 |  4.60% |    50317 | alyssa.moore at cybera.ca
  2.27% |    1 |  6.58% |    71958 | rjacobs at pslightwave.com
  4.55% |    2 |  3.81% |    41658 | andrew.dul at quark.net
  4.55% |    2 |  3.02% |    33023 | jrdelacruz at acm.org
  4.55% |    2 |  2.78% |    30360 | daveid at panix.com
  2.27% |    1 |  3.32% |    36324 | sryerse at eclipse-networks.com
  2.27% |    1 |  2.12% |    23171 | kevinb at thewire.ca
  2.27% |    1 |  1.44% |    15748 | bjones at vt.edu
  2.27% |    1 |  0.87% |     9514 | woody at pch.net
  2.27% |    1 |  0.71% |     7811 | narten at us.ibm.com
  2.27% |    1 |  0.70% |     7682 | dogwallah at gmail.com
  2.27% |    1 |  0.68% |     7417 | rbf+arin-ppml at panix.com
  2.27% |    1 |  0.67% |     7284 | gary.buhrmaster at gmail.com
  2.27% |    1 |  0.53% |     5789 | bcornett at servlet.com
--------+------+--------+----------+------------------------
100.00% |   44 |100.00% |  1092801 | Total



From jcurran at arin.net  Sun May 22 00:24:17 2016
From: jcurran at arin.net (John Curran)
Date: Sun, 22 May 2016 04:24:17 +0000
Subject: [arin-ppml] IPv6 Residential Deployment Survey
Message-ID: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net>

Folks -

    Jordi Palet Mart?nez is conducting a brief survey regarding IPv6 deployment
    in residential Internet service.   Having insight into the various practices that
    are in use may help to inform IPv6 number resource policy development, and
    thus I ask that you take a moment to complete the survey if you are providing
    such services (whether production or trial basis.)

    Jordi notes -

        "The results will be published and updated every month or so -
          No personal data will be published.

          (If you know your network, it takes less than 2 minutes to complete it)
          The survey can be responded even if is not yet a commercial service,
          and customers can also respond, not just the ISP. However, to avoid
          duplicate data, make sure to include the country and ISP name.?

     The IPv6 Residential Deployment Survey may be found here -
        <http://survey.consulintel.es/index.php/175122>


Thanks!
/John

John Curran
President and CEO
ARIN


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

From milton at gatech.edu  Sun May 22 17:11:51 2016
From: milton at gatech.edu (Mueller, Milton L)
Date: Sun, 22 May 2016 21:11:51 +0000
Subject: [arin-ppml] Future of needs assessment
Message-ID: <BL2PR07MB240490856E33BC3753CB8AA2A14D0@BL2PR07MB2404.namprd07.prod.outlook.com>

Note that I've changed the header 

Bill, are you asserting that there is, or should be, needs testing of the way ISPs allocate their FIB slots? 

> -----Original Message-----
> 
> 
> > On May 19, 2016, at 11:52 AM, Mike Burns <mike at iptrading.com> wrote:
> > I want community members to understand that this is evidence that the
> market is a natural conserver of valuable resources.
> 
> Help me understand what evidence you see that any market has ever
> conserved expensive FIB slots.
> 
> > ...and naturally elevates them to a higher and better use.
> 
> It seems to me that this is the same fallacy upon which inter-provider QoS ran
> aground.  Just because something was valuable and expensive to Party A, and
> Party A exchanges traffic with Party B, there?s no reason why the same thing
> would be valued by Party B, who has their own concerns.  Thus, the fact that
> Party A buys an address block for a lot of money may make routing that
> address block very important to Party A, but that?s independent of Party B?s
> interest in receiving that routing announcement or wasting a FIB slot on it.
> Thus, the money has been spent, but nothing has been elevated to a higher or
> better use; it may in fact not be usable at all, outside the context of needs-
> based allocation of FIB slots.
> 
> > Thus reducing the actual importance of these ?angels-on-the-heads-of-pins?
> discussions about utilization periods or parsing the application of free pool
> allocation language in its application to transfers.
> 
> I agree that there?s a lot of cruft that?s built up by people who weren?t intent
> upon using concise language in policy development, and who failed to remove
> or update language before slathering more over the top of it.  However, that
> in no way invalidates the basic requirement for regulation to defend the
> commons (global routing table size) against the competing interests of
> individuals (more smaller prefixes routed).
> 
> Both are valuable.  They?re naturally opposed interests.  Any useful discussion
> of either one must be in terms of the trade-off against the other.  You?re
> discussing only one of the two; only half of an inextricably linked
> conversation.
> 
>                                 -Bill
> 
> 
> 


From chris at semihuman.com  Sun May 22 18:18:26 2016
From: chris at semihuman.com (Chris Woodfield)
Date: Sun, 22 May 2016 15:18:26 -0700
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
	Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <A92EC59A-D2F8-44C4-A880-C0A6458D269F@delong.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
	<BY2PR07MB2408862693DDFA316B2379A8A14A0@BY2PR07MB2408.namprd07.prod.outlook.com>
	<A92EC59A-D2F8-44C4-A880-C0A6458D269F@delong.com>
Message-ID: <3E334622-E06E-4538-A58D-7EE6C9202E9C@semihuman.com>

Reading this thread, as interesting as it has been over the past couple of weeks, makes a few things obvious. I make these assertions primarily to allow others to point out any glaring misreadings I may be making here.

1. We currently don?t have much info regarding the potential for IPv4 addresses to become a speculative commodity. The best we can go by is the experience that unregulated markets have the annoying habit of turning just about any type of asset into a speculative commodity, whether it be real estate, oil, pork bellies, orange juice, or out-of-print Magic: The Gathering cards. Therefore, there is a not-unfounded fear among some that should tight needs-based controls on IPv4 allocations be lifted, IPv4 space will be speculatively commoditized like any other tradable asset.

2. There are community members that don?t think that the above is necessarily a bad thing, and others who believe that at least that the nature of IP allocations (not being hard assets, like many of the other examples I listed above) will curb undesirable speculative activity. 

3. The immediate utilization rule is onerous for many operators and should be updated to reflect current practices.

As such, here?s my thoughts on this:

1. There seems to be a wide gulf between those advocating keeping the 30-day rule and those advocating removing it entirely, which does remove what I do feel to be an effective enforcement policy (when followed up on, of course) against allocating space that does not get used. That said, I haven?t seen any conversations around relaxing the rule to make it less onerous, which could be a viable middle ground here. For example, we could change ?immediate? to ?within 60 (or 90) days"; or we could allow the definition of ?immediate usage? to incorporate something like ?must be announcing the prefix to a peer?. (if there was such a discussion, I?m not finding it in the PPML archives, so please help me find one if it exists).

2. Remember that ARIN has regular meetings, and a policy development process for a reason: So that operational issues with existing policy can be modified as needed to suit the needs of the community and to better execute on RIR principles and goals. If this, or any proposal, is adopted and we do see the negative effects that some are warning against?we have the power to roll it back! And I?d expect that if we were to see rampant speculation/monetization of IPv4 space as a result of this change, ARIN should do exactly that.

As such, I?ll state my position on the policy as currently undecided. I?d be in strong support of a policy that incorporates items #1 and with the community?s commitment to #2.

Thanks,

-Chris

> On May 19, 2016, at 8:48 PM, Owen DeLong <owen at delong.com> wrote:
> 
> 
>> On May 19, 2016, at 07:41 , Mueller, Milton L <milton at gatech.edu <mailto:milton at gatech.edu>> wrote:
>> 
>>  
>> ? <>
>> From: Owen DeLong [mailto:owen at delong.com <mailto:owen at delong.com>] 
>> 
>>  
>> Transfers are not rationed by price?
>>  
>> MM: False. This is like saying white is black. Transfers involve a payment by the receiving party. They are, therefore, rationed by price. Not much room for debate here. You?re just wrong. 
> 
> Rationed: a fixed allowance of provisions or food, especially for soldiers or sailors or for civilians during a shortage: a daily ration of meat and bread. 2. an allotted amount: They finally saved up enough gas rations for the trip.
> 
> I simply do not agree with you that price constitutes any sort of limitation on the amount of resources that can be acquired by an organization with sufficiently deep pockets.
> 
> Therefore, you are simply wrong.
> 
>> Price does not ensure that the purchaser has actual need for the resources, it merely insures that they have monetary resources that they are willing to trade for number resources.
>>  
>> MM: It means that they value the resources and thus have some kind of need for them. There are 1,000 other things they could spend that money on but the buyer has determined that the value they will get out of the numbers is at least equal to the value of the money they spend.
> 
> It means that they believe the resources have value. That is different from having need for them or from valuing them. This is the sophistry in which you consistently engage hoping nobody will notice the inaccuracy in your statement.
> 
> For example, I may perceive that a stock has value or will have a greater value in the future. I may purchase the stock on that basis. It does not mean that I value the particular stock or the company it represents. It further does not mean that I have any need whatsoever for the stock other than my hope that its value will increase and that I can sell it at a gain.
> 
>> You?ve presented no evidence whatsoever to support your conclusion that stringent needs assessment raises the price
>>  
>> In fact, in the RIPE region where there are virtually no needs-based controls, according to the brokers I have discussed things with, prices are rising more rapidly than in the ARIN region, which would in fact appear to suggest that our needs-assessment regime is, in fact, holding prices down.
>>  
>> MM: Facts? Citations to specific transactions? I am always open to evidence.
> 
> These are facts. Feel free to discuss the pricing trends in RIPE vs. ARIN regions with any of the brokers. I cannot cite specific transactions because I am not directly familiar with the details of most of them and I am under NDA for the ones that I do know about. However, that does not discredit my general claim that both the transactions of which I am aware of the specifics, and the discussions I have had with several brokers have indicated that prices are generally higher in the RIPE region than in the ARIN region.
> 
>> If we eliminate needs assessment, what mechanism assures that the transferee is actually a network operator? Further, how does it in any way assure that the transfer is from a place of less need to a place of greater need rather than a place of limited need to a place of greater monetary resources?
>>  
>> MM: This is not the place to rectify your general lack of familiarity with economics. But you seem to think that people with ?greater monetary resources? simply throw them at anything that moves. In fact, in the real world, everyone tries to maximize the value they get from whatever resources they have. So if someone pays for addresses, it is a very reliable indicator that they need them for something. Most if not all of the organizations that can derive value from numbers are network operators.  The threat of massive speculation is a bogeyman you have invented ? there is no evidence that it exists. The only ?speculation and hoarding? that currently exists is the holding of number resources by current assignees who don?t need them. And stringent needs assessment freezes that problem into place. Sorry to say it, but you, Owen, are one of the greatest defenders of hoarding.  
> 
> I am not alone in thinking that this is often true. As cases in point, I give you the Pet Rock, several of P.T. Barnum?s exploits, John Travolta?s personal 727, the Fry Brothers (of Fry?s Electronics fame) personal 747.
> 
> If someone pays for addresses, it is an indicator that one of two things is true? 1. They have a use for the addresses that they believe is at least as valuable as the price paid, or, 2. They have a belief that the market value of the addresses in the future will exceed the cost of obtaining and holding them until that time.
> 
> Your continuing to insist that the second of these two possibilities does not exist is absurd. If it were not true, we would not have stock markets, day traders, mutual funds, or most of the other things regulated by the securities and exchange commission.
> 
> This is not my general lack of familiarity with economics and your continued ad hominem attacks do nothing to change the falsity of your argument.
> 
>> You start with an assumption that you are correct in your conjecture and then act as if it is everyone else?s duty to provide evidence that your speculation is not correct. The reality is that these are judgment calls based on limited experience and while we do know that needs assessment does, in fact, work to some extent, there is very limited experience without it. Unfortunately, once it is eliminated, it will be virtually impossible to put the genie back in the bottle, so people are understandably cautious about opening the bottle all at once.
> 
> Where, exactly, do you see conjecture? It is a fact that if we commoditize IPv4 addresses, we will enable them to be treated as an investment vehicle, just like many other forms of property both real and personal. You?ve provided no reasoning whatsoever that distinguishes IPv4 address registrations from real estate, collectibles, or any of a host of other forms of property in this regard.
> 
> It is not conjecture when I say that there are people who invest in these other things in a variety of ways, some of which are speculative. I have no reason whatsoever to believe that commoditizing IPv4 addresses would not enable similar forms of speculation in addresses.
> 
> Your continued claims to the contrary appear to ignore the realities of other unregulated commodities.
> 
> If you need further examples, I point you to the Chicago Merchantile Exchange.
> 
> 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.

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

From matthew at matthew.at  Sun May 22 18:41:11 2016
From: matthew at matthew.at (Matthew Kaufman)
Date: Sun, 22 May 2016 15:41:11 -0700
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy
	ARIN-2015-3:	Remove 30 day utilization requirement in
	end-user IPv4 policy
In-Reply-To: <C9AEB491-4E80-4D26-88C3-82D3C46EB58B@pch.net>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
	<BY2PR07MB2408862693DDFA316B2379A8A14A0@BY2PR07MB2408.namprd07.prod.outlook.com>
	<037d01d1b1e9$f28a9600$d79fc200$@iptrading.com>
	<4F6ED3D1-D4F5-475B-8A1B-E6A85C7AE4BD@corp.arin.net>
	<03fb01d1b1ff$a69b56b0$f3d20410$@iptrading.com>
	<C9AEB491-4E80-4D26-88C3-82D3C46EB58B@pch.net>
Message-ID: <638B0324-C2DB-42F0-AED0-FFA7065068E0@matthew.at>

So the world is better off (at least FIB-utilization-wize, and probably in dollars expended on lawyers and escrow agents) if I buy one /12 that I can't prove a need for under current policy, instead of buying a /20-/22 every few weeks that does pass the needs test.

Explain why we have arbitrary "needs testing" again?

Matthew Kaufman

(Sent from my iPhone)

> On May 19, 2016, at 1:13 PM, Bill Woodcock <woody at pch.net> wrote:
> 
> 
>> On May 19, 2016, at 11:52 AM, Mike Burns <mike at iptrading.com> wrote:
>> I want community members to understand that this is evidence that the market is a natural conserver of valuable resources.
> 
> Help me understand what evidence you see that any market has ever conserved expensive FIB slots.
> 
>> ...and naturally elevates them to a higher and better use.
> 
> It seems to me that this is the same fallacy upon which inter-provider QoS ran aground.  Just because something was valuable and expensive to Party A, and Party A exchanges traffic with Party B, there?s no reason why the same thing would be valued by Party B, who has their own concerns.  Thus, the fact that Party A buys an address block for a lot of money may make routing that address block very important to Party A, but that?s independent of Party B?s interest in receiving that routing announcement or wasting a FIB slot on it.  Thus, the money has been spent, but nothing has been elevated to a higher or better use; it may in fact not be usable at all, outside the context of needs-based allocation of FIB slots.
> 
>> Thus reducing the actual importance of these ?angels-on-the-heads-of-pins? discussions about utilization periods or parsing the application of free pool allocation language in its application to transfers.
> 
> I agree that there?s a lot of cruft that?s built up by people who weren?t intent upon using concise language in policy development, and who failed to remove or update language before slathering more over the top of it.  However, that in no way invalidates the basic requirement for regulation to defend the commons (global routing table size) against the competing interests of individuals (more smaller prefixes routed).
> 
> Both are valuable.  They?re naturally opposed interests.  Any useful discussion of either one must be in terms of the trade-off against the other.  You?re discussing only one of the two; only half of an inextricably linked conversation.
> 
>                                -Bill
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message 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 JOHN at egh.com  Sun May 22 22:43:33 2016
From: JOHN at egh.com (John Santos)
Date: Sun, 22 May 2016 22:43:33 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
	Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <638B0324-C2DB-42F0-AED0-FFA7065068E0@matthew.at>
Message-ID: <1160522223710.573A-100000@joonya.egh.com>


A /22 every 2 weeks is 27,000 addresses/year
A /20 every 2 weeks is 106,000 addresses/year

A /12 is over 1,000,000 addresses.  A 10 year supply of /20's, or 40 
year supply of /22's.  Explain again to me why these are equivalent.


On Sun, 22 May 2016, Matthew Kaufman wrote:

> So the world is better off (at least FIB-utilization-wize, and probably
in dollars expended on lawyers and escrow agents) if I buy one /12 that I
can't prove a need for under current policy, instead of buying a /20-/22
every few weeks that does pass the needs test. 

Explain why we have arbitrary "needs testing" again?

Matthew Kaufman

(Sent from my iPhone)

> On May 19, 2016, at 1:13 PM, Bill Woodcock <woody at pch.net> wrote:
> 
> 
>> On May 19, 2016, at 11:52 AM, Mike Burns <mike at iptrading.com> wrote:
>> I want community members to understand that this is evidence that the market is a natural conserver of valuable resources.
> 
> Help me understand what evidence you see that any market has ever conserved expensive FIB slots.
> 
>> ...and naturally elevates them to a higher and better use.
> 
> It seems to me that this is the same fallacy upon which inter-provider QoS ran aground.  Just because something was valuable and expensive to Party A, and Party A exchanges traffic with Party B, there???s no reason why the same thing would be valued by Party B, who has their own concerns.  Thus, the fact that Party A buys an address block for a lot of money may make routing that address block very important to Party A, but that???s independent of Party B???s interest in receiving that routing announcement or wasting a FIB slot on it.  Thus, the money has been spent, but nothing has been elevated to a higher or better use; it may in fact not be usable at all, outside the context of needs-based allocation of FIB slots.
> 
>> Thus reducing the actual importance of these ???angels-on-the-heads-of-pins??? discussions about utilization periods or parsing the application of free pool allocation language in its application to transfers.
> 
> I agree that there???s a lot of cruft that???s built up by people who weren???t intent upon using concise language in policy development, and who failed to remove or update language before slathering more over the top of it.  However, that in no way invalidates the basic requirement for regulation to defend the commons (global routing table size) against the competing interests of individuals (more smaller prefixes routed).
> 
> Both are valuable.  They???re naturally opposed interests.  Any useful discussion of either one must be in terms of the trade-off against the other.  You???re discussing only one of the two; only half of an inextricably linked conversation.
> 
>                                -Bill
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message 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.

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



From matthew at matthew.at  Mon May 23 00:16:34 2016
From: matthew at matthew.at (Matthew Kaufman)
Date: Sun, 22 May 2016 21:16:34 -0700
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <1160522223710.573A-100000@joonya.egh.com>
References: <1160522223710.573A-100000@joonya.egh.com>
Message-ID: <57428422.4090904@matthew.at>

Yes. a 10 year supply. Totally reasonable, even if one believes their 
growth will never increase. And if they believe it is, more like a 4 
year supply. Which, given the adoption rate of IPv6 is not at all 
unreasonable to plan for.

Matthew Kaufman

On 5/22/16 7:43 PM, John Santos wrote:
> A /22 every 2 weeks is 27,000 addresses/year
> A /20 every 2 weeks is 106,000 addresses/year
>
> A /12 is over 1,000,000 addresses.  A 10 year supply of /20's, or 40
> year supply of /22's.  Explain again to me why these are equivalent.
>
>
> On Sun, 22 May 2016, Matthew Kaufman wrote:
>
>> So the world is better off (at least FIB-utilization-wize, and probably
> in dollars expended on lawyers and escrow agents) if I buy one /12 that I
> can't prove a need for under current policy, instead of buying a /20-/22
> every few weeks that does pass the needs test.
>
> Explain why we have arbitrary "needs testing" again?
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
>> On May 19, 2016, at 1:13 PM, Bill Woodcock <woody at pch.net> wrote:
>>
>>
>>> On May 19, 2016, at 11:52 AM, Mike Burns <mike at iptrading.com> wrote:
>>> I want community members to understand that this is evidence that the market is a natural conserver of valuable resources.
>> Help me understand what evidence you see that any market has ever conserved expensive FIB slots.
>>
>>> ...and naturally elevates them to a higher and better use.
>> It seems to me that this is the same fallacy upon which inter-provider QoS ran aground.  Just because something was valuable and expensive to Party A, and Party A exchanges traffic with Party B, there???s no reason why the same thing would be valued by Party B, who has their own concerns.  Thus, the fact that Party A buys an address block for a lot of money may make routing that address block very important to Party A, but that???s independent of Party B???s interest in receiving that routing announcement or wasting a FIB slot on it.  Thus, the money has been spent, but nothing has been elevated to a higher or better use; it may in fact not be usable at all, outside the context of needs-based allocation of FIB slots.
>>
>>> Thus reducing the actual importance of these ???angels-on-the-heads-of-pins??? discussions about utilization periods or parsing the application of free pool allocation language in its application to transfers.
>> I agree that there???s a lot of cruft that???s built up by people who weren???t intent upon using concise language in policy development, and who failed to remove or update language before slathering more over the top of it.  However, that in no way invalidates the basic requirement for regulation to defend the commons (global routing table size) against the competing interests of individuals (more smaller prefixes routed).
>>
>> Both are valuable.  They???re naturally opposed interests.  Any useful discussion of either one must be in terms of the trade-off against the other.  You???re discussing only one of the two; only half of an inextricably linked conversation.
>>
>>                                 -Bill
>>
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



From matthew at matthew.at  Mon May 23 00:48:57 2016
From: matthew at matthew.at (Matthew Kaufman)
Date: Sun, 22 May 2016 21:48:57 -0700
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <1160522223710.573A-100000@joonya.egh.com>
References: <1160522223710.573A-100000@joonya.egh.com>
Message-ID: <57428BB9.1080604@matthew.at>

More important to my original point, starting with the 2nd /20, this 
already uses double the FIB slots. And it just gets worse.

Matthew Kaufman

On 5/22/16 7:43 PM, John Santos wrote:
> A /22 every 2 weeks is 27,000 addresses/year
> A /20 every 2 weeks is 106,000 addresses/year
>
> A /12 is over 1,000,000 addresses.  A 10 year supply of /20's, or 40
> year supply of /22's.  Explain again to me why these are equivalent.
>
>
> On Sun, 22 May 2016, Matthew Kaufman wrote:
>
>> So the world is better off (at least FIB-utilization-wize, and probably
> in dollars expended on lawyers and escrow agents) if I buy one /12 that I
> can't prove a need for under current policy, instead of buying a /20-/22
> every few weeks that does pass the needs test.
>
> Explain why we have arbitrary "needs testing" again?
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
>> On May 19, 2016, at 1:13 PM, Bill Woodcock <woody at pch.net> wrote:
>>
>>
>>> On May 19, 2016, at 11:52 AM, Mike Burns <mike at iptrading.com> wrote:
>>> I want community members to understand that this is evidence that the market is a natural conserver of valuable resources.
>> Help me understand what evidence you see that any market has ever conserved expensive FIB slots.
>>
>>> ...and naturally elevates them to a higher and better use.
>> It seems to me that this is the same fallacy upon which inter-provider QoS ran aground.  Just because something was valuable and expensive to Party A, and Party A exchanges traffic with Party B, there???s no reason why the same thing would be valued by Party B, who has their own concerns.  Thus, the fact that Party A buys an address block for a lot of money may make routing that address block very important to Party A, but that???s independent of Party B???s interest in receiving that routing announcement or wasting a FIB slot on it.  Thus, the money has been spent, but nothing has been elevated to a higher or better use; it may in fact not be usable at all, outside the context of needs-based allocation of FIB slots.
>>
>>> Thus reducing the actual importance of these ???angels-on-the-heads-of-pins??? discussions about utilization periods or parsing the application of free pool allocation language in its application to transfers.
>> I agree that there???s a lot of cruft that???s built up by people who weren???t intent upon using concise language in policy development, and who failed to remove or update language before slathering more over the top of it.  However, that in no way invalidates the basic requirement for regulation to defend the commons (global routing table size) against the competing interests of individuals (more smaller prefixes routed).
>>
>> Both are valuable.  They???re naturally opposed interests.  Any useful discussion of either one must be in terms of the trade-off against the other.  You???re discussing only one of the two; only half of an inextricably linked conversation.
>>
>>                                 -Bill
>>
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message 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 mike at iptrading.com  Mon May 23 10:33:03 2016
From: mike at iptrading.com (Mike Burns)
Date: Mon, 23 May 2016 10:33:03 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy
	ARIN-2015-3:	Remove 30 day utilization requirement in
	end-user IPv4 policy
In-Reply-To: <3E334622-E06E-4538-A58D-7EE6C9202E9C@semihuman.com>
References: <571E6439.7010801@arin.net>	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>	<BY2PR07MB2408862693DDFA316B2379A8A14A0@BY2PR07MB2408.namprd07.prod.outlook.com>	<A92EC59A-D2F8-44C4-A880-C0A6458D269F@delong.com>
	<3E334622-E06E-4538-A58D-7EE6C9202E9C@semihuman.com>
Message-ID: <024001d1b500$037ebcc0$0a7c3640$@iptrading.com>

Hi Chris,

 

Thanks for your input. I have some issues with your assertions, inline.

 

Reading this thread, as interesting as it has been over the past couple of weeks, makes a few things obvious. I make these assertions primarily to allow others to point out any glaring misreadings I may be making here.

 

1.     We currently don?t have much info regarding the potential for IPv4 addresses to become a speculative commodity. The best we can go by is the experience that unregulated markets have the annoying habit of turning just about any type of asset into a speculative commodity, whether it be real estate, oil, pork bellies, orange juice, or out-of-print Magic: The Gathering cards. Therefore, there is a not-unfounded fear among some that should tight needs-based controls on IPv4 allocations be lifted, IPv4 space will be speculatively commoditized like any other tradable asset.

 

 

Can you identify a problem with speculation that does not involve market manipulation? They are two different things, and I would like to understand why people feel that simply being able to speculate is inherently bad.  Why not let people speculate? Some will win, more will lose. BTW none of the commodities you list above are in an unregulated market except the Magic: The Gathering cards. More important, none of those commodities has any likelihood of going to a zero value anytime soon, as IPv4 does in the shadow of IPv6.  (Well maybe those cards.) And your assertion that we don?t have much info grows less true every day, as needs-free transfers have been happening in RIPE without evidence of speculation.  It is true that we don?t have information about how much addresses cost, but we have exhaustive lists of policy-compliant transfers that include the size transferred, the RIR-vetted buyer, the RIR-vetted seller, and the date of the transfer.  

 

2.     There are community members that don?t think that the above is necessarily a bad thing, and others who believe that at least that the nature of IP allocations (not being hard assets, like many of the other examples I listed above) will curb undesirable speculative activity. 

 

Since community members are making policy decisions on economic issues, I think it?s important to state what their reasons are for believing that speculation will necessarily be harmful.  You can?t just say we could have speculation and expect everybody to assume that?s a necessarily bad thing.

 

3. The immediate utilization rule is onerous for many operators and should be updated to reflect current practices.

 

As such, here?s my thoughts on this:

 

1. There seems to be a wide gulf between those advocating keeping the 30-day rule and those advocating removing it entirely, which does remove what I do feel to be an effective enforcement policy (when followed up on, of course) against allocating space that does not get used. That said, I haven?t seen any conversations around relaxing the rule to make it less onerous, which could be a viable middle ground here. For example, we could change ?immediate? to ?within 60 (or 90) days"; or we could allow the definition of ?immediate usage? to incorporate something like ?must be announcing the prefix to a peer?. (if there was such a discussion, I?m not finding it in the PPML archives, so please help me find one if it exists).

 

3.     Remember that ARIN has regular meetings, and a policy development process for a reason: So that operational issues with existing policy can be modified as needed to suit the needs of the community and to better execute on RIR principles and goals. If this, or any proposal, is adopted and we do see the negative effects that some are warning against?we have the power to roll it back! And I?d expect that if we were to see rampant speculation/monetization of IPv4 space as a result of this change, ARIN should do exactly that.

 

Given the information published by each registry involving transfers, the evidence of speculation would be plain. And the atomized supply of IPv4 would absolutely make it a long and difficult slog to attempt to acquire enough space to manipulate the market. So I absolutely agree that the RIR communities have the power to change policy in the face of negative results. Add this to the IPv6 transition as a reason why speculators do not exist. It?s just too risky an environment. Stable prices, trajectory towards zero value, atomized supply, public recording of every transfer, and the ability of the RIR communities to change the rules at any time. That?s a tough sell. 

 

Regards,
Mike

 

 

As such, I?ll state my position on the policy as currently undecided. I?d be in strong support of a policy that incorporates items #1 and with the community?s commitment to #2.

 

Thanks,

 

-Chris

 

On May 19, 2016, at 8:48 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com> > wrote:

 

 

On May 19, 2016, at 07:41 , Mueller, Milton L <milton at gatech.edu <mailto:milton at gatech.edu> > wrote:

 

 

 

From: Owen DeLong [ <mailto:owen at delong.com> mailto:owen at delong.com] 




 

Transfers are not rationed by price?

 

MM: False. This is like saying white is black. Transfers involve a payment by the receiving party. They are, therefore, rationed by price. Not much room for debate here. You?re just wrong. 

 

Rationed: a fixed allowance of provisions or food, especially for soldiers or sailors or for civilians during a shortage: a daily ration of meat and bread. 2. an allotted amount: They finally saved up enough gas rations for the trip.

 

I simply do not agree with you that price constitutes any sort of limitation on the amount of resources that can be acquired by an organization with sufficiently deep pockets.

 

Therefore, you are simply wrong.





Price does not ensure that the purchaser has actual need for the resources, it merely insures that they have monetary resources that they are willing to trade for number resources.

 

MM: It means that they value the resources and thus have some kind of need for them. There are 1,000 other things they could spend that money on but the buyer has determined that the value they will get out of the numbers is at least equal to the value of the money they spend.

 

It means that they believe the resources have value. That is different from having need for them or from valuing them. This is the sophistry in which you consistently engage hoping nobody will notice the inaccuracy in your statement.

 

For example, I may perceive that a stock has value or will have a greater value in the future. I may purchase the stock on that basis. It does not mean that I value the particular stock or the company it represents. It further does not mean that I have any need whatsoever for the stock other than my hope that its value will increase and that I can sell it at a gain.





You?ve presented no evidence whatsoever to support your conclusion that stringent needs assessment raises the price

 

In fact, in the RIPE region where there are virtually no needs-based controls, according to the brokers I have discussed things with, prices are rising more rapidly than in the ARIN region, which would in fact appear to suggest that our needs-assessment regime is, in fact, holding prices down.

 

MM: Facts? Citations to specific transactions? I am always open to evidence.

 

These are facts. Feel free to discuss the pricing trends in RIPE vs. ARIN regions with any of the brokers. I cannot cite specific transactions because I am not directly familiar with the details of most of them and I am under NDA for the ones that I do know about. However, that does not discredit my general claim that both the transactions of which I am aware of the specifics, and the discussions I have had with several brokers have indicated that prices are generally higher in the RIPE region than in the ARIN region.





If we eliminate needs assessment, what mechanism assures that the transferee is actually a network operator? Further, how does it in any way assure that the transfer is from a place of less need to a place of greater need rather than a place of limited need to a place of greater monetary resources?

 

MM: This is not the place to rectify your general lack of familiarity with economics. But you seem to think that people with ?greater monetary resources? simply throw them at anything that moves. In fact, in the real world, everyone tries to maximize the value they get from whatever resources they have. So if someone pays for addresses, it is a very reliable indicator that they need them for something. Most if not all of the organizations that can derive value from numbers are network operators.  The threat of massive speculation is a bogeyman you have invented ? there is no evidence that it exists. The only ?speculation and hoarding? that currently exists is the holding of number resources by current assignees who don?t need them. And stringent needs assessment freezes that problem into place. Sorry to say it, but you, Owen, are one of the greatest defenders of hoarding.  

 

I am not alone in thinking that this is often true. As cases in point, I give you the Pet Rock, several of P.T. Barnum?s exploits, John Travolta?s personal 727, the Fry Brothers (of Fry?s Electronics fame) personal 747.

 

If someone pays for addresses, it is an indicator that one of two things is true? 1. They have a use for the addresses that they believe is at least as valuable as the price paid, or, 2. They have a belief that the market value of the addresses in the future will exceed the cost of obtaining and holding them until that time.

 

Your continuing to insist that the second of these two possibilities does not exist is absurd. If it were not true, we would not have stock markets, day traders, mutual funds, or most of the other things regulated by the securities and exchange commission.

 

This is not my general lack of familiarity with economics and your continued ad hominem attacks do nothing to change the falsity of your argument.





You start with an assumption that you are correct in your conjecture and then act as if it is everyone else?s duty to provide evidence that your speculation is not correct. The reality is that these are judgment calls based on limited experience and while we do know that needs assessment does, in fact, work to some extent, there is very limited experience without it. Unfortunately, once it is eliminated, it will be virtually impossible to put the genie back in the bottle, so people are understandably cautious about opening the bottle all at once.

 

Where, exactly, do you see conjecture? It is a fact that if we commoditize IPv4 addresses, we will enable them to be treated as an investment vehicle, just like many other forms of property both real and personal. You?ve provided no reasoning whatsoever that distinguishes IPv4 address registrations from real estate, collectibles, or any of a host of other forms of property in this regard.

 

It is not conjecture when I say that there are people who invest in these other things in a variety of ways, some of which are speculative. I have no reason whatsoever to believe that commoditizing IPv4 addresses would not enable similar forms of speculation in addresses.

 

Your continued claims to the contrary appear to ignore the realities of other unregulated commodities.

 

If you need further examples, I point you to the Chicago Merchantile Exchange.

 

Owen

 

_______________________________________________
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/20160523/3b8f7baf/attachment.htm>

From jschiller at google.com  Mon May 23 13:43:08 2016
From: jschiller at google.com (Jason Schiller)
Date: Mon, 23 May 2016 13:43:08 -0400
Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3:
 Remove 30 day utilization requirement in end-user IPv4 policy
In-Reply-To: <3E334622-E06E-4538-A58D-7EE6C9202E9C@semihuman.com>
References: <571E6439.7010801@arin.net>
	<CAN-Dau2+eOkipSmpEJLjgH_dAo3EVV0ynOn+LXrHFnkohDRCFg@mail.gmail.com>
	<CAC4yj2X+mB46BYpVh+ZXS+V2rLuSgfhEsonfnq+fJXhfDWHa3Q@mail.gmail.com>
	<CAN-Dau2NBBPZhx6yy62LTNGL7ta5Cp+uwi6P-8GzYvDc5dC4sw@mail.gmail.com>
	<C19ADAAB-7721-4B88-8FD4-0FE365C15175@delong.com>
	<CAC4yj2VuD7aAEpd+rV+Lwn7haEZH1bwNJvGsKzQHPOgZcqUTYQ@mail.gmail.com>
	<BY2PR07MB2408276FF6E191DA9495F80DA1760@BY2PR07MB2408.namprd07.prod.outlook.com>
	<1C505D86-D5EA-4DC1-A1B6-7DFF22220D9B@delong.com>
	<BY2PR07MB2408862693DDFA316B2379A8A14A0@BY2PR07MB2408.namprd07.prod.outlook.com>
	<A92EC59A-D2F8-44C4-A880-C0A6458D269F@delong.com>
	<3E334622-E06E-4538-A58D-7EE6C9202E9C@semihuman.com>
Message-ID: <CAC4yj2VsbNXSMYBiWX0==FV+gAh5zka2KpQf3=1L0d-+KNhMPw@mail.gmail.com>

Comments in line.

On Sun, May 22, 2016 at 6:18 PM, Chris Woodfield <chris at semihuman.com>
wrote:

>
>
> [snip]


> As such, here?s my thoughts on this:
>
> 1. There seems to be a wide gulf between those advocating keeping the
> 30-day rule and those advocating removing it entirely, which does remove
> what I do feel to be an effective enforcement policy (when followed up on,
> of course) against allocating space that does not get used. That said, I
> haven?t seen any conversations around relaxing the rule to make it less
> onerous, which could be a viable middle ground here. For example, we could
> change ?immediate? to ?within 60 (or 90) days"; or we could allow the
> definition of ?immediate usage? to incorporate something like ?must be
> announcing the prefix to a peer?. (if there was such a discussion, I?m not
> finding it in the PPML archives, so please help me find one if it exists).
>

I suggested (back in Feb) that we remove the 30 [or 60] day check, but add
back
some other check to limit potential abuse from optimistic future looking
projections,
and not have the ability to do an end run around policy by simply having an
aggressive plan for future projections that may never materialize.

I suggested adding the text:

"there must be some  tangible and verifiable claim to show there was a real
commitment to use half the address space within one year and not just a
future
projection or business case"

Jan 28
subject: "[arin-ppml] ARIN-2015-3: Remove 30-Day Utilization Requirement in
End-User IPv4 Policy"

http://lists.arin.net/pipermail/arin-ppml/2016-January/030642.html
and more clearly:
http://lists.arin.net/pipermail/arin-ppml/2016-January/030642.html




>
> 2. Remember that ARIN has regular meetings, and a policy development
> process for a reason: So that operational issues with existing policy can
> be modified as needed to suit the needs of the community and to better
> execute on RIR principles and goals. If this, or any proposal, is adopted
> and we do see the negative effects that some are warning against?we have
> the power to roll it back! And I?d expect that if we were to see rampant
> speculation/monetization of IPv4 space as a result of this change, ARIN
> should do exactly that.
>
> As such, I?ll state my position on the policy as currently undecided. I?d
> be in strong support of a policy that incorporates items #1 and with the
> community?s commitment to #2.
>
>
I think the real point I was trying to make is that it sounded
like a lot of people supported the changes on the grounds
that is is a no-op.

It seems to me this is not a no-op, as it removes the only
tangible (non-future projection looking) effective
enforcement mechanism limiting end-user requests.

I asked if I was wrong about it being a no-op, or
if the people who supported because they though
it was a no-op were wrong. And if so do they still
support it.

Even if the 25% check is generally not followed up on
it is still somewhat effective against organization who
try to stay in compliance with policy, and to
organizations that have concerns about a possible
report of fraud thereby triggering a check at 25%.

If it is truly a no-op I withdraw my concerns.

If it is not a no-op, I wonder how much support
there is for the policy.

__Jason



> Thanks,
>
> -Chris
>
> On May 19, 2016, at 8:48 PM, Owen DeLong <owen at delong.com> wrote:
>
>
> On May 19, 2016, at 07:41 , Mueller, Milton L <milton at gatech.edu> wrote:
>
>
>
> *From:* Owen DeLong [mailto:owen at delong.com <owen at delong.com>]
>
>
> Transfers are not rationed by price?
>
> MM: False. This is like saying white is black. Transfers involve a payment
> by the receiving party. They are, therefore, rationed by price. Not much
> room for debate here. You?re just wrong.
>
>
> Rationed: a fixed allowance of provisions or food, especially for soldiers
> or sailors or for civilians during a shortage: a daily ration of meat and
> bread. 2. an allotted amount: They finally saved up enough gas rations for
> the trip.
>
> I simply do not agree with you that price constitutes any sort of
> limitation on the amount of resources that can be acquired by an
> organization with sufficiently deep pockets.
>
> Therefore, you are simply wrong.
>
> Price does not ensure that the purchaser has actual need for the
> resources, it merely insures that they have monetary resources that they
> are willing to trade for number resources.
>
> MM: It means that they value the resources and thus have some kind of need
> for them. There are 1,000 other things they could spend that money on but
> the buyer has determined that the value they will get out of the numbers is
> at least equal to the value of the money they spend.
>
>
> It means that they believe the resources have value. That is different
> from having need for them or from valuing them. This is the sophistry in
> which you consistently engage hoping nobody will notice the inaccuracy in
> your statement.
>
> For example, I may perceive that a stock has value or will have a greater
> value in the future. I may purchase the stock on that basis. It does not
> mean that I value the particular stock or the company it represents. It
> further does not mean that I have any need whatsoever for the stock other
> than my hope that its value will increase and that I can sell it at a gain.
>
> You?ve presented no evidence whatsoever to support your conclusion that
> stringent needs assessment raises the price
>
> In fact, in the RIPE region where there are virtually no needs-based
> controls, according to the brokers I have discussed things with, prices are
> rising more rapidly than in the ARIN region, which would in fact appear to
> suggest that our needs-assessment regime is, in fact, holding prices down.
>
> MM: Facts? Citations to specific transactions? I am always open to
> evidence.
>
>
> These are facts. Feel free to discuss the pricing trends in RIPE vs. ARIN
> regions with any of the brokers. I cannot cite specific transactions
> because I am not directly familiar with the details of most of them and I
> am under NDA for the ones that I do know about. However, that does not
> discredit my general claim that both the transactions of which I am aware
> of the specifics, and the discussions I have had with several brokers have
> indicated that prices are generally higher in the RIPE region than in the
> ARIN region.
>
> If we eliminate needs assessment, what mechanism assures that the
> transferee is actually a network operator? Further, how does it in any way
> assure that the transfer is from a place of less need to a place of greater
> need rather than a place of limited need to a place of greater monetary
> resources?
>
> MM: This is not the place to rectify your general lack of familiarity with
> economics. But you seem to think that people with ?greater monetary
> resources? simply throw them at anything that moves. In fact, in the real
> world, everyone tries to maximize the value they get from whatever
> resources they have. So if someone pays for addresses, it is a very
> reliable indicator that they need them for something. Most if not all of
> the organizations that can derive value from numbers are network
> operators.  The threat of massive speculation is a bogeyman you have
> invented ? there is no evidence that it exists. The only ?speculation and
> hoarding? that currently exists is the holding of number resources by
> current assignees who don?t need them. And stringent needs assessment
> freezes that problem into place. Sorry to say it, but you, Owen, are one of
> the greatest defenders of hoarding.
>
>
> I am not alone in thinking that this is often true. As cases in point, I
> give you the Pet Rock, several of P.T. Barnum?s exploits, John Travolta?s
> personal 727, the Fry Brothers (of Fry?s Electronics fame) personal 747.
>
> If someone pays for addresses, it is an indicator that one of two things
> is true? 1. They have a use for the addresses that they believe is at least
> as valuable as the price paid, or, 2. They have a belief that the market
> value of the addresses in the future will exceed the cost of obtaining and
> holding them until that time.
>
> Your continuing to insist that the second of these two possibilities does
> not exist is absurd. If it were not true, we would not have stock markets,
> day traders, mutual funds, or most of the other things regulated by the
> securities and exchange commission.
>
> This is not my general lack of familiarity with economics and your
> continued ad hominem attacks do nothing to change the falsity of your
> argument.
>
> You start with an assumption that you are correct in your conjecture and
> then act as if it is everyone else?s duty to provide evidence that your
> speculation is not correct. The reality is that these are judgment calls
> based on limited experience and while we do know that needs assessment
> does, in fact, work to some extent, there is very limited experience
> without it. Unfortunately, once it is eliminated, it will be virtually
> impossible to put the genie back in the bottle, so people are
> understandably cautious about opening the bottle all at once.
>
>
> Where, exactly, do you see conjecture? It is a fact that if we commoditize
> IPv4 addresses, we will enable them to be treated as an investment vehicle,
> just like many other forms of property both real and personal. You?ve
> provided no reasoning whatsoever that distinguishes IPv4 address
> registrations from real estate, collectibles, or any of a host of other
> forms of property in this regard.
>
> It is not conjecture when I say that there are people who invest in these
> other things in a variety of ways, some of which are speculative. I have no
> reason whatsoever to believe that commoditizing IPv4 addresses would not
> enable similar forms of speculation in addresses.
>
> Your continued claims to the contrary appear to ignore the realities of
> other unregulated commodities.
>
> If you need further examples, I point you to the Chicago Merchantile
> Exchange.
>
> 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.
>



-- 
_______________________________________________________
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/20160523/8890d38c/attachment.htm>

From info at arin.net  Tue May 24 17:01:04 2016
From: info at arin.net (ARIN)
Date: Tue, 24 May 2016 17:01:04 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - May 2016
Message-ID: <5744C110.2060307@arin.net>

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

The AC has recommended the following to the Board of Trustees for adoption:

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

The AC provided the following statement:

There was much discussion during the last call of Recommended Draft 
Policy ARIN-2015-3: Remove 30-day Utilization Requirement in End-User 
IPv4 Policy.  A significant portion of the discussion went on tangents 
that were not directly relevant to the last call of this policy.  The 
portion of the discussion that was relevant to the last call of this 
policy asked staff for several clarifications, which were provided, and 
reiterated the discomfort a small minority had with removing the 
criterion in question without substituting alternate policy language. 
This issue was discussed in some depth by the community at ARIN 37 and 
on PPML, and the policy as a whole was previously discussed at NANOG 64 
PPC and ARIN 36.  The consensus of the community coming out of ARIN 37, 
and confirmed by this last call, was to Remove 30-day Utilization 
Requirement in End-User IPv4 Policy, and not replace it with any 
alternate language at this time.  Therefore the AC is forwarding 
Recommended Draft Policy ARIN-2015-3: Remove 30-day Utilization 
Requirement in End-User IPv4 Policy to the board for adoption.

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

      Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to 
Specified Recipients)

The AC advances Draft Policies to Recommended Draft Policy status and 
recommends it for adoption when they feel it has been fully developed 
and meets ARIN's Principles of Internet Number Resource Policy, 
specifically:

      1) enabling fair and impartial number resource administration,
      2) technically sound (providing for uniqueness and usability of 
number resources), and
      3) supported by the community

The AC has accepted the following Proposals as Draft Policies (each will 
be posted for discussion):

      ARIN-prop-227 Change timeframes for all IPv4 requests to 24 months
      ARIN-prop-228 Alternative simplified criteria for justifying small 
IPv4 transfers

The AC has recommended the editorial revision to the "return" language 
for NRPM 8.2 (posted to PPML on 24 March) to the Board of Trustees for 
adoption.

The AC is continuing to work on:

      Draft Policy ARIN-2015-7: Simplified requirements for demonstrated 
need for IPv4 transfers
      Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy
      ARIN-prop-229 Transfers for new entrants

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

ARIN's PDP details 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 May 24 17:23:56 2016
From: info at arin.net (ARIN)
Date: Tue, 24 May 2016 17:23:56 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN 2015-2 Modify 8.4
 (Inter-RIR Transfers to Specified Recipients)
Message-ID: <5744C66C.8050204@arin.net>


Recommended Draft Policy ARIN-2015-2 Modify 8.4 (Inter-RIR Transfers to 
Specified Recipients)

On 19 May 2016 the ARIN Advisory Council (AC) advanced 2015-2 to 
Recommended Draft Policy status.

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

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

The PDP can be found at:
https://www.arin.net/policy/pdp.html

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

Regards,

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



Recommended Draft Policy ARIN 2015-2
Modify 8.4 (Inter-RIR Transfers to Specified Recipients)

Date: 24 May 2016

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

Draft Policy ARIN 2015-2 contributes to fair and impartial number 
resources administration by removing an impediment to the transfer of 
IPv4 numbering resources to other RIRs when business needs change within 
the first 12 months of receipt of a 24 month supply of IP addresses by 
an entity via the transfer market. It is technically sound in that it 
balances removing limits on transfers of IPv4 numbering resources to 
other RIRs with safeguards related to ownership and control described in 
the draft policy to reduce the likelihood of fraudulent transactions. 
There was strong community support for this draft policy at the NANOG 66 
PPC and ARIN 37, subject only to some suggested editorial changes which 
have now been implemented in the latest version.

Problem Statement:

Organizations that obtain a 24 month supply of IP addresses via the 
transfer market and then have an unexpected change in business plan are 
unable to move IP addresses to the proper RIR within the first 12 months 
of receipt.

Policy statement:

Replace 8.4, bullet 4, to read:

"Source entities within the ARIN region must not have received a 
transfer, allocation, or assignment of IPv4 number resources from ARIN 
for the 12 months prior to the approval of a transfer request, unless 
either the source or recipient entity owns or controls the other, or 
both are under common ownership or control. This restriction does not 
include M&A transfers."

Comments: Organizations that obtain a 24 month supply of IP addresses 
via the transfer market and then have an unexpected change in business 
plan are unable to move IP addresses to the proper RIR within the first 
12 months of receipt. The need to move the resources does not flow from 
ARIN policy, but rather from the requirement of certain registries 
outside the ARIN region to have the resources moved in order to be used 
there.

The intention of this change is to allow organizations to perform 
inter-RIR transfers of space received via an 8.3 transfer regardless of 
the date transferred to ARIN. A common example is that an organization 
acquires a block located in the ARIN region, transfers it to ARIN, then 
3 months later, the organization announces that it wants to launch new 
services out of region. Under current policy, the organization is 
prohibited from moving some or all of those addresses to that region's 
Whois if there is a need to move them to satisfy the rules of the other 
region requiring the movement of the resources to that region in order 
for them to be used there. Instead, the numbers are locked in ARIN's 
Whois. It's important to note that 8.3 transfers are approved for a 24 
month supply, and it would not be unheard of for a business model to 
change within the first 12 months after approval. The proposal also 
introduces a requirement for an affiliation relationship between the 
source and recipient entity, based on established corporate law 
principles, so as to make it reasonably likely that eliminating the 12 
month anti-flip period in that situation will meet the needs of 
organizations that operate networks in more than one region without 
encouraging abuse.

a. Timetable for implementation: Immediate

b. Anything else: N/A

#####

ARIN STAFF & LEGAL ASSESSMENT
Draft Policy ARIN-2015-2
MODIFY 8.4 (INTER-RIR TRANSFERS TO SPECIFIED RECIPIENTS)
https://www.arin.net/policy/proposals/2015_2.html

Date of Assessment: 17 May 2016

___
1. Summary (Staff Understanding)

Currently, organizations are unable to act as a source on an 8.4 
transfer of IPv4 address space if they have received IPv4 address space 
in the past 12 months from ARIN's IPv4 free pool, the waiting list for 
unmet requests, or an 8.3 transfer. This draft policy lifts the 12-month 
restriction in cases when the source or recipient entity owns or 
controls the other, or both are under common ownership or control.

___
2. Comments

A. ARIN Staff Comments

* If this policy is implemented, ARIN staff would no longer apply a 
12-month time restriction to organizations who wish to 8.4 transfer IPv4 
addresses to themselves or in cases when the source or recipient entity 
owns or controls the other, or both are under common ownership or control.

* This policy could be implemented as written.

B. ARIN General Counsel ? Legal Assessment

Concerns raised by the GC regarding previous versions of this policy 
have been satisfactorily addressed in the current draft. The current 
proposed draft does not create material legal issues for ARIN. In order 
to determine when entities are under common ownership or control, 
traditional legal standards will be applied by ARIN.

___
3. Resource Impact

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

* Updated guidelines and internal procedures

* Staff training

___
4. Proposal / Draft Policy Text Assessed

Draft Policy ARIN 2015-2
Modify 8.4 (Inter-RIR Transfers to Specified Recipients)

Date: 11 May 2016

Problem Statement:

Organizations that obtain a 24 month supply of IP addresses via the 
transfer market and then have an unexpected change in business plan are 
unable to move IP addresses to the proper RIR within the first 12 months 
of receipt.

Policy statement:

Replace 8.4, bullet 4, to read: "Source entities within the ARIN region 
must not have received a transfer, allocation, or assignment of IPv4 
number resources from ARIN for the 12 months prior to the approval of a 
transfer request, unless either the source or recipient entity owns or 
controls the other, or both are under common ownership or control. This 
restriction does not include M&A transfers."

Comments: Organizations that obtain a 24 month supply of IP addresses 
via the transfer market and then have an unexpected change in business 
plan are unable to move IP addresses to the proper RIR within the first 
12 months of receipt. The need to move the resources does not flow from 
ARIN policy, but rather from the requirement of certain registries 
outside the ARIN region to have the resources moved in order to be used 
there.

The intention of this change is to allow organizations to perform 
inter-RIR transfers of space received via an 8.3 transfer regardless of 
the date transferred to ARIN. A common example is that an organization 
acquires a block located in the ARIN region, transfers it to ARIN, then 
3 months later, the organization announces that it wants to launch new 
services out of region. Under current policy, the organization is 
prohibited from moving some or all of those addresses to that region's 
Whois if there is a need to move them to satisfy the rules of the other 
region requiring the movement of the resources to that region in order 
for them to be used there. Instead, the numbers are locked in ARIN's 
Whois. It's important to note that 8.3 transfers are approved for a 24 
month supply, and it would not be unheard of for a business model to 
change within the first 12 months after approval. The proposal also 
introduces a requirement for an affiliation relationship between the 
source and recipient entity, based on established corporate law 
principles, so as to make it reasonably likely that eliminating the 12 
month anti-flip period in that situation will meet the needs of 
organizations that operate networks in more than one region without 
encouraging abuse.

a. Timetable for implementation: Immediate
b. Anything else: N/A


From info at arin.net  Tue May 24 17:40:34 2016
From: info at arin.net (ARIN)
Date: Tue, 24 May 2016 17:40:34 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-2 Change timeframes for IPv4
 requests to 24 months
Message-ID: <5744CA52.3060505@arin.net>

Draft Policy ARIN-2016-2 Change timeframes for IPv4 requests to 24 months

On 19 May the ARIN Advisory Council (AC) accepted "ARIN-prop-227 Change 
timeframes for all IPv4 requests to 24 months" as a Draft Policy.

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

You are encouraged to discuss all Draft Policies on PPML. The AC will 
evaluate the discussion in order to assess the conformance of this draft 
policy with ARIN's Principles of Internet number resource policy as 
stated in the Policy Development Process (PDP). Specifically, these 
principles are:

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

The PDP can be found at:
https://www.arin.net/policy/pdp.html

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

Regards,

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



ARIN-2016-2 Change timeframes for IPv4 requests to 24 months

Date: 24 May 2016

Problem Statement:

Disparity in timeframes between pre-approvals for waiting list and 
pre-approval for transfers is creating difficulties for organizations 
that initially apply to be on the waiting list and subsequently elect to 
satisfy their needs through transfers.

Therefore, this proposal seeks to set all timeframes for IPv4 request 
approvals to 24 months. Prior to runout, such a change could have 
created great disparity in resource distribution just because of 
coincidence of request timing. With the free pool gone, this is no 
longer an issue.

Policy statement:

Retitle section 4.2.2.1.3 "Three months" to "Time Horizon".

In section 4.2.2.1.3 body, replace "three months" with "24 months".

In section 4.2.3.8, replace the term "three months" with "24 months".

In section 4.3.3, replace both instances of "one year" with "24 months".

In section 4.2.4.3, replace the entire paragraph which currently reads: 
"ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or 
a 24-month supply via 8.3 or 8.4 transfer. Determination of the 
appropriate allocation to be issued is based on efficient utilization of 
space within this time frame, consistent with the principles in 4.2.1."

with:

"ISPs may request up to a 24 month supply of IPv4 addresses."

Timetable for implementation: Immediate


From info at arin.net  Tue May 24 17:55:36 2016
From: info at arin.net (ARIN)
Date: Tue, 24 May 2016 17:55:36 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-3 Alternative simplified
 criteria for justifying small IPv4 transfers
Message-ID: <5744CDD8.2070902@arin.net>

Draft Policy ARIN-2016-3 Alternative simplified criteria for justifying 
small IPv4 transfers

On 19 May the ARIN Advisory Council (AC) accepted "ARIN-prop-228 
Alternative simplified criteria for justifying small IPv4 transfers" as 
a Draft Policy.

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

You are encouraged to discuss all Draft Policies on PPML. The AC will 
evaluate the discussion in order to assess the conformance of this draft 
policy with ARIN's Principles of Internet Number Resource Policy as 
stated in the Policy Development Process (PDP). Specifically, these 
principles are:

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

The PDP can be found at:
https://www.arin.net/policy/pdp.html

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

Regards,

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



Draft Policy ARIN-2016-3 Change timeframes for IPv4 requests to 24 months

Date: 24 May 2016

Problem Statement:

ARIN transfer policy currently inherits all its demonstrated need 
requirements for IPv4 transfers from NRPM sections 4. Because that 
section was written primarily to deal with free pool allocations, it is 
much more complicated than is really necessary for transfers.

This proposal allows organizations using 80% of their current space to 
double their current holdings via 8.3 or 8.4 specified transfers, up to 
a certain size, such as /12 or /16. Existing section 4 need 
demonstration rules would continue to apply to organizations who request 
more than a [ /12 | /16] of space.

Policy statement:

In section 8.3, replace:

The recipient must demonstrate the need for up to a 24-month supply of 
IP address resources under current ARIN policies and sign an RSA.
with:

The recipient must sign an RSA and either:

Demonstrate 80% utilization of their currently allocated space to 
qualify to receive one or more transfers up to the total size of their 
current ARIN IPv4 address holdings, with a maximum size of [/12 | /16], or

Demonstrate the need for up to a 24-month supply of IP address resources 
under current ARIN policies.

In section 8.4, replace:

Recipients within the ARIN region must demonstrate the need for up to a 
24-month supply of IPv4 address space.

with:

Recipients within the ARIN region must either:

Demonstrate 80% utilization of their currently allocated space to 
qualify to receive one or more transfers up to the total size of their 
current ARIN IPv4 address holdings, with a maximum size of [/12 | /16], or

Demonstrate the need for up to a 24-month supply of IPv4 address space 
under current ARIN policies.

Comments:

Timetable for implementation: immediate

Anything else

The [/12 | /16] notation for the cap is intended to offer some 
suggestions about what the cap should be. It is our intention that this 
will be replaced with a single value prior to this becoming a 
recommended draft.

Notes on interaction with existing IPv4 assignment policy:

Organizations requiring a transfer larger than a [/12 | /16] may either: 
transfer a [/12 | /16] at a time, and re-certify 80% utilization before 
receiving each new [/12 | /16], or continue to qualify under NRPM 4.2 or 
4.3, which allows an organization to qualify for a 24-month supply of 
IPv4 space via transfer. (That means, for example, that an organization 
that has used a /13 in less than a year would ordinarily qualify to 
receive a /12 via transfer.)

An organization holding a /22 and a /20 which are 80% utilized can 
qualify for one or more transfers over a two year period up to a /22 
plus a /20 (up to 5120 IPs). After two years, or at any time that an 
organization wants more than the amount of transfer space approved, the 
organization can re-certify 80% utilization and get a new doubling window.


From jschiller at google.com  Wed May 25 10:07:41 2016
From: jschiller at google.com (Jason Schiller)
Date: Wed, 25 May 2016 10:07:41 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-3 Alternative simplified
 criteria for justifying small IPv4 transfers
In-Reply-To: <5744CDD8.2070902@arin.net>
References: <5744CDD8.2070902@arin.net>
Message-ID: <CAC4yj2WEQ98BYzuh+t9w_fVtKEyiorvT=TFw5zQxyOmBY2cfig@mail.gmail.com>

I think the first order of business here is to discuss the right value for
the doubling cap.

As the policy currently reads it suggest a doubling cap of a /12 or a /16.

Organizations who are currently at 80% utilization and holding less than
or equal to the cap can simply double with one or more transfers over a
two year window.  After which they need to re-certify their utilization.

Organizations who are currently at 80% utilization and holding more than
the cap, can simply transfer in up to the cap with one or more transfers
over a two year window.  After which they need to re-certify their
utilization.

Some questions:

1. What is the "right" value for the cap?
(/12, /16, something else?)

2. Would you support this proposal if the cap was the "right" value?

3. Would you support this proposal if the cap was the "wrong" value?
(if the right value is /12, would you support /16?
  if the right value is /16, would you support /12?
  if the right value is something else would you support /12 and/or /16?)


Note organizations that need more than double, or more than the cap can:

- get the amount permitted, put it into service, re-certify utilization and
repeat.

- qualify under the current policy

___Jason





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

> Draft Policy ARIN-2016-3 Alternative simplified criteria for justifying
> small IPv4 transfers
>
> On 19 May the ARIN Advisory Council (AC) accepted "ARIN-prop-228
> Alternative simplified criteria for justifying small IPv4 transfers" as a
> Draft Policy.
>
> Draft Policy ARIN-2016-3 is below and can be found at:
> https://www.arin.net/policy/proposals/2016_3.html
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion in order to assess the conformance of this draft
> policy with ARIN's Principles of Internet Number Resource Policy as stated
> in the Policy Development Process (PDP). Specifically, these principles are:
>
>   * Enabling Fair and Impartial Number Resource Administration
>   * Technically Sound
>   * Supported by the Community
>
> The PDP can be found at:
> https://www.arin.net/policy/pdp.html
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
>
> Draft Policy ARIN-2016-3 Change timeframes for IPv4 requests to 24 months
>
> Date: 24 May 2016
>
> Problem Statement:
>
> ARIN transfer policy currently inherits all its demonstrated need
> requirements for IPv4 transfers from NRPM sections 4. Because that section
> was written primarily to deal with free pool allocations, it is much more
> complicated than is really necessary for transfers.
>
> This proposal allows organizations using 80% of their current space to
> double their current holdings via 8.3 or 8.4 specified transfers, up to a
> certain size, such as /12 or /16. Existing section 4 need demonstration
> rules would continue to apply to organizations who request more than a [
> /12 | /16] of space.
>
> Policy statement:
>
> In section 8.3, replace:
>
> The recipient must demonstrate the need for up to a 24-month supply of IP
> address resources under current ARIN policies and sign an RSA.
> with:
>
> The recipient must sign an RSA and either:
>
> Demonstrate 80% utilization of their currently allocated space to qualify
> to receive one or more transfers up to the total size of their current ARIN
> IPv4 address holdings, with a maximum size of [/12 | /16], or
>
> Demonstrate the need for up to a 24-month supply of IP address resources
> under current ARIN policies.
>
> In section 8.4, replace:
>
> Recipients within the ARIN region must demonstrate the need for up to a
> 24-month supply of IPv4 address space.
>
> with:
>
> Recipients within the ARIN region must either:
>
> Demonstrate 80% utilization of their currently allocated space to qualify
> to receive one or more transfers up to the total size of their current ARIN
> IPv4 address holdings, with a maximum size of [/12 | /16], or
>
> Demonstrate the need for up to a 24-month supply of IPv4 address space
> under current ARIN policies.
>
> Comments:
>
> Timetable for implementation: immediate
>
> Anything else
>
> The [/12 | /16] notation for the cap is intended to offer some suggestions
> about what the cap should be. It is our intention that this will be
> replaced with a single value prior to this becoming a recommended draft.
>
> Notes on interaction with existing IPv4 assignment policy:
>
> Organizations requiring a transfer larger than a [/12 | /16] may either:
> transfer a [/12 | /16] at a time, and re-certify 80% utilization before
> receiving each new [/12 | /16], or continue to qualify under NRPM 4.2 or
> 4.3, which allows an organization to qualify for a 24-month supply of IPv4
> space via transfer. (That means, for example, that an organization that has
> used a /13 in less than a year would ordinarily qualify to receive a /12
> via transfer.)
>
> An organization holding a /22 and a /20 which are 80% utilized can qualify
> for one or more transfers over a two year period up to a /22 plus a /20 (up
> to 5120 IPs). After two years, or at any time that an organization wants
> more than the amount of transfer space approved, the organization can
> re-certify 80% utilization and get a new doubling window.
> _______________________________________________
> PPML
> You are receiving this message 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/20160525/ce9a47fb/attachment.htm>

From owen at delong.com  Wed May 25 10:41:42 2016
From: owen at delong.com (Owen DeLong)
Date: Wed, 25 May 2016 07:41:42 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-3 Alternative simplified
	criteria for justifying small IPv4 transfers
In-Reply-To: <CAC4yj2WEQ98BYzuh+t9w_fVtKEyiorvT=TFw5zQxyOmBY2cfig@mail.gmail.com>
References: <5744CDD8.2070902@arin.net>
	<CAC4yj2WEQ98BYzuh+t9w_fVtKEyiorvT=TFw5zQxyOmBY2cfig@mail.gmail.com>
Message-ID: <677A9ED0-2464-43C4-B6B8-FCCA6D434EC9@delong.com>

> Some questions:
> 
> 1. What is the "right" value for the cap? 
> (/12, /16, something else?)

I support /16

> 
> 2. Would you support this proposal if the cap was the "right" value?

Yes

> 
> 3. Would you support this proposal if the cap was the "wrong" value?
> (if the right value is /12, would you support /16?
>   if the right value is /16, would you support /12?
>   if the right value is something else would you support /12 and/or /16?)

I will not support if the cap is more than 65,536 addresses. I will support longer than /16 if the community chooses to go in that direction, but I believe that /16 provides adequate protection. 

Owen




From jschiller at google.com  Wed May 25 12:03:23 2016
From: jschiller at google.com (Jason Schiller)
Date: Wed, 25 May 2016 12:03:23 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-2 Change timeframes for IPv4
 requests to 24 months
In-Reply-To: <5744CA52.3060505@arin.net>
References: <5744CA52.3060505@arin.net>
Message-ID: <CAC4yj2V8cpEWutFV=c_0EstpeTR-cHoSrmg2t5Tr5G940fEBpQ@mail.gmail.com>

I'm not sure this impacts whether I support or not, but I
think it is good to have clear expectations.

How would this impact those already on the waiting list?

Would they stay in place, and the request grow to a 2
year need if they could provide justification for such?

Would they stay in place, and the request grow to a 2
year need automatically if they have transfer
pre-approval?

Would this only apply to those being added to the wait
list after the policy is implemented?

___Jason



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

> Draft Policy ARIN-2016-2 Change timeframes for IPv4 requests to 24 months
>
> On 19 May the ARIN Advisory Council (AC) accepted "ARIN-prop-227 Change
> timeframes for all IPv4 requests to 24 months" as a Draft Policy.
>
> Draft Policy ARIN-2016-2 is below and can be found at:
> https://www.arin.net/policy/proposals/2016_2.html
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion in order to assess the conformance of this draft
> policy with ARIN's Principles of Internet number resource policy as stated
> in the Policy Development Process (PDP). Specifically, these principles are:
>
>   * Enabling Fair and Impartial Number Resource Administration
>   * Technically Sound
>   * Supported by the Community
>
> The PDP can be found at:
> https://www.arin.net/policy/pdp.html
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
>
> ARIN-2016-2 Change timeframes for IPv4 requests to 24 months
>
> Date: 24 May 2016
>
> Problem Statement:
>
> Disparity in timeframes between pre-approvals for waiting list and
> pre-approval for transfers is creating difficulties for organizations that
> initially apply to be on the waiting list and subsequently elect to satisfy
> their needs through transfers.
>
> Therefore, this proposal seeks to set all timeframes for IPv4 request
> approvals to 24 months. Prior to runout, such a change could have created
> great disparity in resource distribution just because of coincidence of
> request timing. With the free pool gone, this is no longer an issue.
>
> Policy statement:
>
> Retitle section 4.2.2.1.3 "Three months" to "Time Horizon".
>
> In section 4.2.2.1.3 body, replace "three months" with "24 months".
>
> In section 4.2.3.8, replace the term "three months" with "24 months".
>
> In section 4.3.3, replace both instances of "one year" with "24 months".
>
> In section 4.2.4.3, replace the entire paragraph which currently reads:
> "ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a
> 24-month supply via 8.3 or 8.4 transfer. Determination of the appropriate
> allocation to be issued is based on efficient utilization of space within
> this time frame, consistent with the principles in 4.2.1."
>
> with:
>
> "ISPs may request up to a 24 month supply of IPv4 addresses."
>
> Timetable for implementation: Immediate
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



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

From scottleibrand at gmail.com  Wed May 25 12:09:20 2016
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 25 May 2016 18:09:20 +0200
Subject: [arin-ppml] Draft Policy ARIN-2016-2 Change timeframes for IPv4
 requests to 24 months
In-Reply-To: <CAC4yj2V8cpEWutFV=c_0EstpeTR-cHoSrmg2t5Tr5G940fEBpQ@mail.gmail.com>
References: <5744CA52.3060505@arin.net>
	<CAC4yj2V8cpEWutFV=c_0EstpeTR-cHoSrmg2t5Tr5G940fEBpQ@mail.gmail.com>
Message-ID: <CAGkMwz5ETJadJkm84ms7tA63thi6U3MRf9nkSPXCXEcaFJ2zaA@mail.gmail.com>

My understanding is that those on the waiting list would stay on the
waiting list, approved for the blocks they're already approved for.  We
would not "grow" their approvals, as that would be unfair to those right
behind them on the list, or let them get on the list a second time.  Anyone
who wants to go to the end of the waiting list will be pre-approved for up
to a 24-month supply, but will be unlikely to ever get it from the free
pool.  Such approval will also be properly sized to acquire a block via
transfer, though, so that's how I expect most new approvals to be filled.

-Scott

On Wed, May 25, 2016 at 6:03 PM, Jason Schiller <jschiller at google.com>
wrote:

> I'm not sure this impacts whether I support or not, but I
> think it is good to have clear expectations.
>
> How would this impact those already on the waiting list?
>
> Would they stay in place, and the request grow to a 2
> year need if they could provide justification for such?
>
> Would they stay in place, and the request grow to a 2
> year need automatically if they have transfer
> pre-approval?
>
> Would this only apply to those being added to the wait
> list after the policy is implemented?
>
> ___Jason
>
>
>
> On Tue, May 24, 2016 at 5:40 PM, ARIN <info at arin.net> wrote:
>
>> Draft Policy ARIN-2016-2 Change timeframes for IPv4 requests to 24 months
>>
>> On 19 May the ARIN Advisory Council (AC) accepted "ARIN-prop-227 Change
>> timeframes for all IPv4 requests to 24 months" as a Draft Policy.
>>
>> Draft Policy ARIN-2016-2 is below and can be found at:
>> https://www.arin.net/policy/proposals/2016_2.html
>>
>> You are encouraged to discuss all Draft Policies on PPML. The AC will
>> evaluate the discussion in order to assess the conformance of this draft
>> policy with ARIN's Principles of Internet number resource policy as stated
>> in the Policy Development Process (PDP). Specifically, these principles are:
>>
>>   * Enabling Fair and Impartial Number Resource Administration
>>   * Technically Sound
>>   * Supported by the Community
>>
>> The PDP can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>>
>> Regards,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>> ARIN-2016-2 Change timeframes for IPv4 requests to 24 months
>>
>> Date: 24 May 2016
>>
>> Problem Statement:
>>
>> Disparity in timeframes between pre-approvals for waiting list and
>> pre-approval for transfers is creating difficulties for organizations that
>> initially apply to be on the waiting list and subsequently elect to satisfy
>> their needs through transfers.
>>
>> Therefore, this proposal seeks to set all timeframes for IPv4 request
>> approvals to 24 months. Prior to runout, such a change could have created
>> great disparity in resource distribution just because of coincidence of
>> request timing. With the free pool gone, this is no longer an issue.
>>
>> Policy statement:
>>
>> Retitle section 4.2.2.1.3 "Three months" to "Time Horizon".
>>
>> In section 4.2.2.1.3 body, replace "three months" with "24 months".
>>
>> In section 4.2.3.8, replace the term "three months" with "24 months".
>>
>> In section 4.3.3, replace both instances of "one year" with "24 months".
>>
>> In section 4.2.4.3, replace the entire paragraph which currently reads:
>> "ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a
>> 24-month supply via 8.3 or 8.4 transfer. Determination of the appropriate
>> allocation to be issued is based on efficient utilization of space within
>> this time frame, consistent with the principles in 4.2.1."
>>
>> with:
>>
>> "ISPs may request up to a 24 month supply of IPv4 addresses."
>>
>> Timetable for implementation: Immediate
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>
>
> _______________________________________________
> PPML
> You are receiving this message 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/20160525/8766a694/attachment.htm>

From farmer at umn.edu  Wed May 25 12:26:24 2016
From: farmer at umn.edu (David Farmer)
Date: Wed, 25 May 2016 11:26:24 -0500
Subject: [arin-ppml] Draft Policy ARIN-2016-2 Change timeframes for IPv4
 requests to 24 months
In-Reply-To: <CAGkMwz5ETJadJkm84ms7tA63thi6U3MRf9nkSPXCXEcaFJ2zaA@mail.gmail.com>
References: <5744CA52.3060505@arin.net>
	<CAC4yj2V8cpEWutFV=c_0EstpeTR-cHoSrmg2t5Tr5G940fEBpQ@mail.gmail.com>
	<CAGkMwz5ETJadJkm84ms7tA63thi6U3MRf9nkSPXCXEcaFJ2zaA@mail.gmail.com>
Message-ID: <CAN-Dau2nO99kJowMi=n1Jt7=PW5m6iiaT4bbh6NTeCvO5+bKDQ@mail.gmail.com>

I would concur with that interpretation.  Assuming there is a
consensus around that interpretation, I think it would be good to
document that as the community's intent by adding a comment to the
policy more or less saying just that.

David

On Wed, May 25, 2016 at 11:09 AM, Scott Leibrand
<scottleibrand at gmail.com> wrote:
> My understanding is that those on the waiting list would stay on the waiting
> list, approved for the blocks they're already approved for.  We would not
> "grow" their approvals, as that would be unfair to those right behind them
> on the list, or let them get on the list a second time.  Anyone who wants to
> go to the end of the waiting list will be pre-approved for up to a 24-month
> supply, but will be unlikely to ever get it from the free pool.  Such
> approval will also be properly sized to acquire a block via transfer,
> though, so that's how I expect most new approvals to be filled.
>
> -Scott
>
> On Wed, May 25, 2016 at 6:03 PM, Jason Schiller <jschiller at google.com>
> wrote:
>>
>> I'm not sure this impacts whether I support or not, but I
>> think it is good to have clear expectations.
>>
>> How would this impact those already on the waiting list?
>>
>> Would they stay in place, and the request grow to a 2
>> year need if they could provide justification for such?
>>
>> Would they stay in place, and the request grow to a 2
>> year need automatically if they have transfer
>> pre-approval?
>>
>> Would this only apply to those being added to the wait
>> list after the policy is implemented?
>>
>> ___Jason
>>
>>
>>
>> On Tue, May 24, 2016 at 5:40 PM, ARIN <info at arin.net> wrote:
>>>
>>> Draft Policy ARIN-2016-2 Change timeframes for IPv4 requests to 24 months
>>>
>>> On 19 May the ARIN Advisory Council (AC) accepted "ARIN-prop-227 Change
>>> timeframes for all IPv4 requests to 24 months" as a Draft Policy.
>>>
>>> Draft Policy ARIN-2016-2 is below and can be found at:
>>> https://www.arin.net/policy/proposals/2016_2.html
>>>
>>> You are encouraged to discuss all Draft Policies on PPML. The AC will
>>> evaluate the discussion in order to assess the conformance of this draft
>>> policy with ARIN's Principles of Internet number resource policy as stated
>>> in the Policy Development Process (PDP). Specifically, these principles are:
>>>
>>>   * Enabling Fair and Impartial Number Resource Administration
>>>   * Technically Sound
>>>   * Supported by the Community
>>>
>>> The PDP can be found at:
>>> https://www.arin.net/policy/pdp.html
>>>
>>> Draft Policies and Proposals under discussion can be found at:
>>> https://www.arin.net/policy/proposals/index.html
>>>
>>> Regards,
>>>
>>> Communications and Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>>
>>> ARIN-2016-2 Change timeframes for IPv4 requests to 24 months
>>>
>>> Date: 24 May 2016
>>>
>>> Problem Statement:
>>>
>>> Disparity in timeframes between pre-approvals for waiting list and
>>> pre-approval for transfers is creating difficulties for organizations that
>>> initially apply to be on the waiting list and subsequently elect to satisfy
>>> their needs through transfers.
>>>
>>> Therefore, this proposal seeks to set all timeframes for IPv4 request
>>> approvals to 24 months. Prior to runout, such a change could have created
>>> great disparity in resource distribution just because of coincidence of
>>> request timing. With the free pool gone, this is no longer an issue.
>>>
>>> Policy statement:
>>>
>>> Retitle section 4.2.2.1.3 "Three months" to "Time Horizon".
>>>
>>> In section 4.2.2.1.3 body, replace "three months" with "24 months".
>>>
>>> In section 4.2.3.8, replace the term "three months" with "24 months".
>>>
>>> In section 4.3.3, replace both instances of "one year" with "24 months".
>>>
>>> In section 4.2.4.3, replace the entire paragraph which currently reads:
>>> "ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a
>>> 24-month supply via 8.3 or 8.4 transfer. Determination of the appropriate
>>> allocation to be issued is based on efficient utilization of space within
>>> this time frame, consistent with the principles in 4.2.1."
>>>
>>> with:
>>>
>>> "ISPs may request up to a 24 month supply of IPv4 addresses."
>>>
>>> Timetable for implementation: Immediate
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>
>>
>>
>>
>> --
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message 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
===============================================


From owen at delong.com  Thu May 26 02:26:55 2016
From: owen at delong.com (Owen DeLong)
Date: Wed, 25 May 2016 23:26:55 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-2 Change timeframes for IPv4
	requests to 24 months
In-Reply-To: <CAN-Dau2nO99kJowMi=n1Jt7=PW5m6iiaT4bbh6NTeCvO5+bKDQ@mail.gmail.com>
References: <5744CA52.3060505@arin.net>
	<CAC4yj2V8cpEWutFV=c_0EstpeTR-cHoSrmg2t5Tr5G940fEBpQ@mail.gmail.com>
	<CAGkMwz5ETJadJkm84ms7tA63thi6U3MRf9nkSPXCXEcaFJ2zaA@mail.gmail.com>
	<CAN-Dau2nO99kJowMi=n1Jt7=PW5m6iiaT4bbh6NTeCvO5+bKDQ@mail.gmail.com>
Message-ID: <00982BA1-BA35-4C37-A871-5E4D5D55E88C@delong.com>

I would say that is the only interpretation I can imagine being generally fair.

However, if someone has a better idea, I am open to it.

Owen

> On May 25, 2016, at 09:26 , David Farmer <farmer at umn.edu> wrote:
> 
> I would concur with that interpretation.  Assuming there is a
> consensus around that interpretation, I think it would be good to
> document that as the community's intent by adding a comment to the
> policy more or less saying just that.
> 
> David
> 
> On Wed, May 25, 2016 at 11:09 AM, Scott Leibrand
> <scottleibrand at gmail.com> wrote:
>> My understanding is that those on the waiting list would stay on the waiting
>> list, approved for the blocks they're already approved for.  We would not
>> "grow" their approvals, as that would be unfair to those right behind them
>> on the list, or let them get on the list a second time.  Anyone who wants to
>> go to the end of the waiting list will be pre-approved for up to a 24-month
>> supply, but will be unlikely to ever get it from the free pool.  Such
>> approval will also be properly sized to acquire a block via transfer,
>> though, so that's how I expect most new approvals to be filled.
>> 
>> -Scott
>> 
>> On Wed, May 25, 2016 at 6:03 PM, Jason Schiller <jschiller at google.com>
>> wrote:
>>> 
>>> I'm not sure this impacts whether I support or not, but I
>>> think it is good to have clear expectations.
>>> 
>>> How would this impact those already on the waiting list?
>>> 
>>> Would they stay in place, and the request grow to a 2
>>> year need if they could provide justification for such?
>>> 
>>> Would they stay in place, and the request grow to a 2
>>> year need automatically if they have transfer
>>> pre-approval?
>>> 
>>> Would this only apply to those being added to the wait
>>> list after the policy is implemented?
>>> 
>>> ___Jason
>>> 
>>> 
>>> 
>>> On Tue, May 24, 2016 at 5:40 PM, ARIN <info at arin.net> wrote:
>>>> 
>>>> Draft Policy ARIN-2016-2 Change timeframes for IPv4 requests to 24 months
>>>> 
>>>> On 19 May the ARIN Advisory Council (AC) accepted "ARIN-prop-227 Change
>>>> timeframes for all IPv4 requests to 24 months" as a Draft Policy.
>>>> 
>>>> Draft Policy ARIN-2016-2 is below and can be found at:
>>>> https://www.arin.net/policy/proposals/2016_2.html
>>>> 
>>>> You are encouraged to discuss all Draft Policies on PPML. The AC will
>>>> evaluate the discussion in order to assess the conformance of this draft
>>>> policy with ARIN's Principles of Internet number resource policy as stated
>>>> in the Policy Development Process (PDP). Specifically, these principles are:
>>>> 
>>>>  * Enabling Fair and Impartial Number Resource Administration
>>>>  * Technically Sound
>>>>  * Supported by the Community
>>>> 
>>>> The PDP can be found at:
>>>> https://www.arin.net/policy/pdp.html
>>>> 
>>>> Draft Policies and Proposals under discussion can be found at:
>>>> https://www.arin.net/policy/proposals/index.html
>>>> 
>>>> Regards,
>>>> 
>>>> Communications and Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>> 
>>>> 
>>>> 
>>>> ARIN-2016-2 Change timeframes for IPv4 requests to 24 months
>>>> 
>>>> Date: 24 May 2016
>>>> 
>>>> Problem Statement:
>>>> 
>>>> Disparity in timeframes between pre-approvals for waiting list and
>>>> pre-approval for transfers is creating difficulties for organizations that
>>>> initially apply to be on the waiting list and subsequently elect to satisfy
>>>> their needs through transfers.
>>>> 
>>>> Therefore, this proposal seeks to set all timeframes for IPv4 request
>>>> approvals to 24 months. Prior to runout, such a change could have created
>>>> great disparity in resource distribution just because of coincidence of
>>>> request timing. With the free pool gone, this is no longer an issue.
>>>> 
>>>> Policy statement:
>>>> 
>>>> Retitle section 4.2.2.1.3 "Three months" to "Time Horizon".
>>>> 
>>>> In section 4.2.2.1.3 body, replace "three months" with "24 months".
>>>> 
>>>> In section 4.2.3.8, replace the term "three months" with "24 months".
>>>> 
>>>> In section 4.3.3, replace both instances of "one year" with "24 months".
>>>> 
>>>> In section 4.2.4.3, replace the entire paragraph which currently reads:
>>>> "ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a
>>>> 24-month supply via 8.3 or 8.4 transfer. Determination of the appropriate
>>>> allocation to be issued is based on efficient utilization of space within
>>>> this time frame, consistent with the principles in 4.2.1."
>>>> 
>>>> with:
>>>> 
>>>> "ISPs may request up to a 24 month supply of IPv4 addresses."
>>>> 
>>>> Timetable for implementation: Immediate
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>> 
>>> 
>>> 
>>> 
>>> --
>>> _______________________________________________________
>>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>>> 
>>> 
>>> _______________________________________________
>>> PPML
>>> You are receiving this message 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
> ===============================================
> _______________________________________________
> PPML
> You are receiving this message 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 narten at us.ibm.com  Fri May 27 00:53:02 2016
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 27 May 2016 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201605270453.u4R4r26d006499@rotala.raleigh.ibm.com>

Total of 20 messages in the last 7 days.
 
script run at: Fri May 27 00:53:02 EDT 2016
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 15.00% |    3 | 24.90% |    77812 | jschiller at google.com
 20.00% |    4 | 11.87% |    37076 | info at arin.net
 15.00% |    3 |  8.99% |    28101 | matthew at matthew.at
  5.00% |    1 | 14.14% |    44183 | mike at iptrading.com
  5.00% |    1 | 12.21% |    38138 | chris at semihuman.com
 10.00% |    2 |  5.71% |    17848 | owen at delong.com
  5.00% |    1 |  6.05% |    18912 | scottleibrand at gmail.com
  5.00% |    1 |  4.20% |    13112 | farmer at umn.edu
  5.00% |    1 |  3.44% |    10746 | jcurran at arin.net
  5.00% |    1 |  3.16% |     9870 | milton at gatech.edu
  5.00% |    1 |  2.80% |     8751 | john at egh.com
  5.00% |    1 |  2.54% |     7927 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |   20 |100.00% |   312476 | Total