Would it be beneficial to do a rewrite as Andrew did, but simply make it editorial without changing the intent or implementation of the policy. Then do a red line for intent changes?
This would enable use to discuss the simplification and re-organization without getting bogged down in disagreement over changes. Once we agree on the non-policy impacting editorial re-write, then we could look at red-line changes, and decide which policy changes have support and which do not. We could then move forward with the changes that are supported, tweak the text a bit, and discuss it in the fall without getting bogged down in discussions about the re-organization. Andrew, Owen, what do you think? __Jason On Wed, Jun 22, 2016 at 1:30 PM, Owen DeLong <[email protected]> wrote: > > > On Jun 22, 2016, at 08:46 , Andrew Dul <[email protected]> wrote: > > > > As the primary author of this draft policy, I respectfully disagree with > > my AC colleague. > > > > Now that the free pool has been depleted, it is time to look toward what > > future IPv4 (primarily transfer) policy should do. While this policy > > looks complicated, its intention is to create a very simple transfer > > policy which allows businesses to predictably and efficiently transfer > > IPv4 resources to meet their requirements. > > I don’t disagree with your intent, but I disagree that what you have > proposed achieves that intent. > > You are eliminating key safeguards from the transfer policy while > simultaneously > changing several of the criteria that have previously applied to transfers > of > IPv4 space under section 4. > > In addition, there may be unintended effects on the transfer of ASNs. > > > I share with you here a redline which shows the changes that would be > > made to section 8. > > The redline doesn’t begin to cover it because it does nothing to evaluate > how > removing the existing interactions with section 4 compares to existing > policy > implementation. > > As a result, the redline ends up looking deceptively minor. > > Owen > > > > > Andrew > > > > On 6/21/2016 9:16 AM, Owen DeLong wrote: > >> I am opposed to this policy proposal. > >> > >> Given that we are now in a world where the only way to obtain IPv4 > space is through transfers, I think it makes much more sense to put policy > changes for IPv4 transfers into section 4 and retain the simplified text > that exists today in section 8 rather than copying most of section 4 into > section 8 with revisions in the process. > >> > >> The likely outcome of such an exercise is to create a number of changes > which may or may not be fully understood by the community. The interaction > of this rewrite with other types of transferable resources (AS numbers at > the moment) must also be carefully considered. > >> > >> If we want to change IPv4 policy, then let’s change IPv4 policy in > section 4. > >> > >> If we want to change transfer policy for all resources, we can do that > cleanly in section 8. > >> > >> While the NRPM may not be a perfect model of a structured document, > this proposal would make it significantly worse. > >> > >> Owen > >> > >>> On Jun 21, 2016, at 09:01 , ARIN <[email protected]> wrote: > >>> > >>> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following > Proposal to Draft Policy status: > >>> > >>> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy > >>> > >>> This Draft Policy has been numbered and titled: > >>> > >>> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy > >>> > >>> Draft Policy ARIN-2016-5 is below and can be found at: > >>> https://www.arin.net/policy/proposals/2016_5.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-5: Post-IPv4-Free-Pool-Depletion Transfer Policy > >>> > >>> Date: 21 June 2016 > >>> > >>> Problem Statement > >>> > >>> Section 4 of the Number Policy Resource Manual was developed over the > past 15+ years primarily to conservatively manage the IPv4 number free > pool. Since the IPv4 free pool was depleted in 2015, the policies which > developed since ARIN's inception may now not be as relevant now that the > primary function of the registry, with regard to IPv4 numbers, is to record > transfers. > >>> > >>> Since section 4 of the NRPM now contains many use cases that are not > as relevant, it makes sense to streamline the transfer process and to > specifically outline the criteria that should be used to process transfers. > >>> > >>> Therefore, we propose the following rewrite of the transfer policy, > section 8 of the NRPM. > >>> > >>> The goals of this rewrite are as follows: > >>> > >>>> Separate the criteria that is found in section 4 of the NRPM from the > transfer process. > >>>> Provide a clear set of criteria that should be applied across all > IPv4 transfers. > >>>> Lower the thresholds on utilization and future allocation size to > negate the necessity of the corner cases which are currently enumerated in > section 4 of the NRPM. > >>>> Reduce the complexity that is currently required for transfers, by > applying simpler utilization criteria for current usage, and future > allocation sizing. > >>> Policy statement: > >>> > >>> Add new section 8.5; update sections 8.2-8.4 as follows to reference > 8.5. > >>> > >>> ###### > >>> > >>> 8.2. Mergers, Acquisitions, and Reorganizations > >>> > >>> ARIN will consider requests for the transfer of number resources in > the case of mergers, acquisitions, and reorganizations under the following > conditions: > >>> > >>>> The current registrant must not be involved in any dispute as to the > status of the resources to be transferred. > >>>> The new entity must sign an RSA covering all resources to be > transferred. > >>>> The resources to be transferred will be subject to ARIN policies. > >>>> The minimum transfer size is the smaller of the original allocation > size or the applicable minimum allocation size in current policy. > >>>> For mergers and acquisition transfers, the recipient entity must > provide evidence that they have acquired assets that use the resources to > be transferred from the current registrant. ARIN will maintain an > up-to-date list of acceptable types of documentation. > >>> ARIN will proceed with processing transfer requests even if the number > resources of the combined organizations exceed what can be justified under > current ARIN transfer policy as defined in section 8.5. In that event, ARIN > will work with the resource holder(s) to transfer the extra number > resources to other organization(s) or accept a voluntary return of the > extra number resources to ARIN. > >>> > >>> 8.3. Transfers between Specified Recipients within the ARIN Region > >>> > >>> In addition to transfers under section 8.2, IPv4 numbers resources and > ASNs may be transferred according to the following conditions. > >>> > >>> Conditions on source of the transfer: > >>> > >>>> The source entity must be the current registered holder of the IPv4 > address resources, and not be involved in any dispute as to the status of > those resources. > >>>> The source entity 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. This restriction does not include M&A > transfers. > >>> Conditions on recipient of the transfer: > >>> > >>>> The recipients must meet the transfer requirements as defined in > section 8.5. > >>>> The resources transferred will be subject to current ARIN policies. > >>> 8.4. Inter-RIR Transfers to Specified Recipients > >>> > >>> Inter-regional transfers may take place only via RIRs who agree to the > transfer and share reciprocal, compatible, needs-based policies. > >>> > >>> Conditions on source of the transfer: > >>> > >>>> The source entity must be the current rights holder of the IPv4 > address resources recognized by the RIR responsible for the resources, and > not be involved in any dispute as to the status of those resources. > >>>> Source entities outside of the ARIN region must meet any requirements > defined by the RIR where the source entity holds the registration. > >>>> 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. This restriction > does not include M&A transfers. > >>> Conditions on recipient of the transfer: > >>> > >>>> The conditions on a recipient outside of the ARIN region will be > defined by the policies of the receiving RIR. > >>>> Recipients within the ARIN region must meet the transfer requirements > as defined in section 8.5. > >>>> Recipients within the ARIN region will be subject to current ARIN > policies. > >>> 8.5. Specified Transfer Recipient Requirements > >>> > >>> 8.5.1. Registration Services Agreement > >>> > >>> Transfer recipients must sign an RSA for the resources being received. > >>> > >>> 8.5.2. Operational Use > >>> > >>> ARIN allocates or assigns blocks of IP addresses to organizations via > transfer solely for the purpose of use on an operational network. > >>> > >>> 8.5.3. Minimum transfer size > >>> > >>> ARIN's minimum transfer size is a /24. > >>> > >>> 8.5.4. Initial block > >>> > >>> Organizations without direct assignments or allocations from ARIN > qualify for transfer of an initial block of ARIN's minimum transfer size. > >>> > >>> 8.5.5. Block size > >>> > >>> Organizations may qualify for the transfer of a larger initial block, > or an additional block, by providing documentation to ARIN which details > the use of at least 50% of the requested block size within 24 months. An > officer of the organization shall attest to the documentation provided to > ARIN. > >>> > >>> 8.5.6. Efficient utilization of previous blocks > >>> > >>> Organizations with direct assignments or allocations from ARIN must > have efficiently utilized at least 50% of every block in order to receive > additional space. This includes all space reassigned to their customers. > >>> > >>> Comments: > >>> > >>> Timetable for implementation: immediately > >>> > >>> Anything else: A redline has been provided to help the community > understand the changes that have been made to the NRPM. > >>> _______________________________________________ > >>> 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. > > > > > > <Post-IPv4 Free-Pool Depletion Transfer Policy (NRPM 8 redline) - > 20160609.pdf>_______________________________________________ > > 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. > -- _______________________________________________________ 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.
