[arin-ppml] 2016-3 Revisited

[Jason Schiller]

David,

This policy was  proposed to make transfers easy, with predictable
outcomes, for organizations that have used what they got and likely need
more.

This policy was not proposed to ration to those organizations with the most
need, which is exactly what the up to a /16 every 6 months does.

I appreciate the need to prevent abuse, but want this policy to be able to
be used by all organizations that are using what they have got, and will
continue to do such.  For this reason I oppose the once every 6 months
clause.


In a later thread I suggested demonstrate growth of IPv4 utilization of at
least half of the amount of specified transfers since the previous transfer
pre-authorization or approval.  Would that approach work for your
scenario?  As long as your newly deployed specified transfer space was
above 50% or you had some other growth somewhere else to off set under
utilization (which may be associated with a renumbering event) then you
should be fine.

If that approach still doesn't work can you suggest some other mechanism to
prevent abuse that does not prevent an organization who needs IP space from
using this policy?

While I hate creating added complexity, I could get on board for an either
or...

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

An organization may only qualify under 8.5.7 once every 6 months, unless
they can also demonstrate growth of IPv4 utilization of at least half of
the amount of specified transfers since the previous transfer
pre-authorization or approval.

OR if the community prefers

An organization may only qualify under 8.5.7 once every 6 months, unless
they can also demonstrate at least 50% utilization of each allocation and
assignment.
------

I think Owen prefers the former version, and maybe the former version does
not penalized a requester for something unrelated to the intent of the
anti-abuse text.  This approach would still meet your needs, not rate limit
the organizations with the most need who want to use this policy, still
provide benefits over the non-simplified approach of having a predictable
outcome and not dependent on some assessment of the hand waviness of future
looking predictions, and does not impact organizations that use this policy
infrequently.)

___Jason


On Fri, Feb 3, 2017 at 8:39 AM, David R Huberman <daveid at panix.com> wrote:

> What I dislike about the proposed addition of:
>
> "- at least 50% utilization of each allocation and assignment"
>
> ... is it gives ARIN staff no room to take into account individual
> topology.
>
> I may run a network at 95% utilization across all IP addresses.  But I may
> also have a pool of addresses in datacenter X that is under 50% utilized.
> Why am I being penalized for something unrelated to the intent of the
> anti-abuse text?
>
> I think I like the 2016-3 anti-abuse mechanism as-is. It is effective at
> stopping an abuse vector, and easy to implement across myriad topologies.
>
> _______________________________________________
> 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/20170203/862efb8b/attachment.htm>