[arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy

[Brian Jones]

Support with the changes concerning the reserved pool.

On Wed, Oct 26, 2016 at 5:18 PM ARIN <info at arin.net> wrote:

> The ARIN Advisory Council (AC) met on 21 October 2016 and decided to
> send Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy
> to Last Call:
>
> The AC provided the following statement to the community:
>
> This proposal is technically sound and enables fair and impartial number
> policy by ensuring that the number resources are used in accordance with
> the terms under which they were granted.  There is significant support
> for this change within the Internet community. Re: Merge into 2016-5.
> The new text "Address resources from a reserved pool (including those
> designated in Section 4.4 and 4.10) are not eligible for transfer."
> should be added to the revised 2016-5 sections 8.3 & 8.4 "Conditions on
> source of the transfer:”.
>
> 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 November 2016. After Last Call, the AC will conduct their
> Last Call review.
>
> The full 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-2016-1: Reserved Pool Transfer Policy
>
> AC assessment of conformance with the Principles of Internet Number
> Resource Policy:
>
> This proposal enables fair and impartial number resource administration
> by ensuring that IPv4 resources, which are specially designated for
> critical infrastructure and IPv6 transition, are readily available for
> many years into the future. This is done by ensuring the resources
> remain in their originally designated pool rather than being moved into
> the general IPv4 address pool via a transfer. This proposal is
> technically sound and is supported by the community.
>
> 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/20161102/098c9e72/attachment.htm>