As previously stated, we should revise 4.2.2 to be consistent with 8.5.4. The changes proposed in 2016-3, 2016-4, 2016-5 were all part of a package that intended to:
- create a slow start for transfers (double what you have) - 2016-3 - create a boot strapping for tranfers (first /24 with no justification) - 2016-5 - remove efficent utilization or immedate (30 day) need for ISP initial - 2016-4 - create a boot strapping for initial ISP (first /24 with no justification) - 2016-4 - sync initial ISP w/ no resources, desiring greater than /24 w/ transfers - 2016-4 It is my belief as one of the originators that there was no desire to remove the the time horizion requirement for ISP initial (except for a /24). It is my belief as one of the originators that there was no desire to remove the requirement that ISP with IPv4 space from their upstream need to demonstare efficent utilization. I beleive these are all a side effect of removing the 2.2.2 subsections. 2016-4 is not clear that the sub sections will be removed. On Thu, Feb 1, 2018 at 11:42 AM, Owen DeLong <[email protected]> wrote: > As previously stated, IMHO, we should revise 8.5.4 to be consistent with > 4.2.2. > > Owen > > On Jan 31, 2018, at 13:18 , David Farmer <[email protected]> wrote: > > There seems to be a bit of controversy on the direction to take this > policy. Therefore as the shepherd, it would be helpful to hear from > additional community members regarding this policy. > > Do you support or oppose the policy as written? > > Do you think the inconsistency described in the Problem Statement should > be corrected? > > If yes, should it be corrected by revising by section 8.5.4 to be > consistent with section 4.2.2, as proposed by the current text? > > Or, as an alternative by revising section 4.2.2 to be consistent with > section 8.5.4? > > Are there other alternatives to correct the inconsistency to be considered? > > Other suggestions or comments? > > Your additional feedback and participation are appreciated, thank you. > > On Wed, Jan 24, 2018 at 7:42 AM, ARIN <[email protected]> wrote: > >> The following has been revised: >> >> * Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >> ISP Transfers >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_9.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, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >> ISP Transfers >> >> Problem Statement: >> >> It was noted in the ARIN 40 Policy Experience Report, that there is an >> inconsistency in the initial block size for ISPs. Section 4.2.2 notes that >> the initial ISP block size should be /21 whereas the initial block size in >> 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This >> causes ISP organizations to be approved for different initial block size >> depending on if they first apply for a transfer directly under section 8 or >> if they apply for a block under section 4. This policy is intended to >> clarify this issue, by setting a consistent ISP initial IPv4 block size. It >> was noted that ARIN staff current operational practice is to allow >> qualified ISPs an initial /21 for Section 8 transfers when they first apply >> and are approved under section 4. If an organization applies under section >> 8 first they are initially qualified for a /24; larger allocations require >> additional documentation as noted in 8.5.5. >> >> Policy statement: >> >> Replace section 8.5.4; >> >> 8.5.4. Initial block >> >> Organizations without direct assignments or allocations from ARIN qualify >> for the transfer of an initial IPv4 block, a /24 for assignments or a /24 >> up to a /21 for allocations. >> >> Comments: >> >> Timetable for implementation: Immediate >> >> Anything Else: >> >> The ARIN 40 Policy Experience Report is available at; >> >> Slides: https://www.arin.net/vault/participate/meetings/reports/ARIN >> _40/PDF/PPM/sweeting-policy-experience.pdf >> >> Transcript: https://www.arin.net/vault/participate/meetings/reports/ARIN >> _40/ppm1_transcript.html#anchor_5 >> >> Video: https://www.youtube.com/watch?v=QVsfVMG_6fA >> >> Slides 10 - 13, located in the video from 6:30 to 8:30, are the relevant >> portion of the report, questions from the audience follow. >> _______________________________________________ >> 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. >> > > > > -- > =============================================== > David Farmer Email:[email protected] > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > _______________________________________________ > 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.
