From narten at us.ibm.com Fri Oct 2 00:53:02 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 02 Oct 2015 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201510020453.t924r2pk009060@rotala.raleigh.ibm.com> Total of 64 messages in the last 7 days. script run at: Fri Oct 2 00:53:02 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 21.88% | 14 | 24.59% | 562670 | owen at delong.com 10.94% | 7 | 22.85% | 522919 | bill at tknow.com 10.94% | 7 | 15.06% | 344589 | sryerse at eclipse-networks.com 6.25% | 4 | 5.03% | 115078 | bjones at vt.edu 7.81% | 5 | 2.59% | 59328 | elvis at velea.eu 3.12% | 2 | 5.75% | 131592 | mike at iptrading.com 3.12% | 2 | 4.33% | 99031 | andrew.dul at quark.net 4.69% | 3 | 1.91% | 43745 | stephen at sprunk.org 4.69% | 3 | 1.03% | 23502 | mpetach at netflight.com 1.56% | 1 | 3.92% | 89626 | mm at vr.org 3.12% | 2 | 1.75% | 40025 | droisman at softlayer.com 3.12% | 2 | 1.51% | 34520 | rjletts at uw.edu 3.12% | 2 | 1.46% | 33358 | jcurran at arin.net 1.56% | 1 | 2.49% | 57092 | mwinters at edwardrose.com 1.56% | 1 | 1.94% | 44411 | athompso at athompso.net 1.56% | 1 | 1.06% | 24159 | arin at ics-il.net 1.56% | 1 | 0.59% | 13496 | jrdelacruz at acm.org 1.56% | 1 | 0.41% | 9345 | hannigan at gmail.com 1.56% | 1 | 0.40% | 9111 | springer at inlandnet.com 1.56% | 1 | 0.37% | 8529 | farmer at umn.edu 1.56% | 1 | 0.35% | 7992 | kevinb at thewire.ca 1.56% | 1 | 0.33% | 7455 | narten at us.ibm.com 1.56% | 1 | 0.30% | 6952 | eu at smellmysocks.net --------+------+--------+----------+------------------------ 100.00% | 64 |100.00% | 2288525 | Total From Marla.Azinger at FTR.com Mon Oct 5 14:45:25 2015 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Mon, 5 Oct 2015 18:45:25 +0000 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> Message-ID: Does ARIN staff feel this is needed to support how they asses transfers? Right now I don't support this proposal. Based on experience I don't see a problem. Additionally this could have a side effect of letting larger money endowed entities to purchase more address space faster and deplete the chances smaller entities had on the market. This would shorten the life span of the v4 market. Regards Marla Azinger -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Rob Seastrom Sent: Thursday, August 20, 2015 12:46 PM To: ppml at arin.net Subject: [arin-ppml] Thoughts on 2015-7 Dear Colleagues, It's been almost two months since ARIN 2015-7 was submitted. Anyone have thoughts on "Simplified requirements for demonstrated need for IPv4 transfers"? The AC would love your input. Draft policy text follows: Draft Policy ARIN-2015-7 Simplified requirements for demonstrated need for IPv4 transfers Date: 23 June 2015 Problem statement: ARIN transfer policy currently inherits all its demonstrated need requirements for IPv4 transfers from NRPM sections 4. Because that section was written primarily to deal with free pool allocations, it is much more complicated than is really necessary for transfers. In practice, ARIN staff applies much more lenient needs assessment to section 8 IPv4 transfer requests than to free pool requests, as 24-month needs are much more difficult to assess to the same level of detail. This proposal seeks to dramatically simplify the needs assessment process for 8.3 transfers, while still allowing organizations with corner-case requirements to apply under existing policy if necessary. Policy statement: 8.1.x Simplified requirements for demonstrated need for IPv4 transfers IPv4 transfer recipients must demonstrate (and an officer of the requesting organization must attest) that they will use at least 50% of their aggregate IPv4 addresses (including the requested resources) on an operational network within 24 months. Organizations that do not meet the simplified criteria above may instead demonstrate the need for number resources using the criteria in section 4 of the NRPM. Comments: a. Timetable for implementation: Immediate b. Anything else _______________________________________________ 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. ________________________________ This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. From Marla.Azinger at FTR.com Mon Oct 5 14:55:45 2015 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Mon, 5 Oct 2015 18:55:45 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users In-Reply-To: <55DCBE0D.8010802@arin.net> References: <55DCBE0D.8010802@arin.net> Message-ID: I don't support this based on what I see as a missed opportunity. This policy calls attention to the fact that ARIN should consider removing any difference in policy between End Users and ISPs. I agree this proposal has valid case use scenarios, however it just leaves me thinking only one "class" is needed and not two. One policy for all. Regards Marla Azinger -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Tuesday, August 25, 2015 12:12 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users Draft Policy ARIN-2015-8 Reassignment records for IPv4 End-Users On 20 August 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-222 Reassignment records for IPv4 End-Users" as a Draft Policy. Draft Policy ARIN-2015-8 is below and can be found at: https://www.arin.net/policy/proposals/2015_8.html You are encouraged to discuss the merits and your concerns of Draft Policy 2015-8 on the Public Policy Mailing List. 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 PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (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-2015-8 Reassignment records for IPv4 End-Users Date: 25 August 2015 Problem statement: End-User Organizations do not have the ability to create reassignment records in the number resource database. Reassignment records can be used for a number of different functions which could benefit the overall desire to increase database accuracy by allowing organizations to add additional details in the database. The following reasons have been noted as positive reasons to allow the creation of additional records. - Geolocation (allows an organization to specify a different location within the database which is used by organizations creating geo-location by IP address databases) - Subsidiary reassignment (allows an organization to note that a portion of their netblock is in use by a different subsidiary entity) - Assignment to contracted parties (some organizations have contracts with other organizations which are operating networks under agreements with the registrant, this allows the top-level organizations to accurately specify the organization operating the network in the number resource database) - More specific contact information (some organizations operate large networks which don't necessarily have the same technical or abuse contact information) Policy statement: Create new section 4.3.x End-user organizations which have an active registration services agreement shall be permitted to create reassignment records in the number resource database. Organizations shall use the guidelines outlined in section 4.2.3 when creating reassignment records. Comments: a. Timetable for implementation: immediately b. Anything else: It is noted by the author of this policy proposal that one of the distinctions in the service between ISPs and End-Users has been the ability for an organization to create reassignment records. This policy proposal stretches across responsibilities areas as it impacts number policy, ARIN operational practice, and fees. Below we have noted the three areas and the different responsibilities: A) Providing reassignment support for end-user assignments, for those who wish to use it This is an ARIN Service issue - could be an suggestion/consultation process, so long as any implied additional workload/cost can be accommodated in budget and the community supports B) New requirement on end-users to provide reassignment information in certain circumstances so that ARIN will treat their usage assertion credibly This is a policy issue. These requirements should be vetted through the policy development process. C) Fee Implications of ISPs moving to end-user category This is Board issue, but first requires a community discussion or consultation to be held to solicit community input on desired outcome. _______________________________________________ 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. ________________________________ This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. From Marla.Azinger at FTR.com Mon Oct 5 15:10:15 2015 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Mon, 5 Oct 2015 19:10:15 +0000 Subject: [arin-ppml] ARIN Board members In-Reply-To: References: <55AD24C8.4080604@linuxmagic.com> <4DA79C63-A86F-4355-BF97-FD2EC9317F47@corp.arin.net> <48BB17A1-C89E-41F7-9B01-DD7693390C2D@pch.net> Message-ID: I agree with this concern (and have shared it for some time now) and support trying to come up with a way to measure effectiveness of individuals on the BOT. This particular idea could be carried out in text as well. Video is entertaining for analysis reasons but text would be simple. Regards Marla Azinger -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: Wednesday, July 22, 2015 10:29 AM To: ARIN PPML (ppml at arin.net) Subject: Re: [arin-ppml] ARIN Board members > I wasn?t criticizing your suggestion, I?m sure the current process can > be improved (and this is a great time to do so, since we?re right at > the beginning of the nomcom process for this year). I just wanted to > try to get the gist of what you felt needed to be prioritized. So picture a video (+transcript). David sits down in front of a camera and talks with Bill Woodcock, incumbent BoT member who is running for re-election. We have a talk for about 30 minutes on a wide range of issues, including things like: - what have you accomplished over your current term on the Board? - what needs to improve that you're willing to drive? - what are your key deliverables for the next term you're running for? How will we measure those deliverables, and whether you succeeded or failed? There's also talk about the Board in general, ARIN in general, and our future -- some along the lines of what's in the questionnaire today, but in a freer environment where there's more back and forth about the answers that are given. Would that be helpful if such a video(+transcript) series existed? _______________________________________________ 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. ________________________________ This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. From Marla.Azinger at FTR.com Mon Oct 5 15:21:35 2015 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Mon, 5 Oct 2015 19:21:35 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: <5564C245.7050207@arin.net> References: <5564C245.7050207@arin.net> Message-ID: PPML discussion on this appeared to go several directions. Based on interpretation of the published text only, this is what I see. It needs to retain "This restriction does not include M&A transfers." I think the real goal here is to permit address movement of address space when needed and at the same time remove any address gaming. Should the 12 month restrictions be in play dependent on the free pool status of course, Another way to write a guiding principle on this is: "Source entities within the ARIN region will be restricted from transferring address space within 12 months of its most recent transfer, allocation or assignment barring reasonable business requirements." I suggest this because there is no reasonable way to document and cover every logical and reasonable business angle that has and will reveal itself. It's not possible to write policy that tightly dictates every maneuver. There is a point where policy needs to be written as a guiding principle and then let ARIN staff make decisions based on facts and our guiding principles. I have felt this text has over reached since day one and since then I have witnessed several business cases effected that are logical and in no way "gaming ip addresses and the market". Regards Marla Azinger -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Tuesday, May 26, 2015 11:58 AM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Draft Policy ARIN-2015-2 Modify 8.4 (Inter-RIR Transfers to Specified Recipients) On 21 May 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-216 Modify 8.4 (Inter-RIR Transfers to Specified Recipients)" as a Draft Policy. Draft Policy ARIN-2015-2 is below and can be found at: https://www.arin.net/policy/proposals/2015_2.html You are encouraged to discuss the merits and your concerns of Draft Policy 2015-2 on the Public Policy Mailing List. 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 PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (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-2015-2 Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Date: 26 May 2015 Problem Statement: Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt. Policy statement: Replace 8.4, bullet 4, to read: "Source entities within the ARIN region must not have received an allocation or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request." Comments: The intention of this change is to allow organizations to perform inter-RIR transfers of space received via an 8.3 transfer regardless of the date transferred to ARIN . A common example is that an organization acquires a block located in the ARIN region, transfers it to ARIN, then 3 months later, the organization announces that it wants to launch new services out of region. Under current policy, the organization is prohibited from moving some or all of those addresses to that region's Whois; the numbers are locked in ARIN's Whois. It's important to note that 8.3 transfers are approved for a 24 month supply, and it would not be unheard of for a business model to change within the first 12 months after approval. In addition this will not affect the assignments and allocations issued by ARIN they will still be subject to the 12 month restriction. a. Timetable for implementation: Immediate b. Anything else _______________________________________________ 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. ________________________________ This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. From Marla.Azinger at FTR.com Mon Oct 5 15:24:31 2015 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Mon, 5 Oct 2015 19:24:31 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy In-Reply-To: <5564C252.4060904@arin.net> References: <5564C252.4060904@arin.net> Message-ID: I don't support this proposal. I believe if restrictions are removed, then both End User and ISP should be aligned entirely. One policy for all. Regards Marla Azinger -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Tuesday, May 26, 2015 11:58 AM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy Draft Policy ARIN-2015-3 Remove 30 day utilization requirement in end-user IPv4 policy On 21 May 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-217 Remove 30 day utilization requirement in end-user IPv4 policy" as a Draft Policy. Draft Policy ARIN-2015-3 is below and can be found at: https://www.arin.net/policy/proposals/2015_3.html You are encouraged to discuss the merits and your concerns of Draft Policy 2015-3 on the Public Policy Mailing List. 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 PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (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-2015-3 Remove 30 day utilization requirement in end-user IPv4 policy Date: 26 May 2015 Problem Statement: End-user policy is intended to provide end-users with a one year supply of IP addresses. Qualification for a one-year supply requires the network operator to utilize at least 25% of the requested addresses within 30 days. This text is unrealistic and should be removed. First, it often takes longer than 30 days to stage equipment and start actually using the addresses. Second, growth is often not that regimented; the forecast is to use X addresses over the course of a year, not to use 25% of X within 30 days. Third, this policy text applies to additional address space requests. It is incompatible with the requirements of other additional address space request justification which indicates that 80% utilization of existing space is sufficient to justify new space. If a block is at 80%, then often (almost always?) the remaining 80% will be used over the next 30 days and longer. Therefore the operator cannot honestly state they will use 25% of the ADDITIONAL space within 30 days of receiving it; they're still trying to use their older block efficiently. Fourth, in the face of ARIN exhaustion, some ISPs are starting to not give out /24 (or larger) blocks. So the justification for the 25% rule that previously existed (and in fact, applied for many years) is no longer germane. Policy statement: Remove the 25% utilization criteria bullet point from NRPM 4.3.3. Comments: a.Timetable for implementation: Immediate b.Anything else _______________________________________________ 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. ________________________________ This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. From Marla.Azinger at FTR.com Mon Oct 5 15:26:34 2015 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Mon, 5 Oct 2015 19:26:34 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations In-Reply-To: <55AE8268.2090107@arin.net> References: <55AE8268.2090107@arin.net> Message-ID: It looks like all that was changed was they added the word ?re-organization?. Am I missing some other text change? Regards Marla Azinger -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Tuesday, July 21, 2015 10:33 AM To: arin-ppml at arin.net Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations Recommended Draft Policy ARIN-2015-4 Modify 8.2 section to better reflect how ARIN handles reorganizations On 16 July 2015 the ARIN Advisory Council (AC) recommended ARIN-2015-4 for adoption, making it a Recommended Draft Policy. ARIN-2015-4 is below and can be found at: https://www.arin.net/policy/proposals/2015_4.html You are encouraged to discuss Draft Policy 2015-4 on the PPML prior to the ARIN Public Policy Consultation at ARIN 36 in Montreal in October 2015. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process 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) ## * ## Recommended Draft Policy ARIN-2015-4 Modify 8.2 section to better reflect how ARIN handles reorganizations Date: 21 July 2015 AC's assessment of conformance with the Principles of Internet Number Resource Policy: 2015-4 is largely editorial in nature and does not change policy implementation, but clarifies existing use of policy. The proposal is fair in that it provides a consistent interface for transfers and clarifies the transfer policy. It is technically sound in that it is already effectively implemented. The proposal has received support on the mailing list and we expect it to be generally supported by the community as it is the direct result of community feed back on the existing policy. Problem Statement: ARIN staff indicated that NRPM 8.2 does not clearly indicate how ARIN procedures handle reorganizations. ARIN staff indicated that the first policy bullet point does not apply to reorganizations. Policy statement: Replacement text for entire 8.2 section: 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. In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy. Comments: The problem statement is addressed by: -re-title 8.2 -clarify the documentation bullet point -rearrange the documentation bullet to the end of the list since it only applies to some requestors, while the other bullet points apply to all requestors. a.Timetable for implementation: Immediate b.Anything else ##### ARIN STAFF & LEGAL ASSESSMENT Draft Policy ARIN-2015-4 Modify 8.2 section to better reflect how ARIN handles reorganizations https://www.arin.net/policy/proposals/2015_4.html Date of Assessment: July 14, 2015 ___ 1. Summary (Staff Understanding) This proposal would provide clarification to the 8.2 transfer policy for reorganizations. It does this by adding "reorganizations" to the title, and clarifies that evidence of acquired assets is only required for merger and acquisition transfers; not reorganizations. ___ 2. Comments A. ARIN Staff Comments This proposal can be implemented as written. Minimal staff training and preparation would be needed to implement this if it were to become policy. The proposal clarifies a point about reorganizations that has been confusing to customers in the past. We see no negative impacts. B. ARIN General Counsel ? Legal Assessment Counsel sees no material legal issues in this policy. ___ 3. Resource Impact This policy would require minimal staff training and preparation. We see no negative impacts. ___ 4. Proposal / Draft Policy Text Assessed Draft Policy ARIN-2015-4 Modify 8.2 section to better reflect how ARIN handles reorganizations Problem Statement: ARIN staff indicated that NRPM 8.2 does not clearly indicate how ARIN procedures handle reorganizations. ARIN staff indicated that the first policy bullet point does not apply to reorganizations. Policy statement: Replacement text for entire 8.2 section: 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. In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy. Comments: The problem statement is addressed by: -re-title 8.2 -clarify the documentation bullet point -rearrange the documentation bullet to the end of the list since it only applies to some requestors, while the other bullet points apply to all requestors. a.Timetable for implementation: Immediate b.Anything else _______________________________________________ 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. ________________________________ This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. From scottleibrand at gmail.com Mon Oct 5 15:29:17 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 5 Oct 2015 12:29:17 -0700 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> Message-ID: Reducing the burden on ARIN staff is not part of the problem statement for this proposal (though it might be a side effect, depending on how they implement it). The main goal here is to reduce the administrative burden on organizations who need to acquire IPv4 space via transfer. That burden may actually be higher for smaller entities who don't have experience with and processes in place for jumping through ARIN's hoops. I don't think this policy would have much impact on the ability of large well-funded entities to purchase as much address space as they like. Currently, those organizations simply write a contract that gives them full rights to the address space they're buying, and allows them to transfer the space with ARIN whenever they are ready to put it into use on their network (or can otherwise pass ARIN's needs justification tests). -Scott On Mon, Oct 5, 2015 at 11:45 AM, Azinger, Marla wrote: > Does ARIN staff feel this is needed to support how they asses transfers? > > Right now I don't support this proposal. Based on experience I don't see > a problem. > > Additionally this could have a side effect of letting larger money endowed > entities to purchase more address space faster and deplete the chances > smaller entities had on the market. This would shorten the life span of > the v4 market. > > Regards > Marla Azinger > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Rob Seastrom > Sent: Thursday, August 20, 2015 12:46 PM > To: ppml at arin.net > Subject: [arin-ppml] Thoughts on 2015-7 > > > Dear Colleagues, > > It's been almost two months since ARIN 2015-7 was submitted. Anyone have > thoughts on "Simplified requirements for demonstrated need for IPv4 > transfers"? > > The AC would love your input. > > Draft policy text follows: > > Draft Policy ARIN-2015-7 > Simplified requirements for demonstrated need for IPv4 transfers > > Date: 23 June 2015 > > Problem statement: > > ARIN transfer policy currently inherits all its demonstrated need > requirements for IPv4 transfers from NRPM sections 4. Because that section > was written primarily to deal with free pool allocations, it is much more > complicated than is really necessary for transfers. In practice, ARIN staff > applies much more lenient needs assessment to section 8 IPv4 transfer > requests than to free pool requests, as 24-month needs are much more > difficult to assess to the same level of detail. > > This proposal seeks to dramatically simplify the needs assessment process > for 8.3 transfers, while still allowing organizations with corner-case > requirements to apply under existing policy if necessary. > > Policy statement: > > 8.1.x Simplified requirements for demonstrated need for IPv4 transfers > > IPv4 transfer recipients must demonstrate (and an officer of the > requesting organization must attest) that they will use at least 50% of > their aggregate IPv4 addresses (including the requested resources) on an > operational network within 24 months. > > Organizations that do not meet the simplified criteria above may instead > demonstrate the need for number resources using the criteria in section > 4 of the NRPM. > > Comments: > > a. Timetable for implementation: Immediate > > b. Anything else > > > > > _______________________________________________ > 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. > > ________________________________ > > This communication is confidential. Frontier only sends and receives email > on the basis of the terms set out at > http://www.frontier.com/email_disclaimer. > _______________________________________________ > 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: From farmer at umn.edu Mon Oct 5 15:39:01 2015 From: farmer at umn.edu (David Farmer) Date: Mon, 5 Oct 2015 14:39:01 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users In-Reply-To: References: <55DCBE0D.8010802@arin.net> Message-ID: <5612D1D5.1000906@umn.edu> Marla, From a strategic point of view I agree that we should move to a one policy for everyone model. However, every time we try all-encompassing strategic changes, people say they are too big of a change all at once, and tell us to break them up. When we brake them up into manageable size chunks, the individual changes don't get support because people don't want to see half-measures they want strategic level changes. This is a catch 22. We need to find a way to move forward. How would you suggest we do that? Thanks. On 10/5/15 13:55 , Azinger, Marla wrote: > I don't support this based on what I see as a missed opportunity. This policy calls attention to the fact that ARIN should consider removing any difference in policy between End Users and ISPs. I agree this proposal has valid case use scenarios, however it just leaves me thinking only one "class" is needed and not two. One policy for all. > > Regards > Marla Azinger > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN > Sent: Tuesday, August 25, 2015 12:12 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users > > Draft Policy ARIN-2015-8 > Reassignment records for IPv4 End-Users > > On 20 August 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-222 Reassignment records for IPv4 End-Users" as a Draft Policy. > > Draft Policy ARIN-2015-8 is below and can be found at: > https://www.arin.net/policy/proposals/2015_8.html > > You are encouraged to discuss the merits and your concerns of Draft Policy 2015-8 on the Public Policy Mailing List. > > 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 PDP. Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The ARIN Policy Development Process (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-2015-8 > Reassignment records for IPv4 End-Users > > Date: 25 August 2015 > > Problem statement: > > End-User Organizations do not have the ability to create reassignment records in the number resource database. > > Reassignment records can be used for a number of different functions which could benefit the overall desire to increase database accuracy by allowing organizations to add additional details in the database. > > The following reasons have been noted as positive reasons to allow the creation of additional records. > - Geolocation (allows an organization to specify a different location within the database which is used by organizations creating geo-location by IP address databases) > - Subsidiary reassignment (allows an organization to note that a portion of their netblock is in use by a different subsidiary entity) > - Assignment to contracted parties (some organizations have contracts with other organizations which are operating networks under agreements with the registrant, this allows the top-level organizations to accurately specify the organization operating the network in the number resource database) > - More specific contact information (some organizations operate large networks which don't necessarily have the same technical or abuse contact information) > > Policy statement: > > Create new section 4.3.x > > End-user organizations which have an active registration services agreement shall be permitted to create reassignment records in the number resource database. Organizations shall use the guidelines outlined in section 4.2.3 when creating reassignment records. > > Comments: > a. Timetable for implementation: immediately b. Anything else: > > It is noted by the author of this policy proposal that one of the distinctions in the service between ISPs and End-Users has been the ability for an organization to create reassignment records. > > This policy proposal stretches across responsibilities areas as it impacts number policy, ARIN operational practice, and fees. > > Below we have noted the three areas and the different responsibilities: > > A) Providing reassignment support for end-user assignments, for those who wish to use it > > This is an ARIN Service issue - could be an suggestion/consultation process, so long as any implied additional workload/cost can be accommodated in budget and the community supports > > B) New requirement on end-users to provide reassignment information in certain circumstances so that ARIN will treat their usage assertion credibly > > This is a policy issue. These requirements should be vetted through the policy development process. > > C) Fee Implications of ISPs moving to end-user category > > This is Board issue, but first requires a community discussion or consultation to be held to solicit community input on desired outcome. > _______________________________________________ > 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. > > ________________________________ > > This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. > _______________________________________________ > 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. > -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From farmer at umn.edu Mon Oct 5 15:45:58 2015 From: farmer at umn.edu (David Farmer) Date: Mon, 5 Oct 2015 14:45:58 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy In-Reply-To: References: <5564C252.4060904@arin.net> Message-ID: <5612D376.7020304@umn.edu> Again, philosophically I agree with the one policy for all mantra, but how do we get there. I believe the intent of the author is to find bite size chunks to move is toward a one policy for all model. Thanks. On 10/5/15 14:24 , Azinger, Marla wrote: > I don't support this proposal. I believe if restrictions are removed, then both End User and ISP should be aligned entirely. One policy for all. > > Regards > Marla Azinger > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN > Sent: Tuesday, May 26, 2015 11:58 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy > > Draft Policy ARIN-2015-3 > Remove 30 day utilization requirement in end-user IPv4 policy > > On 21 May 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-217 Remove 30 day utilization requirement in end-user IPv4 policy" as a Draft Policy. > > Draft Policy ARIN-2015-3 is below and can be found at: > https://www.arin.net/policy/proposals/2015_3.html > > You are encouraged to discuss the merits and your concerns of Draft Policy 2015-3 on the Public Policy Mailing List. > > 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 PDP. Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The ARIN Policy Development Process (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-2015-3 > Remove 30 day utilization requirement in end-user IPv4 policy > > Date: 26 May 2015 > > Problem Statement: > > End-user policy is intended to provide end-users with a one year supply of IP addresses. Qualification for a one-year supply requires the network operator to utilize at least 25% of the requested addresses within 30 days. This text is unrealistic and should be removed. > > First, it often takes longer than 30 days to stage equipment and start actually using the addresses. > > Second, growth is often not that regimented; the forecast is to use X addresses over the course of a year, not to use 25% of X within 30 days. > > Third, this policy text applies to additional address space requests. It is incompatible with the requirements of other additional address space request justification which indicates that 80% utilization of existing space is sufficient to justify new space. If a block is at 80%, then often (almost always?) the remaining 80% will be used over the next 30 days and longer. Therefore the operator cannot honestly state they will use 25% of the ADDITIONAL space within 30 days of receiving it; they're still trying to use their older block efficiently. > > Fourth, in the face of ARIN exhaustion, some ISPs are starting to not give out /24 (or larger) blocks. So the justification for the 25% rule that previously existed (and in fact, applied for many years) is no longer germane. > > Policy statement: > > Remove the 25% utilization criteria bullet point from NRPM 4.3.3. > > Comments: > > a.Timetable for implementation: Immediate > > b.Anything else > _______________________________________________ > 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. > > ________________________________ > > This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. > _______________________________________________ > 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. > -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From Marla.Azinger at FTR.com Mon Oct 5 15:50:44 2015 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Mon, 5 Oct 2015 19:50:44 +0000 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> Message-ID: I?ve seen it from all sizes. I don?t see an issue. If a large quantity of people stand up and say they struggle. I?ll be surprised. And the assumption its easier for larger entities than smaller is very off base. I?ve managed a variety of entity sizes and there are different variables at all levels that really create a level playing field. And not everyone has the same contracts. I?ve seen a variety and in those varieties there can also be contingencies. That said, if the majority of people stand up and say it?s too difficult. Then so be it. Regards Marla Azinger From: Scott Leibrand [mailto:scottleibrand at gmail.com] Sent: Monday, October 05, 2015 12:29 PM To: Azinger, Marla Cc: Rob Seastrom ; ppml at arin.net Subject: Re: [arin-ppml] Thoughts on 2015-7 Reducing the burden on ARIN staff is not part of the problem statement for this proposal (though it might be a side effect, depending on how they implement it). The main goal here is to reduce the administrative burden on organizations who need to acquire IPv4 space via transfer. That burden may actually be higher for smaller entities who don't have experience with and processes in place for jumping through ARIN's hoops. I don't think this policy would have much impact on the ability of large well-funded entities to purchase as much address space as they like. Currently, those organizations simply write a contract that gives them full rights to the address space they're buying, and allows them to transfer the space with ARIN whenever they are ready to put it into use on their network (or can otherwise pass ARIN's needs justification tests). -Scott On Mon, Oct 5, 2015 at 11:45 AM, Azinger, Marla > wrote: Does ARIN staff feel this is needed to support how they asses transfers? Right now I don't support this proposal. Based on experience I don't see a problem. Additionally this could have a side effect of letting larger money endowed entities to purchase more address space faster and deplete the chances smaller entities had on the market. This would shorten the life span of the v4 market. Regards Marla Azinger -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Rob Seastrom Sent: Thursday, August 20, 2015 12:46 PM To: ppml at arin.net Subject: [arin-ppml] Thoughts on 2015-7 Dear Colleagues, It's been almost two months since ARIN 2015-7 was submitted. Anyone have thoughts on "Simplified requirements for demonstrated need for IPv4 transfers"? The AC would love your input. Draft policy text follows: Draft Policy ARIN-2015-7 Simplified requirements for demonstrated need for IPv4 transfers Date: 23 June 2015 Problem statement: ARIN transfer policy currently inherits all its demonstrated need requirements for IPv4 transfers from NRPM sections 4. Because that section was written primarily to deal with free pool allocations, it is much more complicated than is really necessary for transfers. In practice, ARIN staff applies much more lenient needs assessment to section 8 IPv4 transfer requests than to free pool requests, as 24-month needs are much more difficult to assess to the same level of detail. This proposal seeks to dramatically simplify the needs assessment process for 8.3 transfers, while still allowing organizations with corner-case requirements to apply under existing policy if necessary. Policy statement: 8.1.x Simplified requirements for demonstrated need for IPv4 transfers IPv4 transfer recipients must demonstrate (and an officer of the requesting organization must attest) that they will use at least 50% of their aggregate IPv4 addresses (including the requested resources) on an operational network within 24 months. Organizations that do not meet the simplified criteria above may instead demonstrate the need for number resources using the criteria in section 4 of the NRPM. Comments: a. Timetable for implementation: Immediate b. Anything else _______________________________________________ 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. ________________________________ This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. _______________________________________________ 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: From scottleibrand at gmail.com Mon Oct 5 15:56:34 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 5 Oct 2015 12:56:34 -0700 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> Message-ID: I think the threshold is "unnecessarily difficult" rather than "too difficult". If we didn't have NRPM section 4 already, and had to set up rules for needs assessment for transfers, I think we would end up with something a lot closer to this draft policy than to the current section 4. If so, that would indicate that all the extra requirements in section 4 are probably no longer serving a useful function, and just making transfer recipients' life unnecessarily difficult. -Scott On Mon, Oct 5, 2015 at 12:50 PM, Azinger, Marla wrote: > I?ve seen it from all sizes. I don?t see an issue. If a large quantity > of people stand up and say they struggle. I?ll be surprised. And the > assumption its easier for larger entities than smaller is very off base. > I?ve managed a variety of entity sizes and there are different variables at > all levels that really create a level playing field. > > > > And not everyone has the same contracts. I?ve seen a variety and in those > varieties there can also be contingencies. > > > > That said, if the majority of people stand up and say it?s too difficult. > Then so be it. > > > > Regards > > Marla Azinger > > > > > > *From:* Scott Leibrand [mailto:scottleibrand at gmail.com] > *Sent:* Monday, October 05, 2015 12:29 PM > *To:* Azinger, Marla > *Cc:* Rob Seastrom ; ppml at arin.net > *Subject:* Re: [arin-ppml] Thoughts on 2015-7 > > > > Reducing the burden on ARIN staff is not part of the problem statement for > this proposal (though it might be a side effect, depending on how they > implement it). The main goal here is to reduce the administrative burden > on organizations who need to acquire IPv4 space via transfer. That burden > may actually be higher for smaller entities who don't have experience with > and processes in place for jumping through ARIN's hoops. > > > > I don't think this policy would have much impact on the ability of large > well-funded entities to purchase as much address space as they like. > Currently, those organizations simply write a contract that gives them full > rights to the address space they're buying, and allows them to transfer the > space with ARIN whenever they are ready to put it into use on their network > (or can otherwise pass ARIN's needs justification tests). > > > > -Scott > > > > > > On Mon, Oct 5, 2015 at 11:45 AM, Azinger, Marla > wrote: > > Does ARIN staff feel this is needed to support how they asses transfers? > > Right now I don't support this proposal. Based on experience I don't see > a problem. > > Additionally this could have a side effect of letting larger money endowed > entities to purchase more address space faster and deplete the chances > smaller entities had on the market. This would shorten the life span of > the v4 market. > > Regards > Marla Azinger > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Rob Seastrom > Sent: Thursday, August 20, 2015 12:46 PM > To: ppml at arin.net > Subject: [arin-ppml] Thoughts on 2015-7 > > Dear Colleagues, > > It's been almost two months since ARIN 2015-7 was submitted. Anyone have > thoughts on "Simplified requirements for demonstrated need for IPv4 > transfers"? > > The AC would love your input. > > Draft policy text follows: > > Draft Policy ARIN-2015-7 > Simplified requirements for demonstrated need for IPv4 transfers > > Date: 23 June 2015 > > Problem statement: > > ARIN transfer policy currently inherits all its demonstrated need > requirements for IPv4 transfers from NRPM sections 4. Because that section > was written primarily to deal with free pool allocations, it is much more > complicated than is really necessary for transfers. In practice, ARIN staff > applies much more lenient needs assessment to section 8 IPv4 transfer > requests than to free pool requests, as 24-month needs are much more > difficult to assess to the same level of detail. > > This proposal seeks to dramatically simplify the needs assessment process > for 8.3 transfers, while still allowing organizations with corner-case > requirements to apply under existing policy if necessary. > > Policy statement: > > 8.1.x Simplified requirements for demonstrated need for IPv4 transfers > > IPv4 transfer recipients must demonstrate (and an officer of the > requesting organization must attest) that they will use at least 50% of > their aggregate IPv4 addresses (including the requested resources) on an > operational network within 24 months. > > Organizations that do not meet the simplified criteria above may instead > demonstrate the need for number resources using the criteria in section > 4 of the NRPM. > > Comments: > > a. Timetable for implementation: Immediate > > b. Anything else > > > > > _______________________________________________ > 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. > > ________________________________ > > This communication is confidential. Frontier only sends and receives email > on the basis of the terms set out at > http://www.frontier.com/email_disclaimer. > > _______________________________________________ > 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: From hannigan at gmail.com Mon Oct 5 16:07:50 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 5 Oct 2015 16:07:50 -0400 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> Message-ID: On Mon, Oct 5, 2015 at 3:29 PM, Scott Leibrand wrote: > Reducing the burden on ARIN staff is not part of the problem statement for > this proposal (though it might be a side effect, depending on how they > implement it). The main goal here is to reduce the administrative burden > on organizations who need to acquire IPv4 space via transfer. That burden > may actually be higher for smaller entities who don't have experience with > and processes in place for jumping through ARIN's hoops. > > I don't think this policy would have much impact on the ability of large > well-funded entities to purchase as much address space as they like. > Currently, those organizations simply write a contract that gives them full > rights to the address space they're buying, and allows them to transfer the > space with ARIN whenever they are ready to put it into use on their network > (or can otherwise pass ARIN's needs justification tests). > > > Let me give you a real world example. 1. Buy rights to use addresses in any quantity you believe you need 2. Use those addresses as you need them, assuming the agreement you made with the party works properly 3. Get an LOA from the documented owner 4. Bypass ARIN entirely 5. Use the addresses. How do you think we should solve that problem? Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Mon Oct 5 16:29:24 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Mon, 5 Oct 2015 20:29:24 +0000 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> Message-ID: I don?t understand why everyone wants to keep blocking all outside of ARIN transactions. A year from now there might be a thousand or more legitimate organizations that meet one or more of the current policies to qualify for an IPv4 allocation. Let?s say that is your Org or your Customer?s Org - and ARIN dutifully places you on their waiting list. Time passes and no significant supply comes available for your request. So then what do you do? ARIN can?t fulfill your request timely. You have a legitimate need. If IPv6 won?t work, Is living without the resources you need really acceptable? If not do you break down and call a Broker to help find you the resources that you need? Why does this community continually paint organizations into the corner of not being able to get IPv4 resources without going outside of ARINs policies? John asked this community to visit the issue of runout several months ago, and there was some discussion but I?ve seen no real will to make any significant adjustments to try and deal with the new world we all must live in now. We can keep rearranging deck chairs on the Titanic, or we can face reality that times have completely changed and the old rules won?t work in a new ARIN world. My 2 cents. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan Sent: Monday, October 5, 2015 4:08 PM To: Scott Leibrand Cc: ppml at arin.net Subject: Re: [arin-ppml] Thoughts on 2015-7 On Mon, Oct 5, 2015 at 3:29 PM, Scott Leibrand > wrote: Reducing the burden on ARIN staff is not part of the problem statement for this proposal (though it might be a side effect, depending on how they implement it). The main goal here is to reduce the administrative burden on organizations who need to acquire IPv4 space via transfer. That burden may actually be higher for smaller entities who don't have experience with and processes in place for jumping through ARIN's hoops. I don't think this policy would have much impact on the ability of large well-funded entities to purchase as much address space as they like. Currently, those organizations simply write a contract that gives them full rights to the address space they're buying, and allows them to transfer the space with ARIN whenever they are ready to put it into use on their network (or can otherwise pass ARIN's needs justification tests). Let me give you a real world example. 1. Buy rights to use addresses in any quantity you believe you need 2. Use those addresses as you need them, assuming the agreement you made with the party works properly 3. Get an LOA from the documented owner 4. Bypass ARIN entirely 5. Use the addresses. How do you think we should solve that problem? Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From scottleibrand at gmail.com Mon Oct 5 16:30:36 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 5 Oct 2015 13:30:36 -0700 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> Message-ID: I believe we should make it easy to: 1. Make an agreement to acquire addresses in the quantity you believe you need. 2. If that agreement brings your total address holdings to less than 2x your current or 24-month projected usage, get easy approval for the transfer from ARIN under the Simplified requirements for demonstrated need for IPv4 transfers defined in this draft policy. 3. Skip the LOA and ongoing legal stuff. 4. Use the addresses. -Scott On Mon, Oct 5, 2015 at 1:07 PM, Martin Hannigan wrote: > > > On Mon, Oct 5, 2015 at 3:29 PM, Scott Leibrand > wrote: > >> Reducing the burden on ARIN staff is not part of the problem statement >> for this proposal (though it might be a side effect, depending on how they >> implement it). The main goal here is to reduce the administrative burden >> on organizations who need to acquire IPv4 space via transfer. That burden >> may actually be higher for smaller entities who don't have experience with >> and processes in place for jumping through ARIN's hoops. >> >> I don't think this policy would have much impact on the ability of large >> well-funded entities to purchase as much address space as they like. >> Currently, those organizations simply write a contract that gives them full >> rights to the address space they're buying, and allows them to transfer the >> space with ARIN whenever they are ready to put it into use on their network >> (or can otherwise pass ARIN's needs justification tests). >> >> >> > > Let me give you a real world example. > > 1. Buy rights to use addresses in any quantity you believe you need > 2. Use those addresses as you need them, assuming the agreement you made > with the party works properly > 3. Get an LOA from the documented owner > 4. Bypass ARIN entirely > 5. Use the addresses. > > How do you think we should solve that problem? > > > Best, > > -M< > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Oct 5 16:40:51 2015 From: jcurran at arin.net (John Curran) Date: Mon, 5 Oct 2015 20:40:51 +0000 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> Message-ID: On Oct 5, 2015, at 4:07 PM, Martin Hannigan wrote: > > Let me give you a real world example. > > 1. Buy rights to use addresses in any quantity you believe you need > 2. Use those addresses as you need them, assuming the agreement you made with the party works properly > 3. Get an LOA from the documented owner > 4. Bypass ARIN entirely > 5. Use the addresses. > > How do you think we should solve that problem? It is not my job to determine whether the example above is a major problem (or not) - that?s for the community to assess, but I do want to highlight some aspects that result from situations (such as the one described above) of which everyone on the list might not be aware - 1) While the network operations confusion that can result is fairly well understood to those on this list, what may not be apparently is that there are others who rely upon the registry (e.g. researchers, anti-spam folks, law enforcement, etc.) and for whom address blocks being used as described above results in real impacts to their ability to rely upon the registry, and thus accomplish their job. 2) Because the ?documented owner? doesn?t ever update the registry, a number of creative schemes are possible whereby the documented owner gets paid from multiple parties for the same rights and then effectively disappears with their proceeds leaving the individual buyers to fight it out. There are ways to reduce this risk (e.g. escrow arrangements, guarantees with adequate backing, etc.) but the need for these (and probability of circumvention) goes up dramatically absent an updated registry. Likewise for the case where the ?documented owner? doesn?t actually have a documentation trail that would support their ability to sell the rights to even one party, but that is not uncovered since the documentation never gets reviewed by the registry. I have not seen a clear expression of these cases on the list, and felt it important to describe them for those who may not have first hand involvement. It is true that under 2015-7, parties would be able to obtain more address space then presently allowed and to so do based upon an officer representation, so the risks that such a change would bring about should be carefully weighted by the community against the situations outlined above which exist under the status quo. Thanks, /John John Curran President and CEO ARIN From matthew at matthew.at Mon Oct 5 17:27:42 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 5 Oct 2015 14:27:42 -0700 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> Message-ID: <5612EB4E.7040603@matthew.at> On 10/5/2015 1:07 PM, Martin Hannigan wrote: > > > Let me give you a real world example. > > 1. Buy rights to use addresses in any quantity you believe you need > 2. Use those addresses as you need them, assuming the agreement you > made with the party works properly > 3. Get an LOA from the documented owner > 4. Bypass ARIN entirely > 5. Use the addresses. > > How do you think we should solve that problem? How about another real-world example (several of these in play that I know of) 1. Enter into a contract to acquire addresses in any quantity you believe you need (or more) 2. Not use the addresses right now, but know that you have as many as you want locked up from that seller, who can't sell to anyone else now 3. Transfer the addresses if/when ARIN policy permits 4. Use the addresses. There is absolutely nothing in the current needs-based policy that ensures that entities that failed to plan for IPv4 runout and do not have sufficient cash to bid against entities engaged in this sort of practice will be able to get IPv4 addresses on the transfer market. And there is nothing about removing needs basis from the transfer policy that will change that. The game is already over, why insist on policies that no longer make any sense in the current environment? Matthew Kaufman From matthew at matthew.at Mon Oct 5 17:36:28 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 5 Oct 2015 14:36:28 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: <5612ED5C.40808@matthew.at> On 9/24/2015 8:46 PM, Richard J. Letts wrote: > It is potentially enabling organizations with more money than need gain more resources, potentially at the expense of non-profit and educational organizations who might not be able to raise cash for additional IPv4 space [or equipment to support a transition to IPv6]. Organizations with "more money than need" have already locked up several /8s worth of address space through contracts with the holders, making it unavailable at any price to the organizations you're concerned about. Game over. Either 1) we let them record those as actual transfers now so we see that in the database or, 2) we wait for them to record them as policy permits, and only those "in the know" are aware of the status of the blocks. There's no third option where people who don't have enough cash to pay the going market price are magically getting addresses due to the continuation of needs-based transfer policy. Matthew Kaufman From hannigan at gmail.com Mon Oct 5 17:36:12 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 5 Oct 2015 17:36:12 -0400 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: <5612EB4E.7040603@matthew.at> References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> <5612EB4E.7040603@matthew.at> Message-ID: > On Oct 5, 2015, at 17:27, Matthew Kaufman wrote: > >> On 10/5/2015 1:07 PM, Martin Hannigan wrote: >> >> >> Let me give you a real world example. >> >> 1. Buy rights to use addresses in any quantity you believe you need >> 2. Use those addresses as you need them, assuming the agreement you made with the party works properly >> 3. Get an LOA from the documented owner >> 4. Bypass ARIN entirely >> 5. Use the addresses. >> >> How do you think we should solve that problem? > > How about another real-world example (several of these in play that I know of) > > 1. Enter into a contract to acquire addresses in any quantity you believe you need (or more) > 2. Not use the addresses right now, but know that you have as many as you want locked up from that seller, who can't sell to anyone else now > 3. Transfer the addresses if/when ARIN policy permits > 4. Use the addresses. > > There is absolutely nothing in the current needs-based policy that ensures that entities that failed to plan for IPv4 runout and do not have sufficient cash to bid against entities engaged in this sort of practice will be able to get IPv4 addresses on the transfer market. And there is nothing about removing needs basis from the transfer policy that will change that. The game is already over, why insist on policies that no longer make any sense in the current environment? > Bingo. The only sufferer is the directory and that is ARINs responsibility. Best, Marty From bjones at vt.edu Mon Oct 5 19:48:58 2015 From: bjones at vt.edu (Brian Jones) Date: Mon, 5 Oct 2015 19:48:58 -0400 Subject: [arin-ppml] Thoughts on 2015-7 Message-ID: See inline comment. -- Brian On Mon, Oct 5, 2015 at 4:40 PM, John Curran wrote: > On Oct 5, 2015, at 4:07 PM, Martin Hannigan wrote: > > > > Let me give you a real world example. > > > > 1. Buy rights to use addresses in any quantity you believe you need > > 2. Use those addresses as you need them, assuming the agreement you made > with the party works properly > > 3. Get an LOA from the documented owner > > 4. Bypass ARIN entirely > > 5. Use the addresses. > > > > How do you think we should solve that problem? > > > It is not my job to determine whether the example above is a major problem > (or not) - > that?s for the community to assess, but I do want to highlight some > aspects that result > from situations (such as the one described above) of which everyone on the > list might > not be aware - > > 1) While the network operations confusion that can result is fairly well > understood to > those on this list, what may not be apparently is that there are > others who rely upon > the registry (e.g. researchers, anti-spam folks, law enforcement, > etc.) and for whom > address blocks being used as described above results in real impacts > to their ability > to rely upon the registry, and thus accomplish their job. > > 2) Because the ?documented owner? doesn?t ever update the registry, a > number of > creative schemes are possible whereby the documented owner gets paid > from > multiple parties for the same rights and then effectively disappears > with their > proceeds leaving the individual buyers to fight it out. There are > ways to reduce > this risk (e.g. escrow arrangements, guarantees with adequate backing, > etc.) > but the need for these (and probability of circumvention) goes up > dramatically > absent an updated registry. Likewise for the case where the > ?documented > owner? doesn?t actually have a documentation trail that would support > their > ability to sell the rights to even one party, but that is not > uncovered since the > documentation never gets reviewed by the registry. > ?Number 2 here is the crux of the matter IMHO. ?In this case the registry not getting updated could cause Internet routing issues, and may not get discovered until routing advertisements for the addresses starts being announced from multiple sources. There is a need for central registration of addresses regardless. I think the entire reasoning for 2015-7 is to simplify the needs assessment process in order to maintain an accurate registry of IPv4 addresses. How do we do that otherwise? > > I have not seen a clear expression of these cases on the list, and felt it > important > to describe them for those who may not have first hand involvement. It is > true that > under 2015-7, parties would be able to obtain more address space then > presently > allowed and to so do based upon an officer representation, so the risks > that such > a change would bring about should be carefully weighted by the community > against > the situations outlined above which exist under the status quo. > > Thanks, > /John > > John Curran > President and CEO > ARIN > > > > > _______________________________________________ > 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: From bjones at vt.edu Mon Oct 5 19:52:46 2015 From: bjones at vt.edu (Brian Jones) Date: Mon, 5 Oct 2015 19:52:46 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy In-Reply-To: <5612D376.7020304@umn.edu> References: <5564C252.4060904@arin.net> <5612D376.7020304@umn.edu> Message-ID: +1 Dave's comments. The question remains, how do we get there... -- Brian On Mon, Oct 5, 2015 at 3:45 PM, David Farmer wrote: > Again, philosophically I agree with the one policy for all mantra, but how > do we get there. I believe the intent of the author is to find bite size > chunks to move is toward a one policy for all model. > > Thanks. > > > On 10/5/15 14:24 , Azinger, Marla wrote: > >> I don't support this proposal. I believe if restrictions are removed, >> then both End User and ISP should be aligned entirely. One policy for all. >> >> Regards >> Marla Azinger >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of ARIN >> Sent: Tuesday, May 26, 2015 11:58 AM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization >> requirement in end-user IPv4 policy >> >> Draft Policy ARIN-2015-3 >> Remove 30 day utilization requirement in end-user IPv4 policy >> >> On 21 May 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-217 >> Remove 30 day utilization requirement in end-user IPv4 policy" as a Draft >> Policy. >> >> Draft Policy ARIN-2015-3 is below and can be found at: >> https://www.arin.net/policy/proposals/2015_3.html >> >> You are encouraged to discuss the merits and your concerns of Draft >> Policy 2015-3 on the Public Policy Mailing List. >> >> 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 PDP. Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The ARIN Policy Development Process (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-2015-3 >> Remove 30 day utilization requirement in end-user IPv4 policy >> >> Date: 26 May 2015 >> >> Problem Statement: >> >> End-user policy is intended to provide end-users with a one year supply >> of IP addresses. Qualification for a one-year supply requires the network >> operator to utilize at least 25% of the requested addresses within 30 days. >> This text is unrealistic and should be removed. >> >> First, it often takes longer than 30 days to stage equipment and start >> actually using the addresses. >> >> Second, growth is often not that regimented; the forecast is to use X >> addresses over the course of a year, not to use 25% of X within 30 days. >> >> Third, this policy text applies to additional address space requests. It >> is incompatible with the requirements of other additional address space >> request justification which indicates that 80% utilization of existing >> space is sufficient to justify new space. If a block is at 80%, then often >> (almost always?) the remaining 80% will be used over the next 30 days and >> longer. Therefore the operator cannot honestly state they will use 25% of >> the ADDITIONAL space within 30 days of receiving it; they're still trying >> to use their older block efficiently. >> >> Fourth, in the face of ARIN exhaustion, some ISPs are starting to not >> give out /24 (or larger) blocks. So the justification for the 25% rule that >> previously existed (and in fact, applied for many years) is no longer >> germane. >> >> Policy statement: >> >> Remove the 25% utilization criteria bullet point from NRPM 4.3.3. >> >> Comments: >> >> a.Timetable for implementation: Immediate >> >> b.Anything else >> _______________________________________________ >> 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. >> >> ________________________________ >> >> This communication is confidential. Frontier only sends and receives >> email on the basis of the terms set out at >> http://www.frontier.com/email_disclaimer. >> _______________________________________________ >> 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. >> >> > > -- > ================================================ > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > > _______________________________________________ > 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: From hannigan at gmail.com Mon Oct 5 20:55:07 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 5 Oct 2015 20:55:07 -0400 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> Message-ID: <8AD7F323-7979-4C41-B34A-DEB097AE1249@gmail.com> > On Oct 5, 2015, at 16:40, John Curran wrote: > >> On Oct 5, 2015, at 4:07 PM, Martin Hannigan wrote: >> >> Let me give you a real world example. >> >> 1. Buy rights to use addresses in any quantity you believe you need >> 2. Use those addresses as you need them, assuming the agreement you made with the party works properly >> 3. Get an LOA from the documented owner >> 4. Bypass ARIN entirely >> 5. Use the addresses. >> >> How do you think we should solve that problem? > > > It is not my job to determine whether the example above is a major problem (or not) - > that?s for the community to assess, but I do want to highlight some aspects that result > from situations (such as the one described above) of which everyone on the list might > not be aware - > > 1) While the network operations confusion that can result is fairly well understood to > those on this list, what may not be apparently is that there are others who rely upon > the registry (e.g. researchers, anti-spam folks, law enforcement, etc.) and for whom > address blocks being used as described above results in real impacts to their ability > to rely upon the registry, and thus accomplish their job. > > 2) Because the ?documented owner? doesn?t ever update the registry, a number of > creative schemes are possible whereby the documented owner gets paid from > multiple parties for the same rights and then effectively disappears with their > proceeds leaving the individual buyers to fight it out. There are ways to reduce > this risk (e.g. escrow arrangements, guarantees with adequate backing, etc.) > but the need for these (and probability of circumvention) goes up dramatically > absent an updated registry. Likewise for the case where the ?documented > owner? doesn?t actually have a documentation trail that would support their > ability to sell the rights to even one party, but that is not uncovered since the > documentation never gets reviewed by the registry. > > I have not seen a clear expression of these cases on the list, and felt it important > to describe them for those who may not have first hand involvement. It is true that > under 2015-7, parties would be able to obtain more address space then presently > allowed and to so do based upon an officer representation, so the risks that such > a change would bring about should be carefully weighted by the community against > the situations outlined above which exist under the status quo. > > Sounds like focused and friendly registry accuracy policy might work better? Best, Marty From heather.skanks at gmail.com Mon Oct 5 20:59:14 2015 From: heather.skanks at gmail.com (Heather Schiller) Date: Mon, 5 Oct 2015 20:59:14 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) In-Reply-To: References: <5564C245.7050207@arin.net> <5564D673.7080106@rollernet.us> Message-ID: I think I agree with Owen here.. to say it simply: Rather than sacrificing all the anti-flip protection by removing the word transfer from "Source entities within the ARIN region must not have received a transfer, allocation, or assignment.." *Add text* to include the exception you want. Add one line to allow transfers within the same entity to cross RIR boundaries. --Heather On Wed, May 27, 2015 at 11:39 PM, Owen DeLong wrote: > My suggestion is that I don't mind (virtually) unrestricted moves of > addresses to different regions staying with the same organization. However, > if we are to allow that, I want us to find a way that you can't merely use > that as a way to move addresses out of flip protection to then flip them to > another organization via an RIR with a less restrictive transfer policy. > > So... If you transfer addresses to another region, keeping them in the > same organization, no penalty. However, you are not allowed to subsequently > transfer them (or other addresses in that region) to an external party for > at least 12 months. > > Owen > > > > > > On May 27, 2015, at 9:27 PM, Jason Schiller > wrote: > > > > Owen, > > > > I am trying to understand your suggestion... is it: > > > > Draft Policy ARIN-2015-2 > > Modify 8.4 (Inter-RIR Transfers to Specified Recipients) > > > > Date: 26 May 2015 > > > > Problem Statement: > > > > Organizations that obtain a 24 month supply of IP addresses via the > > transfer market and then have an unexpected change in business plan > > are unable to move IP addresses to the proper RIR within the first 12 > > months of receipt. > > > > Policy statement: > > > > Replace 8.4, bullet 4, to read: > > > > "> 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. > > This restriction does not include a transfer to a wholly owned > > subsidiary out side of the ARIN service region > > if the recipient org will be required to not transfer the IP space > > for the remaining balance of 12 month window." > > > > Comments: > > > > The intention of this change is to allow organizations to perform > > inter-RIR transfers of space received via an 8.3 transfer regardless > > of the date transferred to ARIN . A common example is that an > > organization acquires a block located in the ARIN region, transfers it > > to ARIN, then 3 months later, the organization announces that it wants > > to launch new services out of region. Under current policy, the > > organization is prohibited from moving some or all of those addresses > > to that region's Whois; the numbers are locked in ARIN's Whois. It's > > important to note that 8.3 transfers are approved for a 24 month > > supply, and it would not be unheard of for a business model to change > > within the first 12 months after approval. In addition this will not > > affect the assignments and allocations issued by ARIN they will still > > be subject to the 12 month restriction. > > > > a. Timetable for implementation: Immediate > > > > b. Anything else > > > >> On Wed, May 27, 2015 at 8:03 AM, Owen DeLong wrote: > >> I could support a policy that allows you to transfer them to your own > entity out of region for this purpose if there were some language that > prevented subsequent flipping. > >> > >> However, the policy as proposed creates too much opportunity for > unintended consequences that the original anti-flip language is intended to > prevent. > >> > >> Owen > >> > >>>> On May 26, 2015, at 10:30 PM, David Huberman < > David.Huberman at microsoft.com> wrote: > >>>> > >>>> Why is another region's policy problem or restrictions something that > needs > >>>> fixing through ARIN policy? > >>> > >>> Two answers: > >>> > >>> Because ARIN-region networks, subject to ARIN's NRPM, need to be able > to move IP addresses out of region where and when they're needed. > >>> AND > >>> Because ARIN policy currently prohibits staff from counting > out-of-region use as part of justification for a request. > >>> > >>> _______________________________________________ > >>> 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. > >> > >> _______________________________________________ > >> 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 > _______________________________________________ > 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: From andrew.dul at quark.net Tue Oct 6 09:55:48 2015 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 6 Oct 2015 09:55:48 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations In-Reply-To: References: <55AE8268.2090107@arin.net> Message-ID: The intent here is to clarify that a reorganization is not required to go through the larger process of showing that assets were acquired and the other needs testing that is currently done on mergers & acquisitions. Andrew > On Oct 5, 2015, at 3:26 PM, Azinger, Marla wrote: > > It looks like all that was changed was they added the word ?re-organization?. Am I missing some other text change? > > Regards > Marla Azinger > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN > Sent: Tuesday, July 21, 2015 10:33 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations > > Recommended Draft Policy ARIN-2015-4 > Modify 8.2 section to better reflect how ARIN handles reorganizations > > On 16 July 2015 the ARIN Advisory Council (AC) recommended > ARIN-2015-4 for adoption, making it a Recommended Draft Policy. > > ARIN-2015-4 is below and can be found at: > https://www.arin.net/policy/proposals/2015_4.html > > You are encouraged to discuss Draft Policy 2015-4 on the PPML prior to the ARIN Public Policy Consultation at ARIN 36 in Montreal in October 2015. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. > > The ARIN Policy Development Process 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) > > > ## * ## > > > Recommended Draft Policy ARIN-2015-4 > Modify 8.2 section to better reflect how ARIN handles reorganizations > > Date: 21 July 2015 > > AC's assessment of conformance with the Principles of Internet Number Resource Policy: > > 2015-4 is largely editorial in nature and does not change policy implementation, but clarifies existing use of policy. The proposal is fair in that it provides a consistent interface for transfers and clarifies the transfer policy. It is technically sound in that it is already effectively implemented. The proposal has received support on the mailing list and we expect it to be generally supported by the community as it is the direct result of community feed back on the existing policy. > > Problem Statement: > > ARIN staff indicated that NRPM 8.2 does not clearly indicate how ARIN procedures handle reorganizations. ARIN staff indicated that the first policy bullet point does not apply to reorganizations. > > Policy statement: > > Replacement text for entire 8.2 section: > > 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. > > In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy. > > Comments: > > The problem statement is addressed by: > > -re-title 8.2 > > -clarify the documentation bullet point > > -rearrange the documentation bullet to the end of the list since it only applies to some requestors, while the other bullet points apply to all requestors. > > a.Timetable for implementation: Immediate > > b.Anything else > > ##### > > ARIN STAFF & LEGAL ASSESSMENT > Draft Policy ARIN-2015-4 > Modify 8.2 section to better reflect how ARIN handles reorganizations https://www.arin.net/policy/proposals/2015_4.html > > Date of Assessment: July 14, 2015 > > ___ > 1. Summary (Staff Understanding) > This proposal would provide clarification to the 8.2 transfer policy for reorganizations. It does this by adding "reorganizations" to the title, and clarifies that evidence of acquired assets is only required for merger and acquisition transfers; not reorganizations. > > ___ > 2. Comments > A. ARIN Staff Comments > This proposal can be implemented as written. Minimal staff training and preparation would be needed to implement this if it were to become policy. The proposal clarifies a point about reorganizations that has been confusing to customers in the past. We see no negative impacts. > > B. ARIN General Counsel ? Legal Assessment Counsel sees no material legal issues in this policy. > > ___ > 3. Resource Impact > This policy would require minimal staff training and preparation. We see no negative impacts. > > ___ > 4. Proposal / Draft Policy Text Assessed > > Draft Policy ARIN-2015-4 > > Modify 8.2 section to better reflect how ARIN handles reorganizations > > Problem Statement: > > ARIN staff indicated that NRPM 8.2 does not clearly indicate how ARIN procedures handle reorganizations. ARIN staff indicated that the first policy bullet point does not apply to reorganizations. > > Policy statement: > > Replacement text for entire 8.2 section: > > 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. > > In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy. > > Comments: > > The problem statement is addressed by: > > -re-title 8.2 > -clarify the documentation bullet point > -rearrange the documentation bullet to the end of the list since it only applies to some requestors, while the other bullet points apply to all requestors. > > a.Timetable for implementation: Immediate > > b.Anything else > _______________________________________________ > 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. > > ________________________________ > > This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. > _______________________________________________ > 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. From David.Huberman at microsoft.com Tue Oct 6 10:09:06 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 6 Oct 2015 14:09:06 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations In-Reply-To: References: <55AE8268.2090107@arin.net> Message-ID: Hi Marla, I'm the policy author. I wrote the policy in reaction to Richard Jimmerson's staff experience report published at: https://www.arin.net/participate/meetings/reports/ARIN_35/PDF/monday/jimmerson_policy.pdf On pages 7 and 8, Richard asked for specific changes, including: - fixing the title to include reorganizations - fixing the language: " 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." ... to make it clear it does NOT apply to reorganizations. So I fixed the title of 8.2 (I added the word re-organizations) and I CHANGED the order of the bullet points to read more clearly to the lay reader. No text was changed except the last bullet point where I prefaced the text with "For mergers and acquisition transfer". 2015-4 is a very minor change, was requested by staff, and makes 8.2 more readable for the lay reader. The AC considered this as an editorial change, but for reasons I don?t remember, we decided to put it through PDP. It was a close call, I think. Hope that helps :) David David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Andrew Dul > Sent: Tuesday, October 6, 2015 6:56 AM > To: Azinger, Marla > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2015-4: Modify 8.2 > section to better reflect how ARIN handles reorganizations > > The intent here is to clarify that a reorganization is not required to go through > the larger process of showing that assets were acquired and the other needs > testing that is currently done on mergers & acquisitions. > > Andrew > > > On Oct 5, 2015, at 3:26 PM, Azinger, Marla > wrote: > > > > It looks like all that was changed was they added the word ?re- > organization?. Am I missing some other text change? > > > > Regards > > Marla Azinger > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > > On Behalf Of ARIN > > Sent: Tuesday, July 21, 2015 10:33 AM > > To: arin-ppml at arin.net > > Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-4: Modify 8.2 > > section to better reflect how ARIN handles reorganizations > > > > Recommended Draft Policy ARIN-2015-4 > > Modify 8.2 section to better reflect how ARIN handles reorganizations > > > > On 16 July 2015 the ARIN Advisory Council (AC) recommended > > ARIN-2015-4 for adoption, making it a Recommended Draft Policy. > > > > ARIN-2015-4 is below and can be found at: > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.a > > > rin.net%2fpolicy%2fproposals%2f2015_4.html&data=01%7c01%7cdavid.hube > rm > > > an%40microsoft.com%7c4ff87465e393490ca8b208d2ce55ea5a%7c72f988bf86 > f141 > > > af91ab2d7cd011db47%7c1&sdata=S%2bCm4qFN%2fqWIWPqajQOBcYhnEtdr > zDaAl5MzW > > G4jd2s%3d > > > > You are encouraged to discuss Draft Policy 2015-4 on the PPML prior to the > ARIN Public Policy Consultation at ARIN 36 in Montreal in October 2015. Both > the discussion on the list and at the meeting will be used by the ARIN > Advisory Council to determine the community consensus for adopting this as > policy. > > > > The ARIN Policy Development Process can be found at: > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.a > > > rin.net%2fpolicy%2fpdp.html&data=01%7c01%7cdavid.huberman%40micros > oft. > > > com%7c4ff87465e393490ca8b208d2ce55ea5a%7c72f988bf86f141af91ab2d7cd > 011d > > b47%7c1&sdata=zsfZBQTnd7KE8YVEOz6Lote4HhEJjd4VsBKNKj3o5pQ%3d > > > > Draft Policies and Proposals under discussion can be found at: > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.a > > > rin.net%2fpolicy%2fproposals%2findex.html&data=01%7c01%7cdavid.huber > ma > > > n%40microsoft.com%7c4ff87465e393490ca8b208d2ce55ea5a%7c72f988bf86f > 141a > > > f91ab2d7cd011db47%7c1&sdata=PPDRFP%2bdKCH1b4WrdOzy4%2b2pERfXM > Mpy7U6Yi6 > > IRx4g%3d > > > > Regards, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Recommended Draft Policy ARIN-2015-4 > > Modify 8.2 section to better reflect how ARIN handles reorganizations > > > > Date: 21 July 2015 > > > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > > > 2015-4 is largely editorial in nature and does not change policy > implementation, but clarifies existing use of policy. The proposal is fair in that > it provides a consistent interface for transfers and clarifies the transfer policy. > It is technically sound in that it is already effectively implemented. The > proposal has received support on the mailing list and we expect it to be > generally supported by the community as it is the direct result of community > feed back on the existing policy. > > > > Problem Statement: > > > > ARIN staff indicated that NRPM 8.2 does not clearly indicate how ARIN > procedures handle reorganizations. ARIN staff indicated that the first policy > bullet point does not apply to reorganizations. > > > > Policy statement: > > > > Replacement text for entire 8.2 section: > > > > 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. > > > > In the event that number resources of the combined organizations are no > longer justified under ARIN policy at the time ARIN becomes aware of the > transaction, through a transfer request or otherwise, ARIN will work with the > resource holder(s) to return or transfer resources as needed to restore > compliance via the processes outlined in current ARIN policy. > > > > Comments: > > > > The problem statement is addressed by: > > > > -re-title 8.2 > > > > -clarify the documentation bullet point > > > > -rearrange the documentation bullet to the end of the list since it only > applies to some requestors, while the other bullet points apply to all > requestors. > > > > a.Timetable for implementation: Immediate > > > > b.Anything else > > > > ##### > > > > ARIN STAFF & LEGAL ASSESSMENT > > Draft Policy ARIN-2015-4 > > Modify 8.2 section to better reflect how ARIN handles reorganizations > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.a > > > rin.net%2fpolicy%2fproposals%2f2015_4.html&data=01%7c01%7cdavid.hube > rm > > > an%40microsoft.com%7c4ff87465e393490ca8b208d2ce55ea5a%7c72f988bf86 > f141 > > > af91ab2d7cd011db47%7c1&sdata=S%2bCm4qFN%2fqWIWPqajQOBcYhnEtdr > zDaAl5MzW > > G4jd2s%3d > > > > Date of Assessment: July 14, 2015 > > > > ___ > > 1. Summary (Staff Understanding) > > This proposal would provide clarification to the 8.2 transfer policy for > reorganizations. It does this by adding "reorganizations" to the title, and > clarifies that evidence of acquired assets is only required for merger and > acquisition transfers; not reorganizations. > > > > ___ > > 2. Comments > > A. ARIN Staff Comments > > This proposal can be implemented as written. Minimal staff training and > preparation would be needed to implement this if it were to become policy. > The proposal clarifies a point about reorganizations that has been confusing > to customers in the past. We see no negative impacts. > > > > B. ARIN General Counsel ? Legal Assessment Counsel sees no material legal > issues in this policy. > > > > ___ > > 3. Resource Impact > > This policy would require minimal staff training and preparation. We see no > negative impacts. > > > > ___ > > 4. Proposal / Draft Policy Text Assessed > > > > Draft Policy ARIN-2015-4 > > > > Modify 8.2 section to better reflect how ARIN handles reorganizations > > > > Problem Statement: > > > > ARIN staff indicated that NRPM 8.2 does not clearly indicate how ARIN > procedures handle reorganizations. ARIN staff indicated that the first policy > bullet point does not apply to reorganizations. > > > > Policy statement: > > > > Replacement text for entire 8.2 section: > > > > 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. > > > > In the event that number resources of the combined organizations are no > longer justified under ARIN policy at the time ARIN becomes aware of the > transaction, through a transfer request or otherwise, ARIN will work with the > resource holder(s) to return or transfer resources as needed to restore > compliance via the processes outlined in current ARIN policy. > > > > Comments: > > > > The problem statement is addressed by: > > > > -re-title 8.2 > > -clarify the documentation bullet point -rearrange the documentation > > bullet to the end of the list since it only applies to some requestors, while > the other bullet points apply to all requestors. > > > > a.Timetable for implementation: Immediate > > > > b.Anything else > > _______________________________________________ > > 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: > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists. > > arin.net%2fmailman%2flistinfo%2farin- > ppml&data=01%7c01%7cdavid.huberma > > > n%40microsoft.com%7c4ff87465e393490ca8b208d2ce55ea5a%7c72f988bf86f > 141a > > > f91ab2d7cd011db47%7c1&sdata=VliIkQb0pzX46tbwUjcvQS3KOkTqroWer9ES > o6SGDy > > M%3d Please contact info at arin.net if you experience any issues. > > > > ________________________________ > > > > This communication is confidential. Frontier only sends and receives > > email on the basis of the terms set out at > > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.fr > > > ontier.com%2femail_disclaimer.&data=01%7c01%7cdavid.huberman%40micr > oso > > > ft.com%7c4ff87465e393490ca8b208d2ce55ea5a%7c72f988bf86f141af91ab2d7 > cd0 > > > 11db47%7c1&sdata=R6TYATTBmacXyZdxStkd9o3D7di3LIp0YXBu3Xd9OyE%3d > > _______________________________________________ > > 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: > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists. > > arin.net%2fmailman%2flistinfo%2farin- > ppml&data=01%7c01%7cdavid.huberma > > > n%40microsoft.com%7c4ff87465e393490ca8b208d2ce55ea5a%7c72f988bf86f > 141a > > > f91ab2d7cd011db47%7c1&sdata=VliIkQb0pzX46tbwUjcvQS3KOkTqroWer9ES > o6SGDy > > M%3d Please contact info at arin.net if you experience any issues. > _______________________________________________ > 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: > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin > .net%2fmailman%2flistinfo%2farin- > ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7c4ff87465e39 > 3490ca8b208d2ce55ea5a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata > =VliIkQb0pzX46tbwUjcvQS3KOkTqroWer9ESo6SGDyM%3d > Please contact info at arin.net if you experience any issues. From bill at herrin.us Tue Oct 6 10:39:28 2015 From: bill at herrin.us (William Herrin) Date: Tue, 6 Oct 2015 10:39:28 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations In-Reply-To: <55AE8268.2090107@arin.net> References: <55AE8268.2090107@arin.net> Message-ID: On Tue, Jul 21, 2015 at 1:33 PM, ARIN wrote: > 2015-4 is largely editorial in nature and does not change policy > implementation, but clarifies existing use of policy. When policies allege themselves to be minor or editorial in nature yet replace an entire section, can we get an explicit diff from the existing policy which shows exactly what words changed? Thanks, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From Marla.Azinger at FTR.com Tue Oct 6 12:27:05 2015 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Tue, 6 Oct 2015 16:27:05 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-11: Remove transfer language which only applied pre-exhaustion of IPv4 pool In-Reply-To: <56031186.5040407@arin.net> References: <56031186.5040407@arin.net> Message-ID: For clarity sake. If this is removed, does that mean it's never added back in should ARIN actually get V4 space back in the free pool? Either way I support removing this policy. I think it shouldn't have existed to begin with. It was not written well enough and unintentionally inhibited reasonable business practices. Regards Marla Azinger -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, September 23, 2015 1:55 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-11: Remove transfer language which only applied pre-exhaustion of IPv4 pool Draft Policy ARIN-2015-11 Remove transfer language which only applied pre-exhaustion of IPv4 pool On 17 September 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-225 Remove transfer language which only applied pre-exhaustion of IPv4 pool" as a Draft Policy. Draft Policy ARIN-2015-11 is below and can be found at: https://www.arin.net/policy/proposals/2015_11.html You are encouraged to discuss the merits and your concerns of Draft Policy 2015-11 on the Public Policy Mailing List. 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 PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (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-2015-11 Remove transfer language which only applied pre-exhaustion of IPv4 pool Date: 23 September 2015 Problem Statement: The current policies in NRPM sections 8.3, and 8.4 include language which is in effect "until exhaustion." As ARIN is no longer able to fulfil IPv4 requests (per 01 July 2015 press release https://www.arin.net/about_us/media/releases/20150701.html), exhaustion has effectively occurred. This proposal serves to remove the outdated language from the NRPM. Policy statement: Remove sections of the NRPM which were only affective until IPv4 pool exhaustion occurred, as follows: Section 8.3 Transfers between Specified Recipients within the ARIN Region: - Remove entirely the second bullet which reads "The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first." Section 8.4 Inter-RIR Transfers to Specified Recipients: - Remove entirely the third bullet which reads "Source entities within the ARIN region will not be eligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first." Comments: 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. ________________________________ This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. From cspears at oar.net Tue Oct 6 15:14:28 2015 From: cspears at oar.net (Spears, Christopher M.) Date: Tue, 6 Oct 2015 19:14:28 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users In-Reply-To: <5612D1D5.1000906@umn.edu> References: <55DCBE0D.8010802@arin.net> <5612D1D5.1000906@umn.edu> Message-ID: <9A714375-8A2F-401B-9431-940319A33C67@oar.net> What about setting a limit on the amount of space that can be re-assigned, or the number of re-assignments? Say 25% of the maximum possible reassignments using the current minimum reassignment size (/29), based on the upper bound of the fee category they're in (e.g., xx-small = /22 = 1024*.25/8 = 32 re-assignmentsl). Or up 50% of the assigned space? It?s also worth noting that this only addresses IPv4 re-assignments under Section 4. There should be parity for IPv6 (which I understand is currently a draft). Doing them in tandem would give this more weight, IMHO. End-users make up over 40% of the Orgs in the ARIN region. If a ?single? policy is a desired outcome, then we should either make accommodations for End Users that starts to level the field, or create a middle-ground that?s acceptable should things stall. Half-measure are often rebuked because they potentially leave you in an unenviable (or untenable) state. -Chris On Oct 5, 2015, at 3:39 PM, David Farmer wrote: > Marla, > > From a strategic point of view I agree that we should move to a one policy for everyone model. > > However, every time we try all-encompassing strategic changes, people say they are too big of a change all at once, and tell us to break them up. When we brake them up into manageable size chunks, the individual changes don't get support because people don't want to see half-measures they want strategic level changes. > > This is a catch 22. We need to find a way to move forward. How would you suggest we do that? > > Thanks. > > On 10/5/15 13:55 , Azinger, Marla wrote: >> I don't support this based on what I see as a missed opportunity. This policy calls attention to the fact that ARIN should consider removing any difference in policy between End Users and ISPs. I agree this proposal has valid case use scenarios, however it just leaves me thinking only one "class" is needed and not two. One policy for all. >> >> Regards >> Marla Azinger >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >> Sent: Tuesday, August 25, 2015 12:12 PM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users >> >> Draft Policy ARIN-2015-8 >> Reassignment records for IPv4 End-Users >> >> On 20 August 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-222 Reassignment records for IPv4 End-Users" as a Draft Policy. >> >> Draft Policy ARIN-2015-8 is below and can be found at: >> https://www.arin.net/policy/proposals/2015_8.html >> >> You are encouraged to discuss the merits and your concerns of Draft Policy 2015-8 on the Public Policy Mailing List. >> >> 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 PDP. Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The ARIN Policy Development Process (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-2015-8 >> Reassignment records for IPv4 End-Users >> >> Date: 25 August 2015 >> >> Problem statement: >> >> End-User Organizations do not have the ability to create reassignment records in the number resource database. >> >> Reassignment records can be used for a number of different functions which could benefit the overall desire to increase database accuracy by allowing organizations to add additional details in the database. >> >> The following reasons have been noted as positive reasons to allow the creation of additional records. >> - Geolocation (allows an organization to specify a different location within the database which is used by organizations creating geo-location by IP address databases) >> - Subsidiary reassignment (allows an organization to note that a portion of their netblock is in use by a different subsidiary entity) >> - Assignment to contracted parties (some organizations have contracts with other organizations which are operating networks under agreements with the registrant, this allows the top-level organizations to accurately specify the organization operating the network in the number resource database) >> - More specific contact information (some organizations operate large networks which don't necessarily have the same technical or abuse contact information) >> >> Policy statement: >> >> Create new section 4.3.x >> >> End-user organizations which have an active registration services agreement shall be permitted to create reassignment records in the number resource database. Organizations shall use the guidelines outlined in section 4.2.3 when creating reassignment records. >> >> Comments: >> a. Timetable for implementation: immediately b. Anything else: >> >> It is noted by the author of this policy proposal that one of the distinctions in the service between ISPs and End-Users has been the ability for an organization to create reassignment records. >> >> This policy proposal stretches across responsibilities areas as it impacts number policy, ARIN operational practice, and fees. >> >> Below we have noted the three areas and the different responsibilities: >> >> A) Providing reassignment support for end-user assignments, for those who wish to use it >> >> This is an ARIN Service issue - could be an suggestion/consultation process, so long as any implied additional workload/cost can be accommodated in budget and the community supports >> >> B) New requirement on end-users to provide reassignment information in certain circumstances so that ARIN will treat their usage assertion credibly >> >> This is a policy issue. These requirements should be vetted through the policy development process. >> >> C) Fee Implications of ISPs moving to end-user category >> >> This is Board issue, but first requires a community discussion or consultation to be held to solicit community input on desired outcome. >> _______________________________________________ >> 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. >> >> ________________________________ >> >> This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. >> _______________________________________________ >> 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. >> > > > -- > ================================================ > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > _______________________________________________ > 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. From andrew.dul at quark.net Tue Oct 6 16:58:01 2015 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 6 Oct 2015 16:58:01 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users In-Reply-To: <9A714375-8A2F-401B-9431-940319A33C67@oar.net> References: <55DCBE0D.8010802@arin.net> <5612D1D5.1000906@umn.edu> <9A714375-8A2F-401B-9431-940319A33C67@oar.net> Message-ID: There are a number of community members that posit that if reassignment records are allowed for end-users "bad" things might happen and thus seek to limit the number or scope of the records that could be added. To me the issue of ISP vs end-user and the downstream effect on ARIN's revenue is some what a side issue. I believe the ARIN board will adjust appropriately should the lines between ISP and end-user blur enough to warrant a fee schedule change. We can improve the quality of data about IP address records by allowing users to add additional information. One might argue that this additional information is not always accurate, but personally I'd rather have additional information (which may not be helpful) rather than no information. Andrew > On Oct 6, 2015, at 3:14 PM, Spears, Christopher M. wrote: > > What about setting a limit on the amount of space that can be re-assigned, or the number of re-assignments? Say 25% of the maximum possible reassignments using the current minimum reassignment size (/29), based on the upper bound of the fee category they're in (e.g., xx-small = /22 = 1024*.25/8 = 32 re-assignmentsl). Or up 50% of the assigned space? > > It?s also worth noting that this only addresses IPv4 re-assignments under Section 4. There should be parity for IPv6 (which I understand is currently a draft). Doing them in tandem would give this more weight, IMHO. > > End-users make up over 40% of the Orgs in the ARIN region. If a ?single? policy is a desired outcome, then we should either make accommodations for End Users that starts to level the field, or create a middle-ground that?s acceptable should things stall. Half-measure are often rebuked because they potentially leave you in an unenviable (or untenable) state. > > -Chris > > > >> On Oct 5, 2015, at 3:39 PM, David Farmer wrote: >> >> Marla, >> >> From a strategic point of view I agree that we should move to a one policy for everyone model. >> >> However, every time we try all-encompassing strategic changes, people say they are too big of a change all at once, and tell us to break them up. When we brake them up into manageable size chunks, the individual changes don't get support because people don't want to see half-measures they want strategic level changes. >> >> This is a catch 22. We need to find a way to move forward. How would you suggest we do that? >> >> Thanks. >> >>> On 10/5/15 13:55 , Azinger, Marla wrote: >>> I don't support this based on what I see as a missed opportunity. This policy calls attention to the fact that ARIN should consider removing any difference in policy between End Users and ISPs. I agree this proposal has valid case use scenarios, however it just leaves me thinking only one "class" is needed and not two. One policy for all. >>> >>> Regards >>> Marla Azinger >>> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >>> Sent: Tuesday, August 25, 2015 12:12 PM >>> To: arin-ppml at arin.net >>> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users >>> >>> Draft Policy ARIN-2015-8 >>> Reassignment records for IPv4 End-Users >>> >>> On 20 August 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-222 Reassignment records for IPv4 End-Users" as a Draft Policy. >>> >>> Draft Policy ARIN-2015-8 is below and can be found at: >>> https://www.arin.net/policy/proposals/2015_8.html >>> >>> You are encouraged to discuss the merits and your concerns of Draft Policy 2015-8 on the Public Policy Mailing List. >>> >>> 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 PDP. Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> The ARIN Policy Development Process (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-2015-8 >>> Reassignment records for IPv4 End-Users >>> >>> Date: 25 August 2015 >>> >>> Problem statement: >>> >>> End-User Organizations do not have the ability to create reassignment records in the number resource database. >>> >>> Reassignment records can be used for a number of different functions which could benefit the overall desire to increase database accuracy by allowing organizations to add additional details in the database. >>> >>> The following reasons have been noted as positive reasons to allow the creation of additional records. >>> - Geolocation (allows an organization to specify a different location within the database which is used by organizations creating geo-location by IP address databases) >>> - Subsidiary reassignment (allows an organization to note that a portion of their netblock is in use by a different subsidiary entity) >>> - Assignment to contracted parties (some organizations have contracts with other organizations which are operating networks under agreements with the registrant, this allows the top-level organizations to accurately specify the organization operating the network in the number resource database) >>> - More specific contact information (some organizations operate large networks which don't necessarily have the same technical or abuse contact information) >>> >>> Policy statement: >>> >>> Create new section 4.3.x >>> >>> End-user organizations which have an active registration services agreement shall be permitted to create reassignment records in the number resource database. Organizations shall use the guidelines outlined in section 4.2.3 when creating reassignment records. >>> >>> Comments: >>> a. Timetable for implementation: immediately b. Anything else: >>> >>> It is noted by the author of this policy proposal that one of the distinctions in the service between ISPs and End-Users has been the ability for an organization to create reassignment records. >>> >>> This policy proposal stretches across responsibilities areas as it impacts number policy, ARIN operational practice, and fees. >>> >>> Below we have noted the three areas and the different responsibilities: >>> >>> A) Providing reassignment support for end-user assignments, for those who wish to use it >>> >>> This is an ARIN Service issue - could be an suggestion/consultation process, so long as any implied additional workload/cost can be accommodated in budget and the community supports >>> >>> B) New requirement on end-users to provide reassignment information in certain circumstances so that ARIN will treat their usage assertion credibly >>> >>> This is a policy issue. These requirements should be vetted through the policy development process. >>> >>> C) Fee Implications of ISPs moving to end-user category >>> >>> This is Board issue, but first requires a community discussion or consultation to be held to solicit community input on desired outcome. >>> _______________________________________________ >>> 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. >>> >>> ________________________________ >>> >>> This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. >>> _______________________________________________ >>> 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. >>> >> >> >> -- >> ================================================ >> David Farmer Email: farmer at umn.edu >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 1-612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 >> ================================================ >> _______________________________________________ >> 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. > > _______________________________________________ > 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. From jschiller at google.com Tue Oct 6 20:57:57 2015 From: jschiller at google.com (Jason Schiller) Date: Tue, 6 Oct 2015 20:57:57 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations In-Reply-To: References: <55AE8268.2090107@arin.net> Message-ID: As David previously said (and I concur with his assessment). 1. inserted the word "re-organizations" to the section title It already existed in the body of the text: "ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:" 2. re order the bullets (they are not actually numbered) original 1, 2, 3, 4, 5 are now 2, 3, 4, 5, 1. 3. Bullet 1 is now clearly scope to mergers and acquisitions (not corporate re-organizations) by prefacing the current text with "For mergers and acquisition transfers," and "new entity" is changed to "recipient entity". new bullet 1: -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. old bullet 1: "> The new 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." 2, 3, 4, & 5 clearly apply to M&A and re-orgs, bullet 1, now moved to the end, only applies to M&A. 4. The shape of the bullet was changed from greater than (>) to a dash (-). The claim that this is editorial is in light of the fact that ARIN currently does not ask for a organization to prove it has acquired assets in order to transfer IPs for one business unit to another. Hope this helps, __Jason On Tue, Oct 6, 2015 at 10:39 AM, William Herrin wrote: > On Tue, Jul 21, 2015 at 1:33 PM, ARIN wrote: > > 2015-4 is largely editorial in nature and does not change policy > > implementation, but clarifies existing use of policy. > > When policies allege themselves to be minor or editorial in nature yet > replace an entire section, can we get an explicit diff from the > existing policy which shows exactly what words changed? > > Thanks, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > _______________________________________________ > 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: From jschiller at google.com Tue Oct 6 21:45:55 2015 From: jschiller at google.com (Jason Schiller) Date: Tue, 6 Oct 2015 21:45:55 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: <092EF5BD-5020-499C-8590-4857E26EF9B3@delong.com> References: <092EF5BD-5020-499C-8590-4857E26EF9B3@delong.com> Message-ID: Before we started mucking around with lowering the minimum size block, it was a /20 for ISPs (/22 for multi-homed ISPs). /20 became the defacto ISP slow start. Post 2014-13, it was reduced for to a /24 as the minimum for ISPs, but the slow start initial block was between a /24 and a /20 at the ISP's request. For end users it was /20 or /24 for multi-homed. https://www.arin.net/policy/proposals/2014_13.html Slow start of between /24 and /20 is consistent with automatic transfer pre-approval for ISPs holding no IPv4 addresses, or for ISPs whose IPv4 holding are at or above 80% used, and have no previous history in the past year to support a larger transfer. We have never had a slow start for end-users, but could imagine a block between /24 and /22 as the right size based on the fact that most assignments are within that size, and it lines up with other region's soft landing. Anti 2 year flip / revert to ARIN free pool is a good provision. I have a few more thoughts for this policy. 1. At any time, an org can opt to revert back to justified need based on their past 3-12 months (the org chooses the window size) run rate they can get a two year supply. [this is useful for orgs growing at faster than the slow start size] 2. Orgs disolved due to corporate restructuring less than 24 months after creation can keep their IP space if they meet traditional needs justification. ___Jason On Wed, Sep 30, 2015 at 10:42 PM, Owen DeLong wrote: > Dani, > > In fairness to Bill, I think he may also have chosen them because I > suggested that those would be boundaries I would consider livable. > > I believe they represent a good size to guarantee that small organizations > are not shut out of the transfer market based on size, but still ensure > that need assessment is preserved in order to prevent acquisition of > addresses without intended use thereof. > > While a /20 is a fair quantity of addresses (4096), it?s a pretty small > number of customers for an ISP in most cases and I think anything smaller > would be somewhat punitive. > > It does also line up well with transfer history and other ARIN data about > small-ish organizations and address issuance over the last several years. > > Owen > > On Sep 30, 2015, at 03:52 , Dani Roisman wrote: > > Hi Bill, > > I?m interested to learn how you came up with the below proposed netblock > sizes ?/20 if a ISP or /22 for an end user? ? Is there data behind that? > If not, does it make sense to ask ARIN to supply data regarding sizes of > transfers which have occurred in the past 12 - 18 months? > > -- > Dani Roisman > > ________________________________ > From: "Bill Buhler" > > To: "owen" > > Cc: arin-ppml at arin.net > Sent: Monday, September 28, 2015 12:59:30 PM > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > OK, how about this: > > Small end users and ISPs are allowed to obtain IPv4 address blocks without > a needs test as long as the following criteria are met: > > > a. The total size of their ARIN allocations at any time of the > process does not exceed a /20 if a ISP or /22 for an end user. > > b. They cannot purchase IP address from the transfer market more than > three total times to reach this size, including the initial operation. > > c. None of the addresses purchased can be transferred to any other > entity for twenty-four months following the date of the last transfer. > > d. If the company ceases operations within the twenty-four month > window the addresses are automatically transferred to the ARIN free pool. > After that period of time regular transfer rights exist. > > e. All subsequent allocations / transfers require regular needs > testing after the initial twenty-four month allocation window. > > f. Eligible entities for this policy consist of ISPs and End users > who have a unique physical address in the ARIN region at the suite level. > Meaning if two companies share the same suite they are not eligible to both > have ARIN allocations. > > ------------------- > > I believe that meets all of your concerns. I would prefer companies get > everything they think they will need in one operation, but I don?t want to > have fear drive them into buying the max amount just in case. > > Best regards, > > Bill Buhler > > _______________________________________________ > 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. > > > > _______________________________________________ > 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: From owen at delong.com Wed Oct 7 01:13:02 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Oct 2015 22:13:02 -0700 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> Message-ID: <1E0FDFE4-144C-4088-B94B-2590BFBF99F0@delong.com> Steven, You don?t have to go outside of policy to use a broker. If you actually need the addresses, you can get a pre-approval through ARIN, take your pre-approval to one or more brokers and arrange to obtain the addresses you need and come back to ARIN and complete the transfer. We have new rules to address the fact that times have changed somewhat. That?s what 8.3 and 8.4 of the NRPM are. Owen > On Oct 5, 2015, at 1:29 PM, Steven Ryerse wrote: > > I don?t understand why everyone wants to keep blocking all outside of ARIN transactions. A year from now there might be a thousand or more legitimate organizations that meet one or more of the current policies to qualify for an IPv4 allocation. Let?s say that is your Org or your Customer?s Org - and ARIN dutifully places you on their waiting list. Time passes and no significant supply comes available for your request. > > So then what do you do? ARIN can?t fulfill your request timely. You have a legitimate need. If IPv6 won?t work, Is living without the resources you need really acceptable? If not do you break down and call a Broker to help find you the resources that you need? > > Why does this community continually paint organizations into the corner of not being able to get IPv4 resources without going outside of ARINs policies? John asked this community to visit the issue of runout several months ago, and there was some discussion but I?ve seen no real will to make any significant adjustments to try and deal with the new world we all must live in now. > > We can keep rearranging deck chairs on the Titanic, or we can face reality that times have completely changed and the old rules won?t work in a new ARIN world. My 2 cents. > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Martin Hannigan > Sent: Monday, October 5, 2015 4:08 PM > To: Scott Leibrand > > Cc: ppml at arin.net > Subject: Re: [arin-ppml] Thoughts on 2015-7 > > > > On Mon, Oct 5, 2015 at 3:29 PM, Scott Leibrand > wrote: > Reducing the burden on ARIN staff is not part of the problem statement for this proposal (though it might be a side effect, depending on how they implement it). The main goal here is to reduce the administrative burden on organizations who need to acquire IPv4 space via transfer. That burden may actually be higher for smaller entities who don't have experience with and processes in place for jumping through ARIN's hoops. > > I don't think this policy would have much impact on the ability of large well-funded entities to purchase as much address space as they like. Currently, those organizations simply write a contract that gives them full rights to the address space they're buying, and allows them to transfer the space with ARIN whenever they are ready to put it into use on their network (or can otherwise pass ARIN's needs justification tests). > > > > > Let me give you a real world example. > > 1. Buy rights to use addresses in any quantity you believe you need > 2. Use those addresses as you need them, assuming the agreement you made with the party works properly > 3. Get an LOA from the documented owner > 4. Bypass ARIN entirely > 5. Use the addresses. > > How do you think we should solve that problem? > > > Best, > > -M< > > > > _______________________________________________ > 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: From owen at delong.com Wed Oct 7 01:26:59 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Oct 2015 22:26:59 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks In-Reply-To: References: <092EF5BD-5020-499C-8590-4857E26EF9B3@delong.com> Message-ID: <54DE784F-1CF9-4B28-A566-077B3B816E0B@delong.com> > On Oct 6, 2015, at 6:45 PM, Jason Schiller wrote: > > Before we started mucking around with lowering the minimum size block, it was a /20 for ISPs (/22 for multi-homed ISPs). /20 became the defacto ISP slow start. Post 2014-13, it was reduced for to a /24 as the minimum for ISPs, but the slow start initial block was between a /24 and a /20 at the ISP's request. > > For end users it was /20 or /24 for multi-homed. > > https://www.arin.net/policy/proposals/2014_13.html > > Slow start of between /24 and /20 is consistent with automatic transfer pre-approval for ISPs holding no IPv4 addresses, or for ISPs whose IPv4 holding are at or above 80% used, and have no previous history in the past year to support a larger transfer. > > We have never had a slow start for end-users, but could imagine a block between /24 and /22 as the right size based on the fact that most assignments are within that size, and it lines up with other region's soft landing. > > Anti 2 year flip / revert to ARIN free pool is a good provision. > > I have a few more thoughts for this policy. > > 1. At any time, an org can opt to revert back to justified need based on their past 3-12 months (the org chooses the window size) run rate they can get a two year supply. > I think that is implicit in the policy as it would get incorporated into the NRPM. Do you believe it needs to be made more explicit? It certainly is in line with my understanding of the author?s intent as well as my own. > [this is useful for orgs growing at faster than the slow start size] > > 2. Orgs disolved due to corporate restructuring less than 24 months after creation can keep their IP space if they meet traditional needs justification. Do you mean that the space could be transferred to the parent organization in this case? I would oppose such a provision because I believe it is quite ripe for abuse. If not, then how, exactly, would you see this working? An org which is dissolved no longer exists to keep their IP space, so who is actually keeping it in this case? Owen > > ___Jason > > > On Wed, Sep 30, 2015 at 10:42 PM, Owen DeLong > wrote: > Dani, > > In fairness to Bill, I think he may also have chosen them because I suggested that those would be boundaries I would consider livable. > > I believe they represent a good size to guarantee that small organizations are not shut out of the transfer market based on size, but still ensure that need assessment is preserved in order to prevent acquisition of addresses without intended use thereof. > > While a /20 is a fair quantity of addresses (4096), it?s a pretty small number of customers for an ISP in most cases and I think anything smaller would be somewhat punitive. > > It does also line up well with transfer history and other ARIN data about small-ish organizations and address issuance over the last several years. > > Owen > >> On Sep 30, 2015, at 03:52 , Dani Roisman > wrote: >> >> Hi Bill, >> >> I?m interested to learn how you came up with the below proposed netblock sizes ?/20 if a ISP or /22 for an end user? ? Is there data behind that? If not, does it make sense to ask ARIN to supply data regarding sizes of transfers which have occurred in the past 12 - 18 months? >> >> -- >> Dani Roisman >> >> ________________________________ >> From: "Bill Buhler" >> >> To: "owen" >> >> Cc: arin-ppml at arin.net> >> Sent: Monday, September 28, 2015 12:59:30 PM >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks >> >> OK, how about this: >> >> Small end users and ISPs are allowed to obtain IPv4 address blocks without a needs test as long as the following criteria are met: >> >> >> a. The total size of their ARIN allocations at any time of the process does not exceed a /20 if a ISP or /22 for an end user. >> >> b. They cannot purchase IP address from the transfer market more than three total times to reach this size, including the initial operation. >> >> c. None of the addresses purchased can be transferred to any other entity for twenty-four months following the date of the last transfer. >> >> d. If the company ceases operations within the twenty-four month window the addresses are automatically transferred to the ARIN free pool. After that period of time regular transfer rights exist. >> >> e. All subsequent allocations / transfers require regular needs testing after the initial twenty-four month allocation window. >> >> f. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. >> >> ------------------- >> >> I believe that meets all of your concerns. I would prefer companies get everything they think they will need in one operation, but I don?t want to have fear drive them into buying the max amount just in case. >> >> Best regards, >> >> Bill Buhler >> >> _______________________________________________ >> 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. > > > _______________________________________________ > 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: From jschiller at google.com Thu Oct 8 01:00:51 2015 From: jschiller at google.com (Jason Schiller) Date: Thu, 8 Oct 2015 01:00:51 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: References: <56031175.5040102@arin.net> Message-ID: I'm not sure I follow the impact of the change here. Under current policy if an ISP assigns only /48s to each customer, then I count the number of customer and consider than many /48s as fully utilized. Under current policy if an ISP assigns only /56s to each customer, then I count the number of customer and consider than many /56s as fully utilized. Under current policy if an ISP assigns a mix of /48s to each large customer, and /56s to each small customer then I count the number of small customer and consider than many /56s as fully utilized and, I count the number of large customers time 256 and count that many /56s as fully used. (this means unused /56s out of a /48 are counted against you thus discouraging mixed sizes). Under current policy if an ISP assigns only /60s to each customer, then I count the number of customer and consider that number divided by 16 as the number of /56s as fully utilized. Under the proposed policy only the last case changes. Under the proposed policy if an ISP assigns only /60s to each customer, then those customers having a /60 (smaller than a /56) are not counted as utilized by the ISP. Is that correct? In general I am not opposed to discouraging ISPs from giving out smaller than a /56, unless the customer specifically requests a small block. ___Jason On Mon, Sep 28, 2015 at 11:35 AM, John Springer wrote: > Thanks, Matt > > This is precisely the subject on which I hoped to get community feedback. > > John Springer > > > On Sat, 26 Sep 2015, Matthew Petach wrote: > > OPPOSED >> >> How I subdivide and allocate addresses >> internally and downstream is not a matter >> for the community to vote on; that's between >> me and my customers. >> >> Matt >> >> >> On Wed, Sep 23, 2015 at 1:54 PM, ARIN wrote: >> >>> Draft Policy ARIN-2015-10 >>> Minimum IPv6 Assignments >>> >>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>> "ARIN-prop-224 >>> Minimum IPv6 Assignments" as a Draft Policy. >>> >>> Draft Policy ARIN-2015-10 is below and can be found at: >>> https://www.arin.net/policy/proposals/2015_10.html >>> >>> You are encouraged to discuss the merits and your concerns of Draft >>> Policy 2015-10 on the Public Policy Mailing List. >>> >>> 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 PDP. Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> The ARIN Policy Development Process (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-2015-10 >>> Minimum IPv6 Assignments >>> >>> Date: 23 September 2015 >>> >>> Problem Statement: >>> >>> ISPs may believe that they have an incentive to obtain smaller blocks >>> than >>> they really need, and once they receive their allocation may subsequently >>> issue blocks smaller than their customers may need in the future. This >>> policy seeks to encourage the correct behavior by reiterating the >>> smallest >>> reasonable sub-allocation size and by discounting any space which has >>> been >>> subdivided more finely from any future utilization analysis. >>> >>> Policy statement: >>> >>> Modify section 2.15 from "When applied to IPv6 policies, the term >>> "provider >>> assignment unit" shall mean the prefix of the smallest block a given ISP >>> assigns to end sites (recommended /48)." to "When applied to IPv6 >>> policies, >>> the term "provider assignment unit" shall mean the prefix of the smallest >>> block a given ISP assigns to end sites. A /48 is recommended as this >>> smallest block size. In no case shall a provider assignment unit for the >>> purpose of this policy be smaller than /56." >>> >>> Modify section 2.16.1 from "A provider assignment unit shall be >>> considered >>> fully utilized when it is assigned to an end-site" to "A provider >>> assignment >>> unit shall be considered fully utilized when it is assigned in full (or >>> as >>> part of a larger aggregate) to a single end-site. If a provider >>> assignment >>> unit (which shall be no smaller than /56) is split and assigned to >>> multiple >>> end-sites that entire provider assignment unit shall be considered NOT >>> utilized." >>> >>> Comments: >>> 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. >>> >>> _______________________________________________ >> 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. >> >> >> _______________________________________________ > 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: From hannigan at gmail.com Thu Oct 8 01:01:49 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 8 Oct 2015 01:01:49 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users In-Reply-To: <4AD333A0-C403-4A6F-84EF-11ED5A949597@corp.arin.net> References: <55DCBE0D.8010802@arin.net> <009201d0e023$42c24710$c846d530$@giesen.me> <55DE0687.4010601@quark.net> <009901d0e032$8e745680$ab5d0380$@giesen.me> <55DF3CED.6050607@quark.net> <031c01d0e1b2$e4b0e190$ae12a4b0$@giesen.me> <55E09EF1.5070206@quark.net> <031e01d0e1ba$dedc4a90$9c94dfb0$@giesen.me> <4AD333A0-C403-4A6F-84EF-11ED5A949597@corp.arin.net> Message-ID: On Fri, Aug 28, 2015 at 4:05 PM, John Curran wrote: > On Aug 28, 2015, at 1:56 PM, Gary T. Giesen wrote: > > Not to beat a dead horse, but I think if an org wants to (or is required > to) > > make assignments to entities that don't fit that definition, then they > > should apply for an ISP block (or have their existing block converted) > and > > pay the appropriate fees, and allow the rest of us to keep end-user fees > > low. > > We have had a handful of organizations switch from end-user to ISP for the > purposes of being able to put in reassignment records (e.g. to improve the > usefulness of geolocation), but it is almost certain that others having > avoided > such a change due to the cost implications. > What's the process to make such a change? Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Oct 8 01:40:51 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 7 Oct 2015 22:40:51 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: References: <56031175.5040102@arin.net> Message-ID: <4CDBC688-5D20-4A85-882C-4EEEEA7FEEBB@delong.com> > On Oct 7, 2015, at 10:00 PM, Jason Schiller wrote: > > I'm not sure I follow the impact of the change here. > > Under current policy if an ISP assigns only /48s to each customer, then I count the number of customer and consider than many /48s as fully utilized. > > Under current policy if an ISP assigns only /56s to each customer, then I count the number of customer and consider than many /56s as fully utilized. > > Under current policy if an ISP assigns a mix of /48s to each large customer, and /56s to each small customer > then I count the number of small customer and consider than many /56s as fully utilized and, > I count the number of large customers time 256 and count that many /56s as fully used. > (this means unused /56s out of a /48 are counted against you thus discouraging mixed sizes). You left out the part where you have to justify issuing that many /56s to each of those large customers. > Under current policy if an ISP assigns only /60s to each customer, then I count the number of customer and consider that number divided by 16 as the number of /56s as fully utilized. Well, actually, you just count everything as /60s in this case under current policy. > Under the proposed policy only the last case changes. > > Under the proposed policy if an ISP assigns only /60s to each customer, then those customers having a /60 (smaller than a /56) are not counted as utilized by the ISP. Correct. Owen > > > Is that correct? > > In general I am not opposed to discouraging ISPs from giving out smaller than a /56, unless the customer specifically requests a small block. > > > ___Jason > > > On Mon, Sep 28, 2015 at 11:35 AM, John Springer > wrote: > Thanks, Matt > > This is precisely the subject on which I hoped to get community feedback. > > John Springer > > > On Sat, 26 Sep 2015, Matthew Petach wrote: > > OPPOSED > > How I subdivide and allocate addresses > internally and downstream is not a matter > for the community to vote on; that's between > me and my customers. > > Matt > > > On Wed, Sep 23, 2015 at 1:54 PM, ARIN > wrote: > Draft Policy ARIN-2015-10 > Minimum IPv6 Assignments > > On 17 September 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-224 > Minimum IPv6 Assignments" as a Draft Policy. > > Draft Policy ARIN-2015-10 is below and can be found at: > https://www.arin.net/policy/proposals/2015_10.html > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2015-10 on the Public Policy Mailing List. > > 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 PDP. Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The ARIN Policy Development Process (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-2015-10 > Minimum IPv6 Assignments > > Date: 23 September 2015 > > Problem Statement: > > ISPs may believe that they have an incentive to obtain smaller blocks than > they really need, and once they receive their allocation may subsequently > issue blocks smaller than their customers may need in the future. This > policy seeks to encourage the correct behavior by reiterating the smallest > reasonable sub-allocation size and by discounting any space which has been > subdivided more finely from any future utilization analysis. > > Policy statement: > > Modify section 2.15 from "When applied to IPv6 policies, the term "provider > assignment unit" shall mean the prefix of the smallest block a given ISP > assigns to end sites (recommended /48)." to "When applied to IPv6 policies, > the term "provider assignment unit" shall mean the prefix of the smallest > block a given ISP assigns to end sites. A /48 is recommended as this > smallest block size. In no case shall a provider assignment unit for the > purpose of this policy be smaller than /56." > > Modify section 2.16.1 from "A provider assignment unit shall be considered > fully utilized when it is assigned to an end-site" to "A provider assignment > unit shall be considered fully utilized when it is assigned in full (or as > part of a larger aggregate) to a single end-site. If a provider assignment > unit (which shall be no smaller than /56) is split and assigned to multiple > end-sites that entire provider assignment unit shall be considered NOT > utilized." > > Comments: > 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. > > _______________________________________________ > 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. > > > _______________________________________________ > 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 > > _______________________________________________ > 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: From jcurran at arin.net Thu Oct 8 06:46:47 2015 From: jcurran at arin.net (John Curran) Date: Thu, 8 Oct 2015 10:46:47 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users In-Reply-To: References: <55DCBE0D.8010802@arin.net> <009201d0e023$42c24710$c846d530$@giesen.me> <55DE0687.4010601@quark.net> <009901d0e032$8e745680$ab5d0380$@giesen.me> <55DF3CED.6050607@quark.net> <031c01d0e1b2$e4b0e190$ae12a4b0$@giesen.me> <55E09EF1.5070206@quark.net> <031e01d0e1ba$dedc4a90$9c94dfb0$@giesen.me> <4AD333A0-C403-4A6F-84EF-11ED5A949597@corp.arin.net> Message-ID: <4B90B50F-88F3-462B-BB2E-54400899767B@arin.net> On Oct 8, 2015, at 1:01 AM, Martin Hannigan > wrote: On Fri, Aug 28, 2015 at 4:05 PM, John Curran > wrote: On Aug 28, 2015, at 1:56 PM, Gary T. Giesen > wrote: > Not to beat a dead horse, but I think if an org wants to (or is required to) > make assignments to entities that don't fit that definition, then they > should apply for an ISP block (or have their existing block converted) and > pay the appropriate fees, and allow the rest of us to keep end-user fees > low. We have had a handful of organizations switch from end-user to ISP for the purposes of being able to put in reassignment records (e.g. to improve the usefulness of geolocation), but it is almost certain that others having avoided such a change due to the cost implications. What's the process to make such a change? We?ve had so few requests of that type that there is no process; we really need to hear from the community about whether there needs to be two different service levels (end-users, who cannot sub delegate & ISPs, who can) or whether we can provide the same registry services to all organizations. Long-term, there will be a substantial fee differential between end-users and ISPs due to the very material difference in assignment sizes under IPv6 policies, so we?ll end up at the same place in the end, but the question remains how to handle services and fees in the meantime. We?ll have some time to explore this topic later today during the Fee Schedule discussion. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggiesen+arin-ppml at giesen.me Thu Oct 8 10:28:37 2015 From: ggiesen+arin-ppml at giesen.me (Gary T. Giesen) Date: Thu, 8 Oct 2015 10:28:37 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-11: Remove transfer language which only applied pre-exhaustion of IPv4 pool In-Reply-To: References: <56031186.5040407@arin.net> Message-ID: <04b701d101d5$9feff4e0$dfcfdea0$@giesen.me> Based on the confusion during the discussion at ARIN 36, it's clear to me we need to further this policy. I support it as written. Should we have a free pool some years into the future (when presumably IPv4 is generally no longer useful, or useful to only a small subset of users), we can re-address policy requirements at that time, should the need arise. GTG -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Azinger, Marla Sent: October-06-15 12:27 PM To: ARIN ; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-11: Remove transfer language which only applied pre-exhaustion of IPv4 pool For clarity sake. If this is removed, does that mean it's never added back in should ARIN actually get V4 space back in the free pool? Either way I support removing this policy. I think it shouldn't have existed to begin with. It was not written well enough and unintentionally inhibited reasonable business practices. Regards Marla Azinger -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, September 23, 2015 1:55 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2015-11: Remove transfer language which only applied pre-exhaustion of IPv4 pool Draft Policy ARIN-2015-11 Remove transfer language which only applied pre-exhaustion of IPv4 pool On 17 September 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-225 Remove transfer language which only applied pre-exhaustion of IPv4 pool" as a Draft Policy. Draft Policy ARIN-2015-11 is below and can be found at: https://www.arin.net/policy/proposals/2015_11.html You are encouraged to discuss the merits and your concerns of Draft Policy 2015-11 on the Public Policy Mailing List. 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 PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (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-2015-11 Remove transfer language which only applied pre-exhaustion of IPv4 pool Date: 23 September 2015 Problem Statement: The current policies in NRPM sections 8.3, and 8.4 include language which is in effect "until exhaustion." As ARIN is no longer able to fulfil IPv4 requests (per 01 July 2015 press release https://www.arin.net/about_us/media/releases/20150701.html), exhaustion has effectively occurred. This proposal serves to remove the outdated language from the NRPM. Policy statement: Remove sections of the NRPM which were only affective until IPv4 pool exhaustion occurred, as follows: Section 8.3 Transfers between Specified Recipients within the ARIN Region: - Remove entirely the second bullet which reads "The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first." Section 8.4 Inter-RIR Transfers to Specified Recipients: - Remove entirely the third bullet which reads "Source entities within the ARIN region will not be eligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first." Comments: 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. ________________________________ This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. _______________________________________________ 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. From jschiller at google.com Thu Oct 8 12:43:15 2015 From: jschiller at google.com (Jason Schiller) Date: Thu, 8 Oct 2015 12:43:15 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: <4CDBC688-5D20-4A85-882C-4EEEEA7FEEBB@delong.com> References: <56031175.5040102@arin.net> <4CDBC688-5D20-4A85-882C-4EEEEA7FEEBB@delong.com> Message-ID: Owen, >> You left out the part where you have to justify issuing that many /56s to each of those large customers. I believe if an ISP gives N number of /64s to a single end-site transit customer, so long a N < 65537 it is justified under ARIN policy. So for an ISP that assigns a mix of /48 and /56 no additional justification is required to count all of the /56s given to a /48 sized customer. 6.5.4. Assignments from LIRs/ISPs Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. 6.5.8.2. Initial assignment size Organizations that meet at least one of the initial assignment criteria above are eligible to receive an initial assignment of /48. I think the final point that you agree with is the meet of the proposal... you don't get to count any utilization by customers if they take smaller than a /56. __Jason __Jason On Thu, Oct 8, 2015 at 1:40 AM, Owen DeLong wrote: > > On Oct 7, 2015, at 10:00 PM, Jason Schiller wrote: > > I'm not sure I follow the impact of the change here. > > Under current policy if an ISP assigns only /48s to each customer, then I > count the number of customer and consider than many /48s as fully utilized. > > Under current policy if an ISP assigns only /56s to each customer, then I > count the number of customer and consider than many /56s as fully utilized. > > Under current policy if an ISP assigns a mix of /48s to each large customer, > and /56s to each small customer > then I count the number of small customer and consider than many /56s as > fully utilized and, > I count the number of large customers time 256 and count that many /56s as > fully used. > (this means unused /56s out of a /48 are counted against you thus > discouraging mixed sizes). > > > You left out the part where you have to justify issuing that many /56s to > each of those large customers. > > Under current policy if an ISP assigns only /60s to each customer, then I > count the number of customer and consider that number divided by 16 as the > number of /56s as fully utilized. > > > Well, actually, you just count everything as /60s in this case under current > policy. > > Under the proposed policy only the last case changes. > > Under the proposed policy if an ISP assigns only /60s to each customer, then > those customers having a /60 (smaller than a /56) are not counted as > utilized by the ISP. > > > Correct. > > Owen > > > > Is that correct? > > In general I am not opposed to discouraging ISPs from giving out smaller > than a /56, unless the customer specifically requests a small block. > > > ___Jason > > > On Mon, Sep 28, 2015 at 11:35 AM, John Springer > wrote: >> >> Thanks, Matt >> >> This is precisely the subject on which I hoped to get community feedback. >> >> John Springer >> >> >> On Sat, 26 Sep 2015, Matthew Petach wrote: >> >>> OPPOSED >>> >>> How I subdivide and allocate addresses >>> internally and downstream is not a matter >>> for the community to vote on; that's between >>> me and my customers. >>> >>> Matt >>> >>> >>> On Wed, Sep 23, 2015 at 1:54 PM, ARIN wrote: >>>> >>>> Draft Policy ARIN-2015-10 >>>> Minimum IPv6 Assignments >>>> >>>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>>> "ARIN-prop-224 >>>> Minimum IPv6 Assignments" as a Draft Policy. >>>> >>>> Draft Policy ARIN-2015-10 is below and can be found at: >>>> https://www.arin.net/policy/proposals/2015_10.html >>>> >>>> You are encouraged to discuss the merits and your concerns of Draft >>>> Policy 2015-10 on the Public Policy Mailing List. >>>> >>>> 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 PDP. Specifically, these principles are: >>>> >>>> * Enabling Fair and Impartial Number Resource Administration >>>> * Technically Sound >>>> * Supported by the Community >>>> >>>> The ARIN Policy Development Process (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-2015-10 >>>> Minimum IPv6 Assignments >>>> >>>> Date: 23 September 2015 >>>> >>>> Problem Statement: >>>> >>>> ISPs may believe that they have an incentive to obtain smaller blocks >>>> than >>>> they really need, and once they receive their allocation may >>>> subsequently >>>> issue blocks smaller than their customers may need in the future. This >>>> policy seeks to encourage the correct behavior by reiterating the >>>> smallest >>>> reasonable sub-allocation size and by discounting any space which has >>>> been >>>> subdivided more finely from any future utilization analysis. >>>> >>>> Policy statement: >>>> >>>> Modify section 2.15 from "When applied to IPv6 policies, the term >>>> "provider >>>> assignment unit" shall mean the prefix of the smallest block a given ISP >>>> assigns to end sites (recommended /48)." to "When applied to IPv6 >>>> policies, >>>> the term "provider assignment unit" shall mean the prefix of the >>>> smallest >>>> block a given ISP assigns to end sites. A /48 is recommended as this >>>> smallest block size. In no case shall a provider assignment unit for the >>>> purpose of this policy be smaller than /56." >>>> >>>> Modify section 2.16.1 from "A provider assignment unit shall be >>>> considered >>>> fully utilized when it is assigned to an end-site" to "A provider >>>> assignment >>>> unit shall be considered fully utilized when it is assigned in full (or >>>> as >>>> part of a larger aggregate) to a single end-site. If a provider >>>> assignment >>>> unit (which shall be no smaller than /56) is split and assigned to >>>> multiple >>>> end-sites that entire provider assignment unit shall be considered NOT >>>> utilized." >>>> >>>> Comments: >>>> 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. >>>> >>> _______________________________________________ >>> 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. >>> >>> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 From bjones at vt.edu Thu Oct 8 16:31:42 2015 From: bjones at vt.edu (Brian Jones) Date: Thu, 8 Oct 2015 16:31:42 -0400 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: <73BC964F-CCB4-452A-9580-59C8FB53D159@gmail.com> References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> <55D67B93.9030501@matthew.at> <73BC964F-CCB4-452A-9580-59C8FB53D159@gmail.com> Message-ID: On Fri, Aug 21, 2015 at 10:55 AM, Scott Leibrand wrote: > > On Aug 20, 2015, at 7:17 PM, Brian Jones wrote: > > Mathew, > I think we are in agreement on some level. I don't want valuable resources > to sit idle either. At the same time arbitrarily handing out large blocks > of resources without any real show of need allows for possible misuse of > the resources by those who would hang on to them to get a better price or > for whatever reason they want. > > > The IPv4 free pool is now empty, and there are no more large blocks to > hand out. Is this still a concern when all blocks must be acquired via > transfer? If so, can you explain why that's more of a concern under the > proposed policy than under current policy? > The "large blocks" reference I used is probably not the appropriate wording, but routed blocks matter and should be documented appropriately in order to help keep the Internet routing tables as accurate as possible. I still believe some show of need should be present. Either way the resources sit idle. I am for a reasonable amount of > justification for the amount of resources that can be consumed in a > reasonable time period. Defining reasonable in the last two sentences and > coming to agreement may be the crux of the matter. > > If the organization was mistaken about how many or how fast they would use > the resources, then the process should be able to easily accommodate > transfer, selling, or returning them as long as they follow procedures to > ensure that documentation records of the resources can be appropriately > updated for the good of the Internet. > > In the end there is really not a good way to prevent unused addresses > sitting idle. It is up to the recipients of justified resources to be good > stewards and use them appropriately and hopefully transfer, sell, or return > them if they no longer need them. > > > Totally agreed. > > -Scott > > > On Aug 20, 2015 9:15 PM, "Matthew Kaufman" wrote: > >> On 8/20/2015 1:04 PM, Brian Jones wrote: >> >> >> ?I agree with this simplified requirement but would even be willing to >> accept a 50% within 12 months and 75% in 24 months requirement. Two years >> is a long time to tie up valuable resources that are not being used. IMHO? >> >> >> I do not understand this reasoning. There is no more free pool. If Org A >> is not using "valuable resources" and they are transferred to Org B who was >> mistaken about how fast they will use them, then Org B is also not using >> "valuable resources". But if instead Org A can't transfer them, then Org B >> doesn't get them and Org A still has "valuable resources" which are "tied >> up". They're "tied up" not being used either way... and ARIN can't do >> anything about it. >> >> If you really want to make sure that these resources don't sit unused, >> make it so that after Org A transfers to Org B then if Org B doesn't use >> all of them, Org B can sell what they're not using. >> >> Matthew Kaufman >> >> _______________________________________________ >> 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. >> > _______________________________________________ > 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: From scottleibrand at gmail.com Thu Oct 8 17:12:35 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 8 Oct 2015 14:12:35 -0700 Subject: [arin-ppml] Deleting unnecessary NRPM 4 text Message-ID: In light of this afternoon's discussion about simplification of the NPRM, I thought I'd dust off a post-exhaustion NRPM 4 simplification proposal I wrote a couple years ago. There are a lot of parts that need updating in light of more recent modifications (expect another email later), but there are a few that seem rather simple and uncontroversial. Can anyone think of any reason not to submit a proposal with all four of these? Anyone interested in (co-)authoring it? 1. Delete from 4.1.6 Aggregation the text that reads ?ARIN may reserve space to maximize aggregation possibilities until the implementation of section 10.4.2.2, at which time? Rationale: remove inoperative text 2. Delete section 4.2.1.2 Annual Renewal. Rationale: Remove operational details (already covered by the RSA and ARIN procedures) from NRPM. 3. Delete section 4.2.2.1.1. Use of /24 Rationale: After exhaustion, many organizations can no longer get a /24 from their upstream ISP, and need to be able to get their initial allocation from ARIN. 4. Delete section 4.2.3.2. VLSM Rationale: VLSM and CIDR are now standard practice, and don?t need to be called out in NRPM. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Oct 8 17:59:48 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Oct 2015 14:59:48 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: References: <56031175.5040102@arin.net> <4CDBC688-5D20-4A85-882C-4EEEEA7FEEBB@delong.com> Message-ID: <13A519ED-7094-4B43-B3BD-4AAF31ABF412@delong.com> > On Oct 8, 2015, at 9:43 AM, Jason Schiller wrote: > > Owen, > >>> You left out the part where you have to justify issuing that many /56s to each of those large customers. > > I believe if an ISP gives N number of /64s to a single end-site > transit customer, so long a N < 65537 it is justified under ARIN > policy. I don?t think that is true under the policy as written. > So for an ISP that assigns a mix of /48 and /56 no additional > justification is required to count all of the /56s given to a /48 > sized customer. That is not the way the policy is written. Staff may be misinterpreting it that way (wouldn?t be the first time), but that is not the way it is written. The PAU is the unit of measure for ALL of your utilization. You get a blanket justification for up to a /48 as your PAU, but if you choose a smaller PAU, then you have to justify any site issued more than one PAU based on its need for more than one PAU. Owen > > > 6.5.4. Assignments from LIRs/ISPs > > Assignments to end users shall be governed by the same practices > adopted by the community in section 6.5.8 except that the requirements > in 6.5.8.1 do not apply. > > 6.5.8.2. Initial assignment size > > Organizations that meet at least one of the initial assignment > criteria above are eligible to receive an initial assignment of /48. > > > I think the final point that you agree with is the meet of the > proposal... you don't get to count any utilization by customers if > they take smaller than a /56. > > __Jason > > __Jason > > On Thu, Oct 8, 2015 at 1:40 AM, Owen DeLong wrote: >> >> On Oct 7, 2015, at 10:00 PM, Jason Schiller wrote: >> >> I'm not sure I follow the impact of the change here. >> >> Under current policy if an ISP assigns only /48s to each customer, then I >> count the number of customer and consider than many /48s as fully utilized. >> >> Under current policy if an ISP assigns only /56s to each customer, then I >> count the number of customer and consider than many /56s as fully utilized. >> >> Under current policy if an ISP assigns a mix of /48s to each large customer, >> and /56s to each small customer >> then I count the number of small customer and consider than many /56s as >> fully utilized and, >> I count the number of large customers time 256 and count that many /56s as >> fully used. >> (this means unused /56s out of a /48 are counted against you thus >> discouraging mixed sizes). >> >> >> You left out the part where you have to justify issuing that many /56s to >> each of those large customers. >> >> Under current policy if an ISP assigns only /60s to each customer, then I >> count the number of customer and consider that number divided by 16 as the >> number of /56s as fully utilized. >> >> >> Well, actually, you just count everything as /60s in this case under current >> policy. >> >> Under the proposed policy only the last case changes. >> >> Under the proposed policy if an ISP assigns only /60s to each customer, then >> those customers having a /60 (smaller than a /56) are not counted as >> utilized by the ISP. >> >> >> Correct. >> >> Owen >> >> >> >> Is that correct? >> >> In general I am not opposed to discouraging ISPs from giving out smaller >> than a /56, unless the customer specifically requests a small block. >> >> >> ___Jason >> >> >> On Mon, Sep 28, 2015 at 11:35 AM, John Springer >> wrote: >>> >>> Thanks, Matt >>> >>> This is precisely the subject on which I hoped to get community feedback. >>> >>> John Springer >>> >>> >>> On Sat, 26 Sep 2015, Matthew Petach wrote: >>> >>>> OPPOSED >>>> >>>> How I subdivide and allocate addresses >>>> internally and downstream is not a matter >>>> for the community to vote on; that's between >>>> me and my customers. >>>> >>>> Matt >>>> >>>> >>>> On Wed, Sep 23, 2015 at 1:54 PM, ARIN wrote: >>>>> >>>>> Draft Policy ARIN-2015-10 >>>>> Minimum IPv6 Assignments >>>>> >>>>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>>>> "ARIN-prop-224 >>>>> Minimum IPv6 Assignments" as a Draft Policy. >>>>> >>>>> Draft Policy ARIN-2015-10 is below and can be found at: >>>>> https://www.arin.net/policy/proposals/2015_10.html >>>>> >>>>> You are encouraged to discuss the merits and your concerns of Draft >>>>> Policy 2015-10 on the Public Policy Mailing List. >>>>> >>>>> 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 PDP. Specifically, these principles are: >>>>> >>>>> * Enabling Fair and Impartial Number Resource Administration >>>>> * Technically Sound >>>>> * Supported by the Community >>>>> >>>>> The ARIN Policy Development Process (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-2015-10 >>>>> Minimum IPv6 Assignments >>>>> >>>>> Date: 23 September 2015 >>>>> >>>>> Problem Statement: >>>>> >>>>> ISPs may believe that they have an incentive to obtain smaller blocks >>>>> than >>>>> they really need, and once they receive their allocation may >>>>> subsequently >>>>> issue blocks smaller than their customers may need in the future. This >>>>> policy seeks to encourage the correct behavior by reiterating the >>>>> smallest >>>>> reasonable sub-allocation size and by discounting any space which has >>>>> been >>>>> subdivided more finely from any future utilization analysis. >>>>> >>>>> Policy statement: >>>>> >>>>> Modify section 2.15 from "When applied to IPv6 policies, the term >>>>> "provider >>>>> assignment unit" shall mean the prefix of the smallest block a given ISP >>>>> assigns to end sites (recommended /48)." to "When applied to IPv6 >>>>> policies, >>>>> the term "provider assignment unit" shall mean the prefix of the >>>>> smallest >>>>> block a given ISP assigns to end sites. A /48 is recommended as this >>>>> smallest block size. In no case shall a provider assignment unit for the >>>>> purpose of this policy be smaller than /56." >>>>> >>>>> Modify section 2.16.1 from "A provider assignment unit shall be >>>>> considered >>>>> fully utilized when it is assigned to an end-site" to "A provider >>>>> assignment >>>>> unit shall be considered fully utilized when it is assigned in full (or >>>>> as >>>>> part of a larger aggregate) to a single end-site. If a provider >>>>> assignment >>>>> unit (which shall be no smaller than /56) is split and assigned to >>>>> multiple >>>>> end-sites that entire provider assignment unit shall be considered NOT >>>>> utilized." >>>>> >>>>> Comments: >>>>> 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. >>>>> >>>> _______________________________________________ >>>> 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. >>>> >>>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 From hvgeekwtrvl at gmail.com Thu Oct 8 20:02:07 2015 From: hvgeekwtrvl at gmail.com (james machado) Date: Thu, 8 Oct 2015 17:02:07 -0700 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: <13A519ED-7094-4B43-B3BD-4AAF31ABF412@delong.com> References: <56031175.5040102@arin.net> <4CDBC688-5D20-4A85-882C-4EEEEA7FEEBB@delong.com> <13A519ED-7094-4B43-B3BD-4AAF31ABF412@delong.com> Message-ID: On Thu, Oct 8, 2015 at 2:59 PM, Owen DeLong wrote: > >> On Oct 8, 2015, at 9:43 AM, Jason Schiller wrote: >> >> Owen, >> >>>> You left out the part where you have to justify issuing that many /56s to each of those large customers. >> >> I believe if an ISP gives N number of /64s to a single end-site >> transit customer, so long a N < 65537 it is justified under ARIN >> policy. > > I don?t think that is true under the policy as written. > >> So for an ISP that assigns a mix of /48 and /56 no additional >> justification is required to count all of the /56s given to a /48 >> sized customer. > > That is not the way the policy is written. Staff may be misinterpreting it that > way (wouldn?t be the first time), but that is not the way it is written. > > The PAU is the unit of measure for ALL of your utilization. You get a blanket > justification for up to a /48 as your PAU, but if you choose a smaller PAU, then > you have to justify any site issued more than one PAU based on its need for > more than one PAU. > > Owen > >> >> >> 6.5.4. Assignments from LIRs/ISPs >> >> Assignments to end users shall be governed by the same practices >> adopted by the community in section 6.5.8 except that the requirements >> in 6.5.8.1 do not apply. >> >> 6.5.8.2. Initial assignment size >> >> Organizations that meet at least one of the initial assignment >> criteria above are eligible to receive an initial assignment of /48. >> >> >> I think the final point that you agree with is the meet of the >> proposal... you don't get to count any utilization by customers if >> they take smaller than a /56. >> >> __Jason >> >> __Jason >> >> On Thu, Oct 8, 2015 at 1:40 AM, Owen DeLong wrote: >>> >>> On Oct 7, 2015, at 10:00 PM, Jason Schiller wrote: >>> >>> I'm not sure I follow the impact of the change here. >>> >>> Under current policy if an ISP assigns only /48s to each customer, then I >>> count the number of customer and consider than many /48s as fully utilized. >>> >>> Under current policy if an ISP assigns only /56s to each customer, then I >>> count the number of customer and consider than many /56s as fully utilized. >>> >>> Under current policy if an ISP assigns a mix of /48s to each large customer, >>> and /56s to each small customer >>> then I count the number of small customer and consider than many /56s as >>> fully utilized and, >>> I count the number of large customers time 256 and count that many /56s as >>> fully used. >>> (this means unused /56s out of a /48 are counted against you thus >>> discouraging mixed sizes). >>> >>> >>> You left out the part where you have to justify issuing that many /56s to >>> each of those large customers. >>> >>> Under current policy if an ISP assigns only /60s to each customer, then I >>> count the number of customer and consider that number divided by 16 as the >>> number of /56s as fully utilized. >>> >>> >>> Well, actually, you just count everything as /60s in this case under current >>> policy. >>> >>> Under the proposed policy only the last case changes. >>> >>> Under the proposed policy if an ISP assigns only /60s to each customer, then >>> those customers having a /60 (smaller than a /56) are not counted as >>> utilized by the ISP. >>> >>> >>> Correct. >>> >>> Owen >>> >>> >>> >>> Is that correct? >>> >>> In general I am not opposed to discouraging ISPs from giving out smaller >>> than a /56, unless the customer specifically requests a small block. >>> >>> >>> ___Jason >>> >>> >>> On Mon, Sep 28, 2015 at 11:35 AM, John Springer >>> wrote: >>>> >>>> Thanks, Matt >>>> >>>> This is precisely the subject on which I hoped to get community feedback. >>>> >>>> John Springer >>>> >>>> >>>> On Sat, 26 Sep 2015, Matthew Petach wrote: >>>> >>>>> OPPOSED >>>>> >>>>> How I subdivide and allocate addresses >>>>> internally and downstream is not a matter >>>>> for the community to vote on; that's between >>>>> me and my customers. >>>>> >>>>> Matt >>>>> >>>>> >>>>> On Wed, Sep 23, 2015 at 1:54 PM, ARIN wrote: >>>>>> >>>>>> Draft Policy ARIN-2015-10 >>>>>> Minimum IPv6 Assignments >>>>>> >>>>>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>>>>> "ARIN-prop-224 >>>>>> Minimum IPv6 Assignments" as a Draft Policy. >>>>>> >>>>>> Draft Policy ARIN-2015-10 is below and can be found at: >>>>>> https://www.arin.net/policy/proposals/2015_10.html >>>>>> >>>>>> You are encouraged to discuss the merits and your concerns of Draft >>>>>> Policy 2015-10 on the Public Policy Mailing List. >>>>>> >>>>>> 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 PDP. Specifically, these principles are: >>>>>> >>>>>> * Enabling Fair and Impartial Number Resource Administration >>>>>> * Technically Sound >>>>>> * Supported by the Community >>>>>> >>>>>> The ARIN Policy Development Process (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-2015-10 >>>>>> Minimum IPv6 Assignments >>>>>> >>>>>> Date: 23 September 2015 >>>>>> >>>>>> Problem Statement: >>>>>> >>>>>> ISPs may believe that they have an incentive to obtain smaller blocks >>>>>> than >>>>>> they really need, and once they receive their allocation may >>>>>> subsequently >>>>>> issue blocks smaller than their customers may need in the future. This >>>>>> policy seeks to encourage the correct behavior by reiterating the >>>>>> smallest >>>>>> reasonable sub-allocation size and by discounting any space which has >>>>>> been >>>>>> subdivided more finely from any future utilization analysis. >>>>>> >>>>>> Policy statement: >>>>>> >>>>>> Modify section 2.15 from "When applied to IPv6 policies, the term >>>>>> "provider >>>>>> assignment unit" shall mean the prefix of the smallest block a given ISP >>>>>> assigns to end sites (recommended /48)." to "When applied to IPv6 >>>>>> policies, >>>>>> the term "provider assignment unit" shall mean the prefix of the >>>>>> smallest >>>>>> block a given ISP assigns to end sites. A /48 is recommended as this >>>>>> smallest block size. In no case shall a provider assignment unit for the >>>>>> purpose of this policy be smaller than /56." >>>>>> >>>>>> Modify section 2.16.1 from "A provider assignment unit shall be >>>>>> considered >>>>>> fully utilized when it is assigned to an end-site" to "A provider >>>>>> assignment >>>>>> unit shall be considered fully utilized when it is assigned in full (or >>>>>> as >>>>>> part of a larger aggregate) to a single end-site. If a provider >>>>>> assignment >>>>>> unit (which shall be no smaller than /56) is split and assigned to >>>>>> multiple >>>>>> end-sites that entire provider assignment unit shall be considered NOT >>>>>> utilized." >>>>>> >>>>>> Comments: >>>>>> 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. >>>>>> >>>>> _______________________________________________ >>>>> 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. >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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. I oppose this as written, specifically 2.15. If an ISP is going to assign a /60 to a customer site, be it a dwelling or small business then they have chosen to justify utilization for all customers at a /60. Isn't it time we finished the allocation/assignment size argument. Pick the size you want to give to customers. Live with the fallout of your choice. James From narten at us.ibm.com Fri Oct 9 00:53:03 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 09 Oct 2015 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201510090453.t994r3xx026600@rotala.raleigh.ibm.com> Total of 43 messages in the last 7 days. script run at: Fri Oct 9 00:53:03 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 18.60% | 8 | 16.85% | 111465 | marla.azinger at ftr.com 9.30% | 4 | 16.02% | 105984 | owen at delong.com 9.30% | 4 | 12.12% | 80146 | jschiller at google.com 9.30% | 4 | 8.82% | 58327 | scottleibrand at gmail.com 6.98% | 3 | 7.98% | 52819 | bjones at vt.edu 9.30% | 4 | 5.16% | 34118 | hannigan at gmail.com 4.65% | 2 | 4.60% | 30441 | andrew.dul at quark.net 4.65% | 2 | 3.81% | 25208 | farmer at umn.edu 4.65% | 2 | 3.13% | 20710 | jcurran at arin.net 2.33% | 1 | 4.22% | 27894 | sryerse at eclipse-networks.com 4.65% | 2 | 1.84% | 12197 | matthew at matthew.at 2.33% | 1 | 3.22% | 21301 | david.huberman at microsoft.com 2.33% | 1 | 3.15% | 20825 | cspears at oar.net 2.33% | 1 | 3.07% | 20322 | heather.skanks at gmail.com 2.33% | 1 | 2.39% | 15808 | hvgeekwtrvl at gmail.com 2.33% | 1 | 1.56% | 10327 | ggiesen+arin-ppml at giesen.me 2.33% | 1 | 1.18% | 7837 | narten at us.ibm.com 2.33% | 1 | 0.87% | 5759 | bill at herrin.us --------+------+--------+----------+------------------------ 100.00% | 43 |100.00% | 661488 | Total From jrdelacruz at acm.org Fri Oct 9 09:03:09 2015 From: jrdelacruz at acm.org (Jose R. de la Cruz III) Date: Fri, 9 Oct 2015 09:03:09 -0400 Subject: [arin-ppml] Deleting unnecessary NRPM 4 text In-Reply-To: References: Message-ID: Good idea. But maybe the whole NPRM needs to be looked, and not just removing sections. One way to go might be to inspect each section header and decide if the policies included in it are relevant or should be joined with other sections (maybe sections 4 & 6 should be only one). Jose On Thu, Oct 8, 2015 at 5:12 PM, Scott Leibrand wrote: > In light of this afternoon's discussion about simplification of the NPRM, > I thought I'd dust off a post-exhaustion NRPM 4 simplification proposal I > wrote a couple years ago. There are a lot of parts that need updating in > light of more recent modifications (expect another email later), but there > are a few that seem rather simple and uncontroversial. Can anyone think of > any reason not to submit a proposal with all four of these? Anyone > interested in (co-)authoring it? > > > 1. Delete from 4.1.6 Aggregation the text that reads ?ARIN may reserve > space to maximize aggregation possibilities until the implementation of > section 10.4.2.2, at which time? > > Rationale: remove inoperative text > > > > 2. Delete section 4.2.1.2 Annual Renewal. > > Rationale: Remove operational details (already covered by the RSA and ARIN > procedures) from NRPM. > > > > 3. Delete section 4.2.2.1.1. Use of /24 > > Rationale: After exhaustion, many organizations can no longer get a /24 > from their upstream ISP, and need to be able to get their initial > allocation from ARIN. > > > > 4. Delete section 4.2.3.2. VLSM > > Rationale: VLSM and CIDR are now standard practice, and don?t need to be > called out in NRPM. > > > -Scott > > _______________________________________________ > 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: From scottleibrand at gmail.com Fri Oct 9 09:06:28 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 9 Oct 2015 06:06:28 -0700 Subject: [arin-ppml] Deleting unnecessary NRPM 4 text In-Reply-To: References: Message-ID: I totally agree. Are you interested in taking a pass and suggesting any changes you see warranted? -Scott On Fri, Oct 9, 2015 at 6:03 AM, Jose R. de la Cruz III wrote: > Good idea. But maybe the whole NPRM needs to be looked, and not just > removing sections. One way to go might be to inspect each section header > and decide if the policies included in it are relevant or should be joined > with other sections (maybe sections 4 & 6 should be only one). > > Jose > > On Thu, Oct 8, 2015 at 5:12 PM, Scott Leibrand > wrote: > >> In light of this afternoon's discussion about simplification of the NPRM, >> I thought I'd dust off a post-exhaustion NRPM 4 simplification proposal I >> wrote a couple years ago. There are a lot of parts that need updating in >> light of more recent modifications (expect another email later), but there >> are a few that seem rather simple and uncontroversial. Can anyone think of >> any reason not to submit a proposal with all four of these? Anyone >> interested in (co-)authoring it? >> >> >> 1. Delete from 4.1.6 Aggregation the text that reads ?ARIN may reserve >> space to maximize aggregation possibilities until the implementation of >> section 10.4.2.2, at which time? >> >> Rationale: remove inoperative text >> >> >> >> 2. Delete section 4.2.1.2 Annual Renewal. >> >> Rationale: Remove operational details (already covered by the RSA and >> ARIN procedures) from NRPM. >> >> >> >> 3. Delete section 4.2.2.1.1. Use of /24 >> >> Rationale: After exhaustion, many organizations can no longer get a /24 >> from their upstream ISP, and need to be able to get their initial >> allocation from ARIN. >> >> >> >> 4. Delete section 4.2.3.2. VLSM >> >> Rationale: VLSM and CIDR are now standard practice, and don?t need to be >> called out in NRPM. >> >> >> -Scott >> >> _______________________________________________ >> 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: From jschiller at google.com Fri Oct 9 12:04:07 2015 From: jschiller at google.com (Jason Schiller) Date: Fri, 9 Oct 2015 12:04:07 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: <13A519ED-7094-4B43-B3BD-4AAF31ABF412@delong.com> References: <56031175.5040102@arin.net> <4CDBC688-5D20-4A85-882C-4EEEEA7FEEBB@delong.com> <13A519ED-7094-4B43-B3BD-4AAF31ABF412@delong.com> Message-ID: Can ARIN staff please comment? If an ISP give out a mix of /48 and /56 which of the following is true: A. each unique customer end site given a /56 counts as a single /56 at 100% utilized and each unique customer end site given a /48 counts as 256 /56s at 100% utilized B. each unique customer end site given a /56 counts as a single /56 at 100% utilized and each unique customer end site given a /48 counts as one /56 at 100% utilization unless there is specific justification why each /48 customer needs more than 256 /64s If B, then how strong does said justification have to be for example do any of the following work: 1. We give all customers of type X a /56 and of type Y a /48. 2. all customers with a /48 said a /56 wasn't enough 3. we give /56 or /48 based on which box they check on the install survey 4. customer xyz said they plan to have 300 subnets in the next 10 years, customer abc said they have 16 sub-nets per building, each build is 4 geographical zones, and each zone has 4 subnets, student, staff, guest, wifi They have 20 buildings customer def said ... ___Jason On Thu, Oct 8, 2015 at 5:59 PM, Owen DeLong wrote: > >> On Oct 8, 2015, at 9:43 AM, Jason Schiller wrote: >> >> Owen, >> >>>> You left out the part where you have to justify issuing that many /56s to each of those large customers. >> >> I believe if an ISP gives N number of /64s to a single end-site >> transit customer, so long a N < 65537 it is justified under ARIN >> policy. > > I don?t think that is true under the policy as written. > >> So for an ISP that assigns a mix of /48 and /56 no additional >> justification is required to count all of the /56s given to a /48 >> sized customer. > > That is not the way the policy is written. Staff may be misinterpreting it that > way (wouldn?t be the first time), but that is not the way it is written. > > The PAU is the unit of measure for ALL of your utilization. You get a blanket > justification for up to a /48 as your PAU, but if you choose a smaller PAU, then > you have to justify any site issued more than one PAU based on its need for > more than one PAU. > > Owen > >> >> >> 6.5.4. Assignments from LIRs/ISPs >> >> Assignments to end users shall be governed by the same practices >> adopted by the community in section 6.5.8 except that the requirements >> in 6.5.8.1 do not apply. >> >> 6.5.8.2. Initial assignment size >> >> Organizations that meet at least one of the initial assignment >> criteria above are eligible to receive an initial assignment of /48. >> >> >> I think the final point that you agree with is the meet of the >> proposal... you don't get to count any utilization by customers if >> they take smaller than a /56. >> >> __Jason >> >> __Jason >> >> On Thu, Oct 8, 2015 at 1:40 AM, Owen DeLong wrote: >>> >>> On Oct 7, 2015, at 10:00 PM, Jason Schiller wrote: >>> >>> I'm not sure I follow the impact of the change here. >>> >>> Under current policy if an ISP assigns only /48s to each customer, then I >>> count the number of customer and consider than many /48s as fully utilized. >>> >>> Under current policy if an ISP assigns only /56s to each customer, then I >>> count the number of customer and consider than many /56s as fully utilized. >>> >>> Under current policy if an ISP assigns a mix of /48s to each large customer, >>> and /56s to each small customer >>> then I count the number of small customer and consider than many /56s as >>> fully utilized and, >>> I count the number of large customers time 256 and count that many /56s as >>> fully used. >>> (this means unused /56s out of a /48 are counted against you thus >>> discouraging mixed sizes). >>> >>> >>> You left out the part where you have to justify issuing that many /56s to >>> each of those large customers. >>> >>> Under current policy if an ISP assigns only /60s to each customer, then I >>> count the number of customer and consider that number divided by 16 as the >>> number of /56s as fully utilized. >>> >>> >>> Well, actually, you just count everything as /60s in this case under current >>> policy. >>> >>> Under the proposed policy only the last case changes. >>> >>> Under the proposed policy if an ISP assigns only /60s to each customer, then >>> those customers having a /60 (smaller than a /56) are not counted as >>> utilized by the ISP. >>> >>> >>> Correct. >>> >>> Owen >>> >>> >>> >>> Is that correct? >>> >>> In general I am not opposed to discouraging ISPs from giving out smaller >>> than a /56, unless the customer specifically requests a small block. >>> >>> >>> ___Jason >>> >>> >>> On Mon, Sep 28, 2015 at 11:35 AM, John Springer >>> wrote: >>>> >>>> Thanks, Matt >>>> >>>> This is precisely the subject on which I hoped to get community feedback. >>>> >>>> John Springer >>>> >>>> >>>> On Sat, 26 Sep 2015, Matthew Petach wrote: >>>> >>>>> OPPOSED >>>>> >>>>> How I subdivide and allocate addresses >>>>> internally and downstream is not a matter >>>>> for the community to vote on; that's between >>>>> me and my customers. >>>>> >>>>> Matt >>>>> >>>>> >>>>> On Wed, Sep 23, 2015 at 1:54 PM, ARIN wrote: >>>>>> >>>>>> Draft Policy ARIN-2015-10 >>>>>> Minimum IPv6 Assignments >>>>>> >>>>>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>>>>> "ARIN-prop-224 >>>>>> Minimum IPv6 Assignments" as a Draft Policy. >>>>>> >>>>>> Draft Policy ARIN-2015-10 is below and can be found at: >>>>>> https://www.arin.net/policy/proposals/2015_10.html >>>>>> >>>>>> You are encouraged to discuss the merits and your concerns of Draft >>>>>> Policy 2015-10 on the Public Policy Mailing List. >>>>>> >>>>>> 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 PDP. Specifically, these principles are: >>>>>> >>>>>> * Enabling Fair and Impartial Number Resource Administration >>>>>> * Technically Sound >>>>>> * Supported by the Community >>>>>> >>>>>> The ARIN Policy Development Process (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-2015-10 >>>>>> Minimum IPv6 Assignments >>>>>> >>>>>> Date: 23 September 2015 >>>>>> >>>>>> Problem Statement: >>>>>> >>>>>> ISPs may believe that they have an incentive to obtain smaller blocks >>>>>> than >>>>>> they really need, and once they receive their allocation may >>>>>> subsequently >>>>>> issue blocks smaller than their customers may need in the future. This >>>>>> policy seeks to encourage the correct behavior by reiterating the >>>>>> smallest >>>>>> reasonable sub-allocation size and by discounting any space which has >>>>>> been >>>>>> subdivided more finely from any future utilization analysis. >>>>>> >>>>>> Policy statement: >>>>>> >>>>>> Modify section 2.15 from "When applied to IPv6 policies, the term >>>>>> "provider >>>>>> assignment unit" shall mean the prefix of the smallest block a given ISP >>>>>> assigns to end sites (recommended /48)." to "When applied to IPv6 >>>>>> policies, >>>>>> the term "provider assignment unit" shall mean the prefix of the >>>>>> smallest >>>>>> block a given ISP assigns to end sites. A /48 is recommended as this >>>>>> smallest block size. In no case shall a provider assignment unit for the >>>>>> purpose of this policy be smaller than /56." >>>>>> >>>>>> Modify section 2.16.1 from "A provider assignment unit shall be >>>>>> considered >>>>>> fully utilized when it is assigned to an end-site" to "A provider >>>>>> assignment >>>>>> unit shall be considered fully utilized when it is assigned in full (or >>>>>> as >>>>>> part of a larger aggregate) to a single end-site. If a provider >>>>>> assignment >>>>>> unit (which shall be no smaller than /56) is split and assigned to >>>>>> multiple >>>>>> end-sites that entire provider assignment unit shall be considered NOT >>>>>> utilized." >>>>>> >>>>>> Comments: >>>>>> 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. >>>>>> >>>>> _______________________________________________ >>>>> 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. >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >>> 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 > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 From rcarpen at network1.net Fri Oct 9 13:19:19 2015 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 9 Oct 2015 13:19:19 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: References: <56031175.5040102@arin.net> <4CDBC688-5D20-4A85-882C-4EEEEA7FEEBB@delong.com> <13A519ED-7094-4B43-B3BD-4AAF31ABF412@delong.com> Message-ID: <2130090485.283109.1444411159704.JavaMail.zimbra@network1.net> This is all getting complex, confusing, and is still encouraging ISPs to give out less than the recommended /48 to end users. Why don't we just change policy so that every ISP gets an automatic IPv6 that approximates /32 IPv4 ~= /48 IPv6 Make it automatic, and at no additional cost. Also, make it the minimum, so that all ISPs have no reason not to hand out /48s. If you have less than a /20, you get a /32 If you have a /20, you get a /28 If you have a /16, you get a /24 If you have a /8, you get a /16 Basically, aggregate all of the IPv4 resources, round up to the nearest single block, add 8 bits, then round to the nearest nibble. If you need more, then it needs to be justified. I've seen several cases of ISP with 100,000s or even millions of customers that have a /32 or similar. That doesn't do anyone any good. If and when they come to their senses, the result will be even more routes in the routing table, because they will have to go back and get more. You could also just define the PAU as /48. The important part is that we make sure that there is no additional cost. IPv6 is plentiful enough that it shouldn't matter. If ARIN gives out N blocks of /20 instead of N blocks of /32, there should not be any financial impact. It is the same number of blocks. thanks, -Randy ----- On Oct 9, 2015, at 12:04 PM, Jason Schiller jschiller at google.com wrote: > Can ARIN staff please comment? > > If an ISP give out a mix of /48 and /56 which of the following is true: > > A. each unique customer end site given a /56 counts as a single /56 at > 100% utilized > and each unique customer end site given a /48 counts as 256 /56s > at 100% utilized > > B. each unique customer end site given a /56 counts as a single /56 at > 100% utilized > and each unique customer end site given a /48 counts as one /56 > at 100% utilization > unless there is specific justification why each /48 customer > needs more than 256 /64s > > If B, then how strong does said justification have to be for example > do any of the following work: > > 1. We give all customers of type X a /56 and of type Y a /48. > 2. all customers with a /48 said a /56 wasn't enough > 3. we give /56 or /48 based on which box they check on the install survey > 4. customer xyz said they plan to have 300 subnets in the next 10 years, > customer abc said they have 16 sub-nets per building, > each build is 4 geographical zones, and each zone has 4 > subnets, student, staff, guest, wifi > They have 20 buildings > customer def said ... > > ___Jason > > > On Thu, Oct 8, 2015 at 5:59 PM, Owen DeLong wrote: >> >>> On Oct 8, 2015, at 9:43 AM, Jason Schiller wrote: >>> >>> Owen, >>> >>>>> You left out the part where you have to justify issuing that many /56s to each >>>>> of those large customers. >>> >>> I believe if an ISP gives N number of /64s to a single end-site >>> transit customer, so long a N < 65537 it is justified under ARIN >>> policy. >> >> I don?t think that is true under the policy as written. >> >>> So for an ISP that assigns a mix of /48 and /56 no additional >>> justification is required to count all of the /56s given to a /48 >>> sized customer. >> >> That is not the way the policy is written. Staff may be misinterpreting it that >> way (wouldn?t be the first time), but that is not the way it is written. >> >> The PAU is the unit of measure for ALL of your utilization. You get a blanket >> justification for up to a /48 as your PAU, but if you choose a smaller PAU, then >> you have to justify any site issued more than one PAU based on its need for >> more than one PAU. >> >> Owen >> >>> >>> >>> 6.5.4. Assignments from LIRs/ISPs >>> >>> Assignments to end users shall be governed by the same practices >>> adopted by the community in section 6.5.8 except that the requirements >>> in 6.5.8.1 do not apply. >>> >>> 6.5.8.2. Initial assignment size >>> >>> Organizations that meet at least one of the initial assignment >>> criteria above are eligible to receive an initial assignment of /48. >>> >>> >>> I think the final point that you agree with is the meet of the >>> proposal... you don't get to count any utilization by customers if >>> they take smaller than a /56. >>> >>> __Jason >>> >>> __Jason >>> >>> On Thu, Oct 8, 2015 at 1:40 AM, Owen DeLong wrote: >>>> >>>> On Oct 7, 2015, at 10:00 PM, Jason Schiller wrote: >>>> >>>> I'm not sure I follow the impact of the change here. >>>> >>>> Under current policy if an ISP assigns only /48s to each customer, then I >>>> count the number of customer and consider than many /48s as fully utilized. >>>> >>>> Under current policy if an ISP assigns only /56s to each customer, then I >>>> count the number of customer and consider than many /56s as fully utilized. >>>> >>>> Under current policy if an ISP assigns a mix of /48s to each large customer, >>>> and /56s to each small customer >>>> then I count the number of small customer and consider than many /56s as >>>> fully utilized and, >>>> I count the number of large customers time 256 and count that many /56s as >>>> fully used. >>>> (this means unused /56s out of a /48 are counted against you thus >>>> discouraging mixed sizes). >>>> >>>> >>>> You left out the part where you have to justify issuing that many /56s to >>>> each of those large customers. >>>> >>>> Under current policy if an ISP assigns only /60s to each customer, then I >>>> count the number of customer and consider that number divided by 16 as the >>>> number of /56s as fully utilized. >>>> >>>> >>>> Well, actually, you just count everything as /60s in this case under current >>>> policy. >>>> >>>> Under the proposed policy only the last case changes. >>>> >>>> Under the proposed policy if an ISP assigns only /60s to each customer, then >>>> those customers having a /60 (smaller than a /56) are not counted as >>>> utilized by the ISP. >>>> >>>> >>>> Correct. >>>> >>>> Owen >>>> >>>> >>>> >>>> Is that correct? >>>> >>>> In general I am not opposed to discouraging ISPs from giving out smaller >>>> than a /56, unless the customer specifically requests a small block. >>>> >>>> >>>> ___Jason >>>> >>>> >>>> On Mon, Sep 28, 2015 at 11:35 AM, John Springer >>>> wrote: >>>>> >>>>> Thanks, Matt >>>>> >>>>> This is precisely the subject on which I hoped to get community feedback. >>>>> >>>>> John Springer >>>>> >>>>> >>>>> On Sat, 26 Sep 2015, Matthew Petach wrote: >>>>> >>>>>> OPPOSED >>>>>> >>>>>> How I subdivide and allocate addresses >>>>>> internally and downstream is not a matter >>>>>> for the community to vote on; that's between >>>>>> me and my customers. >>>>>> >>>>>> Matt >>>>>> >>>>>> >>>>>> On Wed, Sep 23, 2015 at 1:54 PM, ARIN wrote: >>>>>>> >>>>>>> Draft Policy ARIN-2015-10 >>>>>>> Minimum IPv6 Assignments >>>>>>> >>>>>>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>>>>>> "ARIN-prop-224 >>>>>>> Minimum IPv6 Assignments" as a Draft Policy. >>>>>>> >>>>>>> Draft Policy ARIN-2015-10 is below and can be found at: >>>>>>> https://www.arin.net/policy/proposals/2015_10.html >>>>>>> >>>>>>> You are encouraged to discuss the merits and your concerns of Draft >>>>>>> Policy 2015-10 on the Public Policy Mailing List. >>>>>>> >>>>>>> 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 PDP. Specifically, these principles are: >>>>>>> >>>>>>> * Enabling Fair and Impartial Number Resource Administration >>>>>>> * Technically Sound >>>>>>> * Supported by the Community >>>>>>> >>>>>>> The ARIN Policy Development Process (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-2015-10 >>>>>>> Minimum IPv6 Assignments >>>>>>> >>>>>>> Date: 23 September 2015 >>>>>>> >>>>>>> Problem Statement: >>>>>>> >>>>>>> ISPs may believe that they have an incentive to obtain smaller blocks >>>>>>> than >>>>>>> they really need, and once they receive their allocation may >>>>>>> subsequently >>>>>>> issue blocks smaller than their customers may need in the future. This >>>>>>> policy seeks to encourage the correct behavior by reiterating the >>>>>>> smallest >>>>>>> reasonable sub-allocation size and by discounting any space which has >>>>>>> been >>>>>>> subdivided more finely from any future utilization analysis. >>>>>>> >>>>>>> Policy statement: >>>>>>> >>>>>>> Modify section 2.15 from "When applied to IPv6 policies, the term >>>>>>> "provider >>>>>>> assignment unit" shall mean the prefix of the smallest block a given ISP >>>>>>> assigns to end sites (recommended /48)." to "When applied to IPv6 >>>>>>> policies, >>>>>>> the term "provider assignment unit" shall mean the prefix of the >>>>>>> smallest >>>>>>> block a given ISP assigns to end sites. A /48 is recommended as this >>>>>>> smallest block size. In no case shall a provider assignment unit for the >>>>>>> purpose of this policy be smaller than /56." >>>>>>> >>>>>>> Modify section 2.16.1 from "A provider assignment unit shall be >>>>>>> considered >>>>>>> fully utilized when it is assigned to an end-site" to "A provider >>>>>>> assignment >>>>>>> unit shall be considered fully utilized when it is assigned in full (or >>>>>>> as >>>>>>> part of a larger aggregate) to a single end-site. If a provider >>>>>>> assignment >>>>>>> unit (which shall be no smaller than /56) is split and assigned to >>>>>>> multiple >>>>>>> end-sites that entire provider assignment unit shall be considered NOT >>>>>>> utilized." >>>>>>> >>>>>>> Comments: >>>>>>> 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. >>>>>>> >>>>>> _______________________________________________ >>>>>> 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. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > _______________________________________________ > 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. From matthew at matthew.at Fri Oct 9 15:14:13 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 9 Oct 2015 15:14:13 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: <2130090485.283109.1444411159704.JavaMail.zimbra@network1.net> References: <56031175.5040102@arin.net> <4CDBC688-5D20-4A85-882C-4EEEEA7FEEBB@delong.com> <13A519ED-7094-4B43-B3BD-4AAF31ABF412@delong.com> <2130090485.283109.1444411159704.JavaMail.zimbra@network1.net> Message-ID: I'd support such an automatic allocation. I'd support it even more if it was made available to legacy holders. Matthew Kaufman (Sent from my iPhone) > On Oct 9, 2015, at 1:19 PM, Randy Carpenter wrote: > > > This is all getting complex, confusing, and is still encouraging ISPs to give out less than the recommended /48 to end users. > > Why don't we just change policy so that every ISP gets an automatic IPv6 that approximates /32 IPv4 ~= /48 IPv6 > > Make it automatic, and at no additional cost. Also, make it the minimum, so that all ISPs have no reason not to hand out /48s. > > If you have less than a /20, you get a /32 > If you have a /20, you get a /28 > If you have a /16, you get a /24 > If you have a /8, you get a /16 > > Basically, aggregate all of the IPv4 resources, round up to the nearest single block, add 8 bits, then round to the nearest nibble. > > If you need more, then it needs to be justified. > > I've seen several cases of ISP with 100,000s or even millions of customers that have a /32 or similar. That doesn't do anyone any good. If and when they come to their senses, the result will be even more routes in the routing table, because they will have to go back and get more. > > You could also just define the PAU as /48. The important part is that we make sure that there is no additional cost. IPv6 is plentiful enough that it shouldn't matter. If ARIN gives out N blocks of /20 instead of N blocks of /32, there should not be any financial impact. It is the same number of blocks. > > thanks, > -Randy > > > ----- On Oct 9, 2015, at 12:04 PM, Jason Schiller jschiller at google.com wrote: > >> Can ARIN staff please comment? >> >> If an ISP give out a mix of /48 and /56 which of the following is true: >> >> A. each unique customer end site given a /56 counts as a single /56 at >> 100% utilized >> and each unique customer end site given a /48 counts as 256 /56s >> at 100% utilized >> >> B. each unique customer end site given a /56 counts as a single /56 at >> 100% utilized >> and each unique customer end site given a /48 counts as one /56 >> at 100% utilization >> unless there is specific justification why each /48 customer >> needs more than 256 /64s >> >> If B, then how strong does said justification have to be for example >> do any of the following work: >> >> 1. We give all customers of type X a /56 and of type Y a /48. >> 2. all customers with a /48 said a /56 wasn't enough >> 3. we give /56 or /48 based on which box they check on the install survey >> 4. customer xyz said they plan to have 300 subnets in the next 10 years, >> customer abc said they have 16 sub-nets per building, >> each build is 4 geographical zones, and each zone has 4 >> subnets, student, staff, guest, wifi >> They have 20 buildings >> customer def said ... >> >> ___Jason >> >> >>> On Thu, Oct 8, 2015 at 5:59 PM, Owen DeLong wrote: >>> >>>> On Oct 8, 2015, at 9:43 AM, Jason Schiller wrote: >>>> >>>> Owen, >>>> >>>>>> You left out the part where you have to justify issuing that many /56s to each >>>>>> of those large customers. >>>> >>>> I believe if an ISP gives N number of /64s to a single end-site >>>> transit customer, so long a N < 65537 it is justified under ARIN >>>> policy. >>> >>> I don?t think that is true under the policy as written. >>> >>>> So for an ISP that assigns a mix of /48 and /56 no additional >>>> justification is required to count all of the /56s given to a /48 >>>> sized customer. >>> >>> That is not the way the policy is written. Staff may be misinterpreting it that >>> way (wouldn?t be the first time), but that is not the way it is written. >>> >>> The PAU is the unit of measure for ALL of your utilization. You get a blanket >>> justification for up to a /48 as your PAU, but if you choose a smaller PAU, then >>> you have to justify any site issued more than one PAU based on its need for >>> more than one PAU. >>> >>> Owen >>> >>>> >>>> >>>> 6.5.4. Assignments from LIRs/ISPs >>>> >>>> Assignments to end users shall be governed by the same practices >>>> adopted by the community in section 6.5.8 except that the requirements >>>> in 6.5.8.1 do not apply. >>>> >>>> 6.5.8.2. Initial assignment size >>>> >>>> Organizations that meet at least one of the initial assignment >>>> criteria above are eligible to receive an initial assignment of /48. >>>> >>>> >>>> I think the final point that you agree with is the meet of the >>>> proposal... you don't get to count any utilization by customers if >>>> they take smaller than a /56. >>>> >>>> __Jason >>>> >>>> __Jason >>>> >>>>> On Thu, Oct 8, 2015 at 1:40 AM, Owen DeLong wrote: >>>>> >>>>> On Oct 7, 2015, at 10:00 PM, Jason Schiller wrote: >>>>> >>>>> I'm not sure I follow the impact of the change here. >>>>> >>>>> Under current policy if an ISP assigns only /48s to each customer, then I >>>>> count the number of customer and consider than many /48s as fully utilized. >>>>> >>>>> Under current policy if an ISP assigns only /56s to each customer, then I >>>>> count the number of customer and consider than many /56s as fully utilized. >>>>> >>>>> Under current policy if an ISP assigns a mix of /48s to each large customer, >>>>> and /56s to each small customer >>>>> then I count the number of small customer and consider than many /56s as >>>>> fully utilized and, >>>>> I count the number of large customers time 256 and count that many /56s as >>>>> fully used. >>>>> (this means unused /56s out of a /48 are counted against you thus >>>>> discouraging mixed sizes). >>>>> >>>>> >>>>> You left out the part where you have to justify issuing that many /56s to >>>>> each of those large customers. >>>>> >>>>> Under current policy if an ISP assigns only /60s to each customer, then I >>>>> count the number of customer and consider that number divided by 16 as the >>>>> number of /56s as fully utilized. >>>>> >>>>> >>>>> Well, actually, you just count everything as /60s in this case under current >>>>> policy. >>>>> >>>>> Under the proposed policy only the last case changes. >>>>> >>>>> Under the proposed policy if an ISP assigns only /60s to each customer, then >>>>> those customers having a /60 (smaller than a /56) are not counted as >>>>> utilized by the ISP. >>>>> >>>>> >>>>> Correct. >>>>> >>>>> Owen >>>>> >>>>> >>>>> >>>>> Is that correct? >>>>> >>>>> In general I am not opposed to discouraging ISPs from giving out smaller >>>>> than a /56, unless the customer specifically requests a small block. >>>>> >>>>> >>>>> ___Jason >>>>> >>>>> >>>>> On Mon, Sep 28, 2015 at 11:35 AM, John Springer >>>>> wrote: >>>>>> >>>>>> Thanks, Matt >>>>>> >>>>>> This is precisely the subject on which I hoped to get community feedback. >>>>>> >>>>>> John Springer >>>>>> >>>>>> >>>>>>> On Sat, 26 Sep 2015, Matthew Petach wrote: >>>>>>> >>>>>>> OPPOSED >>>>>>> >>>>>>> How I subdivide and allocate addresses >>>>>>> internally and downstream is not a matter >>>>>>> for the community to vote on; that's between >>>>>>> me and my customers. >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> >>>>>>>> On Wed, Sep 23, 2015 at 1:54 PM, ARIN wrote: >>>>>>>> >>>>>>>> Draft Policy ARIN-2015-10 >>>>>>>> Minimum IPv6 Assignments >>>>>>>> >>>>>>>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>>>>>>> "ARIN-prop-224 >>>>>>>> Minimum IPv6 Assignments" as a Draft Policy. >>>>>>>> >>>>>>>> Draft Policy ARIN-2015-10 is below and can be found at: >>>>>>>> https://www.arin.net/policy/proposals/2015_10.html >>>>>>>> >>>>>>>> You are encouraged to discuss the merits and your concerns of Draft >>>>>>>> Policy 2015-10 on the Public Policy Mailing List. >>>>>>>> >>>>>>>> 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 PDP. Specifically, these principles are: >>>>>>>> >>>>>>>> * Enabling Fair and Impartial Number Resource Administration >>>>>>>> * Technically Sound >>>>>>>> * Supported by the Community >>>>>>>> >>>>>>>> The ARIN Policy Development Process (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-2015-10 >>>>>>>> Minimum IPv6 Assignments >>>>>>>> >>>>>>>> Date: 23 September 2015 >>>>>>>> >>>>>>>> Problem Statement: >>>>>>>> >>>>>>>> ISPs may believe that they have an incentive to obtain smaller blocks >>>>>>>> than >>>>>>>> they really need, and once they receive their allocation may >>>>>>>> subsequently >>>>>>>> issue blocks smaller than their customers may need in the future. This >>>>>>>> policy seeks to encourage the correct behavior by reiterating the >>>>>>>> smallest >>>>>>>> reasonable sub-allocation size and by discounting any space which has >>>>>>>> been >>>>>>>> subdivided more finely from any future utilization analysis. >>>>>>>> >>>>>>>> Policy statement: >>>>>>>> >>>>>>>> Modify section 2.15 from "When applied to IPv6 policies, the term >>>>>>>> "provider >>>>>>>> assignment unit" shall mean the prefix of the smallest block a given ISP >>>>>>>> assigns to end sites (recommended /48)." to "When applied to IPv6 >>>>>>>> policies, >>>>>>>> the term "provider assignment unit" shall mean the prefix of the >>>>>>>> smallest >>>>>>>> block a given ISP assigns to end sites. A /48 is recommended as this >>>>>>>> smallest block size. In no case shall a provider assignment unit for the >>>>>>>> purpose of this policy be smaller than /56." >>>>>>>> >>>>>>>> Modify section 2.16.1 from "A provider assignment unit shall be >>>>>>>> considered >>>>>>>> fully utilized when it is assigned to an end-site" to "A provider >>>>>>>> assignment >>>>>>>> unit shall be considered fully utilized when it is assigned in full (or >>>>>>>> as >>>>>>>> part of a larger aggregate) to a single end-site. If a provider >>>>>>>> assignment >>>>>>>> unit (which shall be no smaller than /56) is split and assigned to >>>>>>>> multiple >>>>>>>> end-sites that entire provider assignment unit shall be considered NOT >>>>>>>> utilized." >>>>>>>> >>>>>>>> Comments: >>>>>>>> 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. >>>>>>> _______________________________________________ >>>>>>> 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. >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >> _______________________________________________ >> 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. > _______________________________________________ > 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. From owen at delong.com Fri Oct 9 15:38:23 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Oct 2015 15:38:23 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: References: <56031175.5040102@arin.net> <4CDBC688-5D20-4A85-882C-4EEEEA7FEEBB@delong.com> <13A519ED-7094-4B43-B3BD-4AAF31ABF412@delong.com> <2130090485.283109.1444411159704.JavaMail.zimbra@network1.net> Message-ID: <96FCF1C7-AF9E-4B70-A4BA-2322EE04D6B3@delong.com> Every thing is already available to legacy holders if it is available to the rest of the community. However, for any new resources, they will have to sign an RSA and their new resources will not be legacy. Owen > On Oct 9, 2015, at 3:14 PM, Matthew Kaufman wrote: > > I'd support such an automatic allocation. > > I'd support it even more if it was made available to legacy holders. > > Matthew Kaufman > > (Sent from my iPhone) > >> On Oct 9, 2015, at 1:19 PM, Randy Carpenter wrote: >> >> >> This is all getting complex, confusing, and is still encouraging ISPs to give out less than the recommended /48 to end users. >> >> Why don't we just change policy so that every ISP gets an automatic IPv6 that approximates /32 IPv4 ~= /48 IPv6 >> >> Make it automatic, and at no additional cost. Also, make it the minimum, so that all ISPs have no reason not to hand out /48s. >> >> If you have less than a /20, you get a /32 >> If you have a /20, you get a /28 >> If you have a /16, you get a /24 >> If you have a /8, you get a /16 >> >> Basically, aggregate all of the IPv4 resources, round up to the nearest single block, add 8 bits, then round to the nearest nibble. >> >> If you need more, then it needs to be justified. >> >> I've seen several cases of ISP with 100,000s or even millions of customers that have a /32 or similar. That doesn't do anyone any good. If and when they come to their senses, the result will be even more routes in the routing table, because they will have to go back and get more. >> >> You could also just define the PAU as /48. The important part is that we make sure that there is no additional cost. IPv6 is plentiful enough that it shouldn't matter. If ARIN gives out N blocks of /20 instead of N blocks of /32, there should not be any financial impact. It is the same number of blocks. >> >> thanks, >> -Randy >> >> >> ----- On Oct 9, 2015, at 12:04 PM, Jason Schiller jschiller at google.com wrote: >> >>> Can ARIN staff please comment? >>> >>> If an ISP give out a mix of /48 and /56 which of the following is true: >>> >>> A. each unique customer end site given a /56 counts as a single /56 at >>> 100% utilized >>> and each unique customer end site given a /48 counts as 256 /56s >>> at 100% utilized >>> >>> B. each unique customer end site given a /56 counts as a single /56 at >>> 100% utilized >>> and each unique customer end site given a /48 counts as one /56 >>> at 100% utilization >>> unless there is specific justification why each /48 customer >>> needs more than 256 /64s >>> >>> If B, then how strong does said justification have to be for example >>> do any of the following work: >>> >>> 1. We give all customers of type X a /56 and of type Y a /48. >>> 2. all customers with a /48 said a /56 wasn't enough >>> 3. we give /56 or /48 based on which box they check on the install survey >>> 4. customer xyz said they plan to have 300 subnets in the next 10 years, >>> customer abc said they have 16 sub-nets per building, >>> each build is 4 geographical zones, and each zone has 4 >>> subnets, student, staff, guest, wifi >>> They have 20 buildings >>> customer def said ... >>> >>> ___Jason >>> >>> >>>> On Thu, Oct 8, 2015 at 5:59 PM, Owen DeLong wrote: >>>> >>>>> On Oct 8, 2015, at 9:43 AM, Jason Schiller wrote: >>>>> >>>>> Owen, >>>>> >>>>>>> You left out the part where you have to justify issuing that many /56s to each >>>>>>> of those large customers. >>>>> >>>>> I believe if an ISP gives N number of /64s to a single end-site >>>>> transit customer, so long a N < 65537 it is justified under ARIN >>>>> policy. >>>> >>>> I don?t think that is true under the policy as written. >>>> >>>>> So for an ISP that assigns a mix of /48 and /56 no additional >>>>> justification is required to count all of the /56s given to a /48 >>>>> sized customer. >>>> >>>> That is not the way the policy is written. Staff may be misinterpreting it that >>>> way (wouldn?t be the first time), but that is not the way it is written. >>>> >>>> The PAU is the unit of measure for ALL of your utilization. You get a blanket >>>> justification for up to a /48 as your PAU, but if you choose a smaller PAU, then >>>> you have to justify any site issued more than one PAU based on its need for >>>> more than one PAU. >>>> >>>> Owen >>>> >>>>> >>>>> >>>>> 6.5.4. Assignments from LIRs/ISPs >>>>> >>>>> Assignments to end users shall be governed by the same practices >>>>> adopted by the community in section 6.5.8 except that the requirements >>>>> in 6.5.8.1 do not apply. >>>>> >>>>> 6.5.8.2. Initial assignment size >>>>> >>>>> Organizations that meet at least one of the initial assignment >>>>> criteria above are eligible to receive an initial assignment of /48. >>>>> >>>>> >>>>> I think the final point that you agree with is the meet of the >>>>> proposal... you don't get to count any utilization by customers if >>>>> they take smaller than a /56. >>>>> >>>>> __Jason >>>>> >>>>> __Jason >>>>> >>>>>> On Thu, Oct 8, 2015 at 1:40 AM, Owen DeLong wrote: >>>>>> >>>>>> On Oct 7, 2015, at 10:00 PM, Jason Schiller wrote: >>>>>> >>>>>> I'm not sure I follow the impact of the change here. >>>>>> >>>>>> Under current policy if an ISP assigns only /48s to each customer, then I >>>>>> count the number of customer and consider than many /48s as fully utilized. >>>>>> >>>>>> Under current policy if an ISP assigns only /56s to each customer, then I >>>>>> count the number of customer and consider than many /56s as fully utilized. >>>>>> >>>>>> Under current policy if an ISP assigns a mix of /48s to each large customer, >>>>>> and /56s to each small customer >>>>>> then I count the number of small customer and consider than many /56s as >>>>>> fully utilized and, >>>>>> I count the number of large customers time 256 and count that many /56s as >>>>>> fully used. >>>>>> (this means unused /56s out of a /48 are counted against you thus >>>>>> discouraging mixed sizes). >>>>>> >>>>>> >>>>>> You left out the part where you have to justify issuing that many /56s to >>>>>> each of those large customers. >>>>>> >>>>>> Under current policy if an ISP assigns only /60s to each customer, then I >>>>>> count the number of customer and consider that number divided by 16 as the >>>>>> number of /56s as fully utilized. >>>>>> >>>>>> >>>>>> Well, actually, you just count everything as /60s in this case under current >>>>>> policy. >>>>>> >>>>>> Under the proposed policy only the last case changes. >>>>>> >>>>>> Under the proposed policy if an ISP assigns only /60s to each customer, then >>>>>> those customers having a /60 (smaller than a /56) are not counted as >>>>>> utilized by the ISP. >>>>>> >>>>>> >>>>>> Correct. >>>>>> >>>>>> Owen >>>>>> >>>>>> >>>>>> >>>>>> Is that correct? >>>>>> >>>>>> In general I am not opposed to discouraging ISPs from giving out smaller >>>>>> than a /56, unless the customer specifically requests a small block. >>>>>> >>>>>> >>>>>> ___Jason >>>>>> >>>>>> >>>>>> On Mon, Sep 28, 2015 at 11:35 AM, John Springer >>>>>> wrote: >>>>>>> >>>>>>> Thanks, Matt >>>>>>> >>>>>>> This is precisely the subject on which I hoped to get community feedback. >>>>>>> >>>>>>> John Springer >>>>>>> >>>>>>> >>>>>>>> On Sat, 26 Sep 2015, Matthew Petach wrote: >>>>>>>> >>>>>>>> OPPOSED >>>>>>>> >>>>>>>> How I subdivide and allocate addresses >>>>>>>> internally and downstream is not a matter >>>>>>>> for the community to vote on; that's between >>>>>>>> me and my customers. >>>>>>>> >>>>>>>> Matt >>>>>>>> >>>>>>>> >>>>>>>>> On Wed, Sep 23, 2015 at 1:54 PM, ARIN wrote: >>>>>>>>> >>>>>>>>> Draft Policy ARIN-2015-10 >>>>>>>>> Minimum IPv6 Assignments >>>>>>>>> >>>>>>>>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>>>>>>>> "ARIN-prop-224 >>>>>>>>> Minimum IPv6 Assignments" as a Draft Policy. >>>>>>>>> >>>>>>>>> Draft Policy ARIN-2015-10 is below and can be found at: >>>>>>>>> https://www.arin.net/policy/proposals/2015_10.html >>>>>>>>> >>>>>>>>> You are encouraged to discuss the merits and your concerns of Draft >>>>>>>>> Policy 2015-10 on the Public Policy Mailing List. >>>>>>>>> >>>>>>>>> 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 PDP. Specifically, these principles are: >>>>>>>>> >>>>>>>>> * Enabling Fair and Impartial Number Resource Administration >>>>>>>>> * Technically Sound >>>>>>>>> * Supported by the Community >>>>>>>>> >>>>>>>>> The ARIN Policy Development Process (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-2015-10 >>>>>>>>> Minimum IPv6 Assignments >>>>>>>>> >>>>>>>>> Date: 23 September 2015 >>>>>>>>> >>>>>>>>> Problem Statement: >>>>>>>>> >>>>>>>>> ISPs may believe that they have an incentive to obtain smaller blocks >>>>>>>>> than >>>>>>>>> they really need, and once they receive their allocation may >>>>>>>>> subsequently >>>>>>>>> issue blocks smaller than their customers may need in the future. This >>>>>>>>> policy seeks to encourage the correct behavior by reiterating the >>>>>>>>> smallest >>>>>>>>> reasonable sub-allocation size and by discounting any space which has >>>>>>>>> been >>>>>>>>> subdivided more finely from any future utilization analysis. >>>>>>>>> >>>>>>>>> Policy statement: >>>>>>>>> >>>>>>>>> Modify section 2.15 from "When applied to IPv6 policies, the term >>>>>>>>> "provider >>>>>>>>> assignment unit" shall mean the prefix of the smallest block a given ISP >>>>>>>>> assigns to end sites (recommended /48)." to "When applied to IPv6 >>>>>>>>> policies, >>>>>>>>> the term "provider assignment unit" shall mean the prefix of the >>>>>>>>> smallest >>>>>>>>> block a given ISP assigns to end sites. A /48 is recommended as this >>>>>>>>> smallest block size. In no case shall a provider assignment unit for the >>>>>>>>> purpose of this policy be smaller than /56." >>>>>>>>> >>>>>>>>> Modify section 2.16.1 from "A provider assignment unit shall be >>>>>>>>> considered >>>>>>>>> fully utilized when it is assigned to an end-site" to "A provider >>>>>>>>> assignment >>>>>>>>> unit shall be considered fully utilized when it is assigned in full (or >>>>>>>>> as >>>>>>>>> part of a larger aggregate) to a single end-site. If a provider >>>>>>>>> assignment >>>>>>>>> unit (which shall be no smaller than /56) is split and assigned to >>>>>>>>> multiple >>>>>>>>> end-sites that entire provider assignment unit shall be considered NOT >>>>>>>>> utilized." >>>>>>>>> >>>>>>>>> Comments: >>>>>>>>> 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. >>>>>>>> _______________________________________________ >>>>>>>> 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. >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >>> >>> -- >>> _______________________________________________________ >>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >>> _______________________________________________ >>> 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. >> _______________________________________________ >> 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. > _______________________________________________ > 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. From matthew at matthew.at Fri Oct 9 15:43:46 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 9 Oct 2015 15:43:46 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: <96FCF1C7-AF9E-4B70-A4BA-2322EE04D6B3@delong.com> References: <56031175.5040102@arin.net> <4CDBC688-5D20-4A85-882C-4EEEEA7FEEBB@delong.com> <13A519ED-7094-4B43-B3BD-4AAF31ABF412@delong.com> <2130090485.283109.1444411159704.JavaMail.zimbra@network1.net> <96FCF1C7-AF9E-4B70-A4BA-2322EE04D6B3@delong.com> Message-ID: That is not necessarily true of the hypothetical automatic assignment discussed below Matthew Kaufman (Sent from my iPhone) > On Oct 9, 2015, at 3:38 PM, Owen DeLong wrote: > > Every thing is already available to legacy holders if it is available to the rest of the community. > > However, for any new resources, they will have to sign an RSA and their new resources will not be legacy. > > Owen > >> On Oct 9, 2015, at 3:14 PM, Matthew Kaufman wrote: >> >> I'd support such an automatic allocation. >> >> I'd support it even more if it was made available to legacy holders. >> >> Matthew Kaufman >> >> (Sent from my iPhone) >> >>> On Oct 9, 2015, at 1:19 PM, Randy Carpenter wrote: >>> >>> >>> This is all getting complex, confusing, and is still encouraging ISPs to give out less than the recommended /48 to end users. >>> >>> Why don't we just change policy so that every ISP gets an automatic IPv6 that approximates /32 IPv4 ~= /48 IPv6 >>> >>> Make it automatic, and at no additional cost. Also, make it the minimum, so that all ISPs have no reason not to hand out /48s. >>> >>> If you have less than a /20, you get a /32 >>> If you have a /20, you get a /28 >>> If you have a /16, you get a /24 >>> If you have a /8, you get a /16 >>> >>> Basically, aggregate all of the IPv4 resources, round up to the nearest single block, add 8 bits, then round to the nearest nibble. >>> >>> If you need more, then it needs to be justified. >>> >>> I've seen several cases of ISP with 100,000s or even millions of customers that have a /32 or similar. That doesn't do anyone any good. If and when they come to their senses, the result will be even more routes in the routing table, because they will have to go back and get more. >>> >>> You could also just define the PAU as /48. The important part is that we make sure that there is no additional cost. IPv6 is plentiful enough that it shouldn't matter. If ARIN gives out N blocks of /20 instead of N blocks of /32, there should not be any financial impact. It is the same number of blocks. >>> >>> thanks, >>> -Randy >>> >>> >>> ----- On Oct 9, 2015, at 12:04 PM, Jason Schiller jschiller at google.com wrote: >>> >>>> Can ARIN staff please comment? >>>> >>>> If an ISP give out a mix of /48 and /56 which of the following is true: >>>> >>>> A. each unique customer end site given a /56 counts as a single /56 at >>>> 100% utilized >>>> and each unique customer end site given a /48 counts as 256 /56s >>>> at 100% utilized >>>> >>>> B. each unique customer end site given a /56 counts as a single /56 at >>>> 100% utilized >>>> and each unique customer end site given a /48 counts as one /56 >>>> at 100% utilization >>>> unless there is specific justification why each /48 customer >>>> needs more than 256 /64s >>>> >>>> If B, then how strong does said justification have to be for example >>>> do any of the following work: >>>> >>>> 1. We give all customers of type X a /56 and of type Y a /48. >>>> 2. all customers with a /48 said a /56 wasn't enough >>>> 3. we give /56 or /48 based on which box they check on the install survey >>>> 4. customer xyz said they plan to have 300 subnets in the next 10 years, >>>> customer abc said they have 16 sub-nets per building, >>>> each build is 4 geographical zones, and each zone has 4 >>>> subnets, student, staff, guest, wifi >>>> They have 20 buildings >>>> customer def said ... >>>> >>>> ___Jason >>>> >>>> >>>>>> On Thu, Oct 8, 2015 at 5:59 PM, Owen DeLong wrote: >>>>>> >>>>>> On Oct 8, 2015, at 9:43 AM, Jason Schiller wrote: >>>>>> >>>>>> Owen, >>>>>> >>>>>>>> You left out the part where you have to justify issuing that many /56s to each >>>>>>>> of those large customers. >>>>>> >>>>>> I believe if an ISP gives N number of /64s to a single end-site >>>>>> transit customer, so long a N < 65537 it is justified under ARIN >>>>>> policy. >>>>> >>>>> I don?t think that is true under the policy as written. >>>>> >>>>>> So for an ISP that assigns a mix of /48 and /56 no additional >>>>>> justification is required to count all of the /56s given to a /48 >>>>>> sized customer. >>>>> >>>>> That is not the way the policy is written. Staff may be misinterpreting it that >>>>> way (wouldn?t be the first time), but that is not the way it is written. >>>>> >>>>> The PAU is the unit of measure for ALL of your utilization. You get a blanket >>>>> justification for up to a /48 as your PAU, but if you choose a smaller PAU, then >>>>> you have to justify any site issued more than one PAU based on its need for >>>>> more than one PAU. >>>>> >>>>> Owen >>>>> >>>>>> >>>>>> >>>>>> 6.5.4. Assignments from LIRs/ISPs >>>>>> >>>>>> Assignments to end users shall be governed by the same practices >>>>>> adopted by the community in section 6.5.8 except that the requirements >>>>>> in 6.5.8.1 do not apply. >>>>>> >>>>>> 6.5.8.2. Initial assignment size >>>>>> >>>>>> Organizations that meet at least one of the initial assignment >>>>>> criteria above are eligible to receive an initial assignment of /48. >>>>>> >>>>>> >>>>>> I think the final point that you agree with is the meet of the >>>>>> proposal... you don't get to count any utilization by customers if >>>>>> they take smaller than a /56. >>>>>> >>>>>> __Jason >>>>>> >>>>>> __Jason >>>>>> >>>>>>> On Thu, Oct 8, 2015 at 1:40 AM, Owen DeLong wrote: >>>>>>> >>>>>>> On Oct 7, 2015, at 10:00 PM, Jason Schiller wrote: >>>>>>> >>>>>>> I'm not sure I follow the impact of the change here. >>>>>>> >>>>>>> Under current policy if an ISP assigns only /48s to each customer, then I >>>>>>> count the number of customer and consider than many /48s as fully utilized. >>>>>>> >>>>>>> Under current policy if an ISP assigns only /56s to each customer, then I >>>>>>> count the number of customer and consider than many /56s as fully utilized. >>>>>>> >>>>>>> Under current policy if an ISP assigns a mix of /48s to each large customer, >>>>>>> and /56s to each small customer >>>>>>> then I count the number of small customer and consider than many /56s as >>>>>>> fully utilized and, >>>>>>> I count the number of large customers time 256 and count that many /56s as >>>>>>> fully used. >>>>>>> (this means unused /56s out of a /48 are counted against you thus >>>>>>> discouraging mixed sizes). >>>>>>> >>>>>>> >>>>>>> You left out the part where you have to justify issuing that many /56s to >>>>>>> each of those large customers. >>>>>>> >>>>>>> Under current policy if an ISP assigns only /60s to each customer, then I >>>>>>> count the number of customer and consider that number divided by 16 as the >>>>>>> number of /56s as fully utilized. >>>>>>> >>>>>>> >>>>>>> Well, actually, you just count everything as /60s in this case under current >>>>>>> policy. >>>>>>> >>>>>>> Under the proposed policy only the last case changes. >>>>>>> >>>>>>> Under the proposed policy if an ISP assigns only /60s to each customer, then >>>>>>> those customers having a /60 (smaller than a /56) are not counted as >>>>>>> utilized by the ISP. >>>>>>> >>>>>>> >>>>>>> Correct. >>>>>>> >>>>>>> Owen >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is that correct? >>>>>>> >>>>>>> In general I am not opposed to discouraging ISPs from giving out smaller >>>>>>> than a /56, unless the customer specifically requests a small block. >>>>>>> >>>>>>> >>>>>>> ___Jason >>>>>>> >>>>>>> >>>>>>> On Mon, Sep 28, 2015 at 11:35 AM, John Springer >>>>>>> wrote: >>>>>>>> >>>>>>>> Thanks, Matt >>>>>>>> >>>>>>>> This is precisely the subject on which I hoped to get community feedback. >>>>>>>> >>>>>>>> John Springer >>>>>>>> >>>>>>>> >>>>>>>>> On Sat, 26 Sep 2015, Matthew Petach wrote: >>>>>>>>> >>>>>>>>> OPPOSED >>>>>>>>> >>>>>>>>> How I subdivide and allocate addresses >>>>>>>>> internally and downstream is not a matter >>>>>>>>> for the community to vote on; that's between >>>>>>>>> me and my customers. >>>>>>>>> >>>>>>>>> Matt >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Wed, Sep 23, 2015 at 1:54 PM, ARIN wrote: >>>>>>>>>> >>>>>>>>>> Draft Policy ARIN-2015-10 >>>>>>>>>> Minimum IPv6 Assignments >>>>>>>>>> >>>>>>>>>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>>>>>>>>> "ARIN-prop-224 >>>>>>>>>> Minimum IPv6 Assignments" as a Draft Policy. >>>>>>>>>> >>>>>>>>>> Draft Policy ARIN-2015-10 is below and can be found at: >>>>>>>>>> https://www.arin.net/policy/proposals/2015_10.html >>>>>>>>>> >>>>>>>>>> You are encouraged to discuss the merits and your concerns of Draft >>>>>>>>>> Policy 2015-10 on the Public Policy Mailing List. >>>>>>>>>> >>>>>>>>>> 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 PDP. Specifically, these principles are: >>>>>>>>>> >>>>>>>>>> * Enabling Fair and Impartial Number Resource Administration >>>>>>>>>> * Technically Sound >>>>>>>>>> * Supported by the Community >>>>>>>>>> >>>>>>>>>> The ARIN Policy Development Process (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-2015-10 >>>>>>>>>> Minimum IPv6 Assignments >>>>>>>>>> >>>>>>>>>> Date: 23 September 2015 >>>>>>>>>> >>>>>>>>>> Problem Statement: >>>>>>>>>> >>>>>>>>>> ISPs may believe that they have an incentive to obtain smaller blocks >>>>>>>>>> than >>>>>>>>>> they really need, and once they receive their allocation may >>>>>>>>>> subsequently >>>>>>>>>> issue blocks smaller than their customers may need in the future. This >>>>>>>>>> policy seeks to encourage the correct behavior by reiterating the >>>>>>>>>> smallest >>>>>>>>>> reasonable sub-allocation size and by discounting any space which has >>>>>>>>>> been >>>>>>>>>> subdivided more finely from any future utilization analysis. >>>>>>>>>> >>>>>>>>>> Policy statement: >>>>>>>>>> >>>>>>>>>> Modify section 2.15 from "When applied to IPv6 policies, the term >>>>>>>>>> "provider >>>>>>>>>> assignment unit" shall mean the prefix of the smallest block a given ISP >>>>>>>>>> assigns to end sites (recommended /48)." to "When applied to IPv6 >>>>>>>>>> policies, >>>>>>>>>> the term "provider assignment unit" shall mean the prefix of the >>>>>>>>>> smallest >>>>>>>>>> block a given ISP assigns to end sites. A /48 is recommended as this >>>>>>>>>> smallest block size. In no case shall a provider assignment unit for the >>>>>>>>>> purpose of this policy be smaller than /56." >>>>>>>>>> >>>>>>>>>> Modify section 2.16.1 from "A provider assignment unit shall be >>>>>>>>>> considered >>>>>>>>>> fully utilized when it is assigned to an end-site" to "A provider >>>>>>>>>> assignment >>>>>>>>>> unit shall be considered fully utilized when it is assigned in full (or >>>>>>>>>> as >>>>>>>>>> part of a larger aggregate) to a single end-site. If a provider >>>>>>>>>> assignment >>>>>>>>>> unit (which shall be no smaller than /56) is split and assigned to >>>>>>>>>> multiple >>>>>>>>>> end-sites that entire provider assignment unit shall be considered NOT >>>>>>>>>> utilized." >>>>>>>>>> >>>>>>>>>> Comments: >>>>>>>>>> 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. >>>>>>>>> _______________________________________________ >>>>>>>>> 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. >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> >>>> >>>> -- >>>> _______________________________________________________ >>>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >>>> _______________________________________________ >>>> 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. >>> _______________________________________________ >>> 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. >> _______________________________________________ >> 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. > From owen at delong.com Fri Oct 9 16:11:24 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Oct 2015 16:11:24 -0400 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: References: <56031175.5040102@arin.net> <4CDBC688-5D20-4A85-882C-4EEEEA7FEEBB@delong.com> <13A519ED-7094-4B43-B3BD-4AAF31ABF412@delong.com> <2130090485.283109.1444411159704.JavaMail.zimbra@network1.net> <96FCF1C7-AF9E-4B70-A4BA-2322EE04D6B3@delong.com> Message-ID: <26D39C74-9140-45D0-A28E-8E428DB04105@delong.com> Sure it is? There is nothing in ARIN policy ever that has made a distinction about legacy holders or somehow excluded them from participating in or receiving any benefit of any ARIN policy if they sign an RSA for their new resources. Owen > On Oct 9, 2015, at 3:43 PM, Matthew Kaufman wrote: > > That is not necessarily true of the hypothetical automatic assignment discussed below > > Matthew Kaufman > > (Sent from my iPhone) > >> On Oct 9, 2015, at 3:38 PM, Owen DeLong wrote: >> >> Every thing is already available to legacy holders if it is available to the rest of the community. >> >> However, for any new resources, they will have to sign an RSA and their new resources will not be legacy. >> >> Owen >> >>> On Oct 9, 2015, at 3:14 PM, Matthew Kaufman wrote: >>> >>> I'd support such an automatic allocation. >>> >>> I'd support it even more if it was made available to legacy holders. >>> >>> Matthew Kaufman >>> >>> (Sent from my iPhone) >>> >>>> On Oct 9, 2015, at 1:19 PM, Randy Carpenter wrote: >>>> >>>> >>>> This is all getting complex, confusing, and is still encouraging ISPs to give out less than the recommended /48 to end users. >>>> >>>> Why don't we just change policy so that every ISP gets an automatic IPv6 that approximates /32 IPv4 ~= /48 IPv6 >>>> >>>> Make it automatic, and at no additional cost. Also, make it the minimum, so that all ISPs have no reason not to hand out /48s. >>>> >>>> If you have less than a /20, you get a /32 >>>> If you have a /20, you get a /28 >>>> If you have a /16, you get a /24 >>>> If you have a /8, you get a /16 >>>> >>>> Basically, aggregate all of the IPv4 resources, round up to the nearest single block, add 8 bits, then round to the nearest nibble. >>>> >>>> If you need more, then it needs to be justified. >>>> >>>> I've seen several cases of ISP with 100,000s or even millions of customers that have a /32 or similar. That doesn't do anyone any good. If and when they come to their senses, the result will be even more routes in the routing table, because they will have to go back and get more. >>>> >>>> You could also just define the PAU as /48. The important part is that we make sure that there is no additional cost. IPv6 is plentiful enough that it shouldn't matter. If ARIN gives out N blocks of /20 instead of N blocks of /32, there should not be any financial impact. It is the same number of blocks. >>>> >>>> thanks, >>>> -Randy >>>> >>>> >>>> ----- On Oct 9, 2015, at 12:04 PM, Jason Schiller jschiller at google.com wrote: >>>> >>>>> Can ARIN staff please comment? >>>>> >>>>> If an ISP give out a mix of /48 and /56 which of the following is true: >>>>> >>>>> A. each unique customer end site given a /56 counts as a single /56 at >>>>> 100% utilized >>>>> and each unique customer end site given a /48 counts as 256 /56s >>>>> at 100% utilized >>>>> >>>>> B. each unique customer end site given a /56 counts as a single /56 at >>>>> 100% utilized >>>>> and each unique customer end site given a /48 counts as one /56 >>>>> at 100% utilization >>>>> unless there is specific justification why each /48 customer >>>>> needs more than 256 /64s >>>>> >>>>> If B, then how strong does said justification have to be for example >>>>> do any of the following work: >>>>> >>>>> 1. We give all customers of type X a /56 and of type Y a /48. >>>>> 2. all customers with a /48 said a /56 wasn't enough >>>>> 3. we give /56 or /48 based on which box they check on the install survey >>>>> 4. customer xyz said they plan to have 300 subnets in the next 10 years, >>>>> customer abc said they have 16 sub-nets per building, >>>>> each build is 4 geographical zones, and each zone has 4 >>>>> subnets, student, staff, guest, wifi >>>>> They have 20 buildings >>>>> customer def said ... >>>>> >>>>> ___Jason >>>>> >>>>> >>>>>>> On Thu, Oct 8, 2015 at 5:59 PM, Owen DeLong wrote: >>>>>>> >>>>>>> On Oct 8, 2015, at 9:43 AM, Jason Schiller wrote: >>>>>>> >>>>>>> Owen, >>>>>>> >>>>>>>>> You left out the part where you have to justify issuing that many /56s to each >>>>>>>>> of those large customers. >>>>>>> >>>>>>> I believe if an ISP gives N number of /64s to a single end-site >>>>>>> transit customer, so long a N < 65537 it is justified under ARIN >>>>>>> policy. >>>>>> >>>>>> I don?t think that is true under the policy as written. >>>>>> >>>>>>> So for an ISP that assigns a mix of /48 and /56 no additional >>>>>>> justification is required to count all of the /56s given to a /48 >>>>>>> sized customer. >>>>>> >>>>>> That is not the way the policy is written. Staff may be misinterpreting it that >>>>>> way (wouldn?t be the first time), but that is not the way it is written. >>>>>> >>>>>> The PAU is the unit of measure for ALL of your utilization. You get a blanket >>>>>> justification for up to a /48 as your PAU, but if you choose a smaller PAU, then >>>>>> you have to justify any site issued more than one PAU based on its need for >>>>>> more than one PAU. >>>>>> >>>>>> Owen >>>>>> >>>>>>> >>>>>>> >>>>>>> 6.5.4. Assignments from LIRs/ISPs >>>>>>> >>>>>>> Assignments to end users shall be governed by the same practices >>>>>>> adopted by the community in section 6.5.8 except that the requirements >>>>>>> in 6.5.8.1 do not apply. >>>>>>> >>>>>>> 6.5.8.2. Initial assignment size >>>>>>> >>>>>>> Organizations that meet at least one of the initial assignment >>>>>>> criteria above are eligible to receive an initial assignment of /48. >>>>>>> >>>>>>> >>>>>>> I think the final point that you agree with is the meet of the >>>>>>> proposal... you don't get to count any utilization by customers if >>>>>>> they take smaller than a /56. >>>>>>> >>>>>>> __Jason >>>>>>> >>>>>>> __Jason >>>>>>> >>>>>>>> On Thu, Oct 8, 2015 at 1:40 AM, Owen DeLong wrote: >>>>>>>> >>>>>>>> On Oct 7, 2015, at 10:00 PM, Jason Schiller wrote: >>>>>>>> >>>>>>>> I'm not sure I follow the impact of the change here. >>>>>>>> >>>>>>>> Under current policy if an ISP assigns only /48s to each customer, then I >>>>>>>> count the number of customer and consider than many /48s as fully utilized. >>>>>>>> >>>>>>>> Under current policy if an ISP assigns only /56s to each customer, then I >>>>>>>> count the number of customer and consider than many /56s as fully utilized. >>>>>>>> >>>>>>>> Under current policy if an ISP assigns a mix of /48s to each large customer, >>>>>>>> and /56s to each small customer >>>>>>>> then I count the number of small customer and consider than many /56s as >>>>>>>> fully utilized and, >>>>>>>> I count the number of large customers time 256 and count that many /56s as >>>>>>>> fully used. >>>>>>>> (this means unused /56s out of a /48 are counted against you thus >>>>>>>> discouraging mixed sizes). >>>>>>>> >>>>>>>> >>>>>>>> You left out the part where you have to justify issuing that many /56s to >>>>>>>> each of those large customers. >>>>>>>> >>>>>>>> Under current policy if an ISP assigns only /60s to each customer, then I >>>>>>>> count the number of customer and consider that number divided by 16 as the >>>>>>>> number of /56s as fully utilized. >>>>>>>> >>>>>>>> >>>>>>>> Well, actually, you just count everything as /60s in this case under current >>>>>>>> policy. >>>>>>>> >>>>>>>> Under the proposed policy only the last case changes. >>>>>>>> >>>>>>>> Under the proposed policy if an ISP assigns only /60s to each customer, then >>>>>>>> those customers having a /60 (smaller than a /56) are not counted as >>>>>>>> utilized by the ISP. >>>>>>>> >>>>>>>> >>>>>>>> Correct. >>>>>>>> >>>>>>>> Owen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Is that correct? >>>>>>>> >>>>>>>> In general I am not opposed to discouraging ISPs from giving out smaller >>>>>>>> than a /56, unless the customer specifically requests a small block. >>>>>>>> >>>>>>>> >>>>>>>> ___Jason >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Sep 28, 2015 at 11:35 AM, John Springer >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Thanks, Matt >>>>>>>>> >>>>>>>>> This is precisely the subject on which I hoped to get community feedback. >>>>>>>>> >>>>>>>>> John Springer >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Sat, 26 Sep 2015, Matthew Petach wrote: >>>>>>>>>> >>>>>>>>>> OPPOSED >>>>>>>>>> >>>>>>>>>> How I subdivide and allocate addresses >>>>>>>>>> internally and downstream is not a matter >>>>>>>>>> for the community to vote on; that's between >>>>>>>>>> me and my customers. >>>>>>>>>> >>>>>>>>>> Matt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Wed, Sep 23, 2015 at 1:54 PM, ARIN wrote: >>>>>>>>>>> >>>>>>>>>>> Draft Policy ARIN-2015-10 >>>>>>>>>>> Minimum IPv6 Assignments >>>>>>>>>>> >>>>>>>>>>> On 17 September 2015 the ARIN Advisory Council (AC) accepted >>>>>>>>>>> "ARIN-prop-224 >>>>>>>>>>> Minimum IPv6 Assignments" as a Draft Policy. >>>>>>>>>>> >>>>>>>>>>> Draft Policy ARIN-2015-10 is below and can be found at: >>>>>>>>>>> https://www.arin.net/policy/proposals/2015_10.html >>>>>>>>>>> >>>>>>>>>>> You are encouraged to discuss the merits and your concerns of Draft >>>>>>>>>>> Policy 2015-10 on the Public Policy Mailing List. >>>>>>>>>>> >>>>>>>>>>> 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 PDP. Specifically, these principles are: >>>>>>>>>>> >>>>>>>>>>> * Enabling Fair and Impartial Number Resource Administration >>>>>>>>>>> * Technically Sound >>>>>>>>>>> * Supported by the Community >>>>>>>>>>> >>>>>>>>>>> The ARIN Policy Development Process (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-2015-10 >>>>>>>>>>> Minimum IPv6 Assignments >>>>>>>>>>> >>>>>>>>>>> Date: 23 September 2015 >>>>>>>>>>> >>>>>>>>>>> Problem Statement: >>>>>>>>>>> >>>>>>>>>>> ISPs may believe that they have an incentive to obtain smaller blocks >>>>>>>>>>> than >>>>>>>>>>> they really need, and once they receive their allocation may >>>>>>>>>>> subsequently >>>>>>>>>>> issue blocks smaller than their customers may need in the future. This >>>>>>>>>>> policy seeks to encourage the correct behavior by reiterating the >>>>>>>>>>> smallest >>>>>>>>>>> reasonable sub-allocation size and by discounting any space which has >>>>>>>>>>> been >>>>>>>>>>> subdivided more finely from any future utilization analysis. >>>>>>>>>>> >>>>>>>>>>> Policy statement: >>>>>>>>>>> >>>>>>>>>>> Modify section 2.15 from "When applied to IPv6 policies, the term >>>>>>>>>>> "provider >>>>>>>>>>> assignment unit" shall mean the prefix of the smallest block a given ISP >>>>>>>>>>> assigns to end sites (recommended /48)." to "When applied to IPv6 >>>>>>>>>>> policies, >>>>>>>>>>> the term "provider assignment unit" shall mean the prefix of the >>>>>>>>>>> smallest >>>>>>>>>>> block a given ISP assigns to end sites. A /48 is recommended as this >>>>>>>>>>> smallest block size. In no case shall a provider assignment unit for the >>>>>>>>>>> purpose of this policy be smaller than /56." >>>>>>>>>>> >>>>>>>>>>> Modify section 2.16.1 from "A provider assignment unit shall be >>>>>>>>>>> considered >>>>>>>>>>> fully utilized when it is assigned to an end-site" to "A provider >>>>>>>>>>> assignment >>>>>>>>>>> unit shall be considered fully utilized when it is assigned in full (or >>>>>>>>>>> as >>>>>>>>>>> part of a larger aggregate) to a single end-site. If a provider >>>>>>>>>>> assignment >>>>>>>>>>> unit (which shall be no smaller than /56) is split and assigned to >>>>>>>>>>> multiple >>>>>>>>>>> end-sites that entire provider assignment unit shall be considered NOT >>>>>>>>>>> utilized." >>>>>>>>>>> >>>>>>>>>>> Comments: >>>>>>>>>>> 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. >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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. >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>>> >>>>> >>>>> -- >>>>> _______________________________________________________ >>>>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >>>>> _______________________________________________ >>>>> 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. >>>> _______________________________________________ >>>> 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. >>> _______________________________________________ >>> 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. >> From richardj at arin.net Mon Oct 12 11:42:26 2015 From: richardj at arin.net (Richard Jimmerson) Date: Mon, 12 Oct 2015 15:42:26 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments In-Reply-To: References: <56031175.5040102@arin.net> <4CDBC688-5D20-4A85-882C-4EEEEA7FEEBB@delong.com> <13A519ED-7094-4B43-B3BD-4AAF31ABF412@delong.com> Message-ID: Hello Jason, Thank you for your inquiry regarding ARIN staff review of IPv6 customer reassignments as utilization. To begin, we have not reviewed many requests for additional IPv6 address space from ISPs, to date. Most 2nd requests from ISPs to ARIN involve a declaration that their previous block (usually a /32 or /36) had not been utilized yet, but now that they are actively involved in their deployment they realize the /32 or /36 was not large enough. This results in a new review from ARIN staff for a larger allocation size for the organization. More specific to your questions, we do have some limited experience with reviewing requests for additional IPv6 address space from ISPs. In those cases we always consider a /48 assignment to a customer as 100% utilized. In the case an ISP mixes /48s and /56s to customers, they typically state they issue the /56s from specific /48s (either in general, or per market area). In those cases we consider the /48s from which they issue the /56s to be 100% utilized. In cases that the ISP chooses to only assign /56s to customers, we consider any /56 they assign to a customer 100% utilized. Warm regards, Richard Jimmerson CIO & Interim Director of Registration Services American Registry for Internet Numbers From: Jason Schiller > Date: Friday, October 9, 2015 at 12:04 PM To: Owen DeLong > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments Can ARIN staff please comment? If an ISP give out a mix of /48 and /56 which of the following is true: A. each unique customer end site given a /56 counts as a single /56 at 100% utilized and each unique customer end site given a /48 counts as 256 /56s at 100% utilized B. each unique customer end site given a /56 counts as a single /56 at 100% utilized and each unique customer end site given a /48 counts as one /56 at 100% utilization unless there is specific justification why each /48 customer needs more than 256 /64s If B, then how strong does said justification have to be for example do any of the following work: 1. We give all customers of type X a /56 and of type Y a /48. 2. all customers with a /48 said a /56 wasn't enough 3. we give /56 or /48 based on which box they check on the install survey 4. customer xyz said they plan to have 300 subnets in the next 10 years, customer abc said they have 16 sub-nets per building, each build is 4 geographical zones, and each zone has 4 subnets, student, staff, guest, wifi They have 20 buildings customer def said ... ___Jason On Thu, Oct 8, 2015 at 5:59 PM, Owen DeLong > wrote: On Oct 8, 2015, at 9:43 AM, Jason Schiller > wrote: Owen, You left out the part where you have to justify issuing that many /56s to each of those large customers. I believe if an ISP gives N number of /64s to a single end-site transit customer, so long a N < 65537 it is justified under ARIN policy. I don?t think that is true under the policy as written. So for an ISP that assigns a mix of /48 and /56 no additional justification is required to count all of the /56s given to a /48 sized customer. That is not the way the policy is written. Staff may be misinterpreting it that way (wouldn?t be the first time), but that is not the way it is written. The PAU is the unit of measure for ALL of your utilization. You get a blanket justification for up to a /48 as your PAU, but if you choose a smaller PAU, then you have to justify any site issued more than one PAU based on its need for more than one PAU. Owen 6.5.4. Assignments from LIRs/ISPs Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. 6.5.8.2. Initial assignment size Organizations that meet at least one of the initial assignment criteria above are eligible to receive an initial assignment of /48. I think the final point that you agree with is the meet of the proposal... you don't get to count any utilization by customers if they take smaller than a /56. __Jason __Jason On Thu, Oct 8, 2015 at 1:40 AM, Owen DeLong > wrote: On Oct 7, 2015, at 10:00 PM, Jason Schiller > wrote: I'm not sure I follow the impact of the change here. Under current policy if an ISP assigns only /48s to each customer, then I count the number of customer and consider than many /48s as fully utilized. Under current policy if an ISP assigns only /56s to each customer, then I count the number of customer and consider than many /56s as fully utilized. Under current policy if an ISP assigns a mix of /48s to each large customer, and /56s to each small customer then I count the number of small customer and consider than many /56s as fully utilized and, I count the number of large customers time 256 and count that many /56s as fully used. (this means unused /56s out of a /48 are counted against you thus discouraging mixed sizes). You left out the part where you have to justify issuing that many /56s to each of those large customers. Under current policy if an ISP assigns only /60s to each customer, then I count the number of customer and consider that number divided by 16 as the number of /56s as fully utilized. Well, actually, you just count everything as /60s in this case under current policy. Under the proposed policy only the last case changes. Under the proposed policy if an ISP assigns only /60s to each customer, then those customers having a /60 (smaller than a /56) are not counted as utilized by the ISP. Correct. Owen Is that correct? In general I am not opposed to discouraging ISPs from giving out smaller than a /56, unless the customer specifically requests a small block. ___Jason On Mon, Sep 28, 2015 at 11:35 AM, John Springer > wrote: Thanks, Matt This is precisely the subject on which I hoped to get community feedback. John Springer On Sat, 26 Sep 2015, Matthew Petach wrote: OPPOSED How I subdivide and allocate addresses internally and downstream is not a matter for the community to vote on; that's between me and my customers. Matt On Wed, Sep 23, 2015 at 1:54 PM, ARIN > wrote: Draft Policy ARIN-2015-10 Minimum IPv6 Assignments On 17 September 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-224 Minimum IPv6 Assignments" as a Draft Policy. Draft Policy ARIN-2015-10 is below and can be found at: https://www.arin.net/policy/proposals/2015_10.html You are encouraged to discuss the merits and your concerns of Draft Policy 2015-10 on the Public Policy Mailing List. 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 PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (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-2015-10 Minimum IPv6 Assignments Date: 23 September 2015 Problem Statement: ISPs may believe that they have an incentive to obtain smaller blocks than they really need, and once they receive their allocation may subsequently issue blocks smaller than their customers may need in the future. This policy seeks to encourage the correct behavior by reiterating the smallest reasonable sub-allocation size and by discounting any space which has been subdivided more finely from any future utilization analysis. Policy statement: Modify section 2.15 from "When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48)." to "When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP assigns to end sites. A /48 is recommended as this smallest block size. In no case shall a provider assignment unit for the purpose of this policy be smaller than /56." Modify section 2.16.1 from "A provider assignment unit shall be considered fully utilized when it is assigned to an end-site" to "A provider assignment unit shall be considered fully utilized when it is assigned in full (or as part of a larger aggregate) to a single end-site. If a provider assignment unit (which shall be no smaller than /56) is split and assigned to multiple end-sites that entire provider assignment unit shall be considered NOT utilized." Comments: 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. _______________________________________________ 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. _______________________________________________ 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 _______________________________________________ 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 -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 _______________________________________________ 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: From info at arin.net Wed Oct 14 13:40:22 2015 From: info at arin.net (ARIN) Date: Wed, 14 Oct 2015 13:40:22 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - October 2015 Message-ID: <561E9386.8@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) met on 9 October 2015. The AC moved the following to last call (to be posted separately to last call): Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations Having found the following Draft Policy to be fully developed and meeting ARIN's Principles of Internet Number Resource Policy, the AC recommended it for adoption (to be posted separately for discussion as a Recommended Draft Policy): Draft Policy ARIN-2015-5: Out of region use The AC abandoned the following: Draft Policy ARIN-2015-10: Minimum IPv6 Assignments "The AC abandoned Draft Policy ARIN-2015-10: "Minimum IPv6 Assignments" based on the generally negative feedback the proposal received from the community at the Public Policy Meeting in Montreal." The AC is continuing to work on: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy Draft Policy ARIN-2015-6: Transfers and Multi-national Networks Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Draft Policy ARIN-2015-11: Remove transfer language which only applied pre-exhaustion of IPv4 pool The AC abandoned 2015-10. Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Oct 14 13:40:48 2015 From: info at arin.net (ARIN) Date: Wed, 14 Oct 2015 13:40:48 -0400 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments Message-ID: <561E93A0.604@arin.net> The ARIN Advisory Council (AC) met on 9 October 2015 and decided to send the following to last call: Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments 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 28 October 2015. After last call the AC will conduct their last call review. The draft policy 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-2015-1 Modification to Criteria for IPv6 Initial End-User Assignments Date: 27 August 2015 AC's assessment of conformance with the Principles of Internet Number Resource Policy: ARIN-2015-1 enables fair and impartial number resource administration by providing a concrete threshold (13 active sites) under which end-user organizations who have a large number of potentially geographically dispersed sites, or sites with low subnet and/or user counts, can be reasonably assured of receiving IPv6 address space from ARIN. This proposal is technically sound, in that it retains reasonable thresholds on obtaining IPv6 assignments from ARIN in order to support the aggregation of Internet number resources in a hierarchical manner to the extent feasible. It has been well supported by the community on PPML and at the ARIN PPC at NANOG in San Francisco, where nearly everyone agreed that this was a step in the right direction. To the extent that some in the community desire even more relaxed IPv6 assignment policy, the AC encourages those community members to discuss on PPML and/or submit as additional policy proposals any further changes they would like to see. Problem Statement: Current policy for assignment to end users excludes a class of users whose costs to renumber would far exceed what current policy is designed to mitigate. Current measures designed to minimize the economic cost of renumbering per NRPM 6.5.8.1 (Initial Assignment Criteria) are: c. By having a network that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; These two measures fail to take into account end users who have a large number of potentially geographically dispersed sites, or sites with low subnet and/or user counts. The economic costs for this class of end user would likely far exceed the costs that 6.5.8.1 c. and d. are designed to mitigate. While an end user could possibly apply (and receive an assignment) under 6.5.8.1 e. ("By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable"), it fails to provide a concrete threshold under which this class of end-user can be reasonably assured of receiving address space. Without having the reasonable assurance of IPv6 address number resource continuity that a direct assignment allows, many smaller enterprises are unlikely to adopt IPv6 (currently perceived as an already tenuous proposition for most users given current cost/benefit); or are likely to adopt technical measures (such as using ULA addressing + NAT66) that are widely held to be damaging to the IPv6 Internet. Policy Statement: Renumber NRPM 6.5.8.1 Initial Assignment Criteria subsection e. to f. and and insert a new subsection e. with the following text: By having a contiguous network that has a minimum of 13 active sites within 12 months, or; Comments: a. Timetable for implementation: Immediate b. General Comments: - The threshold of 13 sites was chosen based on NRPM 6.5.8.2, which specifies 13 sites as the minimum number of sites required to receive a /40 initial assignment, to attempt to provide a balance between the costs of carrying the prefix vs. the costs to the end-user in renumbering. - Further constraints were added in that the sites must be in a contiguous network, to further attempt to reduce the costs of carrying the prefix - By introducing this new threshold, we attempt to restore equivalency of number resources for those end-users whose economic costs to renumber are equal to that of other end-users who would qualify for a direct assignment under 6.5.8.1 c. and d. c. Example: Example of an end-user who would not qualify under 6.5.8.2 c. or d.: - 50 locations (IPVPN) spread across the country/continent - 10 staff per location (average; 500 total) - 20 devices per location (average; 1000 total) - 2 subnets (voice & data) per location (average, 100 total) - Not multihomed - Currently using RFC1918 IPv4 space + NAT This end-user only benefits minimally from IPv6 multihoming as they are using an IPVPN, and multihoming provides benefit only for Internet transit, not within their IPVPN. As such requiring the end-user to multihome under NRPM 6.5.8.2 b. is wasteful. This end user currently uses RFC1918 IPv4 address space + a relatively small amount of IPv4 GUA + NAT (currently accepted industry practice for IPv4). Changing providers involves only renumbering the small amount of IPv4 GUA. Forcing the end-user to acquire an IPv4 direct assignment under NRPM 6.5.8.2 a. in order to be able to get a direct IPv6 assignment is incredibly wasteful of a valuable and limited number resource. It also forces the customer occupy more routing table space, as now an IPv4 PI prefix must be routed in addition to an IPv6 PI prefix, instead of using IPv4 PA + IPv6 PI (where only space for an IPv6 PI prefix is required). ##### ARIN STAFF ASSESSMENT Draft Policy ARIN-2015-1 Modification to Criteria for IPv6 Initial End-User Assignments https://www.arin.net/policy/proposals/2015_1.html Date of Assessment: June 11, 2015 ___ 1. Summary (Staff Understanding) This proposal would add a criteria item to 6.5.8.1 (Initial Assignment Criteria). Because each of the existing criteria items in that section can independently qualify an organization for IPv6 address space from ARIN, this new criteria item adds an additional qualification criteria. It makes it easier for some organizations to qualify, and does not make it more difficult for anyone. In particular, it creates a new criteria point that allows any end-user organization large enough to have 13 sites to immediately qualify for IPv6 address space from ARIN. ___ 2. Comments A. ARIN Staff Comments This proposal can be implemented as written. Minimal staff training and preparation would be needed to implement this if it were to become policy. We see no negative impacts. B. ARIN General Counsel ??? Legal Assessment Counsel sees no material legal issues in this policy. ___ 3. Resource Impact This policy would require minimal staff training and preparation. We see no negative impacts. From info at arin.net Wed Oct 14 13:41:00 2015 From: info at arin.net (ARIN) Date: Wed, 14 Oct 2015 13:41:00 -0400 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations Message-ID: <561E93AC.3010903@arin.net> The ARIN Advisory Council (AC) met on 9 October 2015 and decided to send the following to last call: Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations 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 28 October 2015. After last call the AC will conduct their last call review. The draft policy 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-2015-4 Modify 8.2 section to better reflect how ARIN handles reorganizations Date: 21 July 2015 AC's assessment of conformance with the Principles of Internet Number Resource Policy: 2015-4 is largely editorial in nature and does not change policy implementation, but clarifies existing use of policy. The proposal is fair in that it provides a consistent interface for transfers and clarifies the transfer policy. It is technically sound in that it is already effectively implemented. The proposal has received support on the mailing list and we expect it to be generally supported by the community as it is the direct result of community feed back on the existing policy. Problem Statement: ARIN staff indicated that NRPM 8.2 does not clearly indicate how ARIN procedures handle reorganizations. ARIN staff indicated that the first policy bullet point does not apply to reorganizations. Policy statement: Replacement text for entire 8.2 section: 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. In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy. Comments: The problem statement is addressed by: -re-title 8.2 -clarify the documentation bullet point -rearrange the documentation bullet to the end of the list since it only applies to some requestors, while the other bullet points apply to all requestors. a.Timetable for implementation: Immediate b.Anything else ##### ARIN STAFF & LEGAL ASSESSMENT Draft Policy ARIN-2015-4 Modify 8.2 section to better reflect how ARIN handles reorganizations https://www.arin.net/policy/proposals/2015_4.html Date of Assessment: July 14, 2015 ___ 1. Summary (Staff Understanding) This proposal would provide clarification to the 8.2 transfer policy for reorganizations. It does this by adding "reorganizations" to the title, and clarifies that evidence of acquired assets is only required for merger and acquisition transfers; not reorganizations. ___ 2. Comments A. ARIN Staff Comments This proposal can be implemented as written. Minimal staff training and preparation would be needed to implement this if it were to become policy. The proposal clarifies a point about reorganizations that has been confusing to customers in the past. We see no negative impacts. B. ARIN General Counsel ??? Legal Assessment Counsel sees no material legal issues in this policy. ___ 3. Resource Impact This policy would require minimal staff training and preparation. We see no negative impacts. From jcurran at arin.net Thu Oct 15 22:04:53 2015 From: jcurran at arin.net (John Curran) Date: Fri, 16 Oct 2015 02:04:53 +0000 Subject: [arin-ppml] ARIN 2015 election - Polls close in less than 24 hours (Fwd: [arin-announce] Voting Opens for ARIN 2015 Elections) References: <5616BF98.1030000@arin.net> Message-ID: <04CCB74A-FD89-4A60-9BBF-7ACABC58813F@corp.arin.net> Folks - If you have not voted in this year?s election, please do so as soon as possible. Reminder: voting closes tomorrow at 3:00 PM ET! Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Date: October 8, 2015 at 12:10:16 PM PDT To: > Subject: [arin-announce] Voting Opens for ARIN 2015 Elections The polls are now open for the elections to fill two seats on the ARIN Board of Trustees , five seats on the ARIN Advisory Council, and one seat on the NRO Number Council from the ARIN region. Polls close at 3:00 PM EDT, 16 October, and we have emailed specific voting instructions to all eligible Voting Contacts. Please see our Voting FAQ if you have questions about voter eligibility. https://www.arin.net/participate/elections/voterfaq.html You can also watch our video that provides an overview of ARIN Elections as well as instructions on how to vote. Video: https://www.youtube.com/watch?v=TV_h06DTtZ8 Voting Instructions: https://www.arin.net/participate/elections/instructions.html#vote Even if you aren't eligible to vote, you can still provide meaningful input by reviewing candidate biographies and submitting statements of support for candidates. https://www.bigpulse.com/p35820/ If you have any questions about voting or encounter problems with the system, please immediately contact ARIN Communications and Member Services at info at arin.net. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Oct 16 00:53:03 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 16 Oct 2015 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201510160453.t9G4r37I003421@rotala.raleigh.ibm.com> Total of 14 messages in the last 7 days. script run at: Fri Oct 16 00:53:03 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 21.43% | 3 | 12.16% | 27766 | info at arin.net 14.29% | 2 | 17.95% | 40983 | owen at delong.com 14.29% | 2 | 17.10% | 39044 | matthew at matthew.at 7.14% | 1 | 16.90% | 38581 | richardj at arin.net 7.14% | 1 | 8.09% | 18479 | rcarpen at network1.net 7.14% | 1 | 7.48% | 17072 | jschiller at google.com 7.14% | 1 | 6.74% | 15388 | jcurran at arin.net 7.14% | 1 | 5.31% | 12114 | scottleibrand at gmail.com 7.14% | 1 | 4.92% | 11241 | jrdelacruz at acm.org 7.14% | 1 | 3.34% | 7627 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 14 |100.00% | 228295 | Total From rcarpen at network1.net Fri Oct 16 11:47:35 2015 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 16 Oct 2015 11:47:35 -0400 (EDT) Subject: [arin-ppml] [ARIN-consult] ARIN 2015 election - Polls close in less than 24 hours (Fwd: [arin-announce] Voting Opens for ARIN 2015 Elections) In-Reply-To: <04CCB74A-FD89-4A60-9BBF-7ACABC58813F@corp.arin.net> References: <5616BF98.1030000@arin.net> <04CCB74A-FD89-4A60-9BBF-7ACABC58813F@corp.arin.net> Message-ID: <334323731.311439.1445010455287.JavaMail.zimbra@network1.net> Can someone from ARIN let us know why they thought it was necessary to call me at 5:00 AM *twice* to remind me to vote? I can only assume that others also received a call as well. thanks, -Randy ----- On Oct 15, 2015, at 10:04 PM, John Curran jcurran at arin.net wrote: > Folks - > If you have not voted in this year?s election, please do so as soon as possible. > > Reminder: voting closes tomorrow at 3:00 PM ET! > > Thanks! > /John > > John Curran > President and CEO > ARIN > > > > > Begin forwarded message: > > From: ARIN < info at arin.net > > Date: October 8, 2015 at 12:10:16 PM PDT > To: < arin-announce at arin.net > > Subject: [arin-announce] Voting Opens for ARIN 2015 Elections > > The polls are now open for the elections to fill two seats on the ARIN > Board of Trustees , five seats on the ARIN Advisory Council, and one > seat on the NRO Number Council from the ARIN region. > > Polls close at 3:00 PM EDT, 16 October, and we have emailed specific > voting instructions to all eligible Voting Contacts. > > Please see our Voting FAQ if you have questions about voter eligibility. > > https://www.arin.net/participate/elections/voterfaq.html > > You can also watch our video that provides an overview of ARIN Elections > as well as instructions on how to vote. > > Video: https://www.youtube.com/watch?v=TV_h06DTtZ8 > > Voting Instructions: > https://www.arin.net/participate/elections/instructions.html#vote > > > Even if you aren't eligible to vote, you can still provide meaningful > input by reviewing candidate biographies and submitting statements of > support for candidates. > > https://www.bigpulse.com/p35820/ > > If you have any questions about voting or encounter problems with the > system, please immediately contact ARIN Communications and Member > Services at info at arin.net. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > > > > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-announce > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult > Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN > Member Services > Help Desk at info at arin.net if you experience any issues. From josh at imaginenetworksllc.com Fri Oct 16 12:03:07 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 16 Oct 2015 12:03:07 -0400 Subject: [arin-ppml] [ARIN-consult] ARIN 2015 election - Polls close in less than 24 hours (Fwd: [arin-announce] Voting Opens for ARIN 2015 Elections) In-Reply-To: <334323731.311439.1445010455287.JavaMail.zimbra@network1.net> References: <5616BF98.1030000@arin.net> <04CCB74A-FD89-4A60-9BBF-7ACABC58813F@corp.arin.net> <334323731.311439.1445010455287.JavaMail.zimbra@network1.net> Message-ID: No call here Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Oct 16, 2015 8:54 AM, "Randy Carpenter" wrote: > > Can someone from ARIN let us know why they thought it was necessary to > call me at 5:00 AM *twice* to remind me to vote? > > I can only assume that others also received a call as well. > > > thanks, > -Randy > > > ----- On Oct 15, 2015, at 10:04 PM, John Curran jcurran at arin.net wrote: > > > Folks - > > If you have not voted in this year?s election, please do so as soon as > possible. > > > > Reminder: voting closes tomorrow at 3:00 PM ET! > > > > Thanks! > > /John > > > > John Curran > > President and CEO > > ARIN > > > > > > > > > > Begin forwarded message: > > > > From: ARIN < info at arin.net > > > Date: October 8, 2015 at 12:10:16 PM PDT > > To: < arin-announce at arin.net > > > Subject: [arin-announce] Voting Opens for ARIN 2015 Elections > > > > The polls are now open for the elections to fill two seats on the ARIN > > Board of Trustees , five seats on the ARIN Advisory Council, and one > > seat on the NRO Number Council from the ARIN region. > > > > Polls close at 3:00 PM EDT, 16 October, and we have emailed specific > > voting instructions to all eligible Voting Contacts. > > > > Please see our Voting FAQ if you have questions about voter eligibility. > > > > https://www.arin.net/participate/elections/voterfaq.html > > > > You can also watch our video that provides an overview of ARIN Elections > > as well as instructions on how to vote. > > > > Video: https://www.youtube.com/watch?v=TV_h06DTtZ8 > > > > Voting Instructions: > > https://www.arin.net/participate/elections/instructions.html#vote > > > > > > Even if you aren't eligible to vote, you can still provide meaningful > > input by reviewing candidate biographies and submitting statements of > > support for candidates. > > > > https://www.bigpulse.com/p35820/ > > > > If you have any questions about voting or encounter problems with the > > system, please immediately contact ARIN Communications and Member > > Services at info at arin.net. > > > > Regards, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > _______________________________________________ > > ARIN-Announce > > You are receiving this message because you are subscribed to > > the ARIN Announce Mailing List (ARIN-announce at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-announce > > Please contact info at arin.net if you experience any issues. > > > > > > _______________________________________________ > > ARIN-Consult > > You are receiving this message because you are subscribed to the ARIN > Consult > > Mailing > > List (ARIN-consult at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the > ARIN > > Member Services > > Help Desk at info at arin.net if you experience any issues. > _______________________________________________ > 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: From hannigan at gmail.com Tue Oct 20 10:56:55 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 20 Oct 2015 15:56:55 +0100 Subject: [arin-ppml] Transition /10 Message-ID: Any reason why at this point we shouldn't transition the transition /10 to a last /N like policy to more align with others? It does seem to be reasonable and fair. It seems like it was a mistake to not set aside the /8. Thoughts? Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrew.C.Hadenfeldt at windstream.com Tue Oct 20 11:05:35 2015 From: Andrew.C.Hadenfeldt at windstream.com (Hadenfeldt, Andrew C) Date: Tue, 20 Oct 2015 15:05:35 +0000 Subject: [arin-ppml] Transition /10 In-Reply-To: References: Message-ID: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> I?m missing some context? RFC6598 (100.64.0.0/10)? -Andy From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan Sent: Tuesday, October 20, 2015 9:57 AM To: arin-ppml at arin.net Subject: [arin-ppml] Transition /10 Any reason why at this point we shouldn't transition the transition /10 to a last /N like policy to more align with others? It does seem to be reasonable and fair. It seems like it was a mistake to not set aside the /8. Thoughts? Best, -M< ---------------------------------------------------------------------- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Timothy.S.Morizot at irs.gov Tue Oct 20 11:09:45 2015 From: Timothy.S.Morizot at irs.gov (Morizot Timothy S) Date: Tue, 20 Oct 2015 15:09:45 +0000 Subject: [arin-ppml] Transition /10 In-Reply-To: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> Message-ID: <968C470DAC25FB419E0159952F28F0C083D9F3E7@MEM0200CP3XF01.ds.irsnet.gov> A description of the problem the change is intended to address would also be helpful to provide better context. Thanks, Scott From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Hadenfeldt, Andrew C Sent: Tuesday, October 20, 2015 10:06 AM To: Martin Hannigan; arin-ppml at arin.net Subject: Re: [arin-ppml] Transition /10 I?m missing some context? RFC6598 (100.64.0.0/10)? -Andy From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan Sent: Tuesday, October 20, 2015 9:57 AM To: arin-ppml at arin.net Subject: [arin-ppml] Transition /10 Any reason why at this point we shouldn't transition the transition /10 to a last /N like policy to more align with others? It does seem to be reasonable and fair. It seems like it was a mistake to not set aside the /8. Thoughts? Best, -M< ________________________________ This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbrumund at dyn.com Tue Oct 20 11:14:51 2015 From: kbrumund at dyn.com (Karl Brumund) Date: Tue, 20 Oct 2015 11:14:51 -0400 Subject: [arin-ppml] Transition /10 In-Reply-To: <968C470DAC25FB419E0159952F28F0C083D9F3E7@MEM0200CP3XF01.ds.irsnet.gov> References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> <968C470DAC25FB419E0159952F28F0C083D9F3E7@MEM0200CP3XF01.ds.irsnet.gov> Message-ID: I assume Marty is talking about the last /10, not RFC6598 space, but I am also unclear. 23.128.0.0/10 per NRPM Section 4.10 ...karl On Tue, Oct 20, 2015 at 11:09 AM, Morizot Timothy S < Timothy.S.Morizot at irs.gov> wrote: > A description of the problem the change is intended to address would also > be helpful to provide better context. > > > > Thanks, > > > > Scott > > > > *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On > Behalf Of *Hadenfeldt, Andrew C > *Sent:* Tuesday, October 20, 2015 10:06 AM > *To:* Martin Hannigan; arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Transition /10 > > > > I?m missing some context? RFC6598 (100.64.0.0/10)? > > > > *-Andy * > > > > *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net > ] *On Behalf Of *Martin Hannigan > *Sent:* Tuesday, October 20, 2015 9:57 AM > *To:* arin-ppml at arin.net > *Subject:* [arin-ppml] Transition /10 > > > > > > Any reason why at this point we shouldn't transition the transition /10 to > a last /N like policy to more align with others? It does seem to be > reasonable and fair. It seems like it was a mistake to not set aside the /8. > > Thoughts? > > Best, > > -M< > ------------------------------ > > This email message and any attachments are for the sole use of the > intended recipient(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply email and destroy all copies of the original > message and any attachments. > > _______________________________________________ > 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: From hannigan at gmail.com Tue Oct 20 11:14:48 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 20 Oct 2015 16:14:48 +0100 Subject: [arin-ppml] Transition /10 In-Reply-To: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> Message-ID: s\/transition/v6 deployment/g terminology collision. Re-purposing this for new entrants and last allocations, not necessarily "fully" aligning with other regions. You can currently go to RIPE for a last /22 regardless of what region you're in and seems to contradict at least the current fail on "allowing" use of global resources. Anyhow. Just tossing it out there. On Tue, Oct 20, 2015 at 4:05 PM, Hadenfeldt, Andrew C < Andrew.C.Hadenfeldt at windstream.com> wrote: > I?m missing some context? RFC6598 (100.64.0.0/10)? > > > > *-Andy * > > > > *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On > Behalf Of *Martin Hannigan > *Sent:* Tuesday, October 20, 2015 9:57 AM > *To:* arin-ppml at arin.net > *Subject:* [arin-ppml] Transition /10 > > > > > > Any reason why at this point we shouldn't transition the transition /10 to > a last /N like policy to more align with others? It does seem to be > reasonable and fair. It seems like it was a mistake to not set aside the /8. > > Thoughts? > > Best, > > -M< > ------------------------------ > This email message and any attachments are for the sole use of the > intended recipient(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply email and destroy all copies of the original > message and any attachments. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Tue Oct 20 11:17:58 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 20 Oct 2015 16:17:58 +0100 Subject: [arin-ppml] Transition /10 In-Reply-To: References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> <968C470DAC25FB419E0159952F28F0C083D9F3E7@MEM0200CP3XF01.ds.irsnet.gov> Message-ID: Thanks Karl, indeed, 4.10. On Tue, Oct 20, 2015 at 4:14 PM, Karl Brumund wrote: > I assume Marty is talking about the last /10, not RFC6598 space, but I am > also unclear. > 23.128.0.0/10 per NRPM Section 4.10 > > ...karl > > On Tue, Oct 20, 2015 at 11:09 AM, Morizot Timothy S < > Timothy.S.Morizot at irs.gov> wrote: > >> A description of the problem the change is intended to address would also >> be helpful to provide better context. >> >> >> >> Thanks, >> >> >> >> Scott >> >> >> >> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On >> Behalf Of *Hadenfeldt, Andrew C >> *Sent:* Tuesday, October 20, 2015 10:06 AM >> *To:* Martin Hannigan; arin-ppml at arin.net >> *Subject:* Re: [arin-ppml] Transition /10 >> >> >> >> I?m missing some context? RFC6598 (100.64.0.0/10)? >> >> >> >> *-Andy * >> >> >> >> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net >> ] *On Behalf Of *Martin Hannigan >> *Sent:* Tuesday, October 20, 2015 9:57 AM >> *To:* arin-ppml at arin.net >> *Subject:* [arin-ppml] Transition /10 >> >> >> >> >> >> Any reason why at this point we shouldn't transition the transition /10 >> to a last /N like policy to more align with others? It does seem to be >> reasonable and fair. It seems like it was a mistake to not set aside the /8. >> >> Thoughts? >> >> Best, >> >> -M< >> ------------------------------ >> >> This email message and any attachments are for the sole use of the >> intended recipient(s). Any unauthorized review, use, disclosure or >> distribution is prohibited. If you are not the intended recipient, please >> contact the sender by reply email and destroy all copies of the original >> message and any attachments. >> >> _______________________________________________ >> 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. >> > > > _______________________________________________ > 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: From cspears at oar.net Tue Oct 20 11:21:11 2015 From: cspears at oar.net (Spears, Christopher M.) Date: Tue, 20 Oct 2015 15:21:11 +0000 Subject: [arin-ppml] Transition /10 In-Reply-To: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> Message-ID: NRPM 4.10 [1] dedicated /10 for IPv6 "transition?.. I tossed a similar idea around with some folks at ARIN36. Use this /10 to allocate a /24 per **new** Org, and steer subsequent transactions to transfers. That would ensure IPv4 for ~16K **new** entrants in the coming years.. [1] https://www.arin.net/policy/nrpm.html#four10 On Oct 20, 2015, at 11:05 AM, Hadenfeldt, Andrew C wrote: > I?m missing some context? RFC6598 (100.64.0.0/10)? > > -Andy > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan > Sent: Tuesday, October 20, 2015 9:57 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Transition /10 > > > Any reason why at this point we shouldn't transition the transition /10 to a last /N like policy to more align with others? It does seem to be reasonable and fair. It seems like it was a mistake to not set aside the /8. > > Thoughts? > > Best, > > -M< > This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. > _______________________________________________ > 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. From Timothy.S.Morizot at irs.gov Tue Oct 20 11:35:22 2015 From: Timothy.S.Morizot at irs.gov (Morizot Timothy S) Date: Tue, 20 Oct 2015 15:35:22 +0000 Subject: [arin-ppml] Transition /10 In-Reply-To: References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> Message-ID: <968C470DAC25FB419E0159952F28F0C083D9F45F@MEM0200CP3XF01.ds.irsnet.gov> Thanks for the clarifications. In that context, assuming a new entrant is deploying IPv6, wouldn't the current policy allow them to request allocations to support that deployment. It specifically mentions needs like dual-stacked nameservers and various IPv4 life extension solutions. If a new entrant *isn't* deploying IPv6 from the start, do we really want to support them with a free pool allocation? For any needs beyond those described in the policy, there's the transfer market. I don't know that I have particularly strong feelings either way, but if we're going to reserve any general use pool at all rather than simply handing it all out to meet current need, I think it's better to tie it to demonstrated IPv6 deployment. Scott -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Spears, Christopher M. Sent: Tuesday, October 20, 2015 10:21 AM To: Hadenfeldt, Andrew C Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Transition /10 NRPM 4.10 [1] dedicated /10 for IPv6 "transition".. I tossed a similar idea around with some folks at ARIN36. Use this /10 to allocate a /24 per **new** Org, and steer subsequent transactions to transfers. That would ensure IPv4 for ~16K **new** entrants in the coming years.. [1] https://www.arin.net/policy/nrpm.html#four10 From owen at delong.com Tue Oct 20 12:33:10 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Oct 2015 09:33:10 -0700 Subject: [arin-ppml] Transition /10 In-Reply-To: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> Message-ID: <5F6BC072-E10C-4F19-89D7-234EE5D9F317@delong.com> I?m pretty sure he?s not talking about that, but rather about ARIN NRPM Section 4.10 (which happens to be 23.128.0.0/10) Owen > On Oct 20, 2015, at 08:05 , Hadenfeldt, Andrew C wrote: > > I?m missing some context? RFC6598 (100.64.0.0/10)? > > -Andy > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Martin Hannigan > Sent: Tuesday, October 20, 2015 9:57 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Transition /10 > > > Any reason why at this point we shouldn't transition the transition /10 to a last /N like policy to more align with others? It does seem to be reasonable and fair. It seems like it was a mistake to not set aside the /8. > > Thoughts? > > Best, > > -M< > This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. > _______________________________________________ > 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: From andrew.dul at quark.net Tue Oct 20 12:38:19 2015 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 20 Oct 2015 18:38:19 +0200 Subject: [arin-ppml] Transition /10 In-Reply-To: <968C470DAC25FB419E0159952F28F0C083D9F45F@MEM0200CP3XF01.ds.irsnet.gov> References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> <968C470DAC25FB419E0159952F28F0C083D9F45F@MEM0200CP3XF01.ds.irsnet.gov> Message-ID: The ARIN community previously considered these ideas under 2014-16, but changing the /10 to something other than transition never had sufficient support for the AC to move it forward. https://www.arin.net/policy/proposals/2014_16.html .Andrew > On Oct 20, 2015, at 5:35 PM, Morizot Timothy S wrote: > > Thanks for the clarifications. In that context, assuming a new entrant is deploying IPv6, wouldn't the current policy allow them to request allocations to support that deployment. It specifically mentions needs like dual-stacked nameservers and various IPv4 life extension solutions. If a new entrant *isn't* deploying IPv6 from the start, do we really want to support them with a free pool allocation? For any needs beyond those described in the policy, there's the transfer market. I don't know that I have particularly strong feelings either way, but if we're going to reserve any general use pool at all rather than simply handing it all out to meet current need, I think it's better to tie it to demonstrated IPv6 deployment. > > Scott > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Spears, Christopher M. > Sent: Tuesday, October 20, 2015 10:21 AM > To: Hadenfeldt, Andrew C > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Transition /10 > > NRPM 4.10 [1] dedicated /10 for IPv6 "transition".. > > I tossed a similar idea around with some folks at ARIN36. Use this /10 to allocate a /24 per **new** Org, and steer subsequent transactions to transfers. That would ensure IPv4 for ~16K **new** entrants in the coming years.. > > [1] https://www.arin.net/policy/nrpm.html#four10 > > _______________________________________________ > 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: From hannigan at gmail.com Tue Oct 20 14:03:28 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 20 Oct 2015 19:03:28 +0100 Subject: [arin-ppml] Transition /10 In-Reply-To: References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> <968C470DAC25FB419E0159952F28F0C083D9F45F@MEM0200CP3XF01.ds.irsnet.gov> Message-ID: That was 2014. It is now near 2016. Then, we were not exhausted. Now, we are. Here's the RIPE policy bits https://www.ripe.net/publications/docs/ripe-649 Here's the ARIN policy: https://www.arin.net/policy/nrpm.html (Section 4.10) A brief summary. The RIPE policy is liberal in that every LIR (new or old) gets a /22. The ARIN policy is restrictive and digs into the same old noise around needs and transfer. We _could_ narrow this to new entrants (which does pose an antitrust question). We _could_ also direct that incoming IANA bits be redirected to new entrants as well up to the equivalent of a /8 to be parallel to other regions, but I'm not sure we need a limit although. We _could_ limit the size of the allocation to no longer shorter than a /24. Best, -M< On Tue, Oct 20, 2015 at 5:38 PM, Andrew Dul wrote: > The ARIN community previously considered these ideas under 2014-16, but > changing the /10 to something other than transition never had sufficient > support for the AC to move it forward. > > https://www.arin.net/policy/proposals/2014_16.html > > .Andrew > > On Oct 20, 2015, at 5:35 PM, Morizot Timothy S > wrote: > > Thanks for the clarifications. In that context, assuming a new entrant is > deploying IPv6, wouldn't the current policy allow them to request > allocations to support that deployment. It specifically mentions needs like > dual-stacked nameservers and various IPv4 life extension solutions. If a > new entrant *isn't* deploying IPv6 from the start, do we really want to > support them with a free pool allocation? For any needs beyond those > described in the policy, there's the transfer market. I don't know that I > have particularly strong feelings either way, but if we're going to reserve > any general use pool at all rather than simply handing it all out to meet > current need, I think it's better to tie it to demonstrated IPv6 deployment. > > Scott > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net > ] On Behalf Of Spears, Christopher M. > Sent: Tuesday, October 20, 2015 10:21 AM > To: Hadenfeldt, Andrew C > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Transition /10 > > NRPM 4.10 [1] dedicated /10 for IPv6 "transition".. > > I tossed a similar idea around with some folks at ARIN36. Use this /10 > to allocate a /24 per **new** Org, and steer subsequent transactions to > transfers. That would ensure IPv4 for ~16K **new** entrants in the coming > years.. > > [1] https://www.arin.net/policy/nrpm.html#four10 > > _______________________________________________ > 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. > > > _______________________________________________ > 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: From kbrumund at dyn.com Tue Oct 20 15:12:00 2015 From: kbrumund at dyn.com (Karl Brumund) Date: Tue, 20 Oct 2015 15:12:00 -0400 Subject: [arin-ppml] Transition /10 In-Reply-To: References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> <968C470DAC25FB419E0159952F28F0C083D9F45F@MEM0200CP3XF01.ds.irsnet.gov> Message-ID: Martin, I'm unsure what the problem is that you're trying to solve. I'm guessing it's `let anybody new get a /24` so they have a chance for some v4 space. Or maybe its have ARIN be the same as other regions (though I'd say the transfer process is a bigger fish for that). You mentioned 'reasonable and fair'. Could you elaborate a bit, as I think I'm not caffinated enough to follow. Thanks! ...karl On Tue, Oct 20, 2015 at 2:03 PM, Martin Hannigan wrote: > > That was 2014. It is now near 2016. Then, we were not exhausted. Now, we > are. > > Here's the RIPE policy bits > > https://www.ripe.net/publications/docs/ripe-649 > > Here's the ARIN policy: > > https://www.arin.net/policy/nrpm.html (Section 4.10) > > A brief summary. > > The RIPE policy is liberal in that every LIR (new or old) gets a /22. The > ARIN policy is restrictive and digs into the same old noise around needs > and transfer. > > We _could_ narrow this to new entrants (which does pose an antitrust > question). > > We _could_ also direct that incoming IANA bits be redirected to new > entrants as well up to the equivalent of a /8 to be parallel to other > regions, but I'm not sure we need a limit although. > > We _could_ limit the size of the allocation to no longer shorter than a > /24. > > > Best, > > -M< > > > On Tue, Oct 20, 2015 at 5:38 PM, Andrew Dul wrote: > >> The ARIN community previously considered these ideas under 2014-16, but >> changing the /10 to something other than transition never had sufficient >> support for the AC to move it forward. >> >> https://www.arin.net/policy/proposals/2014_16.html >> >> .Andrew >> >> On Oct 20, 2015, at 5:35 PM, Morizot Timothy S >> wrote: >> >> Thanks for the clarifications. In that context, assuming a new entrant is >> deploying IPv6, wouldn't the current policy allow them to request >> allocations to support that deployment. It specifically mentions needs like >> dual-stacked nameservers and various IPv4 life extension solutions. If a >> new entrant *isn't* deploying IPv6 from the start, do we really want to >> support them with a free pool allocation? For any needs beyond those >> described in the policy, there's the transfer market. I don't know that I >> have particularly strong feelings either way, but if we're going to reserve >> any general use pool at all rather than simply handing it all out to meet >> current need, I think it's better to tie it to demonstrated IPv6 deployment. >> >> Scott >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net >> ] On Behalf Of Spears, Christopher M. >> Sent: Tuesday, October 20, 2015 10:21 AM >> To: Hadenfeldt, Andrew C >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Transition /10 >> >> NRPM 4.10 [1] dedicated /10 for IPv6 "transition".. >> >> I tossed a similar idea around with some folks at ARIN36. Use this /10 >> to allocate a /24 per **new** Org, and steer subsequent transactions to >> transfers. That would ensure IPv4 for ~16K **new** entrants in the coming >> years.. >> >> [1] https://www.arin.net/policy/nrpm.html#four10 >> >> _______________________________________________ >> 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. >> >> >> _______________________________________________ >> 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. >> > > > _______________________________________________ > 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: From hannigan at gmail.com Tue Oct 20 16:00:12 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 20 Oct 2015 21:00:12 +0100 Subject: [arin-ppml] Transition /10 In-Reply-To: References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> <968C470DAC25FB419E0159952F28F0C083D9F45F@MEM0200CP3XF01.ds.irsnet.gov> Message-ID: Hi Karl, Just throwing it out there. My personal opinion is that the v6 deployment /10 is a failure and an economic limiter for new entrants and could be rethought. Best, -M< > On Oct 20, 2015, at 20:12, Karl Brumund wrote: > > Martin, > I'm unsure what the problem is that you're trying to solve. I'm guessing it's `let anybody new get a /24` so they have a chance for some v4 space. Or maybe its have ARIN be the same as other regions (though I'd say the transfer process is a bigger fish for that). > You mentioned 'reasonable and fair'. Could you elaborate a bit, as I think I'm not caffinated enough to follow. > > Thanks! > ...karl > > >> On Tue, Oct 20, 2015 at 2:03 PM, Martin Hannigan wrote: >> >> That was 2014. It is now near 2016. Then, we were not exhausted. Now, we are. >> >> Here's the RIPE policy bits >> >> https://www.ripe.net/publications/docs/ripe-649 >> >> Here's the ARIN policy: >> >> https://www.arin.net/policy/nrpm.html (Section 4.10) >> >> A brief summary. >> >> The RIPE policy is liberal in that every LIR (new or old) gets a /22. The ARIN policy is restrictive and digs into the same old noise around needs and transfer. >> >> We _could_ narrow this to new entrants (which does pose an antitrust question). >> >> We _could_ also direct that incoming IANA bits be redirected to new entrants as well up to the equivalent of a /8 to be parallel to other regions, but I'm not sure we need a limit although. >> >> We _could_ limit the size of the allocation to no longer shorter than a /24. >> >> >> Best, >> >> -M< >> >> >>> On Tue, Oct 20, 2015 at 5:38 PM, Andrew Dul wrote: >>> The ARIN community previously considered these ideas under 2014-16, but changing the /10 to something other than transition never had sufficient support for the AC to move it forward. >>> >>> https://www.arin.net/policy/proposals/2014_16.html >>> >>> .Andrew >>> >>>> On Oct 20, 2015, at 5:35 PM, Morizot Timothy S wrote: >>>> >>>> Thanks for the clarifications. In that context, assuming a new entrant is deploying IPv6, wouldn't the current policy allow them to request allocations to support that deployment. It specifically mentions needs like dual-stacked nameservers and various IPv4 life extension solutions. If a new entrant *isn't* deploying IPv6 from the start, do we really want to support them with a free pool allocation? For any needs beyond those described in the policy, there's the transfer market. I don't know that I have particularly strong feelings either way, but if we're going to reserve any general use pool at all rather than simply handing it all out to meet current need, I think it's better to tie it to demonstrated IPv6 deployment. >>>> >>>> Scott >>>> >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Spears, Christopher M. >>>> Sent: Tuesday, October 20, 2015 10:21 AM >>>> To: Hadenfeldt, Andrew C >>>> Cc: arin-ppml at arin.net >>>> Subject: Re: [arin-ppml] Transition /10 >>>> >>>> NRPM 4.10 [1] dedicated /10 for IPv6 "transition".. >>>> >>>> I tossed a similar idea around with some folks at ARIN36. Use this /10 to allocate a /24 per **new** Org, and steer subsequent transactions to transfers. That would ensure IPv4 for ~16K **new** entrants in the coming years.. >>>> >>>> [1] https://www.arin.net/policy/nrpm.html#four10 >>>> >>>> _______________________________________________ >>>> 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. >>> >>> _______________________________________________ >>> 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. >> >> >> _______________________________________________ >> 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. > > _______________________________________________ > 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: From scottleibrand at gmail.com Tue Oct 20 21:20:22 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 20 Oct 2015 18:20:22 -0700 Subject: [arin-ppml] Transition /10 In-Reply-To: References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> <968C470DAC25FB419E0159952F28F0C083D9F45F@MEM0200CP3XF01.ds.irsnet.gov> Message-ID: Personally I think we'll have a much better idea in a few months how well the v6 deployment /10 has worked. Up until now, it's been easier to get (larger) general free pool allocations than space from the /10. Now that the free pool is exhausted, I expect to see every new entrant applying for a block under 4.10, so we should very rapidly get some data on how easy it is for them to get something useful. Based on that experience and data, I would be quite willing to consider a policy change, but up until now I think we've been seeing exactly what we should've expected to see. -Scott On Tue, Oct 20, 2015 at 1:00 PM, Martin Hannigan wrote: > > Hi Karl, > > Just throwing it out there. My personal opinion is that the v6 deployment > /10 is a failure and an economic limiter for new entrants and could be > rethought. > > Best, > > -M< > > On Oct 20, 2015, at 20:12, Karl Brumund wrote: > > Martin, > I'm unsure what the problem is that you're trying to solve. I'm guessing > it's `let anybody new get a /24` so they have a chance for some v4 space. > Or maybe its have ARIN be the same as other regions (though I'd say the > transfer process is a bigger fish for that). > You mentioned 'reasonable and fair'. Could you elaborate a bit, as I think > I'm not caffinated enough to follow. > > Thanks! > ...karl > > > On Tue, Oct 20, 2015 at 2:03 PM, Martin Hannigan > wrote: > >> >> That was 2014. It is now near 2016. Then, we were not exhausted. Now, we >> are. >> >> Here's the RIPE policy bits >> >> https://www.ripe.net/publications/docs/ripe-649 >> >> Here's the ARIN policy: >> >> https://www.arin.net/policy/nrpm.html (Section 4.10) >> >> A brief summary. >> >> The RIPE policy is liberal in that every LIR (new or old) gets a /22. The >> ARIN policy is restrictive and digs into the same old noise around needs >> and transfer. >> >> We _could_ narrow this to new entrants (which does pose an antitrust >> question). >> >> We _could_ also direct that incoming IANA bits be redirected to new >> entrants as well up to the equivalent of a /8 to be parallel to other >> regions, but I'm not sure we need a limit although. >> >> We _could_ limit the size of the allocation to no longer shorter than a >> /24. >> >> >> Best, >> >> -M< >> >> >> On Tue, Oct 20, 2015 at 5:38 PM, Andrew Dul wrote: >> >>> The ARIN community previously considered these ideas under 2014-16, but >>> changing the /10 to something other than transition never had sufficient >>> support for the AC to move it forward. >>> >>> https://www.arin.net/policy/proposals/2014_16.html >>> >>> .Andrew >>> >>> On Oct 20, 2015, at 5:35 PM, Morizot Timothy S < >>> Timothy.S.Morizot at irs.gov> wrote: >>> >>> Thanks for the clarifications. In that context, assuming a new entrant >>> is deploying IPv6, wouldn't the current policy allow them to request >>> allocations to support that deployment. It specifically mentions needs like >>> dual-stacked nameservers and various IPv4 life extension solutions. If a >>> new entrant *isn't* deploying IPv6 from the start, do we really want to >>> support them with a free pool allocation? For any needs beyond those >>> described in the policy, there's the transfer market. I don't know that I >>> have particularly strong feelings either way, but if we're going to reserve >>> any general use pool at all rather than simply handing it all out to meet >>> current need, I think it's better to tie it to demonstrated IPv6 deployment. >>> >>> Scott >>> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net >>> ] On Behalf Of Spears, Christopher M. >>> Sent: Tuesday, October 20, 2015 10:21 AM >>> To: Hadenfeldt, Andrew C >>> Cc: arin-ppml at arin.net >>> Subject: Re: [arin-ppml] Transition /10 >>> >>> NRPM 4.10 [1] dedicated /10 for IPv6 "transition".. >>> >>> I tossed a similar idea around with some folks at ARIN36. Use this /10 >>> to allocate a /24 per **new** Org, and steer subsequent transactions to >>> transfers. That would ensure IPv4 for ~16K **new** entrants in the coming >>> years.. >>> >>> [1] https://www.arin.net/policy/nrpm.html#four10 >>> >>> _______________________________________________ >>> 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. >>> >>> >>> _______________________________________________ >>> 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. >>> >> >> >> _______________________________________________ >> 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. >> > > _______________________________________________ > 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. > > > _______________________________________________ > 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: From hannigan at gmail.com Tue Oct 20 21:22:38 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 21 Oct 2015 02:22:38 +0100 Subject: [arin-ppml] Transition /10 In-Reply-To: References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> <968C470DAC25FB419E0159952F28F0C083D9F45F@MEM0200CP3XF01.ds.irsnet.gov> Message-ID: > On Oct 21, 2015, at 02:20, Scott Leibrand wrote: > > Personally I think we'll have a much better idea in a few months how well the v6 deployment /10 has worked. Any data on uptake to date? From scottleibrand at gmail.com Tue Oct 20 21:41:06 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 20 Oct 2015 18:41:06 -0700 Subject: [arin-ppml] Transition /10 In-Reply-To: References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> <968C470DAC25FB419E0159952F28F0C083D9F45F@MEM0200CP3XF01.ds.irsnet.gov> Message-ID: At Montreal ARIN reported (in their Policy Experience Report) that: "We have received and approved 2 requests so far (/24s) We will keep the community informed as this policy enters expected high volume use" -Scott On Tue, Oct 20, 2015 at 6:22 PM, Martin Hannigan wrote: > > > > On Oct 21, 2015, at 02:20, Scott Leibrand > wrote: > > > > Personally I think we'll have a much better idea in a few months how > well the v6 deployment /10 has worked. > > Any data on uptake to date? > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Oct 20 22:01:54 2015 From: farmer at umn.edu (David Farmer) Date: Tue, 20 Oct 2015 21:01:54 -0500 Subject: [arin-ppml] Transition /10 In-Reply-To: References: <5D106C75D5C2DD41AB2B4B823FE0EC05547426@CWWAPP480.windstream.com> <968C470DAC25FB419E0159952F28F0C083D9F45F@MEM0200CP3XF01.ds.irsnet.gov> Message-ID: <5626F212.9000806@umn.edu> I think Section 4.10 (2008-5) is working as planed. https://www.arin.net/policy/proposals/2008_5.html The IPv4 free pool is now out and we still have a /10 for those that need some IPv4 for IPv6 deployments. At least that much is a success. We would be far worse off without the /10. Our community couldn't agree on reserving the whole last /8 like some of other RIRs did. A /10 isn't enough for the same kind of last /8 policy that the other RIRs have, that is everyone gets a /22 or something like that. It's really too late to change that now. However, we need to think hard about the current policy and if the details are correct now that the IPv4 free pool is gone and we actually need to make use of it. I would love to hear experiences using and/or suggestions to improve section 4.10. But, with only a /10 I'm going to be very leery of suggestions for use of the 4.10 reservation that are not directly tied to IPv6 deployment requirements. If you want IPv4 for IPv4 sake there are transfers and the waiting list, and the waiting list isn't a reliable source of addresses, so that really only leaves transfers. thanks On 10/20/15 20:20 , Scott Leibrand wrote: > Personally I think we'll have a much better idea in a few months how > well the v6 deployment /10 has worked. Up until now, it's been easier > to get (larger) general free pool allocations than space from the /10. > Now that the free pool is exhausted, I expect to see every new entrant > applying for a block under 4.10, so we should very rapidly get some data > on how easy it is for them to get something useful. Based on that > experience and data, I would be quite willing to consider a policy > change, but up until now I think we've been seeing exactly what we > should've expected to see. > > -Scott > > On Tue, Oct 20, 2015 at 1:00 PM, Martin Hannigan > wrote: > > > Hi Karl, > > Just throwing it out there. My personal opinion is that the v6 > deployment /10 is a failure and an economic limiter for new entrants > and could be rethought. > > Best, > > -M< > > On Oct 20, 2015, at 20:12, Karl Brumund > wrote: > >> Martin, >> I'm unsure what the problem is that you're trying to solve. I'm >> guessing it's `let anybody new get a /24` so they have a chance >> for some v4 space. Or maybe its have ARIN be the same as other >> regions (though I'd say the transfer process is a bigger fish for >> that). >> You mentioned 'reasonable and fair'. Could you elaborate a bit, as >> I think I'm not caffinated enough to follow. >> >> Thanks! >> ...karl >> >> >> On Tue, Oct 20, 2015 at 2:03 PM, Martin Hannigan >> > wrote: >> >> >> That was 2014. It is now near 2016. Then, we were not >> exhausted. Now, we are. >> >> Here's the RIPE policy bits >> >> https://www.ripe.net/publications/docs/ripe-649 >> >> Here's the ARIN policy: >> >> https://www.arin.net/policy/nrpm.html (Section 4.10) >> >> A brief summary. >> >> The RIPE policy is liberal in that every LIR (new or old) gets >> a /22. The ARIN policy is restrictive and digs into the same >> old noise around needs and transfer. >> >> We _could_ narrow this to new entrants (which does pose an >> antitrust question). >> >> We _could_ also direct that incoming IANA bits be redirected >> to new entrants as well up to the equivalent of a /8 to be >> parallel to other regions, but I'm not sure we need a limit >> although. >> >> We _could_ limit the size of the allocation to no longer >> shorter than a /24. >> >> >> Best, >> >> -M< >> >> >> On Tue, Oct 20, 2015 at 5:38 PM, Andrew Dul >> > wrote: >> >> The ARIN community previously considered these ideas under >> 2014-16, but changing the /10 to something other than >> transition never had sufficient support for the AC to move >> it forward. >> >> https://www.arin.net/policy/proposals/2014_16.html >> >> .Andrew >> >> On Oct 20, 2015, at 5:35 PM, Morizot Timothy S >> > > wrote: >> >>> Thanks for the clarifications. In that context, assuming >>> a new entrant is deploying IPv6, wouldn't the current >>> policy allow them to request allocations to support that >>> deployment. It specifically mentions needs like >>> dual-stacked nameservers and various IPv4 life extension >>> solutions. If a new entrant *isn't* deploying IPv6 from >>> the start, do we really want to support them with a free >>> pool allocation? For any needs beyond those described in >>> the policy, there's the transfer market. I don't know >>> that I have particularly strong feelings either way, but >>> if we're going to reserve any general use pool at all >>> rather than simply handing it all out to meet current >>> need, I think it's better to tie it to demonstrated IPv6 >>> deployment. >>> >>> Scott >>> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net >>> >>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Spears, >>> Christopher M. >>> Sent: Tuesday, October 20, 2015 10:21 AM >>> To: Hadenfeldt, Andrew C >>> Cc: arin-ppml at arin.net >>> Subject: Re: [arin-ppml] Transition /10 >>> >>> NRPM 4.10 [1] dedicated /10 for IPv6 "transition".. >>> >>> I tossed a similar idea around with some folks at ARIN36. >>> Use this /10 to allocate a /24 per **new** Org, and >>> steer subsequent transactions to transfers. That would >>> ensure IPv4 for ~16K **new** entrants in the coming years.. >>> >>> [1] https://www.arin.net/policy/nrpm.html#four10 >>> >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> 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. >> >> >> >> _______________________________________________ >> 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. >> >> >> _______________________________________________ >> 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. > > _______________________________________________ > 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. > > > > > _______________________________________________ > 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. > -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From hannigan at gmail.com Wed Oct 21 08:27:59 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 21 Oct 2015 13:27:59 +0100 Subject: [arin-ppml] 4.10 transition/deployment /10 Was: Re: Transition /10 Message-ID: Renamed to be more specific. On Wed, Oct 21, 2015 at 3:01 AM, David Farmer wrote: > I think Section 4.10 (2008-5) is working as planed. > > https://www.arin.net/policy/proposals/2008_5.html > > The IPv4 free pool is now out and we still have a /10 for those that need > some IPv4 for IPv6 deployments. At least that much is a success. We would > be far worse off without the /10. > Our community couldn't agree on reserving the whole last /8 like some of > other RIRs did. A /10 isn't enough for the same kind of last /8 policy > that the other RIRs have, that is everyone gets a /22 or something like > that. It's really too late to change that now. > It's not, but the prefix size could be (unfortunately) reduce to accomplish much of the same except not at the same scale in terms of utility. > > However, we need to think hard about the current policy and if the details > are correct now that the IPv4 free pool is gone and we actually need to > make use of it. I would love to hear experiences using and/or suggestions > to improve section 4.10. But, with only a /10 I'm going to be very leery > of suggestions for use of the 4.10 reservation that are not directly tied > to IPv6 deployment requirements. > > Well, there's at least 2 x use. :) > If you want IPv4 for IPv4 sake there are transfers and the waiting list, > and the waiting list isn't a reliable source of addresses, so that really > only leaves transfers. > >> > > I'm well aware of how to get v4 addresses, but thanks. Watching the debate over the RIPE last /8 policy, it simple convinced me we were _wrong_. And having networks go to RIPE for their last v4 allocation seems to be at odds with "out of region" use, which in itself is of questionable utility. The RIPE region could adjust their policies accordingly, but they seemed to have gotten it mostly right. Making new entry into the market easy-peasy without technical restrictions other than you need to use it seems more reasonable that what we have. The impact to v6 deployment overall is probably zero. And finally, it at least addresses the inequity that new entrants will have with those of us who are policy expects and know how to use the secret decoder ring e.g. "assigned" "provisioned" "get a new ORG ID" etc. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Wed Oct 21 13:08:47 2015 From: farmer at umn.edu (David Farmer) Date: Wed, 21 Oct 2015 12:08:47 -0500 Subject: [arin-ppml] 4.10 transition/deployment /10 Was: Re: Transition /10 In-Reply-To: References: Message-ID: <5627C69F.5040505@umn.edu> On 10/21/15 07:27 , Martin Hannigan wrote: > Watching the > debate over the RIPE last /8 policy, it simple convinced me we were > _wrong_. And having networks go to RIPE for their last v4 allocation > seems to be at odds with "out of region" use, which in itself is of > questionable utility. So, how does ARIN handing out /24s, prevent or even discourage someone from going to RIPE for a /22? It seems likely to me they would just go to both ARIN and RIPE and get the /24 and the /22 if they are available to them. > The RIPE region could adjust their policies > accordingly, but they seemed to have gotten it mostly right. Making new > entry into the market easy-peasy without technical restrictions other > than you need to use it seems more reasonable that what we have. Conceptually, I've always liked and even preferred the RIPE and APNIC last /8 policy, but we couldn't agree on it in 2009, and our options are now limited. If you have a specific suggestion based on the realities of today, I'm listening. > The > impact to v6 deployment overall is probably zero. And finally, it at > least addresses the inequity that new entrants will have with those of > us who are policy expects and know how to use the secret decoder ring > e.g. "assigned" "provisioned" "get a new ORG ID" etc. It's not about incentivizing IPv6 deployment, is about ensuring entities a can get some IPv4 for the deployment of IPv6 for many years come. If you have a suggestion to simplify access by new entrants I'm willing to listen. > Best, > > -M< -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From hannigan at gmail.com Wed Oct 21 18:06:42 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 21 Oct 2015 23:06:42 +0100 Subject: [arin-ppml] 4.10 transition/deployment /10 Was: Re: Transition /10 In-Reply-To: <5627C69F.5040505@umn.edu> References: <5627C69F.5040505@umn.edu> Message-ID: On Wed, Oct 21, 2015 at 6:08 PM, David Farmer wrote: > On 10/21/15 07:27 , Martin Hannigan wrote: > > Watching the >> debate over the RIPE last /8 policy, it simple convinced me we were >> _wrong_. And having networks go to RIPE for their last v4 allocation >> seems to be at odds with "out of region" use, which in itself is of >> questionable utility. >> > > So, how does ARIN handing out /24s, prevent or even discourage someone > from going to RIPE for a /22? It seems likely to me they would just go to > both ARIN and RIPE and get the /24 and the /22 if they are available to > them. > Probably, That exists regardless of what ARIN does though. > The RIPE region could adjust their policies >> accordingly, but they seemed to have gotten it mostly right. Making new >> entry into the market easy-peasy without technical restrictions other >> than you need to use it seems more reasonable that what we have. >> > > Conceptually, I've always liked and even preferred the RIPE and APNIC last > /8 policy, but we couldn't agree on it in 2009, and our options are now > limited. If you have a specific suggestion based on the realities of today > The options aren't limited. There's an existing ~/10 and a slow feed of fragments. Does anyone believe there's going to be 'explosive' use of 4.10? The requirements are unrealistic and almost do nothing different in terms of encouraging v6 adoption than a potential 4.10 run out policy would. Thanks, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Thu Oct 22 11:56:05 2015 From: info at arin.net (ARIN) Date: Thu, 22 Oct 2015 11:56:05 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - October 2015 In-Reply-To: <561E9386.8@arin.net> References: <561E9386.8@arin.net> Message-ID: <56290715.3020407@arin.net> > The AC abandoned 2015-10. Anyone dissatisfied with this decision may > initiate a petition. The deadline to begin a petition will be five > business days after the AC's draft meeting minutes are published. The minutes from the ARIN Advisory Council's 9 October 2015 meeting have been published: https://www.arin.net/about_us/ac/ac2015_1009.html The petition deadline is 29 October 2015. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 10/14/15 1:40 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process (PDP), the ARIN > Advisory Council (AC) met on 9 October 2015. > > The AC moved the following to last call (to be posted separately to last > call): > > Recommended Draft Policy ARIN-2015-1: Modification to Criteria for > IPv6 Initial End-User Assignments > Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better > reflect how ARIN handles reorganizations > > Having found the following Draft Policy to be fully developed and > meeting ARIN's Principles of Internet Number Resource Policy, the AC > recommended it for adoption (to be posted separately for discussion as a > Recommended Draft Policy): > > Draft Policy ARIN-2015-5: Out of region use > > The AC abandoned the following: > > Draft Policy ARIN-2015-10: Minimum IPv6 Assignments > > "The AC abandoned Draft Policy ARIN-2015-10: "Minimum IPv6 Assignments" > based on the generally negative feedback the proposal received from the > community at the Public Policy Meeting in Montreal." > > The AC is continuing to work on: > > Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to > Specified Recipients) > Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in > end-user IPv4 policy > Draft Policy ARIN-2015-6: Transfers and Multi-national Networks > Draft Policy ARIN-2015-7: Simplified requirements for demonstrated > need for IPv4 transfers > Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users > Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for > Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > Draft Policy ARIN-2015-11: Remove transfer language which only > applied pre-exhaustion of IPv4 pool > > The AC abandoned 2015-10. Anyone dissatisfied with this decision may > initiate a petition. The deadline to begin a petition will be five > business days after the AC's draft meeting minutes are published. For > more information on starting and participating in petitions, see PDP > Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > Draft Policy and Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) From info at arin.net Thu Oct 22 11:56:57 2015 From: info at arin.net (ARIN) Date: Thu, 22 Oct 2015 11:56:57 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-5: Out of region use Message-ID: <56290749.5040609@arin.net> Recommended Draft Policy ARIN-2015-5 Out of region use On 9 October 2015 the ARIN Advisory Council (AC) recommended ARIN-2015-5 for adoption, making it a Recommended Draft Policy. ARIN-2015-5 is below and can be found at: https://www.arin.net/policy/proposals/2015_5.html You are encouraged to discuss Draft Policy 2015-5 on the PPML prior to its presentation at the next ARIN Public Policy Consultation. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process 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) ## * ## Recommended Draft Policy ARIN-2015-5 Out of region use Date: 22 October 2015 AC's assessment of conformance with the Principles of Internet Number Resource Policy: ARIN-2015-5 enables fair and impartial number resource administration by allowing any ARIN Organization with a real and substantial connection to the ARIN region to use number resources out of region without prejudice. This proposal is technically sound, as it addresses the key concerns related to the unlimited openness of out of region use and enables ARIN staff to implement the policy efficiently. The policy received a unanimous show of support at the ARIN PPM in Montreal. However, the AC encourages further discussion of ARIN-2015-5 on PPML to ensure we also have support from the the ARIN community at large. Problem statement: Current policy neither clearly forbids nor clearly permits out of region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has explored several options to restrict or otherwise limit out of region use or loosen controls and totally authorize such use. None of these options have gained consensus within the community. The next logical option is a proposal that clearly permits out of region use while addressing the key concerns expressed about unlimited openness to out of region use and enables ARIN staff to implement the policy efficiently. Policy statement: Create new Section X: ARIN registered resources may be used outside the ARIN service region. Out of region use of ARIN registered resources are valid justification for additional number resources, provided that the applicant has a real and substantial connection with the ARIN region which applicant must prove (as described below) and is using the same type of resources (with a delegation lineage back to an ARIN allocation or assignment) within the ARIN service region as follows: * IPv4: At least a /22 used in region * IPv6: At least a /44 used in region * ASN: At least one ASN present on one or more peering sessions and/or routers within the region. A real and substantial connection shall be defined as carrying on business in the ARIN region in a meaningful manner. The determination as to whether an entity is carrying on business in the ARIN region in a meaningful manner shall be made by ARIN. Simply being incorporated in the ARIN region shall not be sufficient, on its own, to prove that an entity is carrying on business in the ARIN region in a meaningful manner. Methods that entities may consider using, including cumulatively, to prove that they are carrying on business in the ARIN region in a meaningful manner include: * Demonstrating a physical presence in the ARIN region through a bricks and mortar location that is actually used for the purposes of conducting business in the ARIN region in a meaningful manner. That is to say, the location is not merely a registered office that serves no other business purpose. * Demonstrating that the entity has staff in the ARIN region. The greater the number of staff, the stronger this connecting factor is. * Demonstrating that the entity holds assets in the ARIN region. The greater the asset value, the stronger this connecting factor is. * Demonstrating that the entity provides services to and solicits sales from residents of the ARIN region. * Demonstrating that the entity holds periodic meetings in the ARIN region. * Demonstrating that the entity raises investment capital from investors in the ARIN region. * Demonstrating that the entity has a registered corporation in the ARIN region, although this factor on its own shall not be sufficient. * Other fact based criterion that the entity considers appropriate and submits for ARIN's review. The weight accorded to any of the above-noted factors, if any, shall be determined solely by ARIN. The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR's service region, an officer of the application must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to obtain from the applicant a listing of all the applicant's number holdings in the region(s) of proposed use, when there are factual reasons to support the request. Comments: a) Timetable for implementation: Various iterations of this policy have been presented and debated by ARIN for well over a year now. Given the amount of time that has already been spent on developing a policy, ideally, this policy would be implemented as soon as possible. b) Explanation of draft policy: The draft policy addresses both the problem statement as well as the concerns raised at ARIN 35 by participants as well as ARIN counsel. Firstly, the draft policy addresses the concerns of ARIN counsel as well as some of the participants at ARIN 35 by ensuring that anyone requesting numbered resources from ARIN has a real and substantial connection with the ARIN region. This should go a long way to addressing concerns about fraud, legal liability, and interference with the jurisdiction of other RIRs. In addition, by placing the burden of proof for demonstrating a real and substantial connection with the ARIN region on the applicant, the amount of work required of ARIN staff to apply the policy will be reduced. The factors noted above are suggestions that an entity may use to demonstrate to ARIN that it is carrying on business in the ARIN region in a meaningful manner. These factors are all indicative, some more than others, that an entity has a real and substantial connection to the ARIN region through the carrying on of business in the ARIN region in a meaningful manner. Not all of the factors will apply in a given case and proving a single factor may not be enough to satisfy ARIN that an entity is carrying on business in the region in a meaningful manner. The list of factors is meant to be quite broad, including an open-ended factor, in order to capture the diversity of businesses that operate in the ARIN region and that may justifiably require numbered resources from ARIN. This approach is very similar to the practical method that courts typically apply to assess whether parties have a sufficient connection to a jurisdiction so as to require them to submit themselves to the courts of that jurisdiction. This draft policy is a substantial improvement over the previous version of ARIN-2014-1 in terms of reducing the overall risk to the community by requiring a real and substantial connection between an entity requesting resources and the ARIN region. ##### ARIN STAFF & LEGAL ASSESSMENT Draft Policy ARIN-2015-5 OUT OF REGION USE Date of Assessment: 17 September 2015 ___ 1. Summary (Staff Understanding) This proposal would allow an organization to receive Internet number resources from ARIN for use out of region as long as the applicant is currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively. In addition, the applicant must have a real and substantial connection with the ARIN region, which the applicant shall be responsible for proving. ___ 2. Comments A. ARIN Staff Comments This policy would increase the complexity of ARIN staff review work in request cases that fit the profile of this policy. There would in an increase in the vetting and utilization verification work currently conducted by ARIN staff. This policy would be placed in the NRPM as section 9, "Out of Region Use". B. ARIN General Counsel ? Legal Assessment If the policy is enacted it will require ARIN staff to work with counsel with some attendant increase in costs in the first year to manage implementation. The policy is consistent with standard legal principles routinely utilized in the ARIN region. The policy creates no material legal risks. ___ 3. Resource Impact From a request review standpoint, implementation of this policy would require additional review steps for Internet number resource requests. It could have future staffing implications based on the amount of additional work the policy could present. It is estimated that implementation could occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Updated guidelines and internal procedures * Staff training Implementation of this policy may allow for registrations in the ARIN database that require unicode character sets. From an engineering standpoint, implementation of this policy could have a major resource impact. It is estimated that implementation would occur within 12 months, instead of the 3 months cited above, after ratification by the ARIN Board of Trustees if ARIN is required to support unicode character sets. The following would be needed in order to implement: * Engineering: Engineering efforts to handle out of region business rules may be substantial as our system only supports ascii now. If there is a need for unicode character sets, then there is a substantial amount of work required to upgrade the DB and applications to support unicode. Additionally, we would need to discuss how to display unicode characters in port 43 whois. ___ 4. Proposal / Draft Policy Text Assessed Draft Policy ARIN-2015-5 (September 9, 2015, version) Problem statement: Current policy neither clearly forbids nor clearly permits out of region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has explored several options to restrict or otherwise limit out of region use. None of these options have gained consensus within the community. The next logical option is a proposal that clearly permits out of region use while addressing the key concerns expressed about unlimited openness to out of region use and enables ARIN staff to implement the policy efficiently. Policy statement: Create new Section X: ARIN registered resources may be used outside the ARIN service region. Out of region use of ARIN registered resources are valid justification for additional number resources, provided that the applicant has a real and substantial connection with the ARIN region which applicant must prove (as described below) and is using the same type of resources (with a delegation lineage back to an ARIN allocation or assignment) within the ARIN service region as follows: * IPv4: At least a /22 used in region * IPv6: At least a /44 used in region * ASN: At least one ASN present on one or more peering sessions and/or routers within the region. A real and substantial connection shall be defined as carrying on business in the ARIN region in a meaningful manner, whether for or not for profit. The determination as to whether an entity is carrying on business in the ARIN region in a meaningful manner shall be made by ARIN. Simply being incorporated in the ARIN region shall not be sufficient, on its own, to prove that an entity is carrying on business in the ARIN region in a meaningful manner. Methods that entities may consider using, including cumulatively, to prove that they are carrying on business in the ARIN region in a meaningful manner include: * Demonstrating a physical presence in the ARIN region through a bricks and mortar location that is actually used for the purposes of conducting business in the ARIN region in a meaningful manner. That is to say, the location is not merely a registered office that serves no other business purpose. * Demonstrating that the entity has staff in the ARIN region. The greater the number of staff, the stronger this connecting factor is. * Demonstrating that the entity holds assets in the ARIN region. The greater the asset value, the stronger this connecting factor is. * Demonstrating that the entity provides services to or solicits sales from residents of the ARIN region. * Demonstrating that the entity holds annual meetings in the ARIN region. * Demonstrating that the entity raises investment capital from investors in the ARIN region. * Demonstrating that the entity has a registered office in the ARIN region, although this factor on its own shall not be sufficient. * Any other method that the entity considers appropriate. The weight accorded to any of the above-noted factors, if any, shall be determined solely by ARIN. The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR's service region, an officer of the application must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to request a listing of all the applicant's number holdings in the region(s) of proposed use, but this should happen only when there are significant reasons to suspect duplicate requests. From hannigan at gmail.com Thu Oct 22 11:59:01 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 22 Oct 2015 16:59:01 +0100 Subject: [arin-ppml] 4.10 transition/deployment /10 Was: Re: Transition /10 In-Reply-To: <5627C69F.5040505@umn.edu> References: <5627C69F.5040505@umn.edu> Message-ID: On Wed, Oct 21, 2015 at 6:08 PM, David Farmer wrote: On 10/21/15 07:27 , Martin Hannigan wrote: > > [ clip ] > > Conceptually, I've always liked and even preferred the RIPE and APNIC last > /8 policy, but we couldn't agree on it in 2009, and our options are now > limited. If you have a specific suggestion based on the realities of today, > -- > I'd probably do it by rewriting 4.10 to - retain the /10 and re designate it for run out (yes, 2 are allocated) - restrict all assignments by it from being transferable except by 8.2 - restrict to corporate holdings in aggregate, not by org id <-- opex heavy, discuss - provide new "entrants" and existing resource holders with a single /24, forever. - no needs assessment, just ask and then don't come back Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Oct 23 00:53:02 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 23 Oct 2015 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201510230453.t9N4r2PA022477@rotala.raleigh.ibm.com> Total of 26 messages in the last 7 days. script run at: Fri Oct 23 00:53:02 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 34.62% | 9 | 31.33% | 106533 | hannigan at gmail.com 7.69% | 2 | 9.72% | 33040 | kbrumund at dyn.com 7.69% | 2 | 9.11% | 30983 | scottleibrand at gmail.com 7.69% | 2 | 7.90% | 26867 | info at arin.net 7.69% | 2 | 7.62% | 25911 | farmer at umn.edu 7.69% | 2 | 7.15% | 24325 | timothy.s.morizot at irs.gov 3.85% | 1 | 6.08% | 20662 | owen at delong.com 3.85% | 1 | 4.50% | 15290 | josh at imaginenetworksllc.com 3.85% | 1 | 4.23% | 14367 | cspears at oar.net 3.85% | 1 | 4.08% | 13874 | andrew.c.hadenfeldt at windstream.com 3.85% | 1 | 3.62% | 12310 | andrew.dul at quark.net 3.85% | 1 | 2.54% | 8627 | rcarpen at network1.net 3.85% | 1 | 2.12% | 7207 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 26 |100.00% | 339996 | Total From David.Huberman at microsoft.com Thu Oct 29 18:48:42 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Thu, 29 Oct 2015 22:48:42 +0000 Subject: [arin-ppml] ARIN forcing everyone to sign the new RSA? Message-ID: Hello, I was very surprised to learn today that an established Org at ARIN, with an RSA signed in calendar year 2015, is being forced to sign a new version 12 RSA in order to obtain services on additional IP addresses. ARIN: what is the justification for forcing all registrants* into Version 12? Also, what are the actual rules and where are they published? Do I have to sign a new RSA any time I get a new AS number? What if I justify an additional IPv6 block? How about if I want to participate in RPKI? Or IRR? What if I clear the waiting list? Thanks, David David R Huberman Principal, Global IP Addressing Microsoft Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Huberman at microsoft.com Thu Oct 29 18:55:34 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Thu, 29 Oct 2015 22:55:34 +0000 Subject: [arin-ppml] ARIN forcing everyone to sign the new RSA? In-Reply-To: References: Message-ID: (Answering my own questions a little bit, even though that's a tad gauche.) I see the ARIN website has some text I haven't seen before. At: https://www.arin.net/resources/agreements/index.html . under "Registration Services Agreement", it says: "Both existing and newly approved customers must sign and return the current version of the RSA for each resource request." And thinking about it, I realize we had Version 11 for 3.5 years. The version I have a copy of says April 2012. So it's been a while. And Version 12 was just published this month. So that answers most of my questions. I'd still like clear rules for when, and when not, an updated RSA is required. The RSA is still one-sided and overly aggressive, so it's not easy to get it signed, much less signed when it's already been signed. Thanks! David David R Huberman Principal, Global IP Addressing Microsoft Corporation From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: Thursday, October 29, 2015 3:49 PM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN forcing everyone to sign the new RSA? Hello, I was very surprised to learn today that an established Org at ARIN, with an RSA signed in calendar year 2015, is being forced to sign a new version 12 RSA in order to obtain services on additional IP addresses. ARIN: what is the justification for forcing all registrants* into Version 12? Also, what are the actual rules and where are they published?? Do I have to sign a new RSA any time I get a new AS number? What if I justify an additional IPv6 block? How about if I want to participate in RPKI? Or IRR? What if I clear the waiting list? Thanks, David David R Huberman Principal, Global IP Addressing Microsoft Corporation From jcurran at arin.net Thu Oct 29 21:59:40 2015 From: jcurran at arin.net (John Curran) Date: Fri, 30 Oct 2015 01:59:40 +0000 Subject: [arin-ppml] ARIN forcing everyone to sign the new RSA? In-Reply-To: References: Message-ID: <2CF44F83-F9C3-47F0-ACC3-BFE0F878DF14@corp.arin.net> On Oct 29, 2015, at 6:55 PM, David Huberman wrote: > > (Answering my own questions a little bit, even though that's a tad gauche.) > > I see the ARIN website has some text I haven't seen before. At: > https://www.arin.net/resources/agreements/index.html > > . under "Registration Services Agreement", it says: > > "Both existing and newly approved customers must sign and return the current version of the RSA for each resource request." > > And thinking about it, I realize we had Version 11 for 3.5 years. The version I have a copy of says April 2012. So it's been a while. And Version 12 was just published this month. > > So that answers most of my questions. I'd still like clear rules for when, and when not, an updated RSA is required. The RSA is still one-sided and overly aggressive, so it's not easy to get it signed, much less signed when it's already been signed. David - ARIN issues number resources under the current version of the RSA, so parties requesting new resources should expect to sign the most current version. The changes from RSA version 11 to 12 are based on changes requested by the community, and I would highly recommend that everyone take the opportunity to review them (even if not requesting any additional resources) as the terms may be more suitable to one's needs than those in your present registration services agreement. Thanks! /John John Curran President and CEO ARIN From narten at us.ibm.com Fri Oct 30 00:53:03 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 30 Oct 2015 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201510300453.t9U4r3ae002517@rotala.raleigh.ibm.com> Total of 4 messages in the last 7 days. script run at: Fri Oct 30 00:53:03 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 2 | 60.41% | 21840 | david.huberman at microsoft.com 25.00% | 1 | 20.39% | 7371 | narten at us.ibm.com 25.00% | 1 | 19.20% | 6939 | jcurran at arin.net --------+------+--------+----------+------------------------ 100.00% | 4 |100.00% | 36150 | Total