Hi Jason,
I apologize for not commenting on this earlier, I decided to sit back and see
what other input was received.
I think that you have correctly identified in your problem statement certain
issues we face at the near-exhaust stage and beyond.
ARIN allocation policy was always premised on the free pool, and we have
decided to borrow the same policy and apply it to the wholly new environment of
a trading market.
You correctly identify issues like transactional costs which are imposed on
recipients as a result of free-pool premised policies whose authors did not
consider these implications.
You note that ARIN policy does not efficiently accommodate various recipient
growth profiles, especially as any wiggle-room is squeezed out of every
allocation by a team of ARIN reviewers.
We can expect more such problems as market forces tend to diverge from ARIN
policy prescriptions, and it is my belief that the weight of these distortions
puts a strain on Whois accuracy as more money flows into this market. When
business needs are faced-up against ARIN policy, at a certain point the
business risk of inadequate allocation overrides the risk of an out-of-policy
transfer. And these out-of-policy transfers can happen by multiple means,
including phased-contracts, permanent leasing, and zombie corporations which
ARIN policy can’t touch. ARIN policy is a market distortion which will likely
grow larger over time.
Rather than try to put our finger in the dyke through more and more NRPM
verbiage, isn’t it time we acknowledged that a separate allocation paradigm
exists in the trading market which requires a separate (or absent) needs-test
for transfers?
I believe that every circumstance elucidated in your proposal is answered by
the much more streamlined 2014-14, which removes needs testing from transfers
smaller than a /16, once per year.
I am against further un-necessary clutter in the NRPM, and if we seek to match
every unknown and unknowable vagary of the impending transfer market with new
policy, we open the door to a virtual tax code of text. Here is one of your new
sections:
8.3.2.3.2.1 Calculation of Monthly Average Use Rate
An organization may choose a look-back window of any number of months between 3
and 12, inclusive, from the date of the current request. ARIN will calculate
the total amount of new addresses acquired, during the look-back window, by the
organization from non-M&A transfers, direct allocations or assignments from
ARIN, or reallocations or reassignments from an ISP. That total will be divided
by the number of months in the look-back window to calculate the organization’s
monthly average use rate.
8.3.2.3.2.1?
While I support the recognition of the problems Jason identified, I am opposed
to 2014-20.
(Also I would counsel against regarding silence as approval.)
Regards
Mike Burns
From: Jason Schiller
Sent: Friday, September 12, 2014 12:13 PM
To: [email protected] ; Kevin Blumberg ; David Farmer
Cc: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-20: Transfer Policy Slow Start
and Simplified Needs Verification
It has been a week, and there has been no discussion on this thread.
I take the silence to mean the suggested "option 2" rewrite is
non-controversial and meets all of Bill's concerns.
I also take the silence to mean that all three options I have suggested all
result in the same implementation,
and since no one believes any of the three options differ in implementation,
there is no preference.
I humbly submit we should go with option 2, as it is closest to Bill's
suggestion, and keeps 8.2 and 8.3 in line
(setting the ground work for a future unification of 8.2 and 8.3).
Will there be discussion now? Or should we just silently move forward?
Thanks,
___Jason
On Thu, Sep 4, 2014 at 11:34 AM, Jason Schiller <[email protected]> wrote:
Bill,
Thank you.
The intent was NOT to remove the requirement for in-region recipients of
transfers to sign an RSA.
My apologies.
There is a lot or parallel structure in 8.3 and 8.4 and in my mind 8.4 is
identical to 8.3 except 8.4 has a clause "Except when the recipient is out of
region then that region's policy applies", and " Except when the source is out
of region then that region's policy applies". I really wanted to completely
merge 8.3 and 8.4 to remove the parallel structure but as an editorial re-write
only and not part of this discussion.
in 8.4 there are a separate bullets for 24-month supply and sign the RSA:
"> Recipients within the ARIN region will be subject to current ARIN policies
and sign an RSA for the resources being received.
> Recipients within the ARIN region must demonstrate the need for up to a
24-month supply of IPv4 address space."
I think in my mind I imagined a similar separate bullets in 8.3, one for
24-month supply and another for sign RSA, and I intended just to remove the 24
month part.
I think there are a few ways to fix this.
Option 1 - minimun rewrtite
- remove only the "24-month" portion of the 8.3 text. This is the minimum
change, but brings section 8.3 and 8.4 further out of alignment
Option 2 - single bullet for "meet ARIN policy" and "sign RSA" (8.3 as the
model text)
- replace the whole "24-month" text and "meet ARIN policy" text in 8.3 with a
bullet that included "sign the RSA" and "meet ARIN policy" under one bullet and
is parallel to text in 8.4 (minus within the ARIN region)
Option 3 - two separate bullets for "meet ARIN policy" and "sign RSA" (8.2 as
the model text)
- replace the whole "24-month" text in 8.3 with a bullet that included "sign
the RSA"
-separate the "sign the RSA" and "meet ARIN policy" in 8.4 into two bullets
and is parallel to text in 8.3 (plus the within ARIN region)
(If the summary of the options are hard to follow I have a suggestion for the
specific rewrites below)
I think your suggestion is roughly Option 2 below (the only difference is
with your suggested rewrite, there are now two bullets in 8.3 stating the
recipient is subject to current ARIN policies). Assuming all the options have
the same policy implications, I would prefer option 2 or 3, as these bring
greater alignment of the sections.
Do these options all meet your concern?
Does the community and ARIN staff agree that the thee options have the same
policy implications?
Kevin, David,
I think at this point you own the text?
I would be supportive of the friendly amendment to modify the draft policy as
follows:
OPTION 1:
Replace the following Section 8.3 text:
"> 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:
"> Recipients will sign an RSA for the resources being received."
OPTION 2:
Replace the following Section 8.3 text:
"> 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.
> The resources transferred will be subject to current ARIN policies."
with:
"> Recipients will be subject to current ARIN policies and sign an RSA for
the resources being received."
OPTION 3:
Replace the following Section 8.3 text:
"> 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:
"> Recipients will sign an RSA for the resources being received."
and replace the following Section 8.4 text:
"> Recipients within the ARIN region will be subject to current ARIN policies
and sign an RSA for the resources being received.
> 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 will sign an RSA for the resources being
received.
> The resources transferred to recipients within the ARIN region will be
subject to current ARIN policies."
If all the options are indeed the same I would prefer option 2 or 3.
If the options have different policy implications and we can converge on one
standard for both 8.2 and 8.3, then I would prefer that.
___Jason
On Thu, Sep 4, 2014 at 8:50 AM, Bill Owens <[email protected]> wrote:
On Wed, Sep 03, 2014 at 04:55:58PM -0400, ARIN wrote:
> On 28 August 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-212 Transfer policy slow start and simplified needs
> verification" as a Draft Policy.
>
. . .
>
> Draft Policy ARIN-2014-20
> Transfer Policy Slow Start and Simplified Needs Verification
>
> Date: 3 September 2014
>
. . .
>
> Policy statement:
>
> Remove the following section 8.3 text:
>
> “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.”
Shouldn't that be something like this, instead?
Replace the following Section 8.3 text:
"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 will be subject to current ARIN policies and sign an
RSA for the resources being received."
As written it appears to remove the requirement for recipients of in-region
transfers to sign an RSA.
Bill.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
--
_______________________________________________________
Jason Schiller|NetOps|[email protected]|571-266-0006
--
_______________________________________________________
Jason Schiller|NetOps|[email protected]|571-266-0006
--------------------------------------------------------------------------------
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues._______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
