From farmer at umn.edu Sun Jun 1 01:42:37 2014 From: farmer at umn.edu (David Farmer) Date: Sun, 01 Jun 2014 00:42:37 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <538A8E1F.4020201@impulse.net> References: <1140519223408.47993A-100000@Ives.egh.com> <537B98CA.3030106@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com> <537D069B.5030601@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com> <538A4FE9.9010900@umn.edu> <538A8E1F.4020201@impulse.net> Message-ID: <538ABD4D.7090600@umn.edu> On 5/31/14, 21:21 , Jay Hennigan wrote: > On 5/31/14, 2:55 PM, David Farmer wrote: > >> Therefore, putting all the suggesting together, here is text for the >> Editorial Change I'm proposing at the PPC next week. >> >> If an organization requires more resource resources than stipulated >> by the >> applicable minimum allocation sizes size in force at the time of >> their request, >> their experimental documentation should have request must clearly >> described >> describe and justified justify why this a larger allocation is >> required. > > An organization is a singular entity without gender. Pronoun should > match. ("its", not "their"). Thanks > Also, while the request for the > documentation isn't experimental, the allocation is. "experimental documentation" was already struck-through. > Thus: > > If an organization requires more resources than stipulated > by the applicable minimum allocation size in force at the > time of its request, the request must clearly describe and > justify why a larger allocation is required. Thanks, I'll make the necessary changes. ---- Policy Statement: Modify the section 11.7 heading to be more accurate. Modify the first sentence to prohibit overlapping assignments. Add text at the end to define how research allocations should be designated. Modify the third sentence to clarify the original policy intent regarding justification for allocations larger than the applicable minimum. 11.7 Resource Allocation Guidelines The Numbering Resources requested come from the global Internet Resource space, do not overlap currently assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resources than stipulated by the applicable minimum allocation size in force at the time of its request, the request must clearly describe and justify why a larger allocation is required. All research allocations must be registered publicly in Whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. ---- Anybody have anything else? Thanks -- ================================================ 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 kkargel at polartel.com Mon Jun 2 10:26:55 2014 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 2 Jun 2014 09:26:55 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <538A4FE9.9010900@umn.edu> References: <1140519223408.47993A-100000@Ives.egh.com> <537B98CA.3030106@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com> <537D069B.5030601@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com> <538A4FE9.9010900@umn.edu> Message-ID: <8695009A81378E48879980039EEDAD28013850D859@MAIL1.polartel.local> I will respectfully disagree. What is the point of "should"? Even in the example you gave it would better as "must unless" or "shall unless" instead of "should unless" . With "should" there is no reason for the unless because there is no requirement to do otherwise in the first place. Should leaves a loophole that can be easily exploited, i.e. "you never said we had to do that, you just said we should, so I can technically do whatever I want".. It would be perfectly functional to say: "The allocation size shall be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment." Using "should" in the statement makes it a no-op. With "should" you can choose not to follow what is only a suggestion. If you use "shall" or "must" you have enforceable policy. If the policy is not enforceable it is nothing more than a best practice statement at best. Kevin From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer Sent: Saturday, May 31, 2014 4:56 PM To: Leif Sawyer; Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy After thinking about this for a while, the justification for a larger allocation is clearly intended to be a requirement, and not intended to be optional. So, "must" seems appropriate in the case. However, I can't agree with the comments that "should" and "may" are inappropriate in policy all together. A perfect example is the sentence just before the one we are discussing. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. Therefore, putting all the suggesting together, here is text for the Editorial Change I'm proposing at the PPC next week. If an organization requires more resource resources than stipulated by the applicable minimum allocation sizes size in force at the time of their request, their experimental documentation should have request must clearly described describe and justified justify why this a larger allocation is required. Thanks On 5/21/14, 17:23 , Leif Sawyer wrote: I just can't think of a time when "experimental documentation [should] clearly describe and justify" "should" ever be "doesn't" hence my suggestion to use "must". -----Original Message----- From: David Farmer [mailto:farmer at umn.edu] Sent: Wednesday, May 21, 2014 12:04 PM To: Leif Sawyer; Owen DeLong Cc: David Farmer; arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy I think "should" is sufficiently strong, and gives ARIN Staff a little wiggle room to do what makes sense. There really have never been that many experimental allocations. We had a big whoopsie with all 5 RIR's authorizing /12 anchor routes. ARIN probably won't do that again anyway, but it's still worth a small fix in policy, just to be clear about it. The sentence is question is a little rough, so while we are at it a little editorial clean up is probably in order, but please let's not over do it. I really would like to hear from a few more people about if this editorial change is a good idea or not, even a few +/-1s would be helpful. Thanks. On 5/21/14, 13:52 , Leif Sawyer wrote: s/should/must -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Wednesday, May 21, 2014 10:34 AM To: David Farmer Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In looking at the sentence in question; I think the "have" in the sentence is extraneous, and can deleted. Then changing "this" to "a larger allocation" and the tense changes you suggest, results in; If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should clearly describe and justify why a larger allocation is required. s/resource/resources/ s/minimum allocation sizes/applicable minimum allocation size/ s/experimental documentation/request/ result: If an organization requires more resources than stipulated by the applicable minimum allocation in force at the time of their request, their request should clearly describe and justify why a larger allocation is required. I think this not only parses better, but is more accurate. The first change resolves a grammar error. The second change avoids ambiguity between whether all requests are subject to all minimums in this case vs. the intended meaning that the minimum applicable elsewhere in policy. The third change is because their documentation should be documentation of an experiment, not experimental documentation and what we really care about is the information provided in their ARIN request anyway. I think since this is a minor change which does not alter the meaning of the policy and does improve readability and clarity, that we should probably go ahead and incorporate it as you proposed prior to last call. Owen -- ================================================ 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 ================================================ -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Mon Jun 2 12:04:49 2014 From: farmer at umn.edu (David Farmer) Date: Mon, 02 Jun 2014 11:04:49 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <8695009A81378E48879980039EEDAD28013850D859@MAIL1.polartel.local> References: <1140519223408.47993A-100000@Ives.egh.com> <537B98CA.3030106@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com> <537D069B.5030601@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com> <538A4FE9.9010900@umn.edu> <8695009A81378E48879980039EEDAD28013850D859@MAIL1.polartel.local> Message-ID: <538CA0A1.5080400@umn.edu> On 6/2/14, 09:26 , Kevin Kargel wrote: > I will respectfully disagree. What is the point of ?should?? Even in > the example you gave it would better as ?must unless? or ?shall unless? > instead of ?should unless? . With ?should? there is no reason for the > unless because there is no requirement to do otherwise in the first place. > > Should leaves a loophole that can be easily exploited, i.e. ?you never > said we had to do that, you just said we should, so I can technically do > whatever I want?.. Sorry, I don't have time to debate this issue in general at this moment. The PPC at NANOG 61 is just over 24 hours away. > It would be perfectly functional to say: > > ?The allocation size shall be consistent with the existing ARIN minimum > allocation sizes, unless small allocations are intended to be > explicitly part > of the experiment.? Are you suggesting we should also change that sentence as well? If you are I need to know ASAP, like I said the PPC is just over 24 hours away and I have to finalize the presentation ASAP. I would also like to hear support from a couple others on PPML before opening that sentence also to changes, as well. > Using ?should? in the statement makes it a no-op. With ?should? you can > choose not to follow what is only a suggestion. If you use ?shall? or > ?must? you have enforceable policy. If the policy is not enforceable it > is nothing more than a best practice statement at best. I also respectfully disagree. However, I will discuss the issue with ARIN staff here at NANOG to understand how they interpret this issue. -- ================================================ 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 Mon Jun 2 13:32:21 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 2 Jun 2014 10:32:21 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <8695009A81378E48879980039EEDAD28013850D859@MAIL1.polartel.local> References: <1140519223408.47993A-100000@Ives.egh.com> <537B98CA.3030106@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com> <537D069B.5030601@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com> <538A4FE9.9010900@umn.edu> <8695009A81378E48879980039EEDAD28013850D859@MAIL1.polartel.local> Message-ID: These are not standards, it's policy. Policy should be concise and binary. ARIN already doesn't follow the policies and using words like "should" allow for more wink and nudge and less certainty and especially less consistency. Best, -M< On Mon, Jun 2, 2014 at 7:26 AM, Kevin Kargel wrote: > I will respectfully disagree. What is the point of "should"? Even in the > example you gave it would better as "must unless" or "shall unless" > instead of "should unless" . With "should" there is no reason for the > unless because there is no requirement to do otherwise in the first place. > > Should leaves a loophole that can be easily exploited, i.e. "you never > said we had to do that, you just said we should, so I can technically do > whatever I want".. > > It would be perfectly functional to say: > > "The allocation size shall be consistent with the existing ARIN minimum > allocation sizes, unless small allocations are intended to be > explicitly part > of the experiment." > > Using "should" in the statement makes it a no-op. With "should" you can > choose not to follow what is only a suggestion. If you use "shall" or > "must" you have enforceable policy. If the policy is not enforceable it is > nothing more than a best practice statement at best. > > Kevin > > > > *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On > Behalf Of *David Farmer > *Sent:* Saturday, May 31, 2014 4:56 PM > > *To:* Leif Sawyer; Owen DeLong > *Cc:* arin-ppml at arin.net > > *Subject:* Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: > Anti-hijack Policy > > > > After thinking about this for a while, the justification for a larger > allocation is clearly intended to be a requirement, and not intended to be > optional. So, "must" seems appropriate in the case. However, I can't > agree with the comments that "should" and "may" are inappropriate in policy > all together. A perfect example is the sentence just before the one we are > discussing. > > The allocation size should be consistent with the existing ARIN > minimum > allocation sizes, unless small allocations are intended to be > explicitly part > of the experiment. > > Therefore, putting all the suggesting together, here is text for the > Editorial Change I'm proposing at the PPC next week. > > If an organization requires more resource resources than stipulated > by the > applicable minimum allocation sizes size in force at the time of > their request, > their experimental documentation should have request must clearly > described > describe and justified justify why this a larger allocation is > required. > > Thanks > > On 5/21/14, 17:23 , Leif Sawyer wrote: > > I just can't think of a time when > > "experimental documentation [should] clearly describe and justify" > > "should" ever be "doesn't" > > > > > > hence my suggestion to use "must". > > > > > > > > -----Original Message----- > > From: David Farmer [mailto:farmer at umn.edu ] > > Sent: Wednesday, May 21, 2014 12:04 PM > > To: Leif Sawyer; Owen DeLong > > Cc: David Farmer; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy > > > > I think "should" is sufficiently strong, and gives ARIN Staff a little wiggle room to do what makes sense. There really have never been that many experimental allocations. > > > > We had a big whoopsie with all 5 RIR's authorizing /12 anchor routes. > > ARIN probably won't do that again anyway, but it's still worth a small fix in policy, just to be clear about it. The sentence is question is a little rough, so while we are at it a little editorial clean up is probably in order, but please let's not over do it. > > > > I really would like to hear from a few more people about if this editorial change is a good idea or not, even a few +/-1s would be helpful. > > > > > Thanks. > > > > On 5/21/14, 13:52 , Leif Sawyer wrote: > > s/should/must > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] > > On Behalf Of Owen DeLong > > Sent: Wednesday, May 21, 2014 10:34 AM > > To: David Farmer > > Cc: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: > > Anti-hijack Policy > > > > > > In looking at the sentence in question; I think the "have" in the > > sentence is extraneous, and can deleted. Then changing "this" to "a > > larger allocation" and the tense changes you suggest, results in; > > > > If an organization requires more resource than stipulated by the > > minimum allocation sizes in force at the time of their request, > > their experimental documentation should clearly describe and > > justify why a larger allocation is required. > > > > > > s/resource/resources/ > > s/minimum allocation sizes/applicable minimum allocation size/ > > s/experimental documentation/request/ > > > > result: > > > > If an organization requires more resources than stipulated by the applicable minimum allocation in force at the time of their request, their request should clearly describe and justify why a larger allocation is required. > > > > I think this not only parses better, but is more accurate. > > > > The first change resolves a grammar error. > > The second change avoids ambiguity between whether all requests are subject to all minimums in this case vs. the intended meaning that the minimum applicable elsewhere in policy. > > The third change is because their documentation should be documentation of an experiment, not experimental documentation and what we really care about is the information provided in their ARIN request anyway. > > > > I think since this is a minor change which does not alter the meaning of the policy and does improve readability and clarity, that we should probably go ahead and incorporate it as you proposed prior to last call. > > > > Owen > > > > -- > > ================================================ > > 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 heather.skanks at gmail.com Mon Jun 2 13:34:06 2014 From: heather.skanks at gmail.com (Heather Schiller) Date: Mon, 2 Jun 2014 13:34:06 -0400 Subject: [arin-ppml] [Revised] DRAFT POLICY ARIN-2014-9: RESOLVE CONFLICT BETWEEN RSA AND 8.2 UTILIZATION REQUIREMENTS Message-ID: At the PPM in April, there was support for leaving this paragraph in the NRPM, but removing the words 'aggregate' and 'return', resulting in the text below. The AC encourages feedback on this proposed change. Thanks, --Heather Draft Policy ARIN-2014-9 Resolve Conflict Between RSA and 8.2 Utilization Requirements Revised: 16 May 2014 Problem Statement: 8.2 transfer policy has utilization requirements at the time of the review of the transfer request. The RSA section 6 expressly forbids ARIN from de-registering blocks (in whole or in part) due to under-utilization or no-justification during transfer requests. This is a direct conflict. Policy statement: Remove the words "aggregate" and "reclaim" from 8.2, so it reads: "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: a.Timetable for implementation: Immediate b.Anything else: -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Mon Jun 2 15:03:44 2014 From: info at arin.net (ARIN) Date: Mon, 02 Jun 2014 15:03:44 -0400 Subject: [arin-ppml] =?windows-1252?q?Request_for_Community_Input_=96_Enha?= =?windows-1252?q?ncing_ICANN_Accountability?= Message-ID: <538CCA90.2080705@arin.net> ICANN issued a call for community input regarding its continuing accountability in the future in the absence of a contractual relationship with the U.S. Government. https://www.icann.org/public-comments/enhancing-accountability-2014-05-06-en The Executive Council of the Number Resource Organization (NRO) has drafted a response on behalf of the five Regional Internet Registry (RIR) communities. (See below) ARIN welcomes your feedback on this draft, and we will be accepting input through 4 June 2014. Please send your comments to info at arin.net. The community may also participate directly by providing feedback directly to ICANN as described here: https://www.icann.org/resources/pages/enhancing-accountability-2014-05-06-en Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) *** ICANN call for public comments on Enhancing ICANN?s Accountability Response from the Number Resource Organization (NRO) DRAFT ONLY - 29 May 2014 The NRO thanks ICANN for the opportunity to comment on means for improving its accountability, and we provide the following responses to the questions contained in the call for comments: https://www.icann.org/public-comments/enhancing-accountability-2014-05-06-en 1. What issues does the community identify as being core to strengthening ICANN?s overall accountability in the absence of its historical contractual relationship to the US government? Regarding ICANN's accountability with respect to IP addressing functions, we believe that the ASO structure provides a necessary and sufficient separation between policy formation and policy implementation. Global IP addressing policy is developed by the RIR communities and passed via the ASO to ICANN, in accordance with the ASO MoU; while policy is implemented by the IANA in the form of services delivered to the RIRs under specific service agreements. While these existing mechanisms have proven successful over the past 10 years, we believe than a review is appropriate at this time, prior to the expected NTIA transition, along with reviews by each of the RIRs of their own accountability mechanisms. Notwishstanding any improvements needed, these agreements must clearly define appropriate dispute resolution, escalation and arbitration procedures. We note that there is no agreement or expectation of any role for the USG NTIA in these processes; therefore we do not view the historical contractual relationship between ICANN and the US government as an accountability mechanism, and neither do we consider the NTIA's role as a source of ICANN?s accountability with respect to Internet number resources. In the hypothetical case that IANA had ever failed to provide number allocation services to any RIR in accordance to existing policies and agreements, we would have not relied upon the US government to solve this issue. Rather we would have worked transparently with ICANN, in accordance to the terms of existing agreements, to address the issue. The NRO is committed to continue to work with ICANN to strengthen escalation and dispute resolution mechanisms to allow the parties to work better in any hypothetical case of failed expectations. 2. What should be the guiding principles to ensure that the notion of accountability is understood and accepted globally? What are the consequences if the ICANN Board is not being accountable to the community? Is there anything that should be added to the Working Group?s mandate? The NRO does not believe that the contract with the US government should be replaced with a similar mechanism at a global level, therefore a guiding principle is specifically not to create any "superior" structure or organisation; rather ICANN's accountability should be defined in terms of transparent agreements with ICANN stakeholders, in which roles and responsibilities, and dispute resolution and arbitration mechanisms are fully defined. We believe that a failure by ICANN to abide clearly by established accountability mechanisms, and in particular by defined dispute resolution and arbitration mechanisms should have clear consequences, and therefore that arbitration mechanisms should be binding. Furthermore, they must be implementable and effective upon ICANN, regardless of its final structure or locale. The guiding principles for defining or strengthening these accountability mechanisms should be: that they are transparent, implementable and open to improvement; and that they operate in the interests of the open, stable and secure operation of the Internet. 3. Do the Affirmation of Commitments and the values expressed therein need to evolve to support global acceptance of ICANN?s accountability and so, how? The NRO believes that the Affirmation of Commitments is a good umbrella covering higher-level issues that may not be specifically included in existing contracts, MoUs, accountability frameworks and documents that govern ICANN?s relationships with its different stakeholder groups. While the most important accountability of ICANN is with its respective stakeholders and community, the Affirmation of Commitments and its evolution could support wider trust in ICANN?s ongoing operations at the international level. We believe that this evolution could take the form of a new affirmation into which many more stakeholder communities, including Governments, would enter. 4. What are the means by which the Community is assured that ICANN is meeting its accountability commitments? The current contracts, MoUs, accountability frameworks and documents that ICANN currently has with different parts of its community provide certain levels of accountability. These documents can evolve and improve however this should be an ongoing process which continues beyond the end of NTIA?s role, and throughout the entire lifetime of ICANN. 5. Are there other mechanisms that would better ensure that ICANN lives up to its commitments? If ICANN can in time be incorporated as an international organization under international law, this may provide the ICANN community with additional mechanisms to solve disputes through mediation, arbitration or judicial avenues; and added confidence in the ability to serve stakeholders uniformly across the globe. While we would like this possibility to be actively explored by ICANN, we do not believe it is a necessary prerequisite to any of the other measures described in this response, but welcome continued engagement with the global stakeholder community on this topic. 6. What additional comments would you like to share that could be of use to the ICANN Accountability Working Group? The NRO notes the present clarity of responsibility that exists with respect ICANN's roles in administration of Internet protocol identifiers for the IETF and Internet number resources for the Internet address community, and suggests that it might helpful for the ICANN Accountability Working Group to examine these successes in its efforts. The NRO expects to contribute and work together with the ICANN Accountability Working Group, and other stakeholders in the ICANN community, to improve mechanisms for enhancing accountability in the years to come. From jcurran at arin.net Mon Jun 2 16:51:18 2014 From: jcurran at arin.net (John Curran) Date: Mon, 2 Jun 2014 20:51:18 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: References: <1140519223408.47993A-100000@Ives.egh.com> <537B98CA.3030106@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com> <537D069B.5030601@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com> <538A4FE9.9010900@umn.edu> <8695009A81378E48879980039EEDAD28013850D859@MAIL1.polartel.local>, Message-ID: On Jun 2, 2014, at 1:33 PM, "Martin Hannigan" wrote: > > These are not standards, it's policy. Policy should be concise and binary. Agreed - clarity and specificity in policy language is always preferred. > ARIN already doesn't follow the policies and using words like "should" allow for more wink and nudge and less certainty and especially less consistency. Martin - While not perfect, we make every attempt to follow policy language as written. If you are aware of any problems with policy compliance, please bring it to my attention (I will also note that requesters have option of both appeal review and 3rd party arbitration.) FYI, /John John Curran President and CEO ARIN From David.Huberman at microsoft.com Tue Jun 3 15:31:55 2014 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 3 Jun 2014 19:31:55 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers Message-ID: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> We had a discussion today at NANOG in the ARIN PPC about needs-basis in 8.3 transfers. I'd like to state the following, and then let's see where the discussion takes us: My team runs an AS. And yep, we're a pretty big company. We rely on IPv4 today for most of our numbering, and will continue to do so for the next couple of years.[1] In the coming year, when we can't get space from ARIN or other RIRs, we have to turn to the market for our IP address needs. We may choose to buy more than a 2 year supply, because it may make business sense for us to do so. ARIN policy, however, only allows us to take the IP addresses we buy and transfer the portion which represents a 2 year need. The rest will remain in the name of whoever sold the IP addresses to us. Why is this result good for the operator community? Wouldn't it be better if ARIN rules allowed us to transfer into our name all the IP addresses which we now own? Regards, /david [1] We're working on increasing IPv6 presence in our network and our products, but large corporations move slowly ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron at wholesaleinternet.net Tue Jun 3 15:43:57 2014 From: aaron at wholesaleinternet.net (Aaron) Date: Tue, 03 Jun 2014 14:43:57 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <538E257D.2010501@wholesaleinternet.net> Maybe the conversation should be: "What actions does the community wish to take when Microsoft tries to scam the system?" On 6/3/2014 2:31 PM, David Huberman wrote: > > We had a discussion today at NANOG in the ARIN PPC about needs-basis > in 8.3 transfers. > > I'd like to state the following, and then let's see where the > discussion takes us: > > My team runs an AS. And yep, we're a pretty big company. We rely on > IPv4 today for most of our numbering, and will continue to do so for > the next couple of years.[1] In the coming year, when we can't get > space from ARIN or other RIRs, we have to turn to the market for our > IP address needs. We may choose to buy more than a 2 year supply, > because it may make business sense for us to do so. ARIN policy, > however, only allows us to take the IP addresses we buy and transfer > the portion which represents a 2 year need. The rest will remain in > the name of whoever sold the IP addresses to us. > > Why is this result good for the operator community? Wouldn't it be > better if ARIN rules allowed us to transfer into our name all the IP > addresses which we now own? > > Regards, > > /david > > [1] We're working on increasing IPv6 presence in our network and our > products, but large corporations move slowly ;) > > > > _______________________________________________ > 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. -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsawyer at gci.com Tue Jun 3 15:44:19 2014 From: lsawyer at gci.com (Leif Sawyer) Date: Tue, 3 Jun 2014 11:44:19 -0800 Subject: [arin-ppml] ARIN 2014-16 Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102C8328341@fnb1mbx01.gci.com> Since my jabber client won't connect to the ARIN server, I'll oppose this here. The whole point of the /10 was to provide transition space that did not overlap existing RFC1918/3330 I would support a separate austerity policy for new IANA reclaim and deploys. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Tue Jun 3 15:51:46 2014 From: mike at iptrading.com (Mike Burns) Date: Tue, 3 Jun 2014 15:51:46 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: Retaining the needs policy will result in a Whois filled with zombie corporations, resuscitated from the dead, alive only in the sense of their Whois listing and (sometimes) up-to-date corporate filing. These zombie corporations will be owned by companies like David?s, whose business decisions drive them towards non-policy-compliant address transfers. Whois will not be updated. Kind of like how all the addresses sold by Nortel to Microsoft in 2011 were registered not to Nortel, but to zombie companies acquired by Nortel along the way. Had not Microsoft elected to negotiate a secret modified Legacy Registration Services Agreement with ARIN, and instead simply routed the addresses, we would still see the zombified Bay Networks in Whois. And when and if Microsoft sold those addresses to another party, Bay Networks would live on. Please note these are entirely legal business transactions, and to add to the discussion at NANOG today, in my experience I have never had an upstream fail to route addresses for a customer whose name did not match the Whois registrant. Sometimes (usually, actually) they will require an LOA. But as long as the block is not advertised anywhere else, why would any upstream decide to stick a finger in their customer?s eye by refusing to route them, since the LOA covers any conceivable legal risk to the upstream. Large or small companies, I have never seen them refused. What?s more, I think any upstream that does refuse knows that their competition will not, which along with customer circuit revenue drives their decision. Regards, Mike Burns IPTrading.com From: David Huberman Sent: Tuesday, June 03, 2014 3:31 PM To: arin-ppml at arin.net Subject: [arin-ppml] About needs basis in 8.3 transfers We had a discussion today at NANOG in the ARIN PPC about needs-basis in 8.3 transfers. I?d like to state the following, and then let?s see where the discussion takes us: My team runs an AS. And yep, we?re a pretty big company. We rely on IPv4 today for most of our numbering, and will continue to do so for the next couple of years.[1] In the coming year, when we can?t get space from ARIN or other RIRs, we have to turn to the market for our IP address needs. We may choose to buy more than a 2 year supply, because it may make business sense for us to do so. ARIN policy, however, only allows us to take the IP addresses we buy and transfer the portion which represents a 2 year need. The rest will remain in the name of whoever sold the IP addresses to us. Why is this result good for the operator community? Wouldn?t it be better if ARIN rules allowed us to transfer into our name all the IP addresses which we now own? Regards, /david [1] We?re working on increasing IPv6 presence in our network and our products, but large corporations move slowly ;) -------------------------------------------------------------------------------- _______________________________________________ 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 Tue Jun 3 22:27:17 2014 From: jcurran at arin.net (John Curran) Date: Wed, 4 Jun 2014 02:27:17 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <91821A2C-060E-4B72-A92B-8AF67C0ED9F9@corp.arin.net> On Jun 3, 2014, at 12:51 PM, Mike Burns > wrote: Retaining the needs policy will result in a Whois filled with zombie corporations, resuscitated from the dead, alive only in the sense of their Whois listing and (sometimes) up-to-date corporate filing. These zombie corporations will be owned by companies like David?s, whose business decisions drive them towards non-policy-compliant address transfers. Whois will not be updated. Mike - Indeed, there quite likely will be some organizations that end up taking that approach; it is not possible to know whether the "non-compliant" aspect will deter them such that they transfer within policy constraints (i.e. limited to 2 years of expected growth) Note also that some organizations may transfer in compliance with policy and existing need, but then lock in the option with the current holder for future transfer of any remainder of the address block (which is neither detectable nor within ARIN's remit.) Whether that kind of outcome meets the desired policy goals is not clear, but it should be recognized as a rather likely in light of present policy and desire by networks for more certainty in their available supply of IPv4 number resources. In the end, the community needs to consider the ongoing expected benefits of the needs-based transfer constraints in light of these evolving conditions. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Jun 4 00:11:26 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 3 Jun 2014 21:11:26 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: Yes, David, an organization can be a bad actor and tie up excess resources without transferring them in violation of the spirit and intent of the policy. Or, you could recognize that the intent of the policy and the reason for that policy is to make those addresses available to other entities with a more immediate need and behave in the spirit of the community. We can?t make the letter of the law force all organizations to be good actors. It?s just not practical. The best we can do is provide policy that expresses the general intent of the community and hope that the majority of people and organizations are good actors. So while your ability to circumvent the intent of the policy within the ?letter of the law? is not in the interest of the community, compliance with the spirit and intent of the policy is, in fact good for the operator community. Of course, it is inevitably up to each organization whether to act as a good citizen of the community or not. This is true even in cases where the policy is iron clad and there are certainly no shortage of examples of bad actors throughout history. Owen On Jun 3, 2014, at 12:31 PM, David Huberman wrote: > We had a discussion today at NANOG in the ARIN PPC about needs-basis in 8.3 transfers. > > I?d like to state the following, and then let?s see where the discussion takes us: > > My team runs an AS. And yep, we?re a pretty big company. We rely on IPv4 today for most of our numbering, and will continue to do so for the next couple of years.[1] In the coming year, when we can?t get space from ARIN or other RIRs, we have to turn to the market for our IP address needs. We may choose to buy more than a 2 year supply, because it may make business sense for us to do so. ARIN policy, however, only allows us to take the IP addresses we buy and transfer the portion which represents a 2 year need. The rest will remain in the name of whoever sold the IP addresses to us. > > Why is this result good for the operator community? Wouldn?t it be better if ARIN rules allowed us to transfer into our name all the IP addresses which we now own? > > Regards, > /david > > [1] We?re working on increasing IPv6 presence in our network and our products, but large corporations move slowly ;) > > _______________________________________________ > 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 ikiris at gmail.com Wed Jun 4 10:05:27 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 4 Jun 2014 09:05:27 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: I would actually prefer to find a way to resolve the problem of entities not caring about their whois being accurate^H^H^H^H^H^H^H^H^H^H resources being properly registered to them. It's rather pointless to have any rules without them actually mattering. RPKI had hope, but it doesn't seem to be going anywhere. -Blake On Tue, Jun 3, 2014 at 11:11 PM, Owen DeLong wrote: > Yes, David, an organization can be a bad actor and tie up excess resources > without transferring them in violation of the spirit and intent of the > policy. > > Or, you could recognize that the intent of the policy and the reason for > that policy is to make those addresses available to other entities with a > more immediate need and behave in the spirit of the community. > > We can?t make the letter of the law force all organizations to be good > actors. It?s just not practical. The best we can do is provide policy that > expresses the general intent of the community and hope that the majority of > people and organizations are good actors. > > So while your ability to circumvent the intent of the policy within the > ?letter of the law? is not in the interest of the community, compliance with > the spirit and intent of the policy is, in fact good for the operator > community. Of course, it is inevitably up to each organization whether to > act as a good citizen of the community or not. This is true even in cases > where the policy is iron clad and there are certainly no shortage of > examples of bad actors throughout history. > > Owen > > On Jun 3, 2014, at 12:31 PM, David Huberman > wrote: > > We had a discussion today at NANOG in the ARIN PPC about needs-basis in 8.3 > transfers. > > I?d like to state the following, and then let?s see where the discussion > takes us: > > My team runs an AS. And yep, we?re a pretty big company. We rely on IPv4 > today for most of our numbering, and will continue to do so for the next > couple of years.[1] In the coming year, when we can?t get space from ARIN > or other RIRs, we have to turn to the market for our IP address needs. We > may choose to buy more than a 2 year supply, because it may make business > sense for us to do so. ARIN policy, however, only allows us to take the IP > addresses we buy and transfer the portion which represents a 2 year need. > The rest will remain in the name of whoever sold the IP addresses to us. > > Why is this result good for the operator community? Wouldn?t it be better > if ARIN rules allowed us to transfer into our name all the IP addresses > which we now own? > > Regards, > /david > > [1] We?re working on increasing IPv6 presence in our network and our > products, but large corporations move slowly ;) > > _______________________________________________ > 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 mike at iptrading.com Wed Jun 4 11:16:48 2014 From: mike at iptrading.com (Mike Burns) Date: Wed, 4 Jun 2014 11:16:48 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <7BA05D8710DA46C4ACF2B8F7F2C95DFE@MPC> Hi Blake, We can be wistful for the lack of progress of RPKI or the fact that addresses are regularly routed for customers who are not the Whois registrants, but we are powerless to change those things, community-wide. We are a community of private network operators for the most part. We are stakeholders tasked primarily with maintaining a registry of uniqueness of IP addresses. We need to ask ourselves whether the purported benefits of maintaining a needs-test for every change of registrant in Whois is worth the risk to the registry and the expenditure of fungible ARIN staff resources. I elucidated one such risk, which is the risk of un-registered acquisitions of shell corporations which are incentivized by the lack of a needs test. John Curran acknowledged this risk. I offered an example of one of the few publicly demonstrable cases of this in Whois, related to the public information surrounding the Microsoft/Nortel deal. I am aware of many more but can not disclose them. People seek to frame this issue as if it were this question: "Should we change the rules just because some people will break them?" My answer to that is yes, of course we should, unless the rule provides some overriding benefit. So my question for the community is "What is the benefit we realize by insisting on ARIN team review of every single transfer, down to /24, and is it worth ARIN ticket time delay and the risk of decreased Whois accuracy?" And secondarily, what size of un-needs tested transfer would be an acceptable balance between the benefits of the needs test and the costs of the needs test? Regards, Mike Burns -----Original Message----- From: Blake Dunlap Sent: Wednesday, June 04, 2014 10:05 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers I would actually prefer to find a way to resolve the problem of entities not caring about their whois being accurate^H^H^H^H^H^H^H^H^H^H resources being properly registered to them. It's rather pointless to have any rules without them actually mattering. RPKI had hope, but it doesn't seem to be going anywhere. -Blake On Tue, Jun 3, 2014 at 11:11 PM, Owen DeLong wrote: > Yes, David, an organization can be a bad actor and tie up excess resources > without transferring them in violation of the spirit and intent of the > policy. > > Or, you could recognize that the intent of the policy and the reason for > that policy is to make those addresses available to other entities with a > more immediate need and behave in the spirit of the community. > > We can?t make the letter of the law force all organizations to be good > actors. It?s just not practical. The best we can do is provide policy that > expresses the general intent of the community and hope that the majority > of > people and organizations are good actors. > > So while your ability to circumvent the intent of the policy within the > ?letter of the law? is not in the interest of the community, compliance > with > the spirit and intent of the policy is, in fact good for the operator > community. Of course, it is inevitably up to each organization whether to > act as a good citizen of the community or not. This is true even in cases > where the policy is iron clad and there are certainly no shortage of > examples of bad actors throughout history. > > Owen > > On Jun 3, 2014, at 12:31 PM, David Huberman > wrote: > > We had a discussion today at NANOG in the ARIN PPC about needs-basis in > 8.3 > transfers. > > I?d like to state the following, and then let?s see where the discussion > takes us: > > My team runs an AS. And yep, we?re a pretty big company. We rely on IPv4 > today for most of our numbering, and will continue to do so for the next > couple of years.[1] In the coming year, when we can?t get space from ARIN > or other RIRs, we have to turn to the market for our IP address needs. > We > may choose to buy more than a 2 year supply, because it may make business > sense for us to do so. ARIN policy, however, only allows us to take the > IP > addresses we buy and transfer the portion which represents a 2 year need. > The rest will remain in the name of whoever sold the IP addresses to us. > > Why is this result good for the operator community? Wouldn?t it be better > if ARIN rules allowed us to transfer into our name all the IP addresses > which we now own? > > Regards, > /david > > [1] We?re working on increasing IPv6 presence in our network and our > products, but large corporations move slowly ;) > > _______________________________________________ > 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 Wed Jun 4 11:28:53 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 04 Jun 2014 18:28:53 +0300 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <538F3B35.8090806@matthew.at> On 6/4/2014 7:11 AM, Owen DeLong wrote: > Or, you could recognize that the intent of the policy and the reason > for that policy is to make those addresses available to other entities > with a more immediate need and behave in the spirit of the community. > > We can't make the letter of the law force all organizations to be good > actors. It's just not practical. The best we can do is provide policy > that expresses the general intent of the community and hope that the > majority of people and organizations are good actors. > Once addresses are no longer available from ARIN, all organizations in need of addresses will be spending real money to acquire them. They will spend that money as directed by their leadership and their shareholders to ensure their own perceived need is met, not what ARIN thinks they need this week. In fact, for public companies to do otherwise would be irresponsible to their shareholders and actionable by said shareholders. If they are unable to register the addresses, they will still lock them up in contracts that are none of ARIN's business (and entirely invisible to ARIN), not "make those addresses available to other entities with a more immediate need". That's just not going to happen, for the same reason GM doesn't say "Well, tires are going to be in short supply for the next couple of quarters. We really should stop ordering them so other more charitable car makers can get their share." Matthew Kaufman ps. I'd also note that "policy that expresses the general intent of the community" may in fact *be* policy that lets post-runout transfers be performed without a needs test, as "the community" consists of a lot more than "Owen". -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgrant at skywaywest.com Wed Jun 4 11:40:35 2014 From: rgrant at skywaywest.com (Ron Grant) Date: Wed, 04 Jun 2014 08:40:35 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538F3B35.8090806@matthew.at> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> Message-ID: <538F3DF3.80609@skywaywest.com> +1, with the added note that speculation and hoarding will be in play in a limited-resources market. "In other business news, a man traded a kidney for an IPv4 C Class network today...." But wait - isn't this a GOOD thing? Who's going to hold out on IPv6 deployment if those addresses are FREE and IPv4 addresses cost more than an Apple share? On 2014-06-04 8:28 AM, Matthew Kaufman wrote: > On 6/4/2014 7:11 AM, Owen DeLong wrote: >> Or, you could recognize that the intent of the policy and the reason >> for that policy is to make those addresses available to other >> entities with a more immediate need and behave in the spirit of the >> community. >> >> We can't make the letter of the law force all organizations to be >> good actors. It's just not practical. The best we can do is provide >> policy that expresses the general intent of the community and hope >> that the majority of people and organizations are good actors. >> > > Once addresses are no longer available from ARIN, all organizations in > need of addresses will be spending real money to acquire them. They > will spend that money as directed by their leadership and their > shareholders to ensure their own perceived need is met, not what ARIN > thinks they need this week. In fact, for public companies to do > otherwise would be irresponsible to their shareholders and actionable > by said shareholders. > > If they are unable to register the addresses, they will still lock > them up in contracts that are none of ARIN's business (and entirely > invisible to ARIN), not "make those addresses available to other > entities with a more immediate need". That's just not going to happen, > for the same reason GM doesn't say "Well, tires are going to be in > short supply for the next couple of quarters. We really should stop > ordering them so other more charitable car makers can get their share." > > Matthew Kaufman > > ps. I'd also note that "policy that expresses the general intent of > the community" may in fact *be* policy that lets post-runout transfers > be performed without a needs test, as "the community" consists of a > lot more than "Owen". > > > _______________________________________________ > 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. -- Ron Grant Managed DSL/T1/Wireless/Fibre Skyway West Business Internet Internet and Private Networking rgrant at skywaywest.com Bonding and Fail Over Solutions ph: 604 737 2113 Virtual Data Centre and Private Clouds fax: 604 482 1299 http://www.skywaywest.com Sales, Support and Billing http://www.skywaywest.com/contact-us.htm ca.linkedin.com/in/obiron -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Wed Jun 4 11:46:54 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 4 Jun 2014 15:46:54 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <7BA05D8710DA46C4ACF2B8F7F2C95DFE@MPC> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com> <7BA05D8710DA46C4ACF2B8F7F2C95DFE@MPC> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD47E5@ENI-MAIL.eclipse-networks.com> I think the fact that organizations are regularly going around the policies in place is their continued voting that the policies are way too unreasonable and arbitrary. If the policies were workable for them they might go thru ARIN rather than around them. The needs tests need to go, and once they do, real progress could be made getting the database updated to be more accurate - and oh by the way real organizations with real needs could actually get their needed resources thru ARIN's established channels. It should not be ARIN's role to impose policies that completely shut out organizations like ours from getting resources. That is what has happened to us and that is why so many organization keep going around ARIN to avoid the hassle and the chance that some arbitrary policy will shut them out somehow too. But there I go again, trying to impart some common sense where common sense is not welcome. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mike Burns Sent: Wednesday, June 04, 2014 11:17 AM To: Blake Dunlap; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers Hi Blake, We can be wistful for the lack of progress of RPKI or the fact that addresses are regularly routed for customers who are not the Whois registrants, but we are powerless to change those things, community-wide. We are a community of private network operators for the most part. We are stakeholders tasked primarily with maintaining a registry of uniqueness of IP addresses. We need to ask ourselves whether the purported benefits of maintaining a needs-test for every change of registrant in Whois is worth the risk to the registry and the expenditure of fungible ARIN staff resources. I elucidated one such risk, which is the risk of un-registered acquisitions of shell corporations which are incentivized by the lack of a needs test. John Curran acknowledged this risk. I offered an example of one of the few publicly demonstrable cases of this in Whois, related to the public information surrounding the Microsoft/Nortel deal. I am aware of many more but can not disclose them. People seek to frame this issue as if it were this question: "Should we change the rules just because some people will break them?" My answer to that is yes, of course we should, unless the rule provides some overriding benefit. So my question for the community is "What is the benefit we realize by insisting on ARIN team review of every single transfer, down to /24, and is it worth ARIN ticket time delay and the risk of decreased Whois accuracy?" And secondarily, what size of un-needs tested transfer would be an acceptable balance between the benefits of the needs test and the costs of the needs test? Regards, Mike Burns -----Original Message----- From: Blake Dunlap Sent: Wednesday, June 04, 2014 10:05 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers I would actually prefer to find a way to resolve the problem of entities not caring about their whois being accurate^H^H^H^H^H^H^H^H^H^H resources being properly registered to them. It's rather pointless to have any rules without them actually mattering. RPKI had hope, but it doesn't seem to be going anywhere. -Blake On Tue, Jun 3, 2014 at 11:11 PM, Owen DeLong wrote: > Yes, David, an organization can be a bad actor and tie up excess > resources without transferring them in violation of the spirit and > intent of the policy. > > Or, you could recognize that the intent of the policy and the reason > for that policy is to make those addresses available to other entities > with a more immediate need and behave in the spirit of the community. > > We can?t make the letter of the law force all organizations to be good > actors. It?s just not practical. The best we can do is provide policy > that expresses the general intent of the community and hope that the > majority of people and organizations are good actors. > > So while your ability to circumvent the intent of the policy within > the ?letter of the law? is not in the interest of the community, > compliance with the spirit and intent of the policy is, in fact good > for the operator community. Of course, it is inevitably up to each > organization whether to act as a good citizen of the community or not. > This is true even in cases where the policy is iron clad and there are > certainly no shortage of examples of bad actors throughout history. > > Owen > > On Jun 3, 2014, at 12:31 PM, David Huberman > > wrote: > > We had a discussion today at NANOG in the ARIN PPC about needs-basis > in > 8.3 > transfers. > > I?d like to state the following, and then let?s see where the > discussion takes us: > > My team runs an AS. And yep, we?re a pretty big company. We rely on > IPv4 today for most of our numbering, and will continue to do so for > the next couple of years.[1] In the coming year, when we can?t get > space from ARIN or other RIRs, we have to turn to the market for our IP address needs. > We > may choose to buy more than a 2 year supply, because it may make business > sense for us to do so. ARIN policy, however, only allows us to take the > IP > addresses we buy and transfer the portion which represents a 2 year need. > The rest will remain in the name of whoever sold the IP addresses to us. > > Why is this result good for the operator community? Wouldn?t it be > better if ARIN rules allowed us to transfer into our name all the IP > addresses which we now own? > > Regards, > /david > > [1] We?re working on increasing IPv6 presence in our network and our > products, but large corporations move slowly ;) > > _______________________________________________ > 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. From michael at linuxmagic.com Wed Jun 4 12:11:47 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Wed, 04 Jun 2014 09:11:47 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <538F4543.6070605@linuxmagic.com> On 14-06-04 07:05 AM, Blake Dunlap wrote: > I would actually prefer to find a way to resolve the problem of > entities not caring about their whois being > accurate^H^H^H^H^H^H^H^H^H^H resources being properly registered to > them. It's rather pointless to have any rules without them actually > mattering. I think this is the most important thing, and the area we have to help ARIN get more enforcement teeth. 13. TERM AND TERMINATION (b) Termination of Suspension of Services for Cause by ARIN, ARIN shall have the right to stop Services pursuant to any breach of Section 2(c), 2(e), 4 or 7. In addition, ARIN may exercise its judgement to immediately stop Services upon written notice to Holder if Holder breaches Sections 2(c), 2(d), 7, or 11. Which references .. 2. CONDITIONS OF SERVICE (c) Information and Cooperation. Holder has completed an application provided by ARIN for one or more Services (the "Application"). Holder MUST (i) promptly notify ARIN if any informatin provided in the Application changes during the term of this Agreement, and (ii) promptly, accurately, and completely respond to any inquiry Holder by ARIN during the term of this Agreement. In addition, Holder shall promptly provide ARIN with complete and accurate information, and coppoeration as required by any Service Terms or that ARIN requests in connection with ARIN's provision of any of the Services to the Holder. If Holder does not provide ARIN with such information or cooperation that ARIN requests, ARIN may take such failure into account in evaluating Holders' subsequent requests for transfer, allocation or assignment of additional resources, or requests for changes to any Service. (d) Prohibited Conduct by Holder. In using any of the Services, Holder shall not: (i) disrupt or interfere with the security or use of any of the Services; (ii) violate any applicable laws, statuses, rules, or regulations; or (iii) assist any third party in engaging in any activities prohibited by any Service Terms. (7 and 11 are mostly to protect ARIN itself, so we ignore them for this thread) .... Now it seems that ARIN does 'take such failure into account'... when someone reports a report, however the issue is that it does NOT exercise 13 on contraventions. It has been pointed out that sometimes it is very hard for ARIN to conduct the 'written' notice, when the information is incorrect (I am sure a clause could be written that says registered letter to the last known address being sufficient) however I believe ARIN needs to take a stronger role in exercising section 13 rights when inaccurate or no whois information is maintained. Also, when 'fake' delegations are made and advertised (or in transfers as previously mentioned) that should also be addressed by acting on Section 13, however it might be harder to prove. Also, while very controversial, especially given the issues with US control being discussed, section 2(d)(ii) and 2(d)(iii) should be examined, in terms of does ARIN have the mandate to act on those? Some hosting companies have a 'turn the blind eye' to the activities of on their IP space. (I had one conference with a company who blatantly said, what we don't monitor, we can't get sued for) And also, the jurisdiction of the 'laws' that are being broken vary from region to region, and this isn't directly addressed in the agreements. (Can ARIN suspend agreements for laws broken in US, but not the jurisdiction of operation?) More work is needed on clear mandates, both in the wording of agreements, as well as directions from the Board as to when/where/how hard they should act on section 13. (Ps, what about IP space being lent to the hackers recently in the news, is the company that gave/lent/rent them that space to them culpable? Slippery slope.) Especially with diminishing IP space, ARIN needs to have a clearer mandate on getting some IP space back, if the operators don't keep up clear rwhois records, or use the space or allow it to be used for nefarious reasons. (And, from a personal perspective.. it seems wrong that over 600k IP(s) are being used strictly to push car/life insurance, the latest Dr Oz, all from throw away domains, in contravention of most anti-spam laws, and even worse, that 'usage' of current IP space can be used as justification for receiving more IP space by the hosters that allow that activity, and for much of that space, proper rwhois records are not in place. End Vent/Rant) -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From cja at daydream.com Wed Jun 4 16:24:18 2014 From: cja at daydream.com (CJ Aronson) Date: Wed, 4 Jun 2014 14:24:18 -0600 Subject: [arin-ppml] 2013-8 New Subsequent Allocations for new multiple discrete networks Message-ID: Hi everyone! This recommended draft policy was just presented at the Public Policy Consultation at NANOG in Washington. Please review and comment if you have any input for or against this proposal. Thanks! -----Cathy ----------------------------------------------------- 2013-8 New Subsequent Allocations for new multiple discrete networks Policy Statement: IPv4: Add the following statement to section 4.5.4. Upon verification that the organization has shown evidence of deployment of the new discrete network site, the new network(s) shall be allocated the minimum allocation size under section 4.2.1.5 unless the organization can demonstrate additional need using the immediate need criteria (4.2.1.6). IPv6: Add an additional reference to section 6.11.5.b such that it references both the initial allocation and subsequent allocation sections of the IPv6 LIR policy. "Each network will be judged against the existing utilization criteria specified in 6.5.2 and 6.5.3 as if it were a separate organization..." Comments: a. Timetable for implementation: immediate b. This policy is being proposed based upon the Policy Implementation & Experience Report from ARIN 32. https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf c: Older versions of the MDN policy did contain new network criteria. This criteria appears to have been dropped during subsequent rewrites of the MDN policy. "The organization must not allocate a CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to a new network." (https://www.arin.net/policy/archive/nrpm_20041015.pdf) -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Jun 4 19:23:08 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 4 Jun 2014 16:23:08 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <7BA05D8710DA46C4ACF2B8F7F2C95DFE@MPC> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <7BA05D8710DA46C4ACF2B8F7F2C95DFE@MPC> Message-ID: <6C8203F0-AB62-41EF-91B1-736336B82A20@delong.com> On Jun 4, 2014, at 8:16 AM, Mike Burns wrote: > Hi Blake, > > We can be wistful for the lack of progress of RPKI or the fact that addresses are regularly routed for customers who are not the Whois registrants, but we are powerless to change those things, community-wide. > > We are a community of private network operators for the most part. We are stakeholders tasked primarily with maintaining a registry of uniqueness of IP addresses. We need to ask ourselves whether the purported benefits of maintaining a needs-test for every change of registrant in Whois is worth the risk to the registry and the expenditure of fungible ARIN staff resources. > > I elucidated one such risk, which is the risk of un-registered acquisitions of shell corporations which are incentivized by the lack of a needs test. John Curran acknowledged this risk. > > I offered an example of one of the few publicly demonstrable cases of this in Whois, related to the public information surrounding the Microsoft/Nortel deal. I am aware of many more but can not disclose them. > > People seek to frame this issue as if it were this question: "Should we change the rules just because some people will break them?" > > My answer to that is yes, of course we should, unless the rule provides some overriding benefit. > > So my question for the community is "What is the benefit we realize by insisting on ARIN team review of every single transfer, down to /24, and is it worth ARIN ticket time delay and the risk of decreased Whois accuracy?? The benefit is preserving addresses on a fair basis for those who actually have legitimate and quasi-immediate use for them. Yes, this benefit is worth the ARIN ticket time and delay. There has not yet been any actual evidence presented to show that the risk to whois accuracy is any greater without this proposal than it is with it. Those that would ignore ARIN policy to effectuate a transfer are just as likely IMHO to ignore whois as not. > And secondarily, what size of un-needs tested transfer would be an acceptable balance between the benefits of the needs test and the costs of the needs test? /24 seems like a perfectly reasonable balancing point to me. I?d be willing to conduct an experiment on a temporary basis at /20 for a limited time (12 months). Owen From owen at delong.com Wed Jun 4 19:25:12 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 4 Jun 2014 16:25:12 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538F3B35.8090806@matthew.at> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> Message-ID: <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> > > Matthew Kaufman > > ps. I'd also note that "policy that expresses the general intent of the community" may in fact *be* policy that lets post-runout transfers be performed without a needs test, as "the community" consists of a lot more than "Owen?. Indeed, it does. However, many people have also repeatedly stood up in defense of needs basis, so singling me out as if I am the lone supporter of preserving needs basis is as specious as many of your other arguments. Owen From SRyerse at eclipse-networks.com Wed Jun 4 19:50:37 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 4 Jun 2014 23:50:37 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> There are several folks (like me) who want to ditch the needs test and there are several folks who don't want to ditch them. I take it your position is that the folks who want to keep needs tests should somehow prevail in this argument without much or any change, and those of us who wish to ditch them should just accept the status quo with needs tests. In other words you win and we lose! I saw a lot of folks comment here recently who want to at least loosen needs tests on the smaller block sizes, many many more than I've ever seen before. Since it is obvious a sizable portion of this community desires a change toward loosening policies, why is it that you persist in standing in the way of compromise? There comes a time when fair is fair - and small organizations are routinely discriminated against because of our small size and not so deep pockets. There is a lot of anger out there over the unfairness of these existing policies. It should be just as easy for us to get resources as it was for T-Mobile and others. I call on all members of this community to at least come to a compromise. After all the world hasn't ended for RIPE with their changes - and it won't end here either if fairness is put back into the policies so that small organizations can get the resources they need too! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Wednesday, June 04, 2014 7:25 PM To: Matthew Kaufman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > Matthew Kaufman > > ps. I'd also note that "policy that expresses the general intent of the community" may in fact *be* policy that lets post-runout transfers be performed without a needs test, as "the community" consists of a lot more than "Owen?. Indeed, it does. However, many people have also repeatedly stood up in defense of needs basis, so singling me out as if I am the lone supporter of preserving needs basis is as specious as many of your other arguments. Owen _______________________________________________ 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 ppml at rsuc.gweep.net Wed Jun 4 19:52:27 2014 From: ppml at rsuc.gweep.net (Joe Provo) Date: Wed, 4 Jun 2014 19:52:27 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> Message-ID: <20140604235227.GA93629@gweep.net> On Wed, Jun 04, 2014 at 04:25:12PM -0700, Owen DeLong wrote: > > > > Matthew Kaufman > > > > ps. I'd also note that "policy that expresses the general intent of the community" may in fact *be* policy that lets post-runout transfers be performed without a needs test, as "the community" consists of a lot more than "Owen?. > > Indeed, it does. However, many people have also repeatedly stood > up in defense of needs basis, so singling me out as if I am the > lone supporter of preserving needs basis is as specious as many of > your other arguments. Speaking for myself here on PPML as I've done since the list got spun up, I can shockingly say "I agree with Owen". See the PPC transcript for what I and my colleagues had to say about the proposal, which was amusingly based on an utterly false problem statement. If we need to streamline the needs evaluation, that's a different kettle of fish. Throwing it out is a mistake. -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG From owen at delong.com Wed Jun 4 20:13:52 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 4 Jun 2014 17:13:52 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> Message-ID: On Jun 4, 2014, at 4:50 PM, Steven Ryerse wrote: > There are several folks (like me) who want to ditch the needs test and there are several folks who don't want to ditch them. I take it your position is that the folks who want to keep needs tests should somehow prevail in this argument without much or any change, and those of us who wish to ditch them should just accept the status quo with needs tests. In other words you win and we lose! Not necessarily. I?m open for a good debate of the issue on the merits of the proposal. I?ve attempted to stick to that. > I saw a lot of folks comment here recently who want to at least loosen needs tests on the smaller block sizes, many many more than I've ever seen before. Since it is obvious a sizable portion of this community desires a change toward loosening policies, why is it that you persist in standing in the way of compromise? I have not stood in the way of compromise and could not do so even if I wanted to. I am only one of 15 votes on the AC. You only need ten of them to get a policy proposal sent to the board. It is, however, equally obvious that a sizable portion of the community, not merely myself, does not want to eliminate the needs test. Currently, there is no actual proposal on the table for loosening them or compromising. If there were one, I would address the merits of it as I saw them. > There comes a time when fair is fair - and small organizations are routinely discriminated against because of our small size and not so deep pockets. There is a lot of anger out there over the unfairness of these existing policies. It should be just as easy for us to get resources as it was for T-Mobile and others. I call on all members of this community to at least come to a compromise. After all the world hasn't ended for RIPE with their changes - and it won't end here either if fairness is put back into the policies so that small organizations can get the resources they need too! Given the number of sole-proprietors with very small budgets that I have obtained IP allocations for over the past several years, I think this is an inaccurate characterization of the facts at hand. Indeed, if you look at my posting history and my voting history throughout my tenure on the AC, you will find that I am one of the biggest advocates that the small organization could find. It is just as easy (if not easier) for small organizations to get resources as large ones. (I know this full well because I have applied for resources for virtually every size category in the ARIN fee table). If you are having trouble with a particular application, feel free to contact me off-line with the details. I may be able to help you navigate the ARIN process more effectively. We have, by the way, been making steady progress on loosening the restrictions on needs basis. There used to be no ability to get anything smaller than a /20 from ARIN for conventional uses at one time. Today, that?s down to a /24 and there is progress being made on making that possible without multihoming. Owen From David.Huberman at microsoft.com Wed Jun 4 20:21:10 2014 From: David.Huberman at microsoft.com (David Huberman) Date: Thu, 5 Jun 2014 00:21:10 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <20140604235227.GA93629@gweep.net> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> Message-ID: <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> We're going to be a cross-roads very soon. ARIN is going to exhaust, and network operators will be unable to obtain additional IPv4 address blocks from ARIN. At that point, the most obvious solution for IPv4 needs will be the market. Proper stewardship of the ARIN function demands that ARIN policy adjust to what happens in the market. It's not the other way around, if only because that's not how markets work. The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, professors who study markets, brokers who operate in the market, and buyers and sellers who buy and sell in the market have all told the ARIN community the same story for around 5 years now: the market is going to act as a market, and ARIN policy needs to be ready for it; ARIN policy needs to make sense with the dynamics of the market. It's hard to know how to argue with operators like Owen and the Google folks who all say the opposite; that ARIN policy should stick to the same ideals as 1995 (important ideals for a very long time!) and not adjust. I fear the results of this kind of ostracism :( David R Huberman Microsoft Corporation Senior IT/OPS Program Manager (GFS) From jcurran at arin.net Wed Jun 4 20:27:19 2014 From: jcurran at arin.net (John Curran) Date: Thu, 5 Jun 2014 00:27:19 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <20140604235227.GA93629@gweep.net> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> Message-ID: <3CFA7018-277B-44A6-B8B8-CEEF32E897C3@corp.arin.net> On Jun 4, 2014, at 7:52 PM, Joe Provo wrote: > On Wed, Jun 04, 2014 at 04:25:12PM -0700, Owen DeLong wrote: >>> >>> Matthew Kaufman >>> >>> ps. I'd also note that "policy that expresses the general intent of the community" may in fact *be* policy that lets post-runout transfers be performed without a needs test, as "the community" consists of a lot more than "Owen?. >> >> Indeed, it does. However, many people have also repeatedly stood >> up in defense of needs basis, so singling me out as if I am the >> lone supporter of preserving needs basis is as specious as many of >> your other arguments. > > Speaking for myself here on PPML as I've done since the list got spun > up, I can shockingly say "I agree with Owen". > > See the PPC transcript for what I and my colleagues had to say about > the proposal, which was amusingly based on an utterly false problem > statement. > > If we need to streamline the needs evaluation, that's a different > kettle of fish. Throwing it out is a mistake. Joe - Could you briefly explain how/why the presence of the needs-test is important? Is this based on concern of non-network operators engaging in market activities (presumably detrimental), or based potential of well-funded network operators depleting the supply of blocks for transfer, or ... (I can think of several possibilities, but it would be good for those on the list to know some of the reasoning behind your stated concern.) Thanks! /John John Curran President and CEO ARIN From mike at iptrading.com Wed Jun 4 20:41:48 2014 From: mike at iptrading.com (Mike Burns) Date: Wed, 4 Jun 2014 20:41:48 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <7BA05D8710DA46C4ACF2B8F7F2C95DFE@MPC> <6C8203F0-AB62-41EF-91B1-736336B82A20@delong.com> Message-ID: <068283D4AA6C4261B83F7A9AF337737F@ncsscfoipoxes4> > And secondarily, what size of un-needs tested transfer would be an > acceptable balance between the benefits of the needs test and the costs of > the needs test? /24 seems like a perfectly reasonable balancing point to me. I?d be willing to conduct an experiment on a temporary basis at /20 for a limited time (12 months). Owen Hi Owen, I understand your position and belief that the needs test serves to preserve space for those with a legitimate and quasi-immediate need, but in my experience there is plenty of supply in the transfer market currently, and in any case we are talking about relatively small amounts which can be sequestered without the demonstration of need. Thus I don't think the removal of a needs test for transfers smaller than a /16 will have any measurable effect on the ability to find space on the transfer market at current price levels. Thanks for offering your input to my second question. A /20 is an interesting choice because it appears in policy as the minimum size for some allocations and requestors who fail to meet that threshold are some of the corner cases which would be helped by the potential for a needs-free transfer. Regards, Mike From David.Huberman at microsoft.com Wed Jun 4 20:42:33 2014 From: David.Huberman at microsoft.com (David Huberman) Date: Thu, 5 Jun 2014 00:42:33 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <3aed59f33f4d4ce38cbdf87f52588c66@DM2PR03MB398.namprd03.prod.outlook.com> And I'd like to follow-up my own post with a "my fault"/"I'm sorry" for directly calling out Owen in my email. Owen is doing what so many others aren't: he's actively participating. He and I are on opposite sides here, so it sometimes feel antagonistic when it isn't. Sorry, Owen, for calling you out by name. That was wrong of me. David R Huberman Microsoft Corporation Senior IT/OPS Program Manager (GFS) -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: Wednesday, June 4, 2014 5:21 PM To: ppml at rsuc.gweep.net; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers We're going to be a cross-roads very soon. ARIN is going to exhaust, and network operators will be unable to obtain additional IPv4 address blocks from ARIN. At that point, the most obvious solution for IPv4 needs will be the market. Proper stewardship of the ARIN function demands that ARIN policy adjust to what happens in the market. It's not the other way around, if only because that's not how markets work. The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, professors who study markets, brokers who operate in the market, and buyers and sellers who buy and sell in the market have all told the ARIN community the same story for around 5 years now: the market is going to act as a market, and ARIN policy needs to be ready for it; ARIN policy needs to make sense with the dynamics of the market. It's hard to know how to argue with operators like Owen and the Google folks who all say the opposite; that ARIN policy should stick to the same ideals as 1995 (important ideals for a very long time!) and not adjust. I fear the results of this kind of ostracism :( David R Huberman Microsoft Corporation Senior IT/OPS Program Manager (GFS) _______________________________________________ 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 mike at iptrading.com Wed Jun 4 20:56:25 2014 From: mike at iptrading.com (Mike Burns) Date: Wed, 4 Jun 2014 20:56:25 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com><538F3B35.8090806@matthew.at><973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> Message-ID: > up, I can shockingly say "I agree with Owen". > > See the PPC transcript for what I and my colleagues had to say about > the proposal, which was amusingly based on an utterly false problem > statement. > > If we need to streamline the needs evaluation, that's a different > kettle of fish. Throwing it out is a mistake. > Hi Joe, We are not throwing out the needs test. We are seeking reasonable compromise in limiting the application of that needs test by imposing size and time restrictions which hopefully will reduce compliance-avoidance behavior while at the same time improving access to space for small companies. Because the transfer is policy is written to reference the allocation policies which apply to free pool addresses, any streamlining of the needs evaluation such as you suggest will require substantial change to the NRPM, whereas the proposed change includes the insertion of one clause into 8.3 and 8.4. Regards, Mike Burns From SRyerse at eclipse-networks.com Wed Jun 4 21:01:33 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 5 Jun 2014 01:01:33 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.809080 6@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD5AC8@ENI-MAIL.eclipse-networks.com> No offense, but there should not be a need for any organization to have to hire a consult to try and get the Minimum size allocation. If you need a consultant for that then something is very wrong with the policies! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, June 04, 2014 8:14 PM To: Steven Ryerse Cc: Matthew Kaufman; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Jun 4, 2014, at 4:50 PM, Steven Ryerse wrote: > There are several folks (like me) who want to ditch the needs test and there are several folks who don't want to ditch them. I take it your position is that the folks who want to keep needs tests should somehow prevail in this argument without much or any change, and those of us who wish to ditch them should just accept the status quo with needs tests. In other words you win and we lose! Not necessarily. I?m open for a good debate of the issue on the merits of the proposal. I?ve attempted to stick to that. > I saw a lot of folks comment here recently who want to at least loosen needs tests on the smaller block sizes, many many more than I've ever seen before. Since it is obvious a sizable portion of this community desires a change toward loosening policies, why is it that you persist in standing in the way of compromise? I have not stood in the way of compromise and could not do so even if I wanted to. I am only one of 15 votes on the AC. You only need ten of them to get a policy proposal sent to the board. It is, however, equally obvious that a sizable portion of the community, not merely myself, does not want to eliminate the needs test. Currently, there is no actual proposal on the table for loosening them or compromising. If there were one, I would address the merits of it as I saw them. > There comes a time when fair is fair - and small organizations are routinely discriminated against because of our small size and not so deep pockets. There is a lot of anger out there over the unfairness of these existing policies. It should be just as easy for us to get resources as it was for T-Mobile and others. I call on all members of this community to at least come to a compromise. After all the world hasn't ended for RIPE with their changes - and it won't end here either if fairness is put back into the policies so that small organizations can get the resources they need too! Given the number of sole-proprietors with very small budgets that I have obtained IP allocations for over the past several years, I think this is an inaccurate characterization of the facts at hand. Indeed, if you look at my posting history and my voting history throughout my tenure on the AC, you will find that I am one of the biggest advocates that the small organization could find. It is just as easy (if not easier) for small organizations to get resources as large ones. (I know this full well because I have applied for resources for virtually every size category in the ARIN fee table). If you are having trouble with a particular application, feel free to contact me off-line with the details. I may be able to help you navigate the ARIN process more effectively. We have, by the way, been making steady progress on loosening the restrictions on needs basis. There used to be no ability to get anything smaller than a /20 from ARIN for conventional uses at one time. Today, that?s down to a /24 and there is progress being made on making that possible without multihoming. Owen From SRyerse at eclipse-networks.com Wed Jun 4 21:05:12 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 5 Jun 2014 01:05:12 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.8090806 @matthew.at><973FD910-966B-42E1-83B9-DA485445D04E@delong.com><20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD5B28@ENI-MAIL.eclipse-networks.com> I think we are already at near exhaustion and the only loosening discussion I've seen is at the low end. I seriously doubt that the forces that are for full needs requirements now will change their mind just because ARIN has less resources to allocate. They like the status quo and they show almost no desire to even compromise. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: Wednesday, June 04, 2014 8:21 PM To: ppml at rsuc.gweep.net; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers We're going to be a cross-roads very soon. ARIN is going to exhaust, and network operators will be unable to obtain additional IPv4 address blocks from ARIN. At that point, the most obvious solution for IPv4 needs will be the market. Proper stewardship of the ARIN function demands that ARIN policy adjust to what happens in the market. It's not the other way around, if only because that's not how markets work. The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, professors who study markets, brokers who operate in the market, and buyers and sellers who buy and sell in the market have all told the ARIN community the same story for around 5 years now: the market is going to act as a market, and ARIN policy needs to be ready for it; ARIN policy needs to make sense with the dynamics of the market. It's hard to know how to argue with operators like Owen and the Google folks who all say the opposite; that ARIN policy should stick to the same ideals as 1995 (important ideals for a very long time!) and not adjust. I fear the results of this kind of ostracism :( David R Huberman Microsoft Corporation Senior IT/OPS Program Manager (GFS) _______________________________________________ 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 Wed Jun 4 21:07:36 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 04 Jun 2014 18:07:36 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> Message-ID: <538FC2D8.8020207@matthew.at> On 6/4/14, 4:25 PM, Owen DeLong wrote: >> Matthew Kaufman >> >> ps. I'd also note that "policy that expresses the general intent of the community" may in fact *be* policy that lets post-runout transfers be performed without a needs test, as "the community" consists of a lot more than "Owen?. > Indeed, it does. However, many people have also repeatedly stood up in defense of needs basis, so singling me out as if I am the lone supporter of preserving needs basis is as specious as many of your other arguments. > Wasn't to single you out, but was meant to call attention to an argument that says "in addition to it being how I feel, that's what the community wants [as proven by the existence of current policy]" But we should be clear... the policy as written in the PPML today may or may not be "policy that expresses the general intent of the community". In fact, I would argue that it isn't. For starters, most of "the community" isn't participating in the PDP at all. And secondly, for a policy that the community likes, we sure have a lot of fairly significant changes queued up. In summary, I don't think it is appropriate to back up any argument for or against a policy change with "but that's what the current policy says, therefore everyone else already agrees with me". Matthew Kaufman From matthew at matthew.at Wed Jun 4 21:10:29 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 04 Jun 2014 18:10:29 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> Message-ID: <538FC385.5030602@matthew.at> On 6/4/14, 5:13 PM, Owen DeLong wrote: > It is, however, equally obvious that a sizable portion of the > community, not merely myself, does not want to eliminate the needs test. For the extremely limited version of "the community" which consists of "see existing policy" and "see the handful of people who participate on the PPML". Despite all the fee collection that has been spent on outreach, there's still just not that much representation. > Currently, there is no actual proposal on the table for loosening them > or compromising. If there were one, I would address the merits of it > as I saw them. That's fair. I'm sure one will show up. Matthew Kaufman From elvis at velea.eu Wed Jun 4 21:16:55 2014 From: elvis at velea.eu (Elvis Velea) Date: Thu, 05 Jun 2014 03:16:55 +0200 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538FC385.5030602@matthew.at> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> <538FC385.5030602@matthew.at> Message-ID: <538FC507.4040304@velea.eu> Hi, On 05/06/14 03:10, Matthew Kaufman wrote: > > On 6/4/14, 5:13 PM, Owen DeLong wrote: >> It is, however, equally obvious that a sizable portion of the >> community, not merely myself, does not want to eliminate the needs test. > > For the extremely limited version of "the community" which consists of > "see existing policy" and "see the handful of people who participate > on the PPML". Despite all the fee collection that has been spent on > outreach, there's still just not that much representation. > >> Currently, there is no actual proposal on the table for loosening >> them or compromising. If there were one, I would address the merits >> of it as I saw them. > > That's fair. I'm sure one will show up. What about ARIN-2014-14? https://www.arin.net/policy/proposals/2014_14.html cheers, elvis From elvis at velea.eu Wed Jun 4 21:21:52 2014 From: elvis at velea.eu (Elvis Velea) Date: Thu, 05 Jun 2014 03:21:52 +0200 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <538FC630.9090404@velea.eu> Hi David, On 05/06/14 02:21, David Huberman wrote: > We're going to be a cross-roads very soon. ARIN is going to exhaust, and network operators will be unable to obtain additional IPv4 address blocks from ARIN. At that point, the most obvious solution for IPv4 needs will be the market. And then, they will be able to register as RIPE NCC members (LIRs) and receive as many IP addresses as they want without having to prove any demonstrated need. All they will need to do is to confirm that they will use these addresses for themselves or their customers. > Proper stewardship of the ARIN function demands that ARIN policy adjust to what happens in the market. It's not the other way around, if only because that's not how markets work. > > The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, professors who study markets, brokers who operate in the market, and buyers and sellers who buy and sell in the market have all told the ARIN community the same story for around 5 years now: the market is going to act as a market, and ARIN policy needs to be ready for it; ARIN policy needs to make sense with the dynamics of the market. > > It's hard to know how to argue with operators like Owen and the Google folks who all say the opposite; that ARIN policy should stick to the same ideals as 1995 (important ideals for a very long time!) and not adjust. I fear the results of this kind of ostracism :( Well, then let them slowly kill the ARIN function. If all ARIN members can no longer get resources and they stop paying and go to the cheapest RIR (which btw is RIPE NCC with EUR1600/year no matter how many resources one has) and get as many resources they want... what do you think will happen? cheers, elvis From SRyerse at eclipse-networks.com Wed Jun 4 21:26:08 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 5 Jun 2014 01:26:08 +0000 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201313DA3E4@ENI-MAIL.eclipse-networks.com> References: <0AA40348-4CD0-4896-8639-D46ED2022D21@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD1201313DA3E4@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD5C9A@ENI-MAIL.eclipse-networks.com> As a reminder, back on April 30th 2013 I submitted this message. I still propose that this is what needs to be done. As I mentioned I am not capable of doing the significant write-up this would require but I would support anyone willing to take the time to submit a proposal to ARIN similar to the one outlined in the RIPE proposal mentioned below. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Steven Ryerse Sent: Tuesday, April 30, 2013 4:34 PM To: Alexander, Daniel; Owen DeLong; ARIN-PPML List Subject: RE: [arin-ppml] Clean up definition of LIR/ISP vs. end-user I agree with Daniel. I strongly believe it is Arin?s charter and mission to further the Internet and not impede access to it. Debating about what an organization is doing on the Internet or what they are called is really a discussion on how to limit access to the Internet. I don?t believe that Arin should be trying to deny or limit an organization?s access to the Internet. I believe Arin should be trying to expand the Internet for good of everyone as was done before Arin?s existence. I?m all for right sizing an organizations access with reasonable polices but I am not in favor of policies that have the sole purpose of denying or restricting access to the Internet. I believe that Arin and this community need to adopt a similar set of policies like have been proposed in Europe https://www.ripe.net/ripe/policies/proposals/2013-03 This would require a wholesale rewrite of a lot of policies which I am not capable of doing - but removing the needs requirements in all policies and just instituting right-sizing policies would be in line with Arin?s mission and be best for all. I would support anyone willing to take the time to submit a proposal to Arin similar to the one above that has been proposed for RIPE. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: 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 Alexander, Daniel Sent: Tuesday, April 30, 2013 3:54 PM To: Owen DeLong; ARIN-PPML List Subject: Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user I suggest it is a worthwhile conversation to explore why they will be necessary? If the Internet is a network of networks, why does ARIN, an RIR, need to make the distinctions in how it allocates or assigns resources? Why shouldn't ARIN simply allocate resources to networks, regardless of how they operate simply based on what they need? Are we over complicating things, not only for the Registry, but for those who don't do this for a living who are struggling to understand what all this means and why? This goes back to the original PI/PA debate. There are End User networks that dwarf many ISP/LIR networks and vise versa. Why should we maintain multiple layers of requirements to justify IPv4 transfers and an exceedingly large pool of IPv6 space? -Dan From: Owen DeLong > Date: Tue, 30 Apr 2013 11:36:30 -0700 To: Microsoft Office User > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user Dan, The definitions apply to IPv6 as well. I believe they are still necessary. Owen On Apr 29, 2013, at 20:37 , "Alexander, Daniel" > wrote: Hello All, I would be curious to hear people's opinions of whether the distinctions are still necessary within ARIN policy. Once the IPv4 free pool is depleted, and the policies become focused on processing transfers, do we need to distinguish between End Users, non-End Users, and PA vs PI within ARIN policy? What are the criteria in which these distinctions matter, and will they still apply next year? Dan ARIN AC From: Scott Leibrand > Date: Mon, 29 Apr 2013 13:41:56 -0700 To: ARIN-PPML List > Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user At ARIN 31 last week, Leslie's Policy Experience Report (slides at https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf or https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx) reported that, in ARIN staff's experience, the NRPM does not adequately define ISP/LIR vs. end-user. For example, by literally applying the existing definitions as currently written, my employer would be neither an ISP nor and end-user, because while they do not *primarily* assign address space to users, neither do they *exclusively* use it in their own networks. So I think those definitions need a few tweaks. I would propose that the primary difference between ISPs/LIRs vs. end-users, for purposes of the NRPM, is whether an organization reassigns address blocks to third parties. If an organization maintains full control of all of the equipment on its network, and doesn't need to make any reassignments to other organizations, then it can qualify as an end-user. In particular, an end user organization must be able to supply a full list of all the IP addresses in use on its network, and know what devices are using those addresses. An ISP/LIR, on the other hand, should be defined by whether they delegate that responsibility to another organization. In that case, they need to reassign the network space via SWIP/rwhois, which makes them an LIR. I understand that there are other considerations, such as the expectation in the security community that addresses within an ISP allocation are generally controlled by third parties, whereas addresses in an end-user assignment are generally controlled by the end-user organization. However, I don't believe it's practical to try to draw a distinction there: rather, organizations can decide for themselves whether they need to make reassignments (for that or several other reasons), and that decision can drive whether they are considered an ISP/LIR or end-user for purposes of ARIN policy. In light of the above, I would propose the following revised definitions: 2.4. Local Internet Registry (LIR) The terms Internet Service Provider (ISP) and LIR are used interchangeably in this document. A Local Internet Registry (LIR) is an IR that assigns address space to the users of the network services that it provides. Therefore, LIRs / ISPs are organizations that reassign addresses to end users and/or reallocate addresses to other ISPs/LIRs. 2.6. End-user An end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks, and does not register any reassignments of that space. Thoughts? Should I submit this as a policy proposal? -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. _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1468 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1473 bytes Desc: image003.jpg URL: From dmiller at tiggee.com Wed Jun 4 21:26:41 2014 From: dmiller at tiggee.com (David Miller) Date: Wed, 04 Jun 2014 21:26:41 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538FC385.5030602@matthew.at> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> <538FC385.5030602@matthew.at> Message-ID: <538FC751.3020403@tiggee.com> On 6/4/2014 9:10 PM, Matthew Kaufman wrote: > > On 6/4/14, 5:13 PM, Owen DeLong wrote: >> It is, however, equally obvious that a sizable portion of the >> community, not merely myself, does not want to eliminate the needs test. > > For the extremely limited version of "the community" which consists of > "see existing policy" and "see the handful of people who participate on > the PPML". Despite all the fee collection that has been spent on > outreach, there's still just not that much representation. Which viewpoint gets to "claim" those who chose not to make their opinions known? >> Currently, there is no actual proposal on the table for loosening them >> or compromising. If there were one, I would address the merits of it >> as I saw them. > > That's fair. I'm sure one will show up. > > Matthew Kaufman -DMM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From David.Huberman at microsoft.com Wed Jun 4 21:30:38 2014 From: David.Huberman at microsoft.com (David Huberman) Date: Thu, 5 Jun 2014 01:30:38 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538FC630.9090404@velea.eu> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com>, <538FC630.9090404@velea.eu> Message-ID: <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> I agree completely, Elvis. There's an argument to be made that if ARIN won't be flexible with transfer policy, that RIPE becomes the most useful RIR for operators to work within. There's a further argument that's been made that the time for regional IRs may be passed (past?) and that IETF should review the situation. David R Huberman Microsoft Corporation Senior IT/OPS Program Manager (GFS) ________________________________________ From: arin-ppml-bounces at arin.net on behalf of Elvis Velea Sent: Wednesday, June 4, 2014 6:21:52 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers Hi David, On 05/06/14 02:21, David Huberman wrote: > We're going to be a cross-roads very soon. ARIN is going to exhaust, and network operators will be unable to obtain additional IPv4 address blocks from ARIN. At that point, the most obvious solution for IPv4 needs will be the market. And then, they will be able to register as RIPE NCC members (LIRs) and receive as many IP addresses as they want without having to prove any demonstrated need. All they will need to do is to confirm that they will use these addresses for themselves or their customers. > Proper stewardship of the ARIN function demands that ARIN policy adjust to what happens in the market. It's not the other way around, if only because that's not how markets work. > > The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, professors who study markets, brokers who operate in the market, and buyers and sellers who buy and sell in the market have all told the ARIN community the same story for around 5 years now: the market is going to act as a market, and ARIN policy needs to be ready for it; ARIN policy needs to make sense with the dynamics of the market. > > It's hard to know how to argue with operators like Owen and the Google folks who all say the opposite; that ARIN policy should stick to the same ideals as 1995 (important ideals for a very long time!) and not adjust. I fear the results of this kind of ostracism :( Well, then let them slowly kill the ARIN function. If all ARIN members can no longer get resources and they stop paying and go to the cheapest RIR (which btw is RIPE NCC with EUR1600/year no matter how many resources one has) and get as many resources they want... what do you think will happen? cheers, elvis _______________________________________________ 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 elvis at velea.eu Wed Jun 4 21:35:29 2014 From: elvis at velea.eu (Elvis Velea) Date: Thu, 05 Jun 2014 03:35:29 +0200 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com>, <538FC630.9090404@velea.eu> <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <538FC961.9090608@velea.eu> Hi David, even further... for those that do not know yet, any legal or private person can become a member of the RIPE NCC while the ARIN policies/procedures still require a company to have a legal presence in the ARIN region in order to request resources. And, btw.. have I already mentioned that the RIPE Community has completely removed the demonstrated need from their policy? I think I was only discussing this matter in the APNIC mailing lists and maybe those subscribed to this mailing list should also be aware of. cheers, elvis On 05/06/14 03:30, David Huberman wrote: > I agree completely, Elvis. There's an argument to be made that if ARIN won't be flexible with transfer policy, that RIPE becomes the most useful RIR for operators to work within. There's a further argument that's been made that the time for regional IRs may be passed (past?) and that IETF should review the situation. > > David R Huberman > Microsoft Corporation > Senior IT/OPS Program Manager (GFS) > > ________________________________________ > From: arin-ppml-bounces at arin.net on behalf of Elvis Velea > Sent: Wednesday, June 4, 2014 6:21:52 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > Hi David, > > On 05/06/14 02:21, David Huberman wrote: >> We're going to be a cross-roads very soon. ARIN is going to exhaust, and network operators will be unable to obtain additional IPv4 address blocks from ARIN. At that point, the most obvious solution for IPv4 needs will be the market. > And then, they will be able to register as RIPE NCC members (LIRs) and > receive as many IP addresses as they want without having to prove any > demonstrated need. All they will need to do is to confirm that they will > use these addresses for themselves or their customers. > >> Proper stewardship of the ARIN function demands that ARIN policy adjust to what happens in the market. It's not the other way around, if only because that's not how markets work. >> >> The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, professors who study markets, brokers who operate in the market, and buyers and sellers who buy and sell in the market have all told the ARIN community the same story for around 5 years now: the market is going to act as a market, and ARIN policy needs to be ready for it; ARIN policy needs to make sense with the dynamics of the market. >> >> It's hard to know how to argue with operators like Owen and the Google folks who all say the opposite; that ARIN policy should stick to the same ideals as 1995 (important ideals for a very long time!) and not adjust. I fear the results of this kind of ostracism :( > Well, then let them slowly kill the ARIN function. If all ARIN members > can no longer get resources and they stop paying and go to the cheapest > RIR (which btw is RIPE NCC with EUR1600/year no matter how many > resources one has) and get as many resources they want... what do you > think will happen? > > cheers, > elvis > > > _______________________________________________ > 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 John at qxccommunications.com Wed Jun 4 22:05:06 2014 From: John at qxccommunications.com (John Von Stein) Date: Thu, 5 Jun 2014 02:05:06 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538FC961.9090608@velea.eu> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com>, <538FC630.9090404@velea.eu> <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> <538FC961.9090608@velea.eu> Message-ID: Elvis, So does that mean a US based ISP such as QxC wanted / needed an additional IPv4 allocation we could simply go to RIPE and get the IPv4 we want/need? Thank you, John W. Von Stein [cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] 102 NE 2nd Street Suite 136 Boca Raton, FL 33432 Office: 561-288-6989 www.QxCcommunications.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Elvis Velea Sent: Wednesday, June 4, 2014 9:35 PM To: David Huberman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers Hi David, even further... for those that do not know yet, any legal or private person can become a member of the RIPE NCC while the ARIN policies/procedures still require a company to have a legal presence in the ARIN region in order to request resources. And, btw.. have I already mentioned that the RIPE Community has completely removed the demonstrated need from their policy? I think I was only discussing this matter in the APNIC mailing lists and maybe those subscribed to this mailing list should also be aware of. cheers, elvis On 05/06/14 03:30, David Huberman wrote: > I agree completely, Elvis. There's an argument to be made that if ARIN won't be flexible with transfer policy, that RIPE becomes the most useful RIR for operators to work within. There's a further argument that's been made that the time for regional IRs may be passed (past?) and that IETF should review the situation. > > David R Huberman > Microsoft Corporation > Senior IT/OPS Program Manager (GFS) > > ________________________________________ > From: arin-ppml-bounces at arin.net > on > behalf of Elvis Velea > > Sent: Wednesday, June 4, 2014 6:21:52 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > Hi David, > > On 05/06/14 02:21, David Huberman wrote: >> We're going to be a cross-roads very soon. ARIN is going to exhaust, and network operators will be unable to obtain additional IPv4 address blocks from ARIN. At that point, the most obvious solution for IPv4 needs will be the market. > And then, they will be able to register as RIPE NCC members (LIRs) and > receive as many IP addresses as they want without having to prove any > demonstrated need. All they will need to do is to confirm that they > will use these addresses for themselves or their customers. > >> Proper stewardship of the ARIN function demands that ARIN policy adjust to what happens in the market. It's not the other way around, if only because that's not how markets work. >> >> The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, professors who study markets, brokers who operate in the market, and buyers and sellers who buy and sell in the market have all told the ARIN community the same story for around 5 years now: the market is going to act as a market, and ARIN policy needs to be ready for it; ARIN policy needs to make sense with the dynamics of the market. >> >> It's hard to know how to argue with operators like Owen and the >> Google folks who all say the opposite; that ARIN policy should stick >> to the same ideals as 1995 (important ideals for a very long time!) >> and not adjust. I fear the results of this kind of ostracism :( > Well, then let them slowly kill the ARIN function. If all ARIN members > can no longer get resources and they stop paying and go to the > cheapest RIR (which btw is RIPE NCC with EUR1600/year no matter how > many resources one has) and get as many resources they want... what do > you think will happen? > > cheers, > elvis > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2999 bytes Desc: image001.jpg URL: From elvis at velea.eu Wed Jun 4 22:24:28 2014 From: elvis at velea.eu (Elvis Velea) Date: Thu, 05 Jun 2014 04:24:28 +0200 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com>, <538FC630.9090404@velea.eu> <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> <538FC961.9090608@velea.eu> Message-ID: <538FD4DC.5020209@velea.eu> Hi John, On 05/06/14 04:05, John Von Stein wrote: > > Elvis, > > So does that mean a US based ISP such as QxC wanted / needed an > additional IPv4 allocation we could simply go to RIPE and get the IPv4 > we want/need? > yup :) and only for EUR1600/year and with no transfer fees :) cheers, elvis > > Thank you, > > John W. Von Stein > > cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823 > > 102 NE 2^nd Street > > Suite 136 > > Boca Raton, FL 33432 > > Office: 561-288-6989 > > www.QxCcommunications.com > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of Elvis Velea > Sent: Wednesday, June 4, 2014 9:35 PM > To: David Huberman > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > Hi David, > > even further... for those that do not know yet, any legal or private > person can become a member of the RIPE NCC while the ARIN > policies/procedures still require a company to have a legal presence > in the ARIN region in order to request resources. > > And, btw.. have I already mentioned that the RIPE Community has > completely removed the demonstrated need from their policy? I think I > was only discussing this matter in the APNIC mailing lists and maybe > those subscribed to this mailing list should also be aware of. > > cheers, > > elvis > > On 05/06/14 03:30, David Huberman wrote: > > > I agree completely, Elvis. There's an argument to be made that if > ARIN won't be flexible with transfer policy, that RIPE becomes the > most useful RIR for operators to work within. There's a further > argument that's been made that the time for regional IRs may be passed > (past?) and that IETF should review the situation. > > > > > > David R Huberman > > > Microsoft Corporation > > > Senior IT/OPS Program Manager (GFS) > > > > > > ________________________________________ > > > From: arin-ppml-bounces at arin.net > > on > > > behalf of Elvis Velea > > > > Sent: Wednesday, June 4, 2014 6:21:52 PM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > > > > Hi David, > > > > > > On 05/06/14 02:21, David Huberman wrote: > > >> We're going to be a cross-roads very soon. ARIN is going to > exhaust, and network operators will be unable to obtain additional > IPv4 address blocks from ARIN. At that point, the most obvious > solution for IPv4 needs will be the market. > > > And then, they will be able to register as RIPE NCC members (LIRs) and > > > receive as many IP addresses as they want without having to prove any > > > demonstrated need. All they will need to do is to confirm that they > > > will use these addresses for themselves or their customers. > > > > > >> Proper stewardship of the ARIN function demands that ARIN policy > adjust to what happens in the market. It's not the other way around, > if only because that's not how markets work. > > >> > > >> The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN > pays, professors who study markets, brokers who operate in the market, > and buyers and sellers who buy and sell in the market have all told > the ARIN community the same story for around 5 years now: the market > is going to act as a market, and ARIN policy needs to be ready for it; > ARIN policy needs to make sense with the dynamics of the market. > > >> > > >> It's hard to know how to argue with operators like Owen and the > > >> Google folks who all say the opposite; that ARIN policy should stick > > >> to the same ideals as 1995 (important ideals for a very long time!) > > >> and not adjust. I fear the results of this kind of ostracism :( > > > Well, then let them slowly kill the ARIN function. If all ARIN members > > > can no longer get resources and they stop paying and go to the > > > cheapest RIR (which btw is RIPE NCC with EUR1600/year no matter how > > > many resources one has) and get as many resources they want... what do > > > you think will happen? > > > > > > cheers, > > > elvis > > > > > > > > > _______________________________________________ > > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2999 bytes Desc: not available URL: From cja at daydream.com Wed Jun 4 22:31:50 2014 From: cja at daydream.com (CJ Aronson) Date: Wed, 4 Jun 2014 20:31:50 -0600 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538FD4DC.5020209@velea.eu> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FC630.9090404@velea.eu> <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> <538FC961.9090608@velea.eu> <538FD4DC.5020209@velea.eu> Message-ID: Let's be clear.. the RIPE NCC will only give a one-time /22 for your 1600 Euros/year. RIPE has always made applicants prove a business presense in the region and I believe that's what the " - The name of the "Chamber of Commerce" where your company is registered - For example, Companies House, KvK etc." Is referring to. The link is here for your reference: http://www.ripe.net/lir-services/member-support/become-a-member/application You'll have to apply and see. If you want more than a /22 you'll have to go to the transfer market. ----Cathy On Wed, Jun 4, 2014 at 8:24 PM, Elvis Velea wrote: > Hi John, > > > On 05/06/14 04:05, John Von Stein wrote: > > Elvis, > > > > So does that mean a US based ISP such as QxC wanted / needed an additional > IPv4 allocation we could simply go to RIPE and get the IPv4 we want/need? > > > yup :) and only for ?1600/year and with no transfer fees :) > > cheers, > elvis > > > > Thank you, > > John W. Von Stein > > > > [image: cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] > > > > 102 NE 2nd Street > > Suite 136 > > Boca Raton, FL 33432 > > Office: 561-288-6989 > > www.QxCcommunications.com > > > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net > ] On Behalf Of Elvis Velea > Sent: Wednesday, June 4, 2014 9:35 PM > To: David Huberman > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > > Hi David, > > > > even further... for those that do not know yet, any legal or private > person can become a member of the RIPE NCC while the ARIN > policies/procedures still require a company to have a legal presence in the > ARIN region in order to request resources. > > > > And, btw.. have I already mentioned that the RIPE Community has completely > removed the demonstrated need from their policy? I think I was only > discussing this matter in the APNIC mailing lists and maybe those > subscribed to this mailing list should also be aware of. > > > > cheers, > > elvis > > > > On 05/06/14 03:30, David Huberman wrote: > > > I agree completely, Elvis. There's an argument to be made that if ARIN > won't be flexible with transfer policy, that RIPE becomes the most useful > RIR for operators to work within. There's a further argument that's been > made that the time for regional IRs may be passed (past?) and that IETF > should review the situation. > > > > > > David R Huberman > > > Microsoft Corporation > > > Senior IT/OPS Program Manager (GFS) > > > > > > ________________________________________ > > > From: arin-ppml-bounces at arin.net on > > > behalf of Elvis Velea > > > Sent: Wednesday, June 4, 2014 6:21:52 PM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > > > > Hi David, > > > > > > On 05/06/14 02:21, David Huberman wrote: > > >> We're going to be a cross-roads very soon. ARIN is going to exhaust, > and network operators will be unable to obtain additional IPv4 address > blocks from ARIN. At that point, the most obvious solution for IPv4 needs > will be the market. > > > And then, they will be able to register as RIPE NCC members (LIRs) and > > > receive as many IP addresses as they want without having to prove any > > > demonstrated need. All they will need to do is to confirm that they > > > will use these addresses for themselves or their customers. > > > > > >> Proper stewardship of the ARIN function demands that ARIN policy > adjust to what happens in the market. It's not the other way around, if > only because that's not how markets work. > > >> > > >> The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, > professors who study markets, brokers who operate in the market, and buyers > and sellers who buy and sell in the market have all told the ARIN community > the same story for around 5 years now: the market is going to act as a > market, and ARIN policy needs to be ready for it; ARIN policy needs to make > sense with the dynamics of the market. > > >> > > >> It's hard to know how to argue with operators like Owen and the > > >> Google folks who all say the opposite; that ARIN policy should stick > > >> to the same ideals as 1995 (important ideals for a very long time!) > > >> and not adjust. I fear the results of this kind of ostracism :( > > > Well, then let them slowly kill the ARIN function. If all ARIN members > > > can no longer get resources and they stop paying and go to the > > > cheapest RIR (which btw is RIPE NCC with EUR1600/year no matter how > > > many resources one has) and get as many resources they want... what do > > > you think will happen? > > > > > > cheers, > > > elvis > > > > > > > > > _______________________________________________ > > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2999 bytes Desc: not available URL: From elvis at velea.eu Wed Jun 4 22:41:41 2014 From: elvis at velea.eu (Elvis Velea) Date: Thu, 05 Jun 2014 04:41:41 +0200 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FC630.9090404@velea.eu> <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> <538FC961.9090608@velea.eu> <538FD4DC.5020209@velea.eu> Message-ID: <538FD8E5.5030608@velea.eu> Hi Cathy, On 05/06/14 04:31, CJ Aronson wrote: > Let's be clear.. the RIPE NCC will only give a one-time /22 for your > 1600 Euros/year. RIPE has always made applicants prove a business > presense in the region and I believe that's what the > " > > * > > The name of the "Chamber of Commerce" where your company is registered > > o > > For example, Companies House, KvK etc." > > Is referring to. The link is here for your reference: > http://www.ripe.net/lir-services/member-support/become-a-member/application > RIPE NCC does not require it's members to be registered in the RIPE region. You can have a look at their members list if you need proof. You will see lots of companies registered everywhere. Here is their link for companies that say they offer services in the US: https://www.ripe.net/membership/indices/US.html > You'll have to apply and see. > > If you want more than a /22 you'll have to go to the transfer market. correct.. you could contact an IPv4 Broker if you want someone specialized in the market to help you. For full disclosure, I used to work as IPRA/Hostmaster for the RIPE NCC between 2007 and 2013. I now work for V4Escrow, LLC which is a US registered company. We are a member of the RIPE NCC and APNIC and we use resources from these two regions :-) https://www.ripe.net/membership/indices/data/us.v4escrow.html cheers, elvis -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmiller at tiggee.com Wed Jun 4 22:50:45 2014 From: dmiller at tiggee.com (David Miller) Date: Wed, 04 Jun 2014 22:50:45 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <538FDB05.3070700@tiggee.com> > We're going to be a cross-roads very soon. ARIN is going to exhaust, > and network operators will be unable to obtain additional IPv4 address > blocks from ARIN. At that point, the most obvious solution for IPv4 > needs will be the market. Discounting the other obvious solutions of IPv6, IPv6, or even IPv6. :) > Proper stewardship of the ARIN function demands that ARIN policy > adjust to what happens in the market. It's not the other way around, > if only because that's not how markets work. If, and only if, one redefines ARIN's function as *only* bookkeeping. > The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, > professors who study markets, brokers who operate in the market, and > buyers and sellers who buy and sell in the market have all told the > ARIN community the same story for around 5 years now: the market is > going to act as a market, and ARIN policy needs to be ready for it; > ARIN policy needs to make sense with the dynamics of the market. In addition to internet number resources, there are also 'markets' in drugs, stolen cars, ivory, endangered species, and human slaves. The fact that a 'market' exists does not, in and of itself, imply that policies should be adjusted so that the market can function more efficiently. There seems to be a hidden assumption here that number resources with incorrect registration are "as good as" those with accurate registration, and thus all that is being requested is that the db be cleaned up. If that were actually the case, then I doubt we would be having this discussion. If there is a benefit to accurate registration through legitimization of this market on an unlimited scale, that outweighs the negative impacts of hoarding, speculation, and IPv6 denial, then I haven't seen it yet. I am, however, open to being convinced. > It's hard to know how to argue with operators like Owen and the Google > folks who all say the opposite; that ARIN policy should stick to the > same ideals as 1995 (important ideals for a very long time!) and not > adjust. > I fear the results of this kind of ostracism :( "Ostracism" would be ignoring your statements - instead of discussing them actively. -DMM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From elvis at velea.eu Wed Jun 4 22:57:10 2014 From: elvis at velea.eu (Elvis Velea) Date: Thu, 05 Jun 2014 04:57:10 +0200 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538FDB05.3070700@tiggee.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> Message-ID: <538FDC86.9070600@velea.eu> Hi David, On 05/06/14 04:50, David Miller wrote: > Proper stewardship of the ARIN function demands that ARIN policy > adjust to what happens in the market. It's not the other way around, > if only because that's not how markets work. > If, and only if, one redefines ARIN's function as *only* bookkeeping. Once ARIN runs out of IPv4, it's only function in IPv4 will be the bookkeeping. > >> The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, >> professors who study markets, brokers who operate in the market, and >> buyers and sellers who buy and sell in the market have all told the >> ARIN community the same story for around 5 years now: the market is >> going to act as a market, and ARIN policy needs to be ready for it; >> ARIN policy needs to make sense with the dynamics of the market. > In addition to internet number resources, there are also 'markets' in > drugs, stolen cars, ivory, endangered species, and human slaves. Still, ARIN, like APNIC and the RIPE NCC, recognize the IPv4 Brokers and even provides a Listing service. You can not compare the IPv4 market to the 'human slaves market'. One is legal, the other one is not. > > The fact that a 'market' exists does not, in and of itself, imply that > policies should be adjusted so that the market can function more > efficiently. > > There seems to be a hidden assumption here that number resources with > incorrect registration are "as good as" those with accurate > registration, and thus all that is being requested is that the db be > cleaned up. If that were actually the case, then I doubt we would be > having this discussion. My router will not care if the database registration is accurate. > > If there is a benefit to accurate registration through legitimization of > this market on an unlimited scale, that outweighs the negative impacts > of hoarding, speculation, and IPv6 denial, then I haven't seen it yet. > I am, however, open to being convinced. The market is already legitimized. Check the RIR websites and their links to the market and the recognized IPv4 Brokers. cheers, elvis > -DMM > > > _______________________________________________ > 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 dmiller at tiggee.com Wed Jun 4 22:59:53 2014 From: dmiller at tiggee.com (David Miller) Date: Wed, 04 Jun 2014 22:59:53 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538FD8E5.5030608@velea.eu> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FC630.9090404@velea.eu> <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> <538FC961.9090608@velea.eu> <538FD4DC.5020209@velea.eu> <538FD8E5.5030608@velea.eu> Message-ID: <538FDD29.8060709@tiggee.com> On 6/4/2014 10:41 PM, Elvis Velea wrote: > Hi Cathy, > > On 05/06/14 04:31, CJ Aronson wrote: >> Let's be clear.. the RIPE NCC will only give a one-time /22 for your >> 1600 Euros/year. RIPE has always made applicants prove a business >> presense in the region and I believe that's what the >> " >> >> * >> >> The name of the "Chamber of Commerce" where your company is registered >> >> o >> >> For example, Companies House, KvK etc." >> >> Is referring to. The link is here for your reference: >> http://www.ripe.net/lir-services/member-support/become-a-member/application >> > RIPE NCC does not require it's members to be registered in the RIPE > region. You can have a look at their members list if you need proof. You > will see lots of companies registered everywhere. Here is their link for > companies that say they offer services in the US: > > https://www.ripe.net/membership/indices/US.html On that list you will find my company. To get our allocation from RIPE we had to demonstrate a presence in the EU and assert that those resources allocated to us from RIPE would only be used within the RIPE region. Note the text "" (and other more specific EU regions). >> You'll have to apply and see. >> >> If you want more than a /22 you'll have to go to the transfer market. > correct.. you could contact an IPv4 Broker if you want someone > specialized in the market to help you. > > For full disclosure, I used to work as IPRA/Hostmaster for the RIPE NCC > between 2007 and 2013. > I now work for V4Escrow, LLC which is a US registered company. We are a > member of the RIPE NCC and APNIC and we use resources from these two > regions :-) > https://www.ripe.net/membership/indices/data/us.v4escrow.html > > cheers, > elvis -DMM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From elvis at velea.eu Wed Jun 4 23:07:21 2014 From: elvis at velea.eu (Elvis Velea) Date: Thu, 05 Jun 2014 05:07:21 +0200 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538FDD29.8060709@tiggee.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FC630.9090404@velea.eu> <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> <538FC961.9090608@velea.eu> <538FD4DC.5020209@velea.eu> <538FD8E5.5030608@velea.eu> <538FDD29.8060709@tiggee.com> Message-ID: <538FDEE9.7000402@velea.eu> Hi David, On 05/06/14 04:59, David Miller wrote: > > On 6/4/2014 10:41 PM, Elvis Velea wrote: >> Hi Cathy, >> >> On 05/06/14 04:31, CJ Aronson wrote: >>> Let's be clear.. the RIPE NCC will only give a one-time /22 for your >>> 1600 Euros/year. RIPE has always made applicants prove a business >>> presense in the region and I believe that's what the >>> " >>> >>> * >>> >>> The name of the "Chamber of Commerce" where your company is registered >>> >>> o >>> >>> For example, Companies House, KvK etc." >>> >>> Is referring to. The link is here for your reference: >>> http://www.ripe.net/lir-services/member-support/become-a-member/application >>> >> RIPE NCC does not require it's members to be registered in the RIPE >> region. You can have a look at their members list if you need proof. You >> will see lots of companies registered everywhere. Here is their link for >> companies that say they offer services in the US: >> >> https://www.ripe.net/membership/indices/US.html > On that list you will find my company. To get our allocation from RIPE > we had to demonstrate a presence in the EU how did you demonstrate the presence in the EU? > and assert that those > resources allocated to us from RIPE would only be used within the > RIPE region. Note the text "" (and other more > specific EU regions). only is the wrong word. RIPE NCC does not require the IPs it allocates to be used *only* in the region. I would, instead, use the word *some*. Some of the IPs may need to be used within the RIPE region. I can have a router and a few devices collocated in an IX in Europe and would still qualify to receive IP addresses from the RIPE NCC. Once a member, what is stopping me from receiving a transfer? cheers, elvis From dmiller at tiggee.com Wed Jun 4 23:37:05 2014 From: dmiller at tiggee.com (David Miller) Date: Wed, 04 Jun 2014 23:37:05 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538FDC86.9070600@velea.eu> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> Message-ID: <538FE5E1.3010105@tiggee.com> On 6/4/2014 10:57 PM, Elvis Velea wrote: > Hi David, > > On 05/06/14 04:50, David Miller wrote: >> Proper stewardship of the ARIN function demands that ARIN policy >> adjust to what happens in the market. It's not the other way around, >> if only because that's not how markets work. >> If, and only if, one redefines ARIN's function as *only* bookkeeping. > Once ARIN runs out of IPv4, it's only function in IPv4 will be the > bookkeeping. Not if a needs basis remains for transfers. >> >>> The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, >>> professors who study markets, brokers who operate in the market, and >>> buyers and sellers who buy and sell in the market have all told the >>> ARIN community the same story for around 5 years now: the market is >>> going to act as a market, and ARIN policy needs to be ready for it; >>> ARIN policy needs to make sense with the dynamics of the market. >> In addition to internet number resources, there are also 'markets' in >> drugs, stolen cars, ivory, endangered species, and human slaves. > Still, ARIN, like APNIC and the RIPE NCC, recognize the IPv4 Brokers and > even provides a Listing service. > > You can not compare the IPv4 market to the 'human slaves market'. One is > legal, the other one is not. I did not "compare" the two markets. I simply stated that they are both markets. All of the experts cited above will agree that they are both markets. >> >> The fact that a 'market' exists does not, in and of itself, imply that >> policies should be adjusted so that the market can function more >> efficiently. >> >> There seems to be a hidden assumption here that number resources with >> incorrect registration are "as good as" those with accurate >> registration, and thus all that is being requested is that the db be >> cleaned up. If that were actually the case, then I doubt we would be >> having this discussion. > My router will not care if the database registration is accurate. I know the value to me of the addresses you are using being registered to you. If the registration of the addresses you use is unimportant (and it appears that is the case you are making), then why do you care? I suspect it is because your upstreams almost certainly will care if you are trying to announce prefixes that do not appear to be allocated to you. Also, your customers will probably care if you are assigning them IP addresses that don't appear to be allocated to you. ...and so on... >> >> If there is a benefit to accurate registration through legitimization of >> this market on an unlimited scale, that outweighs the negative impacts >> of hoarding, speculation, and IPv6 denial, then I haven't seen it yet. >> I am, however, open to being convinced. > The market is already legitimized. Check the RIR websites and their > links to the market and the recognized IPv4 Brokers. The full phrase I used was "legitimization of this market on an unlimited scale" and it was intentional. > cheers, > elvis > >> -DMM -DMM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From woody at pch.net Wed Jun 4 23:58:01 2014 From: woody at pch.net (Bill Woodcock) Date: Wed, 4 Jun 2014 20:58:01 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538FE5E1.3010105@tiggee.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> Message-ID: <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> >>> The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, >>> professors who study markets, brokers who operate in the market, and >>> buyers and sellers who buy and sell in the market have all told the >>> ARIN community the same story for around 5 years now: the market is >>> going to act as a market, and ARIN policy needs to be ready for it; >>> ARIN policy needs to make sense with the dynamics of the market. >> In addition to internet number resources, there are also 'markets' in >> drugs, stolen cars, ivory, endangered species, and human slaves. > You can not compare the IPv4 market to the 'human slaves market'. One is > legal, the other one is not. You're making your opponent?s point for him. Which is easy to do, since it?s correct. The difference between a legal market and an illegal market is not that one is a market and the other is not, nor that one is natural and the other unnatural; it?s that society has deemed one to be in the common good and the other detrimental. One of ARIN?s key functions is to enable private-sector self-regulation of detrimental behaviors within the Internet number space in the ARIN region, so that legislators won?t see a need to step in and do a half-assed job of it for us. In order to do that, we need to behave like adults. We need to uphold our stated goals of stewardship and conservation and we need to ensure the rights of the minority and new-market-entrants. Your argument that ARIN needs to step out of the way of the human slaves market, recognize its validity, and duly record the transfers of those slaves, because Ayn Rand, is idiotic. And if you think that?s not what you just said, you need to step back and reflect a little before touching your keyboard. We self-regulate, rather than wallowing in the trough of self-indulgence, because we are (speaking collectively and aspirationally, at least) adults. As such, we don?t want our power to self-regulate removed. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From owen at delong.com Thu Jun 5 03:32:14 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jun 2014 00:32:14 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <068283D4AA6C4261B83F7A9AF337737F@ncsscfoipoxes4> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <7BA05D8710DA46C4ACF2B8F7F2C95DFE@MPC> <6C8203F0-AB62-41EF-91B1-736336B82A20@delong.com> <068283D4AA6C4261B83F7A9AF337737F@ncsscfoipoxes4> Message-ID: On Jun 4, 2014, at 5:41 PM, Mike Burns wrote: > >> And secondarily, what size of un-needs tested transfer would be an acceptable balance between the benefits of the needs test and the costs of the needs test? > > /24 seems like a perfectly reasonable balancing point to me. I?d be willing to conduct an experiment on a temporary basis at /20 for a limited time (12 months). > > Owen > > > Hi Owen, > > I understand your position and belief that the needs test serves to preserve space for those with a legitimate and quasi-immediate need, but in my experience there is plenty of supply in the transfer market currently, and in any case we are talking about relatively small amounts which can be sequestered without the demonstration of need. > > Thus I don't think the removal of a needs test for transfers smaller than a /16 will have any measurable effect on the ability to find space on the transfer market at current price levels. So you have repeatedly said. We can agree to disagree. > Thanks for offering your input to my second question. A /20 is an interesting choice because it appears in policy as the minimum size for some allocations and requestors who fail to meet that threshold are some of the corner cases which would be helped by the potential for a needs-free transfer. I thought it was a reasonable compromise between the status quo and the proposed /16. It?s literally meeting half-way. For some reason, those on the other side mostly want to call that ?standing in the way of progress? and/or ?refusing to compromise?. Personally, I wish we could take the emotion out of the discussion and argue the merits. Owen From owen at delong.com Thu Jun 5 03:33:19 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jun 2014 00:33:19 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <3aed59f33f4d4ce38cbdf87f52588c66@DM2PR03MB398.namprd03.prod.outlook.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <3aed59f33f4d4ce38cbdf87f52588c66@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: No harm, no foul, but I appreciate and accept your apology. I know we?re both trying to do what we think is right for the community. Owen On Jun 4, 2014, at 5:42 PM, David Huberman wrote: > And I'd like to follow-up my own post with a "my fault"/"I'm sorry" for directly calling out Owen in my email. Owen is doing what so many others aren't: he's actively participating. He and I are on opposite sides here, so it sometimes feel antagonistic when it isn't. Sorry, Owen, for calling you out by name. That was wrong of me. > > David R Huberman > Microsoft Corporation > Senior IT/OPS Program Manager (GFS) > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman > Sent: Wednesday, June 4, 2014 5:21 PM > To: ppml at rsuc.gweep.net; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > We're going to be a cross-roads very soon. ARIN is going to exhaust, and network operators will be unable to obtain additional IPv4 address blocks from ARIN. At that point, the most obvious solution for IPv4 needs will be the market. Proper stewardship of the ARIN function demands that ARIN policy adjust to what happens in the market. It's not the other way around, if only because that's not how markets work. > > The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, professors who study markets, brokers who operate in the market, and buyers and sellers who buy and sell in the market have all told the ARIN community the same story for around 5 years now: the market is going to act as a market, and ARIN policy needs to be ready for it; ARIN policy needs to make sense with the dynamics of the market. > > It's hard to know how to argue with operators like Owen and the Google folks who all say the opposite; that ARIN policy should stick to the same ideals as 1995 (important ideals for a very long time!) and not adjust. I fear the results of this kind of ostracism :( > > David R Huberman > Microsoft Corporation > Senior IT/OPS Program Manager (GFS) > _______________________________________________ > 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 Thu Jun 5 03:38:30 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jun 2014 00:38:30 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD5AC8@ENI-MAIL.eclipse-networks.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.809080 6@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD5AC8@ENI-MAIL.eclipse-networks.com> Message-ID: There isn?t. But like many things in the world, sometimes it?s just easier to hire a professional. I know many small organizations that have read the NRPM and applied successfully for various size allocations and/or assignments. Your statement, to me, sounds like ?If you need to hire a lawyer to form your corporation, then something is very wrong with the law? or ?If you need to hire a mechanic to fix your car, then something is very wrong with the design of your car.? As a general rule, virtually anything you do in business can be done by amateurs, but is usually faster and easier if you involve professionals. Owen On Jun 4, 2014, at 6:01 PM, Steven Ryerse wrote: > No offense, but there should not be a need for any organization to have to hire a consult to try and get the Minimum size allocation. If you need a consultant for that then something is very wrong with the policies! > > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > www.eclipse-networks.com > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, June 04, 2014 8:14 PM > To: Steven Ryerse > Cc: Matthew Kaufman; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > On Jun 4, 2014, at 4:50 PM, Steven Ryerse wrote: > >> There are several folks (like me) who want to ditch the needs test and there are several folks who don't want to ditch them. I take it your position is that the folks who want to keep needs tests should somehow prevail in this argument without much or any change, and those of us who wish to ditch them should just accept the status quo with needs tests. In other words you win and we lose! > > Not necessarily. I?m open for a good debate of the issue on the merits of the proposal. I?ve attempted to stick to that. > >> I saw a lot of folks comment here recently who want to at least loosen needs tests on the smaller block sizes, many many more than I've ever seen before. Since it is obvious a sizable portion of this community desires a change toward loosening policies, why is it that you persist in standing in the way of compromise? > > I have not stood in the way of compromise and could not do so even if I wanted to. I am only one of 15 votes on the AC. You only need ten of them to get a policy proposal sent to the board. It is, however, equally obvious that a sizable portion of the community, not merely myself, does not want to eliminate the needs test. Currently, there is no actual proposal on the table for loosening them or compromising. If there were one, I would address the merits of it as I saw them. > >> There comes a time when fair is fair - and small organizations are routinely discriminated against because of our small size and not so deep pockets. There is a lot of anger out there over the unfairness of these existing policies. It should be just as easy for us to get resources as it was for T-Mobile and others. I call on all members of this community to at least come to a compromise. After all the world hasn't ended for RIPE with their changes - and it won't end here either if fairness is put back into the policies so that small organizations can get the resources they need too! > > Given the number of sole-proprietors with very small budgets that I have obtained IP allocations for over the past several years, I think this is an inaccurate characterization of the facts at hand. Indeed, if you look at my posting history and my voting history throughout my tenure on the AC, you will find that I am one of the biggest advocates that the small organization could find. > > It is just as easy (if not easier) for small organizations to get resources as large ones. (I know this full well because I have applied for resources for virtually every size category in the ARIN fee table). > > If you are having trouble with a particular application, feel free to contact me off-line with the details. I may be able to help you navigate the ARIN process more effectively. We have, by the way, been making steady progress on loosening the restrictions on needs basis. There used to be no ability to get anything smaller than a /20 from ARIN for conventional uses at one time. Today, that?s down to a /24 and there is progress being made on making that possible without multihoming. > > Owen > From owen at delong.com Thu Jun 5 03:42:18 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jun 2014 00:42:18 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538FC2D8.8020207@matthew.at> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <538FC2D8.8020207@matthew.at> Message-ID: <1E5080BB-1E38-4F9C-BDFA-7D957D49E83B@delong.com> On Jun 4, 2014, at 6:07 PM, Matthew Kaufman wrote: > > On 6/4/14, 4:25 PM, Owen DeLong wrote: >>> Matthew Kaufman >>> >>> ps. I'd also note that "policy that expresses the general intent of the community" may in fact *be* policy that lets post-runout transfers be performed without a needs test, as "the community" consists of a lot more than "Owen?. >> Indeed, it does. However, many people have also repeatedly stood up in defense of needs basis, so singling me out as if I am the lone supporter of preserving needs basis is as specious as many of your other arguments. >> > > Wasn't to single you out, but was meant to call attention to an argument that says "in addition to it being how I feel, that's what the community wants [as proven by the existence of current policy]" But we should be clear... the policy as written in the PPML today may or may not be "policy that expresses the general intent of the community?. Funny, I don?t remember making that argument. Yes, I said ?that?s what the community wants?, but I never said ?as proven by the existence of current policy?. What I will say is that the combination of the current policy and the community response each and every time this has been regurgitated in yet another policy proposal since 8.3 was first put in place seems to reflect an intent by the community to preserve the needs test in policy in some form at least pretty close to what it is today. > In fact, I would argue that it isn't. > > For starters, most of "the community" isn't participating in the PDP at all. Because most of the community is tired of repeating the same debate about the same proposal under a different title over and over again. > And secondly, for a policy that the community likes, we sure have a lot of fairly significant changes queued up. Almost all of which were submitted by a single individual. > In summary, I don't think it is appropriate to back up any argument for or against a policy change with "but that's what the current policy says, therefore everyone else already agrees with me?. Which is not at all what I did. It?s also not appropriate to put words in my mouth. Owen From owen at delong.com Thu Jun 5 03:46:01 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jun 2014 00:46:01 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538FC507.4040304@velea.eu> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> <538FC385.5030602@matthew.at> <538FC507.4040304@velea.eu> Message-ID: On Jun 4, 2014, at 6:16 PM, Elvis Velea wrote: > Hi, > > On 05/06/14 03:10, Matthew Kaufman wrote: >> >> On 6/4/14, 5:13 PM, Owen DeLong wrote: >>> It is, however, equally obvious that a sizable portion of the community, not merely myself, does not want to eliminate the needs test. >> >> For the extremely limited version of "the community" which consists of "see existing policy" and "see the handful of people who participate on the PPML". Despite all the fee collection that has been spent on outreach, there's still just not that much representation. >> >>> Currently, there is no actual proposal on the table for loosening them or compromising. If there were one, I would address the merits of it as I saw them. >> >> That's fair. I'm sure one will show up. > > What about ARIN-2014-14? > > https://www.arin.net/policy/proposals/2014_14.html Yes, I have responded to that one with the suggestion of a test at /20 for a limited time as a reasonable compromise. Once we learn whether that does indeed improve whois accuracy or not, whether ti does provide improvement or not and what harm it does, we are in a better position to evaluate further changes to the needs test. Opening the floodgates all the way to /16 to start with is still a really bad idea, IMHO. Owen From owen at delong.com Thu Jun 5 03:49:53 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jun 2014 00:49:53 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538FC751.3020403@tiggee.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> <538FC385.5030602@matthew.at> <538FC751.3020403@tiggee.com> Message-ID: <4B16BA6B-628B-4D92-ACB6-16271F0A1511@delong.com> On Jun 4, 2014, at 6:26 PM, David Miller wrote: > > > On 6/4/2014 9:10 PM, Matthew Kaufman wrote: >> >> On 6/4/14, 5:13 PM, Owen DeLong wrote: >>> It is, however, equally obvious that a sizable portion of the >>> community, not merely myself, does not want to eliminate the needs test. >> >> For the extremely limited version of "the community" which consists of >> "see existing policy" and "see the handful of people who participate on >> the PPML". Despite all the fee collection that has been spent on >> outreach, there's still just not that much representation. > > Which viewpoint gets to "claim" those who chose not to make their > opinions known? I would say neither as a general rule. However, there is a valid argument for the concept of acquiescence by estoppel (silence is consent) which would argue that those who oppose current policy would be more likely to speak up. Owen From owen at delong.com Thu Jun 5 04:32:40 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jun 2014 01:32:40 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <538FDC86.9070600@velea.eu> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> Message-ID: On Jun 4, 2014, at 7:57 PM, Elvis Velea wrote: > Hi David, > > On 05/06/14 04:50, David Miller wrote: >> Proper stewardship of the ARIN function demands that ARIN policy >> adjust to what happens in the market. It's not the other way around, >> if only because that's not how markets work. >> If, and only if, one redefines ARIN's function as *only* bookkeeping. > Once ARIN runs out of IPv4, it's only function in IPv4 will be the bookkeeping. I realize that is what the brokers want, but that is not necessarily the case. It is up to the community to decide whether we want to preserve a policy role or simply become book-keepers. >>> The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, >>> professors who study markets, brokers who operate in the market, and >>> buyers and sellers who buy and sell in the market have all told the >>> ARIN community the same story for around 5 years now: the market is >>> going to act as a market, and ARIN policy needs to be ready for it; >>> ARIN policy needs to make sense with the dynamics of the market. >> In addition to internet number resources, there are also 'markets' in >> drugs, stolen cars, ivory, endangered species, and human slaves. > Still, ARIN, like APNIC and the RIPE NCC, recognize the IPv4 Brokers and even provides a Listing service. > > You can not compare the IPv4 market to the 'human slaves market'. One is legal, the other one is not. OK, so compare it to the drug market. Some drug sales are legal and some are not. >> The fact that a 'market' exists does not, in and of itself, imply that >> policies should be adjusted so that the market can function more >> efficiently. >> >> There seems to be a hidden assumption here that number resources with >> incorrect registration are "as good as" those with accurate >> registration, and thus all that is being requested is that the db be >> cleaned up. If that were actually the case, then I doubt we would be >> having this discussion. > My router will not care if the database registration is accurate. Perhaps, perhaps not. This depends in part on the implementation of RPKI and in part on whether the people configuring your router choose to continue to operate on a cooperative internet in compliance with the system for maintaining uniqueness as it exists. If that cooperation breaks down, it leads to very interesting times for the IPv4 internet. If that system is preserved and router operators continue to operate in a cooperating fashion, then it leads to greater stability and a more functional internet. >> If there is a benefit to accurate registration through legitimization of >> this market on an unlimited scale, that outweighs the negative impacts >> of hoarding, speculation, and IPv6 denial, then I haven't seen it yet. >> I am, however, open to being convinced. > The market is already legitimized. Check the RIR websites and their links to the market and the recognized IPv4 Brokers. You are ignoring the last 3/4 of his statement and it discredits your argument. Nobody is arguing against the legitimacy of the market at this point. What is being argued is whether we want the wild west of a completely unregulated market or whether the application of policy to govern the market according to the consensus of the community is preferred. Owen From matthew at matthew.at Thu Jun 5 07:01:43 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 05 Jun 2014 14:01:43 +0300 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <1E5080BB-1E38-4F9C-BDFA-7D957D49E83B@delong.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <538FC2D8.8020207@matthew.at> <1E5080BB-1E38-4F9C-BDFA-7D957D49E83B@delong.com> Message-ID: <53904E17.9000008@matthew.at> On 6/5/2014 10:42 AM, Owen DeLong wrote: > On Jun 4, 2014, at 6:07 PM, Matthew Kaufman wrote: > >> On 6/4/14, 4:25 PM, Owen DeLong wrote: >>>> Matthew Kaufman >>>> >>>> ps. I'd also note that "policy that expresses the general intent of the community" may in fact *be* policy that lets post-runout transfers be performed without a needs test, as "the community" consists of a lot more than "Owen?. >>> Indeed, it does. However, many people have also repeatedly stood up in defense of needs basis, so singling me out as if I am the lone supporter of preserving needs basis is as specious as many of your other arguments. >>> >> Wasn't to single you out, but was meant to call attention to an argument that says "in addition to it being how I feel, that's what the community wants [as proven by the existence of current policy]" But we should be clear... the policy as written in the PPML today may or may not be "policy that expresses the general intent of the community?. > Funny, I don?t remember making that argument. Yes, I said ?that?s what the community wants?, but I never said ?as proven by the existence of current policy?. What I will say is that the combination of the current policy and the community response each and every time this has been regurgitated in yet another policy proposal since 8.3 was first put in place seems to reflect an intent by the community to preserve the needs test in policy in some form at least pretty close to what it is today. And until ARIN actually runs out of IPv4, we're going to see the needs test analyzed in the context of ARIN still having IPv4. No surprise that the arguments haven't changed. > >> In fact, I would argue that it isn't. >> >> For starters, most of "the community" isn't participating in the PDP at all. > Because most of the community is tired of repeating the same debate about the same proposal under a different title over and over again. Most of the community who is actually on this list, perhaps. But I was speaking of a much much larger community. IPv4 users >> IPv4 holders >> PPML subscribers >> PPML posters. > >> And secondly, for a policy that the community likes, we sure have a lot of fairly significant changes queued up. > Almost all of which were submitted by a single individual. > >> In summary, I don't think it is appropriate to back up any argument for or against a policy change with "but that's what the current policy says, therefore everyone else already agrees with me?. > Which is not at all what I did. It?s also not appropriate to put words in my mouth. Sorry if that's how you believe that was interpreted. At least we all have hardened positions and well-practiced arguments and are starting to offend one another regularly now. Good to have that all out of the way before run-out actually occurs. Matthew Kaufman From owen at delong.com Thu Jun 5 07:32:54 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jun 2014 12:32:54 +0100 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <53904E17.9000008@matthew.at> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <538FC2D8.8020207@matthew.at> <1E5080BB-1E38-4F9C-BDFA-7D957D49E83B@delong.com> <53904E17.9000008@matthew.at> Message-ID: >> Funny, I don?t remember making that argument. Yes, I said ?that?s what the community wants?, but I never said ?as proven by the existence of current policy?. What I will say is that the combination of the current policy and the community response each and every time this has been regurgitated in yet another policy proposal since 8.3 was first put in place seems to reflect an intent by the community to preserve the needs test in policy in some form at least pretty close to what it is today. > > And until ARIN actually runs out of IPv4, we're going to see the needs test analyzed in the context of ARIN still having IPv4. No surprise that the arguments haven't changed. Personally, I don't believe that IPv4 runout changes the need for policy that attempts to preserve fairness in how addresses are (re)distributed. I realize and respect that you disagree with this. However, my analysis of the continued need for this policy is not based on the context of ARIN still having IPv4. Obviously I can't authoritatively comment on anyone else's perspective and neither can you. >>> In fact, I would argue that it isn't. >>> >>> For starters, most of "the community" isn't participating in the PDP at all. >> Because most of the community is tired of repeating the same debate about the same proposal under a different title over and over again. > > Most of the community who is actually on this list, perhaps. But I was speaking of a much much larger community. IPv4 users >> IPv4 holders >> PPML subscribers >> PPML posters. Fair enough, but as in any policy process, at the end of the day, decisions are made by those who show up. Anyone with an Email address (which I would argue is potentially > IPv4 users as it could include IPv6-only users and users of other networks) can participate in the policy process if they choose to. Attempting to make an argument based on your position being supposedly supported by anonymous masses who have not chosen to participate in the process is fallacious at best and I do not find it convincing or give it any weight. >>> And secondly, for a policy that the community likes, we sure have a lot of fairly significant changes queued up. >> Almost all of which were submitted by a single individual. >> >>> In summary, I don't think it is appropriate to back up any argument for or against a policy change with "but that's what the current policy says, therefore everyone else already agrees with me?. >> Which is not at all what I did. It?s also not appropriate to put words in my mouth. > > Sorry if that's how you believe that was interpreted. When you claimed that I said "...because current policy...", that's exactly what you did because I never made that argument. The argument I made was that each and every time this has been discussed in the last 5 years (and there have been many such events), the community has overwhelmingly expressed support for needs basis being preserved. > At least we all have hardened positions and well-practiced arguments and are starting to offend one another regularly now. Good to have that all out of the way before run-out actually occurs. Meh... I don't consider my position particularly hardened. If a compelling argument to the contrary is presented, I am willing to change my position. So far, none of the arguments presented has been compelling or even new compared to the same ones that have lost each and every time they were presented over the last five years. Sorry if I offended you. That was not my intent. I don't consider this personal. Owen From cja at daydream.com Thu Jun 5 08:23:00 2014 From: cja at daydream.com (CJ Aronson) Date: Thu, 5 Jun 2014 06:23:00 -0600 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FC630.9090404@velea.eu> <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> <538FC961.9090608@velea.eu> <538FD4DC.5020209@velea.eu> Message-ID: I asked a colleague at the RIPE NCC regarding this question of getting address space from RIPE. She said, "We accept organisations that are incorporated in other regions as members. But we require that the address space we allocate will be used/announced in the RIPE NCC service region." ----Cathy On Wed, Jun 4, 2014 at 8:31 PM, CJ Aronson wrote: > Let's be clear.. the RIPE NCC will only give a one-time /22 for your 1600 > Euros/year. RIPE has always made applicants prove a business presense in > the region and I believe that's what the > " > > - > > The name of the "Chamber of Commerce" where your company is registered > - > > For example, Companies House, KvK etc." > > Is referring to. The link is here for your reference: > http://www.ripe.net/lir-services/member-support/become-a-member/application > > You'll have to apply and see. > > If you want more than a /22 you'll have to go to the transfer market. > > ----Cathy > > > On Wed, Jun 4, 2014 at 8:24 PM, Elvis Velea wrote: > >> Hi John, >> >> >> On 05/06/14 04:05, John Von Stein wrote: >> >> Elvis, >> >> >> >> So does that mean a US based ISP such as QxC wanted / needed an >> additional IPv4 allocation we could simply go to RIPE and get the IPv4 we >> want/need? >> >> >> yup :) and only for ?1600/year and with no transfer fees :) >> >> cheers, >> elvis >> >> >> >> Thank you, >> >> John W. Von Stein >> >> >> >> [image: cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] >> >> >> >> 102 NE 2nd Street >> >> Suite 136 >> >> Boca Raton, FL 33432 >> >> Office: 561-288-6989 >> >> www.QxCcommunications.com >> >> >> >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they are >> addressed. >> >> >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net >> ] On Behalf Of Elvis Velea >> Sent: Wednesday, June 4, 2014 9:35 PM >> To: David Huberman >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] About needs basis in 8.3 transfers >> >> >> >> Hi David, >> >> >> >> even further... for those that do not know yet, any legal or private >> person can become a member of the RIPE NCC while the ARIN >> policies/procedures still require a company to have a legal presence in the >> ARIN region in order to request resources. >> >> >> >> And, btw.. have I already mentioned that the RIPE Community has >> completely removed the demonstrated need from their policy? I think I was >> only discussing this matter in the APNIC mailing lists and maybe those >> subscribed to this mailing list should also be aware of. >> >> >> >> cheers, >> >> elvis >> >> >> >> On 05/06/14 03:30, David Huberman wrote: >> >> > I agree completely, Elvis. There's an argument to be made that if ARIN >> won't be flexible with transfer policy, that RIPE becomes the most useful >> RIR for operators to work within. There's a further argument that's been >> made that the time for regional IRs may be passed (past?) and that IETF >> should review the situation. >> >> > >> >> > David R Huberman >> >> > Microsoft Corporation >> >> > Senior IT/OPS Program Manager (GFS) >> >> > >> >> > ________________________________________ >> >> > From: arin-ppml-bounces at arin.net on >> >> > behalf of Elvis Velea >> >> > Sent: Wednesday, June 4, 2014 6:21:52 PM >> >> > To: arin-ppml at arin.net >> >> > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers >> >> > >> >> > Hi David, >> >> > >> >> > On 05/06/14 02:21, David Huberman wrote: >> >> >> We're going to be a cross-roads very soon. ARIN is going to exhaust, >> and network operators will be unable to obtain additional IPv4 address >> blocks from ARIN. At that point, the most obvious solution for IPv4 needs >> will be the market. >> >> > And then, they will be able to register as RIPE NCC members (LIRs) and >> >> > receive as many IP addresses as they want without having to prove any >> >> > demonstrated need. All they will need to do is to confirm that they >> >> > will use these addresses for themselves or their customers. >> >> > >> >> >> Proper stewardship of the ARIN function demands that ARIN policy >> adjust to what happens in the market. It's not the other way around, if >> only because that's not how markets work. >> >> >> >> >> >> The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN pays, >> professors who study markets, brokers who operate in the market, and buyers >> and sellers who buy and sell in the market have all told the ARIN community >> the same story for around 5 years now: the market is going to act as a >> market, and ARIN policy needs to be ready for it; ARIN policy needs to make >> sense with the dynamics of the market. >> >> >> >> >> >> It's hard to know how to argue with operators like Owen and the >> >> >> Google folks who all say the opposite; that ARIN policy should stick >> >> >> to the same ideals as 1995 (important ideals for a very long time!) >> >> >> and not adjust. I fear the results of this kind of ostracism :( >> >> > Well, then let them slowly kill the ARIN function. If all ARIN members >> >> > can no longer get resources and they stop paying and go to the >> >> > cheapest RIR (which btw is RIPE NCC with EUR1600/year no matter how >> >> > many resources one has) and get as many resources they want... what do >> >> > you think will happen? >> >> > >> >> > cheers, >> >> > elvis >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2999 bytes Desc: not available URL: From mike at iptrading.com Thu Jun 5 08:26:30 2014 From: mike at iptrading.com (Mike Burns) Date: Thu, 5 Jun 2014 08:26:30 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com><538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> Message-ID: David said: The full phrase I used was "legitimization of this market on an unlimited scale" and it was intentional. "unlimited" as intentionally used, then, is a straw man argument in the context of 2014-14. https://www.arin.net/policy/proposals/2014_14.html Which to be fair to David, his comment did not appear in this context, but 2014-4 was the genesis for this discussion. 2014-14 does not open an unlimited market and so David'so other references towards speculation and hoarding which may apply to an unlimited market do not apply to 2014-14. Regards, Mike Burns From elvis at velea.eu Thu Jun 5 09:12:18 2014 From: elvis at velea.eu (Elvis Velea) Date: Thu, 05 Jun 2014 15:12:18 +0200 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FC630.9090404@velea.eu> <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> <538FC961.9090608@velea.eu> <538FD4DC.5020209@velea.eu> Message-ID: <53906CB2.7020905@velea.eu> Hi Cathy, how can one verify where address space is used? Do you verify the AS announcing it, and what if that AS is globally routed and it peers with various organisations within several service regions? Do you ping the address to see how long it takes for the Pong to come back to you? These RIR bordes are artificial and have nothing to do with operational reality. One can route the address space it gets from/to anywhere in the world, especially if it has a Tier1/2 provider which offers global services. There has been a simple workaround available for years. Have a look at the RIPE Database split files and see how many inetnums have country code US. You will be surprised :) You can always announce a /16 in the RIPE region and two /17s in the ARIN region and then the 'requirement' of having the space announced in the RIPE region is satisfied, right? It's just that all the traffic will flow to the router announcing the two /17s. Plus, the RIPE NCC allocates only a /22 from the last /8. So, if you become a member and have a router somewhere in Europe where you will need to use at least a few addresses and therefore you qualify to receive the /22. RIPE NCC will not complain if the /24 used for that router/equipment is announced in the RIPE region and the rest in an other region where you may have other equipment and/or customers. Additionally, once you are a member and request a transfer, the only thing you need to fill in is the transfer agreement template and confirm that you are requesting the transfer in order to make assignments from the allocation. It does not matter to whom you make those assignments or where these will be used. http://www.ripe.net/lir-services/resource-management/ipv4-transfers/transfer-agreement-template Lastly, the RIPE NCC SSA (the contract) does not say anything about where the resources can be used and the _current policies_ are at best *vague*. For example, the RIPE IPv4 policy says: "1.0 Introduction The RIPE NCC is an independent association and serves as one of five Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia. The RIPE NCC is responsible for the allocation and assignment of Internet Protocol (IP) address space, Autonomous System Numbers (ASNs) and the management of reverse domain names within this region. [...] 1.1 Scope This document describes the policies for the responsible management of globally unique IPv4 Internet address space in the RIPE NCC service region. The policies documented here apply to all IPv4 address space allocated and assigned by the RIPE NCC." There is no document saying that the address space allocated by the RIPE NCC can only be used in the RIPE service region. As far as I have seen ARIN is only now trying to limit the use of the address space it allocates to it's service region. I do not think a similar policy proposal would fly in the RIPE community. We live in a global world, most large companies have operations in more than one region. I think these organisations should have only one RIR handle their addresses and the RIRs should mirror the databases of the other RIRs to avoid duplicate registration. My impression is that the RIPE NCC is the only RIR that is currently mirroring the other RIR databases and making steps towards what I think should become at some point a unique point of data collection. cheers, elvis PS: the views above are my own and have nothing to do with my previous or current employer On 05/06/14 14:23, CJ Aronson wrote: > I asked a colleague at the RIPE NCC regarding this question of getting > address space from RIPE. > > She said, "We accept organisations that are > incorporated in other regions as members. But we require that the > address space we allocate will be used/announced in the RIPE NCC service > region." > > ----Cathy > > > > > On Wed, Jun 4, 2014 at 8:31 PM, CJ Aronson > wrote: > > Let's be clear.. the RIPE NCC will only give a one-time /22 for > your 1600 Euros/year. RIPE has always made applicants prove a > business presense in the region and I believe that's what the > " > > * > > The name of the "Chamber of Commerce" where your company is > registered > > o > > For example, Companies House, KvK etc." > > Is referring to. The link is here for your reference: > http://www.ripe.net/lir-services/member-support/become-a-member/application > > You'll have to apply and see. > > If you want more than a /22 you'll have to go to the transfer market. > > ----Cathy > > > On Wed, Jun 4, 2014 at 8:24 PM, Elvis Velea > wrote: > > Hi John, > > > On 05/06/14 04:05, John Von Stein wrote: >> >> Elvis, >> >> So does that mean a US based ISP such as QxC wanted / needed >> an additional IPv4 allocation we could simply go to RIPE and >> get the IPv4 we want/need? >> > > yup :) and only for ?1600/year and with no transfer fees :) > > cheers, > elvis > >> Thank you, >> >> John W. Von Stein >> >> cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823 >> >> 102 NE 2^nd Street >> >> Suite 136 >> >> Boca Raton, FL 33432 >> >> Office: 561-288-6989 >> >> www.QxCcommunications.com >> >> This email and any files transmitted with it are confidential >> and intended solely for the use of the individual or entity >> to whom they are addressed. >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Elvis Velea >> Sent: Wednesday, June 4, 2014 9:35 PM >> To: David Huberman >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] About needs basis in 8.3 transfers >> >> Hi David, >> >> even further... for those that do not know yet, any legal or >> private person can become a member of the RIPE NCC while the >> ARIN policies/procedures still require a company to have a >> legal presence in the ARIN region in order to request resources. >> >> And, btw.. have I already mentioned that the RIPE Community >> has completely removed the demonstrated need from their >> policy? I think I was only discussing this matter in the >> APNIC mailing lists and maybe those subscribed to this >> mailing list should also be aware of. >> >> cheers, >> >> elvis >> >> On 05/06/14 03:30, David Huberman wrote: >> >> > I agree completely, Elvis. There's an argument to be made >> that if ARIN won't be flexible with transfer policy, that >> RIPE becomes the most useful RIR for operators to work >> within. There's a further argument that's been made that the >> time for regional IRs may be passed (past?) and that IETF >> should review the situation. >> >> > >> >> > David R Huberman >> >> > Microsoft Corporation >> >> > Senior IT/OPS Program Manager (GFS) >> >> > >> >> > ________________________________________ >> >> > From: arin-ppml-bounces at arin.net >> >> > > on >> >> > behalf of Elvis Velea > >> >> > Sent: Wednesday, June 4, 2014 6:21:52 PM >> >> > To: arin-ppml at arin.net >> >> > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers >> >> > >> >> > Hi David, >> >> > >> >> > On 05/06/14 02:21, David Huberman wrote: >> >> >> We're going to be a cross-roads very soon. ARIN is going >> to exhaust, and network operators will be unable to obtain >> additional IPv4 address blocks from ARIN. At that point, the >> most obvious solution for IPv4 needs will be the market. >> >> > And then, they will be able to register as RIPE NCC members >> (LIRs) and >> >> > receive as many IP addresses as they want without having to >> prove any >> >> > demonstrated need. All they will need to do is to confirm >> that they >> >> > will use these addresses for themselves or their customers. >> >> > >> >> >> Proper stewardship of the ARIN function demands that >> ARIN policy adjust to what happens in the market. It's not >> the other way around, if only because that's not how markets >> work. >> >> >> >> >> >> The ARIN CEO, ARIN's General Counsel, the Harvard >> economist ARIN pays, professors who study markets, brokers >> who operate in the market, and buyers and sellers who buy and >> sell in the market have all told the ARIN community the same >> story for around 5 years now: the market is going to act as a >> market, and ARIN policy needs to be ready for it; ARIN policy >> needs to make sense with the dynamics of the market. >> >> >> >> >> >> It's hard to know how to argue with operators like Owen >> and the >> >> >> Google folks who all say the opposite; that ARIN policy >> should stick >> >> >> to the same ideals as 1995 (important ideals for a very >> long time!) >> >> >> and not adjust. I fear the results of this kind of >> ostracism :( >> >> > Well, then let them slowly kill the ARIN function. If all >> ARIN members >> >> > can no longer get resources and they stop paying and go to the >> >> > cheapest RIR (which btw is RIPE NCC with EUR1600/year no >> matter how >> >> > many resources one has) and get as many resources they >> want... what do >> >> > you think will happen? >> >> > >> >> > cheers, >> >> > elvis >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2999 bytes Desc: not available URL: From cja at daydream.com Thu Jun 5 09:42:34 2014 From: cja at daydream.com (CJ Aronson) Date: Thu, 5 Jun 2014 07:42:34 -0600 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <53906CB2.7020905@velea.eu> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FC630.9090404@velea.eu> <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> <538FC961.9090608@velea.eu> <538FD4DC.5020209@velea.eu> <53906CB2.7020905@velea.eu> Message-ID: Elvis.. I am sure with any policy folks will try to game the system. From my experience with RIPE I think the community would not be pleased if the last of the remaining /22s were all given to US companies for use in the US. But who knows. I went to a colleague at the RIPE NCC to get information for this list. Your summary that anyone can get as much address space as they want from the RIPE NCC for 1600 Euros a year is not true and I wanted to make sure that for this discussion that we had a more realistic assessment. If folks want to become RIPE members and misrepresent how the address space is going to be used that's really up to them. ----Cathy On Thu, Jun 5, 2014 at 7:12 AM, Elvis Velea wrote: > Hi Cathy, > > how can one verify where address space is used? Do you verify the AS > announcing it, and what if that AS is globally routed and it peers with > various organisations within several service regions? Do you ping the > address to see how long it takes for the Pong to come back to you? > These RIR bordes are artificial and have nothing to do with operational > reality. One can route the address space it gets from/to anywhere in the > world, especially if it has a Tier1/2 provider which offers global services. > > There has been a simple workaround available for years. Have a look at the > RIPE Database split files and see how many inetnums have country code US. > You will be surprised :) > You can always announce a /16 in the RIPE region and two /17s in the ARIN > region and then the 'requirement' of having the space announced in the RIPE > region is satisfied, right? > It's just that all the traffic will flow to the router announcing the two > /17s. > Plus, the RIPE NCC allocates only a /22 from the last /8. So, if you > become a member and have a router somewhere in Europe where you will need > to use at least a few addresses and therefore you qualify to receive the > /22. RIPE NCC will not complain if the /24 used for that router/equipment > is announced in the RIPE region and the rest in an other region where you > may have other equipment and/or customers. > Additionally, once you are a member and request a transfer, the only thing > you need to fill in is the transfer agreement template and confirm that you > are requesting the transfer in order to make assignments from the > allocation. It does not matter to whom you make those assignments or where > these will be used. > > http://www.ripe.net/lir-services/resource-management/ipv4-transfers/transfer-agreement-template > Lastly, the RIPE NCC SSA (the contract) does not say anything about where > the resources can be used and the _current policies_ are at best *vague*. > > For example, the RIPE IPv4 policy says: > "1.0 Introduction > The RIPE NCC is an independent association and serves as one of five > Regional Internet Registries (RIRs). Its service region incorporates > Europe, the Middle East, and Central Asia. The RIPE NCC is responsible for > the allocation and assignment of Internet Protocol (IP) address space, > Autonomous System Numbers (ASNs) and the management of reverse domain names > within this region. > [...] > 1.1 Scope > This document describes the policies for the responsible management of > globally unique IPv4 Internet address space in the RIPE NCC service region. > The policies documented here apply to all IPv4 address space allocated and > assigned by the RIPE NCC." > > There is no document saying that the address space allocated by the RIPE > NCC can only be used in the RIPE service region. > > As far as I have seen ARIN is only now trying to limit the use of the > address space it allocates to it's service region. I do not think a similar > policy proposal would fly in the RIPE community. > > We live in a global world, most large companies have operations in more > than one region. I think these organisations should have only one RIR > handle their addresses and the RIRs should mirror the databases of the > other RIRs to avoid duplicate registration. My impression is that the RIPE > NCC is the only RIR that is currently mirroring the other RIR databases and > making steps towards what I think should become at some point a unique > point of data collection. > > cheers, > elvis > > PS: the views above are my own and have nothing to do with my previous or > current employer > > > On 05/06/14 14:23, CJ Aronson wrote: > > I asked a colleague at the RIPE NCC regarding this question of getting > address space from RIPE. > > She said, "We accept organisations that are > incorporated in other regions as members. But we require that the > address space we allocate will be used/announced in the RIPE NCC service > region." > > ----Cathy > > > > > On Wed, Jun 4, 2014 at 8:31 PM, CJ Aronson wrote: > >> Let's be clear.. the RIPE NCC will only give a one-time /22 for your 1600 >> Euros/year. RIPE has always made applicants prove a business presense in >> the region and I believe that's what the >> " >> >> - >> >> The name of the "Chamber of Commerce" where your company is registered >> - >> >> For example, Companies House, KvK etc." >> >> Is referring to. The link is here for your reference: >> >> http://www.ripe.net/lir-services/member-support/become-a-member/application >> >> You'll have to apply and see. >> >> If you want more than a /22 you'll have to go to the transfer market. >> >> ----Cathy >> >> >> On Wed, Jun 4, 2014 at 8:24 PM, Elvis Velea wrote: >> >>> Hi John, >>> >>> >>> On 05/06/14 04:05, John Von Stein wrote: >>> >>> Elvis, >>> >>> >>> >>> So does that mean a US based ISP such as QxC wanted / needed an >>> additional IPv4 allocation we could simply go to RIPE and get the IPv4 we >>> want/need? >>> >>> >>> yup :) and only for ?1600/year and with no transfer fees :) >>> >>> cheers, >>> elvis >>> >>> >>> >>> Thank you, >>> >>> John W. Von Stein >>> >>> >>> >>> [image: cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] >>> >>> >>> >>> 102 NE 2nd Street >>> >>> Suite 136 >>> >>> Boca Raton, FL 33432 >>> >>> Office: 561-288-6989 >>> >>> www.QxCcommunications.com >>> >>> >>> >>> This email and any files transmitted with it are confidential and >>> intended solely for the use of the individual or entity to whom they are >>> addressed. >>> >>> >>> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net >>> ] On Behalf Of Elvis Velea >>> Sent: Wednesday, June 4, 2014 9:35 PM >>> To: David Huberman >>> Cc: arin-ppml at arin.net >>> Subject: Re: [arin-ppml] About needs basis in 8.3 transfers >>> >>> >>> >>> Hi David, >>> >>> >>> >>> even further... for those that do not know yet, any legal or private >>> person can become a member of the RIPE NCC while the ARIN >>> policies/procedures still require a company to have a legal presence in the >>> ARIN region in order to request resources. >>> >>> >>> >>> And, btw.. have I already mentioned that the RIPE Community has >>> completely removed the demonstrated need from their policy? I think I was >>> only discussing this matter in the APNIC mailing lists and maybe those >>> subscribed to this mailing list should also be aware of. >>> >>> >>> >>> cheers, >>> >>> elvis >>> >>> >>> >>> On 05/06/14 03:30, David Huberman wrote: >>> >>> > I agree completely, Elvis. There's an argument to be made that if >>> ARIN won't be flexible with transfer policy, that RIPE becomes the most >>> useful RIR for operators to work within. There's a further argument that's >>> been made that the time for regional IRs may be passed (past?) and that >>> IETF should review the situation. >>> >>> > >>> >>> > David R Huberman >>> >>> > Microsoft Corporation >>> >>> > Senior IT/OPS Program Manager (GFS) >>> >>> > >>> >>> > ________________________________________ >>> >>> > From: arin-ppml-bounces at arin.net on >>> >>> > behalf of Elvis Velea >>> >>> > Sent: Wednesday, June 4, 2014 6:21:52 PM >>> >>> > To: arin-ppml at arin.net >>> >>> > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers >>> >>> > >>> >>> > Hi David, >>> >>> > >>> >>> > On 05/06/14 02:21, David Huberman wrote: >>> >>> >> We're going to be a cross-roads very soon. ARIN is going to exhaust, >>> and network operators will be unable to obtain additional IPv4 address >>> blocks from ARIN. At that point, the most obvious solution for IPv4 needs >>> will be the market. >>> >>> > And then, they will be able to register as RIPE NCC members (LIRs) and >>> >>> > receive as many IP addresses as they want without having to prove any >>> >>> > demonstrated need. All they will need to do is to confirm that they >>> >>> > will use these addresses for themselves or their customers. >>> >>> > >>> >>> >> Proper stewardship of the ARIN function demands that ARIN policy >>> adjust to what happens in the market. It's not the other way around, if >>> only because that's not how markets work. >>> >>> >> >>> >>> >> The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN >>> pays, professors who study markets, brokers who operate in the market, and >>> buyers and sellers who buy and sell in the market have all told the ARIN >>> community the same story for around 5 years now: the market is going to act >>> as a market, and ARIN policy needs to be ready for it; ARIN policy needs to >>> make sense with the dynamics of the market. >>> >>> >> >>> >>> >> It's hard to know how to argue with operators like Owen and the >>> >>> >> Google folks who all say the opposite; that ARIN policy should stick >>> >>> >> to the same ideals as 1995 (important ideals for a very long time!) >>> >>> >> and not adjust. I fear the results of this kind of ostracism :( >>> >>> > Well, then let them slowly kill the ARIN function. If all ARIN members >>> >>> > can no longer get resources and they stop paying and go to the >>> >>> > cheapest RIR (which btw is RIPE NCC with EUR1600/year no matter how >>> >>> > many resources one has) and get as many resources they want... what do >>> >>> > you think will happen? >>> >>> > >>> >>> > cheers, >>> >>> > elvis >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2999 bytes Desc: not available URL: From dogwallah at gmail.com Thu Jun 5 09:52:26 2014 From: dogwallah at gmail.com (McTim) Date: Thu, 5 Jun 2014 08:52:26 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <6C8203F0-AB62-41EF-91B1-736336B82A20@delong.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <7BA05D8710DA46C4ACF2B8F7F2C95DFE@MPC> <6C8203F0-AB62-41EF-91B1-736336B82A20@delong.com> Message-ID: On Wed, Jun 4, 2014 at 6:23 PM, Owen DeLong wrote: > > On Jun 4, 2014, at 8:16 AM, Mike Burns wrote: > > > Hi Blake, > > > > We can be wistful for the lack of progress of RPKI or the fact that > addresses are regularly routed for customers who are not the Whois > registrants, but we are powerless to change those things, community-wide. > > > > We are a community of private network operators for the most part. We > are stakeholders tasked primarily with maintaining a registry of uniqueness > of IP addresses. We need to ask ourselves whether the purported benefits of > maintaining a needs-test for every change of registrant in Whois is worth > the risk to the registry and the expenditure of fungible ARIN staff > resources. > > > > I elucidated one such risk, which is the risk of un-registered > acquisitions of shell corporations which are incentivized by the lack of a > needs test. John Curran acknowledged this risk. > > > > I offered an example of one of the few publicly demonstrable cases of > this in Whois, related to the public information surrounding the > Microsoft/Nortel deal. I am aware of many more but can not disclose them. > > > > People seek to frame this issue as if it were this question: "Should we > change the rules just because some people will break them?" > > > > My answer to that is yes, of course we should, unless the rule provides > some overriding benefit. > > > > So my question for the community is "What is the benefit we realize by > insisting on ARIN team review of every single transfer, down to /24, and is > it worth ARIN ticket time delay and the risk of decreased Whois accuracy?? > > The benefit is preserving addresses on a fair basis for those who actually > have legitimate and quasi-immediate use for them. > > Yes, this benefit is worth the ARIN ticket time and delay. > Agree. > > There has not yet been any actual evidence presented to show that the risk > to whois accuracy is any greater without this proposal than it is with it. > Those that would ignore ARIN policy to effectuate a transfer are just as > likely IMHO to ignore whois as not. > > > And secondarily, what size of un-needs tested transfer would be an > acceptable balance between the benefits of the needs test and the costs of > the needs test? > > /24 seems like a perfectly reasonable balancing point to me. Also Agree. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Thu Jun 5 10:10:12 2014 From: dogwallah at gmail.com (McTim) Date: Thu, 5 Jun 2014 09:10:12 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FC630.9090404@velea.eu> <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> <538FC961.9090608@velea.eu> <538FD4DC.5020209@velea.eu> <53906CB2.7020905@velea.eu> Message-ID: On Thu, Jun 5, 2014 at 8:42 AM, CJ Aronson wrote: > Elvis.. > > I am sure with any policy folks will try to game the system. From my > experience with RIPE I think the community would not be pleased if the last > of the remaining /22s were all given to US companies for use in the US. > But who knows. > > I went to a colleague at the RIPE NCC to get information for this list. > Your summary that anyone can get as much address space as they want from > the RIPE NCC for 1600 Euros a year is not true > It's Euro1750 and not unlimited space. https://www.ripe.net/ripe/docs/ripe-591 > and I wanted to make sure that for this discussion that we had a more > realistic assessment. If folks want to become RIPE members and > misrepresent how the address space is going to be used that's really up to > them. > > ----Cathy > > > On Thu, Jun 5, 2014 at 7:12 AM, Elvis Velea wrote: > >> Hi Cathy, >> >> how can one verify where address space is used? Do you verify the AS >> announcing it, and what if that AS is globally routed and it peers with >> various organisations within several service regions? Do you ping the >> address to see how long it takes for the Pong to come back to you? >> These RIR bordes are artificial and have nothing to do with operational >> reality. One can route the address space it gets from/to anywhere in the >> world, especially if it has a Tier1/2 provider which offers global services. >> >> There has been a simple workaround available for years. Have a look at >> the RIPE Database split files and see how many inetnums have country code >> US. You will be surprised :) >> You can always announce a /16 in the RIPE region and two /17s in the ARIN >> region and then the 'requirement' of having the space announced in the RIPE >> region is satisfied, right? >> It's just that all the traffic will flow to the router announcing the two >> /17s. >> Plus, the RIPE NCC allocates only a /22 from the last /8. So, if you >> become a member and have a router somewhere in Europe where you will need >> to use at least a few addresses and therefore you qualify to receive the >> /22. RIPE NCC will not complain if the /24 used for that router/equipment >> is announced in the RIPE region and the rest in an other region where you >> may have other equipment and/or customers. >> Additionally, once you are a member and request a transfer, the only >> thing you need to fill in is the transfer agreement template and confirm >> that you are requesting the transfer in order to make assignments from the >> allocation. It does not matter to whom you make those assignments or where >> these will be used. >> >> http://www.ripe.net/lir-services/resource-management/ipv4-transfers/transfer-agreement-template >> Lastly, the RIPE NCC SSA (the contract) does not say anything about where >> the resources can be used and the _current policies_ are at best *vague*. >> >> For example, the RIPE IPv4 policy says: >> "1.0 Introduction >> The RIPE NCC is an independent association and serves as one of five >> Regional Internet Registries (RIRs). Its service region incorporates >> Europe, the Middle East, and Central Asia. The RIPE NCC is responsible for >> the allocation and assignment of Internet Protocol (IP) address space, >> Autonomous System Numbers (ASNs) and the management of reverse domain names >> within this region. >> [...] >> 1.1 Scope >> This document describes the policies for the responsible management of >> globally unique IPv4 Internet address space in the RIPE NCC service region. >> The policies documented here apply to all IPv4 address space allocated and >> assigned by the RIPE NCC." >> >> There is no document saying that the address space allocated by the RIPE >> NCC can only be used in the RIPE service region. >> >> As far as I have seen ARIN is only now trying to limit the use of the >> address space it allocates to it's service region. I do not think a similar >> policy proposal would fly in the RIPE community. >> >> We live in a global world, most large companies have operations in more >> than one region. I think these organisations should have only one RIR >> handle their addresses and the RIRs should mirror the databases of the >> other RIRs to avoid duplicate registration. My impression is that the RIPE >> NCC is the only RIR that is currently mirroring the other RIR databases and >> making steps towards what I think should become at some point a unique >> point of data collection. >> >> cheers, >> elvis >> >> PS: the views above are my own and have nothing to do with my previous or >> current employer >> >> >> On 05/06/14 14:23, CJ Aronson wrote: >> >> I asked a colleague at the RIPE NCC regarding this question of getting >> address space from RIPE. >> >> She said, "We accept organisations that are >> incorporated in other regions as members. But we require that the >> address space we allocate will be used/announced in the RIPE NCC service >> region." >> >> ----Cathy >> >> >> >> >> On Wed, Jun 4, 2014 at 8:31 PM, CJ Aronson wrote: >> >>> Let's be clear.. the RIPE NCC will only give a one-time /22 for your >>> 1600 Euros/year. RIPE has always made applicants prove a business >>> presense in the region and I believe that's what the >>> " >>> >>> - >>> >>> The name of the "Chamber of Commerce" where your company is >>> registered >>> - >>> >>> For example, Companies House, KvK etc." >>> >>> Is referring to. The link is here for your reference: >>> >>> http://www.ripe.net/lir-services/member-support/become-a-member/application >>> >>> You'll have to apply and see. >>> >>> If you want more than a /22 you'll have to go to the transfer market. >>> >>> ----Cathy >>> >>> >>> On Wed, Jun 4, 2014 at 8:24 PM, Elvis Velea wrote: >>> >>>> Hi John, >>>> >>>> >>>> On 05/06/14 04:05, John Von Stein wrote: >>>> >>>> Elvis, >>>> >>>> >>>> >>>> So does that mean a US based ISP such as QxC wanted / needed an >>>> additional IPv4 allocation we could simply go to RIPE and get the IPv4 we >>>> want/need? >>>> >>>> >>>> yup :) and only for ?1600/year and with no transfer fees :) >>>> >>>> cheers, >>>> elvis >>>> >>>> >>>> >>>> Thank you, >>>> >>>> John W. Von Stein >>>> >>>> >>>> >>>> [image: cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] >>>> >>>> >>>> >>>> 102 NE 2nd Street >>>> >>>> Suite 136 >>>> >>>> Boca Raton, FL 33432 >>>> >>>> Office: 561-288-6989 >>>> >>>> www.QxCcommunications.com >>>> >>>> >>>> >>>> This email and any files transmitted with it are confidential and >>>> intended solely for the use of the individual or entity to whom they are >>>> addressed. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net >>>> ] On Behalf Of Elvis Velea >>>> Sent: Wednesday, June 4, 2014 9:35 PM >>>> To: David Huberman >>>> Cc: arin-ppml at arin.net >>>> Subject: Re: [arin-ppml] About needs basis in 8.3 transfers >>>> >>>> >>>> >>>> Hi David, >>>> >>>> >>>> >>>> even further... for those that do not know yet, any legal or private >>>> person can become a member of the RIPE NCC while the ARIN >>>> policies/procedures still require a company to have a legal presence in the >>>> ARIN region in order to request resources. >>>> >>>> >>>> >>>> And, btw.. have I already mentioned that the RIPE Community has >>>> completely removed the demonstrated need from their policy? I think I was >>>> only discussing this matter in the APNIC mailing lists and maybe those >>>> subscribed to this mailing list should also be aware of. >>>> >>>> >>>> >>>> cheers, >>>> >>>> elvis >>>> >>>> >>>> >>>> On 05/06/14 03:30, David Huberman wrote: >>>> >>>> > I agree completely, Elvis. There's an argument to be made that if >>>> ARIN won't be flexible with transfer policy, that RIPE becomes the most >>>> useful RIR for operators to work within. There's a further argument that's >>>> been made that the time for regional IRs may be passed (past?) and that >>>> IETF should review the situation. >>>> >>>> > >>>> >>>> > David R Huberman >>>> >>>> > Microsoft Corporation >>>> >>>> > Senior IT/OPS Program Manager (GFS) >>>> >>>> > >>>> >>>> > ________________________________________ >>>> >>>> > From: arin-ppml-bounces at arin.net on >>>> >>>> > behalf of Elvis Velea >>>> >>>> > Sent: Wednesday, June 4, 2014 6:21:52 PM >>>> >>>> > To: arin-ppml at arin.net >>>> >>>> > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers >>>> >>>> > >>>> >>>> > Hi David, >>>> >>>> > >>>> >>>> > On 05/06/14 02:21, David Huberman wrote: >>>> >>>> >> We're going to be a cross-roads very soon. ARIN is going to >>>> exhaust, and network operators will be unable to obtain additional IPv4 >>>> address blocks from ARIN. At that point, the most obvious solution for >>>> IPv4 needs will be the market. >>>> >>>> > And then, they will be able to register as RIPE NCC members (LIRs) >>>> and >>>> >>>> > receive as many IP addresses as they want without having to prove any >>>> >>>> > demonstrated need. All they will need to do is to confirm that they >>>> >>>> > will use these addresses for themselves or their customers. >>>> >>>> > >>>> >>>> >> Proper stewardship of the ARIN function demands that ARIN policy >>>> adjust to what happens in the market. It's not the other way around, if >>>> only because that's not how markets work. >>>> >>>> >> >>>> >>>> >> The ARIN CEO, ARIN's General Counsel, the Harvard economist ARIN >>>> pays, professors who study markets, brokers who operate in the market, and >>>> buyers and sellers who buy and sell in the market have all told the ARIN >>>> community the same story for around 5 years now: the market is going to act >>>> as a market, and ARIN policy needs to be ready for it; ARIN policy needs to >>>> make sense with the dynamics of the market. >>>> >>>> >> >>>> >>>> >> It's hard to know how to argue with operators like Owen and the >>>> >>>> >> Google folks who all say the opposite; that ARIN policy should stick >>>> >>>> >> to the same ideals as 1995 (important ideals for a very long time!) >>>> >>>> >> and not adjust. I fear the results of this kind of ostracism :( >>>> >>>> > Well, then let them slowly kill the ARIN function. If all ARIN >>>> members >>>> >>>> > can no longer get resources and they stop paying and go to the >>>> >>>> > cheapest RIR (which btw is RIPE NCC with EUR1600/year no matter how >>>> >>>> > many resources one has) and get as many resources they want... what >>>> do >>>> >>>> > you think will happen? >>>> >>>> > >>>> >>>> > cheers, >>>> >>>> > elvis >>>> >>>> > >>>> >>>> > >>>> >>>> > _______________________________________________ >>>> >>>> > 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. > -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2999 bytes Desc: not available URL: From elvis at velea.eu Thu Jun 5 10:35:00 2014 From: elvis at velea.eu (Elvis Velea) Date: Thu, 05 Jun 2014 16:35:00 +0200 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FC630.9090404@velea.eu> <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> <538FC961.9090608@velea.eu> <538FD4DC.5020209@velea.eu> <53906CB2.7020905@velea.eu> Message-ID: <53908014.9080001@velea.eu> Hi Cathy, McTim, On 05/06/14 16:10, McTim wrote: > > > > On Thu, Jun 5, 2014 at 8:42 AM, CJ Aronson > wrote: > > Elvis.. > > I am sure with any policy folks will try to game the system. > You are right, I referred to a workaround that would game the system, but there is no actual policy requiring LIRs in the RIPE service region to only use addresses in that region. > From my experience with RIPE I think the community would not be > pleased if the last of the remaining /22s were all given to US > companies for use in the US. But who knows. > I was talking about IP addresses received through transfers and not the last /22. > > I went to a colleague at the RIPE NCC to get information for this > list. Your summary that anyone can get as much address space as > they want from the RIPE NCC for 1600 Euros a year is not true > Yes it is, with the DN out the window, any RIPE member (LIR) can receive through the transfer market as many IP addresses as they need/want. Are you actually calling me a liar? Because that would be quite personal and not nice coming from an ARIN AC which " feels that cross pollination of ARIN with other RIRs as well as ARIN with other networking groups is essential to making good address policy." > > > > It's Euro1750 and not unlimited space. > > https://www.ripe.net/ripe/docs/ripe-591 It is going to be ?1600. http://www.ripe.net/lir-services/ncc/gm/may-2014/supporting-documents/ChargingScheme2015.pdf And if the RIPE NCC continues to grow in membership, we may see a further lowering of the fee next year. http://www.ripe.net/lir-services/ncc/gm/may-2014/RIPENCCChargingScheme2015.pdf - slide 3 is very interesting. What do you mean by not unlimited space? An LIR can receive a 'free' /22 from the RIPE NCC and because the demonstrated need has been removed from the policy, anyone can receive through transfers as many IP addresses as they need/want. Actually, if 2014-05 is approved by the community, these 'unlimited' transfers will be possible to other regions as well (off course, depending on the other region's policy). > > and I wanted to make sure that for this discussion that we had a > more realistic assessment. If folks want to become RIPE members > and misrepresent how the address space is going to be used that's > really up to them. > So my assessment is not realistic and your is? This is not nice, again. Anyway, we've moved a bit too much off-track. I think we should go back to the needs basis in the ARIN region. My opinion is that for transfers, the DN should go away and that is the only way the registry can survive. As long as ARIN still has addresses to allocate, it should keep DN for that space but allow transfers within and outside the region to be correctly registered in the registry. These transfers do and will happen and we, brokers, see attempts very often. We are trying to raise a signal here but if the community or the ARIN Staff, AC, etc... decides to ignore the potential problem - there's not much we can do. We'll probably talk again in a few years :) cheers, elvis -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Thu Jun 5 10:38:44 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 05 Jun 2014 17:38:44 +0300 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <538FC2D8.8020207@matthew.at> <1E5080BB-1E38-4F9C-BDFA-7D957D49E83B@delong.com> <53904E17.9000008@matthew.at> Message-ID: <539080F4.3020503@matthew.at> On 6/5/2014 2:32 PM, Owen DeLong wrote: > Personally, I don't believe that IPv4 runout changes the need for > policy that attempts to preserve fairness in how addresses are > (re)distributed. I realize and respect that you disagree with this. > However, my analysis of the continued need for this policy is not > based on the context of ARIN still having IPv4. Obviously I can't > authoritatively comment on anyone else's perspective and neither can you. IPv4 runout certainly changes the need for policy that attempts to preserve fairness in how addresses are distributed *from the ARIN free pool*. Or at least makes any such policy irrelevant unless/until more free pool is generated for IPv4. The means by which ARIN ensures "fairness" when allocating from the free pool are necessarily quite different than any means by which ARIN might ensure "fairness" when private parties are making agreements to exchange the right to current or future use of address space for money. Even if there are such means, expecting the *same* policy and mechanisms to have an identical effect in both cases is foolhardy, in my opinion. If you *really* wanted ARIN to be able to use the same policy, we should give ARIN enough money that it could incent current holders to return their space to the free pool, then allocate from the newly refilled pool to exactly the "right" people (those who most fit the established "fair" need-based policies). Or of course tell people to get IPv6 addresses and figure IPv4 is going to get pretty ugly no matter what. Matthew Kaufman From cja at daydream.com Thu Jun 5 10:53:15 2014 From: cja at daydream.com (CJ Aronson) Date: Thu, 5 Jun 2014 08:53:15 -0600 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <53908014.9080001@velea.eu> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FC630.9090404@velea.eu> <11b482b7388f4d28af755b60a43bb124@DM2PR03MB398.namprd03.prod.outlook.com> <538FC961.9090608@velea.eu> <538FD4DC.5020209@velea.eu> <53906CB2.7020905@velea.eu> <53908014.9080001@velea.eu> Message-ID: Elvis My point was that the transfer market is not free so you may be able to get addresses on the market.. maybe as many as you want but they are not included in the annual RIPE fee.. They will cost money. All you can possibly get from RIPE for your annual fee is that one-time /22 and access to the transfer market. It is also the case (based on my discussions) that RIPE asks you to use that address space within their region. Thanks! -----Cathy On Thu, Jun 5, 2014 at 8:35 AM, Elvis Velea wrote: > Hi Cathy, McTim, > > > On 05/06/14 16:10, McTim wrote: > > > > > On Thu, Jun 5, 2014 at 8:42 AM, CJ Aronson wrote: > >> Elvis.. >> >> I am sure with any policy folks will try to game the system. >> > You are right, I referred to a workaround that would game the system, > but there is no actual policy requiring LIRs in the RIPE service region to > only use addresses in that region. > > From my experience with RIPE I think the community would not be >> pleased if the last of the remaining /22s were all given to US companies >> for use in the US. But who knows. >> >> I was talking about IP addresses received through transfers and not > the last /22. > > I went to a colleague at the RIPE NCC to get information for this >> list. Your summary that anyone can get as much address space as they want >> from the RIPE NCC for 1600 Euros a year is not true >> > Yes it is, with the DN out the window, any RIPE member (LIR) can > receive through the transfer market as many IP addresses as they need/want. > Are you actually calling me a liar? Because that would be quite personal > and not nice coming from an ARIN AC which " feels that cross pollination > of ARIN with other RIRs as well as ARIN with other networking groups is > essential to making good address policy." > > > > It's Euro1750 and not unlimited space. > > https://www.ripe.net/ripe/docs/ripe-591 > > It is going to be ?1600. > > > http://www.ripe.net/lir-services/ncc/gm/may-2014/supporting-documents/ChargingScheme2015.pdf > And if the RIPE NCC continues to grow in membership, we may see a further > lowering of the fee next year. > > > http://www.ripe.net/lir-services/ncc/gm/may-2014/RIPENCCChargingScheme2015.pdf > - slide 3 is very interesting. > > What do you mean by not unlimited space? An LIR can receive a 'free' /22 > from the RIPE NCC and because the demonstrated need has been removed from > the policy, anyone can receive through transfers as many IP addresses as > they need/want. > Actually, if 2014-05 is approved by the community, these 'unlimited' > transfers will be possible to other regions as well (off course, depending > on the other region's policy). > > > > >> and I wanted to make sure that for this discussion that we had a more >> realistic assessment. If folks want to become RIPE members and >> misrepresent how the address space is going to be used that's really up to >> them. >> > So my assessment is not realistic and your is? > > This is not nice, again. > > Anyway, we've moved a bit too much off-track. I think we should go back to > the needs basis in the ARIN region. > > My opinion is that for transfers, the DN should go away and that is the > only way the registry can survive. As long as ARIN still has addresses to > allocate, it should keep DN for that space but allow transfers within and > outside the region to be correctly registered in the registry. These > transfers do and will happen and we, brokers, see attempts very often. We > are trying to raise a signal here but if the community or the ARIN Staff, > AC, etc... decides to ignore the potential problem - there's not much we > can do. We'll probably talk again in a few years :) > > cheers, > elvis > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jun 5 11:52:56 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jun 2014 16:52:56 +0100 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <539080F4.3020503@matthew.at> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <538FC2D8.8020207@matthew.at> <1E5080BB-1E38-4F9C-BDFA-7D957D49E83B@delong.com> <53904E17.9000008@matthew.at> <539080F4.3020503@matthew.at> Message-ID: <2E2072AE-4177-442E-B0B6-F27ECBD27C06@delong.com> > On Jun 5, 2014, at 3:38 PM, Matthew Kaufman wrote: > >> On 6/5/2014 2:32 PM, Owen DeLong wrote: >> Personally, I don't believe that IPv4 runout changes the need for policy that attempts to preserve fairness in how addresses are (re)distributed. I realize and respect that you disagree with this. However, my analysis of the continued need for this policy is not based on the context of ARIN still having IPv4. Obviously I can't authoritatively comment on anyone else's perspective and neither can you. > > IPv4 runout certainly changes the need for policy that attempts to preserve fairness in how addresses are distributed *from the ARIN free pool*. Or at least makes any such policy irrelevant unless/until more free pool is generated for IPv4. I don't believe that's all that current policy seeks to do. Current policy seeks fairness in who receives IP number resources, whether from the free pool or via transfer. I believe that the fairness in the receipt of resources remains the same regardless of the source of the resources. Clearly you don't agree and that's fine. > The means by which ARIN ensures "fairness" when allocating from the free pool are necessarily quite different than any means by which ARIN might ensure "fairness" when private parties are making agreements to exchange the right to current or future use of address space for money. I disagree completely. > Even if there are such means, expecting the *same* policy and mechanisms to have an identical effect in both cases is foolhardy, in my opinion. And we can agree to disagree about this, but it does not mean that I have not considered the future context just because I came to a different conclusion than you have. > If you *really* wanted ARIN to be able to use the same policy, we should give ARIN enough money that it could incent current holders to return their space to the free pool, then allocate from the newly refilled pool to exactly the "right" people (those who most fit the established "fair" need-based policies). I proposed this, actually, some time ago and it was very quickly shouted down. > Or of course tell people to get IPv6 addresses and figure IPv4 is going to get pretty ugly no matter what. Which I think is a pretty good summary of what I've been doing for the last 6+ years. Owen From dmiller at tiggee.com Thu Jun 5 11:55:22 2014 From: dmiller at tiggee.com (David Miller) Date: Thu, 05 Jun 2014 11:55:22 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com><538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> Message-ID: <539092EA.7090502@tiggee.com> On 06/05/2014 08:26 AM, Mike Burns wrote: > David said: The full phrase I used was "legitimization of this market on an > unlimited scale" and it was intentional. > > "unlimited" as intentionally used, then, is a straw man argument in the > context of 2014-14. > https://www.arin.net/policy/proposals/2014_14.html Agreed. > Which to be fair to David, his comment did not appear in this context, > but 2014-4 was the genesis for this discussion. Correct. My comment was not made wrt 2014-14. The start of this thread was David Huberman's post which included, "Wouldn?t it be better if ARIN rules allowed us to transfer into our name all the IP addresses which we now own?". I take this to mean unlimited, instead of what is proposed in 2014-14. ^^ Not an attempt to misquote David Huberman or take his quote out of context, please read the entire original post. > 2014-14 does not open an unlimited market and so David'so other > references towards speculation and hoarding which may apply to an > unlimited market do not apply to 2014-14. I agree that 2014-14 does not open an unlimited market. However, to be clear, I have never stated (and it is not my view) that *only* an unlimited market would cause concerns regarding speculation and hoarding. > Regards, > Mike Burns -DMM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature URL: From SRyerse at eclipse-networks.com Thu Jun 5 12:07:21 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 5 Jun 2014 16:07:21 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.809080 6@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD5AC8@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD6B4B@ENI-MAIL.eclipse-networks.com> And your statement to me sounds like the haves trying to make it harder for the have nots, so that it is harder for the have nots to compete with the haves. The current ARIN policies are stacked against a small organization trying to compete with larger ones for resources. In my opinion that is very anti-competitive and I defy you to show me where in the ARIN mission statement et al it says that that ARIN should make it harder for a small organization just starting out to get resources than larger ones. I repeat that ARIN's mission is to allocate resources and it isn't to find way not to allocate resources!!! 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? -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Thursday, June 05, 2014 3:39 AM To: Steven Ryerse Cc: Matthew Kaufman; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers There isn?t. But like many things in the world, sometimes it?s just easier to hire a professional. I know many small organizations that have read the NRPM and applied successfully for various size allocations and/or assignments. Your statement, to me, sounds like ?If you need to hire a lawyer to form your corporation, then something is very wrong with the law? or ?If you need to hire a mechanic to fix your car, then something is very wrong with the design of your car.? As a general rule, virtually anything you do in business can be done by amateurs, but is usually faster and easier if you involve professionals. Owen On Jun 4, 2014, at 6:01 PM, Steven Ryerse wrote: > No offense, but there should not be a need for any organization to have to hire a consult to try and get the Minimum size allocation. If you need a consultant for that then something is very wrong with the policies! > > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > www.eclipse-networks.com > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, June 04, 2014 8:14 PM > To: Steven Ryerse > Cc: Matthew Kaufman; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > On Jun 4, 2014, at 4:50 PM, Steven Ryerse wrote: > >> There are several folks (like me) who want to ditch the needs test and there are several folks who don't want to ditch them. I take it your position is that the folks who want to keep needs tests should somehow prevail in this argument without much or any change, and those of us who wish to ditch them should just accept the status quo with needs tests. In other words you win and we lose! > > Not necessarily. I?m open for a good debate of the issue on the merits of the proposal. I?ve attempted to stick to that. > >> I saw a lot of folks comment here recently who want to at least loosen needs tests on the smaller block sizes, many many more than I've ever seen before. Since it is obvious a sizable portion of this community desires a change toward loosening policies, why is it that you persist in standing in the way of compromise? > > I have not stood in the way of compromise and could not do so even if I wanted to. I am only one of 15 votes on the AC. You only need ten of them to get a policy proposal sent to the board. It is, however, equally obvious that a sizable portion of the community, not merely myself, does not want to eliminate the needs test. Currently, there is no actual proposal on the table for loosening them or compromising. If there were one, I would address the merits of it as I saw them. > >> There comes a time when fair is fair - and small organizations are routinely discriminated against because of our small size and not so deep pockets. There is a lot of anger out there over the unfairness of these existing policies. It should be just as easy for us to get resources as it was for T-Mobile and others. I call on all members of this community to at least come to a compromise. After all the world hasn't ended for RIPE with their changes - and it won't end here either if fairness is put back into the policies so that small organizations can get the resources they need too! > > Given the number of sole-proprietors with very small budgets that I have obtained IP allocations for over the past several years, I think this is an inaccurate characterization of the facts at hand. Indeed, if you look at my posting history and my voting history throughout my tenure on the AC, you will find that I am one of the biggest advocates that the small organization could find. > > It is just as easy (if not easier) for small organizations to get resources as large ones. (I know this full well because I have applied for resources for virtually every size category in the ARIN fee table). > > If you are having trouble with a particular application, feel free to contact me off-line with the details. I may be able to help you navigate the ARIN process more effectively. We have, by the way, been making steady progress on loosening the restrictions on needs basis. There used to be no ability to get anything smaller than a /20 from ARIN for conventional uses at one time. Today, that?s down to a /24 and there is progress being made on making that possible without multihoming. > > Owen > From gary.buhrmaster at gmail.com Thu Jun 5 12:34:20 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 5 Jun 2014 16:34:20 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <2E2072AE-4177-442E-B0B6-F27ECBD27C06@delong.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <538FC2D8.8020207@matthew.at> <1E5080BB-1E38-4F9C-BDFA-7D957D49E83B@delong.com> <53904E17.9000008@matthew.at> <539080F4.3020503@matthew.at> <2E2072AE-4177-442E-B0B6-F27ECBD27C06@delong.com> Message-ID: On Thu, Jun 5, 2014 at 3:52 PM, Owen DeLong wrote: > > >> On Jun 5, 2014, at 3:38 PM, Matthew Kaufman wrote: >> >>> On 6/5/2014 2:32 PM, Owen DeLong wrote: >>> Personally, I don't believe that IPv4 runout changes the need for policy that attempts to preserve fairness in how addresses are (re)distributed. I realize and respect that you disagree with this. However, my analysis of the continued need for this policy is not based on the context of ARIN still having IPv4. Obviously I can't authoritatively comment on anyone else's perspective and neither can you. >> >> IPv4 runout certainly changes the need for policy that attempts to preserve fairness in how addresses are distributed *from the ARIN free pool*. Or at least makes any such policy irrelevant unless/until more free pool is generated for IPv4. > > I don't believe that's all that current policy seeks to do. Current policy seeks fairness in who receives IP number resources, whether from the free pool or via transfer. My definition of fairness, in this context, is that we (the community) will (within the justified time frame jitter) run out of IPv4s to allocate/assign/transfer at about the same time for those with current need. I support needs based assignment/allocation/transfer, as attempting to implement my definition of fairness. Even recognizing that existing policy will be imperfect in practice, and there will always be those that look to game the system. There should be no $MEGACORP$ advantage by being able to agree to transfer a 10 years advanced supply, giving them a competitive advantage over their competitors or new entrants. We sink (in IPv4), or swim (in IPv6) together. btw, I really with more $MEGACORP$s would IPv6 enable their main web sites to demonstrate (if nothing else) that they *do* get it, and are serious about moving themselves and their customers forward. Gary From drc at virtualized.org Thu Jun 5 16:28:01 2014 From: drc at virtualized.org (David Conrad) Date: Thu, 5 Jun 2014 13:28:01 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> Message-ID: <819111DE-D16F-4AA1-95EA-9906B622BBE4@virtualized.org> Bill, On Jun 4, 2014, at 8:58 PM, Bill Woodcock wrote: > The difference between a legal market and an illegal market is [...] that society has deemed one to be in the common good and the other detrimental. This is only true if you believe "society" has determined "common good" appropriately and universally. As I'm sure you're aware, in many cases, the definition of legal vs. illegal boils down to what supports the interests of those in power, not necessarily the interests of the larger society or even "common good". I believe one of the arguments being made is that ARIN's current policies are not reflective of what the larger society actually wants and/or is in the "common good". > Your argument that ARIN needs to step out of the way of the human slaves market, recognize its validity, and duly record the transfers of those slaves, because Ayn Rand, is idiotic. Do you really believe your statement above follows your demand that "we need to behave like adults"? > we don?t want our power to self-regulate removed. ARIN was established as a registry. That is, an entity that records registration information for the resources it administers on behalf of the community it serves. In order to provide that service, ARIN has created a rather Byzantine (IMHO) policy definition mechanism. However, that policy definition mechanism exists solely to regulate the provision of ARIN's registry services. Nothing more, nothing less. In my view, if ARIN's policy definition mechanism, driven by a vocal but tiny minority of the community it serves, creates policies that are detrimental to the very reason ARIN was established, then its power to "self-regulate" _should_ be removed. Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mueller at syr.edu Thu Jun 5 17:15:17 2014 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 5 Jun 2014 21:15:17 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> Message-ID: Owen, > Given the number of sole-proprietors with very small budgets that I have > obtained IP allocations for over the past several years, I think this is an Are you doing this on a consulting basis? I am not accusing you of anything here, just think some additional clarity and perhaps COI disclosure might be appropriate here. From lar at mwtcorp.net Thu Jun 5 19:48:29 2014 From: lar at mwtcorp.net (lar at mwtcorp.net) Date: Thu, 05 Jun 2014 17:48:29 -0600 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD6B4B@ENI-MAIL.eclipse-networks.com> Message-ID: On Thu, 5 Jun 2014 16:07:21 +0000 Steven Ryerse wrote: > And your statement to me sounds like the haves trying to make it harder for the have nots, so that it is harder for the have >nots to compete with the haves. The current ARIN policies are stacked against a small organization trying to compete with larger >ones for resources. In my opinion that is very anti-competitive and I defy you to show me where in the ARIN mission statement et >al it says that that ARIN should make it harder for a small organization just starting out to get resources than larger ones. I >repeat that ARIN's mission is to allocate resources and it isn't to find way not to allocate resources!!! Personally I suspect that without needs testing the "haves" would have had it all a long time ago. I have felt the same frustration, as a small provider, trying to meet the 80% requirement can be almost impossible without gaming the system due to numerous small holes in a small allocation. That said, I worry about any company that could purchase a couple of Billion dollars of IPV4. I think I could make a stronger business case for that than some of the purchases/mergers that have happened over the last 10 years. I've hoped that IPV6 would eliminate that possibility but so far that hasn't happened. I live in a place where there is very little use of much of the licensed radio spectrum. Yet there is none available. Big players have snatched it up to keep from the others. They use it just enough to say they did and then hundreds of miles from here. Many of us fear that if need is not considered in the transfer market the little guys will find that none is available at any price. Like it or not the big guys have an advantage. Let's make sure that "cornering the market" isn't one of them. > > 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? > > > -----Original Message----- >From: Owen DeLong [mailto:owen at delong.com] > Sent: Thursday, June 05, 2014 3:39 AM > To: Steven Ryerse > Cc: Matthew Kaufman; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > There isn?t. But like many things in the world, sometimes it?s just easier to hire a professional. I know many small >organizations that have read the NRPM and applied successfully for various size allocations and/or assignments. > > Your statement, to me, sounds like ?If you need to hire a lawyer to form your corporation, then something is very wrong with the >law? or ?If you need to hire a mechanic to fix your car, then something is very wrong with the design of your car.? > > As a general rule, virtually anything you do in business can be done by amateurs, but is usually faster and easier if you >involve professionals. > > Owen > > On Jun 4, 2014, at 6:01 PM, Steven Ryerse wrote: > >> No offense, but there should not be a need for any organization to have to hire a consult to try and get the Minimum size >>allocation. If you need a consultant for that then something is very wrong with the policies! >> >> >> Steven Ryerse >> President >> 100 Ashford Center North, Suite 110, Atlanta, GA 30338 >> www.eclipse-networks.com >> 770.656.1460 - Cell >> 770.399.9099- Office >> >> ? Eclipse Networks, Inc. >> Conquering Complex Networks? >> >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Wednesday, June 04, 2014 8:14 PM >> To: Steven Ryerse >> Cc: Matthew Kaufman; arin-ppml at arin.net >> Subject: Re: [arin-ppml] About needs basis in 8.3 transfers >> >> >> On Jun 4, 2014, at 4:50 PM, Steven Ryerse wrote: >> >>> There are several folks (like me) who want to ditch the needs test and there are several folks who don't want to ditch them. I >>>take it your position is that the folks who want to keep needs tests should somehow prevail in this argument without much or any >>>change, and those of us who wish to ditch them should just accept the status quo with needs tests. In other words you win and we >>>lose! >> >> Not necessarily. I?m open for a good debate of the issue on the merits of the proposal. I?ve attempted to stick to that. >> >>> I saw a lot of folks comment here recently who want to at least loosen needs tests on the smaller block sizes, many many more >>>than I've ever seen before. Since it is obvious a sizable portion of this community desires a change toward loosening policies, >>>why is it that you persist in standing in the way of compromise? >> >> I have not stood in the way of compromise and could not do so even if I wanted to. I am only one of 15 votes on the AC. You only >>need ten of them to get a policy proposal sent to the board. It is, however, equally obvious that a sizable portion of the >>community, not merely myself, does not want to eliminate the needs test. Currently, there is no actual proposal on the table for >>loosening them or compromising. If there were one, I would address the merits of it as I saw them. >> >>> There comes a time when fair is fair - and small organizations are routinely discriminated against because of our small size and >>>not so deep pockets. There is a lot of anger out there over the unfairness of these existing policies. It should be just as >>>easy for us to get resources as it was for T-Mobile and others. I call on all members of this community to at least come to a >>>compromise. After all the world hasn't ended for RIPE with their changes - and it won't end here either if fairness is put back >>>into the policies so that small organizations can get the resources they need too! >> >> Given the number of sole-proprietors with very small budgets that I have obtained IP allocations for over the past several >>years, I think this is an inaccurate characterization of the facts at hand. Indeed, if you look at my posting history and my >>voting history throughout my tenure on the AC, you will find that I am one of the biggest advocates that the small organization >>could find. >> >> It is just as easy (if not easier) for small organizations to get resources as large ones. (I know this full well because I have >>applied for resources for virtually every size category in the ARIN fee table). >> >> If you are having trouble with a particular application, feel free to contact me off-line with the details. I may be able to >>help you navigate the ARIN process more effectively. We have, by the way, been making steady progress on loosening the >>restrictions on needs basis. There used to be no ability to get anything smaller than a /20 from ARIN for conventional uses at >>one time. Today, that?s down to a /24 and there is progress being made on making that possible without multihoming. >> >> Owen >> > > _______________________________________________ > 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. Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From JOHN at egh.com Thu Jun 5 21:43:45 2014 From: JOHN at egh.com (John Santos) Date: Thu, 5 Jun 2014 21:43:45 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: Message-ID: <1140605212432.46270A-100000@Ives.egh.com> (Something strange about the quoting below. I think Steven wrote the stuff with one ">" and Larry wrote the unquoted lines.) On Thu, 5 Jun 2014 lar at mwtcorp.net wrote: > On Thu, 5 Jun 2014 16:07:21 +0000 Steven Ryerse wrote: > And your statement to me sounds like the haves trying to make it harder > for the have nots, so that it is harder for the have > nots to compete with the haves. The current ARIN policies are stacked > against a small organization trying to compete with larger > ones for resources. In my opinion that is very anti-competitive and I > defy you to show me where in the ARIN mission statement et > al it says that that ARIN should make it harder for a small organization > just starting out to get resources than larger ones. I > repeat that ARIN's mission is to allocate resources and it isn't to find > way not to allocate resources!!! Personally I suspect that without needs testing the "haves" would have had it all a long time ago. I have felt the same frustration, as a small provider, trying to meet the 80% requirement can be almost impossible without gaming the system due to numerous small holes in a small allocation. That said, I worry about any company that could purchase a couple of Billion dollars of IPV4. I think I could make a stronger business case for that than some of the purchases/mergers that have happened over the last 10 years. I've hoped that IPV6 would eliminate that possibility but so far that hasn't happened. I live in a place where there is very little use of much of the licensed radio spectrum. Yet there is none available. Big players have snatched it up to keep from the others. They use it just enough to say they did and then hundreds of miles from here. Many of us fear that if need is not considered in the transfer market the little guys will find that none is available at any price. Like it or not the big guys have an advantage. Let's make sure that "cornering the market" isn't one of them. ----- +1 deregulating a market rarely helps the have-nots. It usually just helps the "haves" to have more. I don't think eliminating the needs requirement would help Steven and other small operators; I think it would make address space unacquirable at a reasonable cost. (Unless there's a secret agenda at work to promote IPv6 :-) Steven, are you the person who has proffered the notion of "right-sizing" as an alternative to needs testing? I think the determination of the right size to allocate to an organization is exactly what needs testing should do. If you (or anyone else) has specific examples of how needs testing as currently implemented fails to accomplish this, then I would be interested in any proposals to fix needs testing to do it right. (There have been many such proposals in the past and many of them have been adopted.) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From SRyerse at eclipse-networks.com Thu Jun 5 22:10:21 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 6 Jun 2014 02:10:21 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <1140605212432.46270A-100000@Ives.egh.com> References: <1140605212432.46270A-100000@Ives.egh.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD8B14@ENI-MAIL.eclipse-networks.com> My post was in fact the lines below with the single > in front of them. Yes I have advocated right-sizing instead of needs testing several times. Right sizing and needs testing have some similarities and in my opinion are easily confused. A needs test ends up in a pass fail or yes no outcome and you either get the requested resources or you don?t. I would add this needs testing can easily be used by the haves to keep the have nots from receiving any resources at all, and in my opinion that is happening. However with a right-sizing test, the outcome always ends up with an allocation being made (or offered) even if it turns out to only be the size of the current policy Minimum. This is a huge difference for a small organization and it levels the playing field for smaller organizations! I realize that an organization might be allocated (or offered) a smaller allocation than requested, but all organizations can at least get the smallest allocation per the current policy minimum - not always the perfect situation but a lot better than zero resources. Further I don't think this hurts the haves at all (except maybe more competition), and I do not agree that "without needs testing the "haves" would have had it all a long time ago" - as long as right-sizing tests are applied to all. I appreciate the discussion. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Santos Sent: Thursday, June 5, 2014 9:44 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers (Something strange about the quoting below. I think Steven wrote the stuff with one ">" and Larry wrote the unquoted lines.) On Thu, 5 Jun 2014 lar at mwtcorp.net wrote: > On Thu, 5 Jun 2014 16:07:21 +0000 Steven Ryerse wrote: > And your statement to me sounds like the haves trying to make it > harder for the have nots, so that it is harder for the have nots to > compete with the haves. The current ARIN policies are stacked against > a small organization trying to compete with larger ones for resources. > In my opinion that is very anti-competitive and I defy you to show me > where in the ARIN mission statement et al it says that that ARIN > should make it harder for a small organization just starting out to > get resources than larger ones. I repeat that ARIN's mission is to > allocate resources and it isn't to find way not to allocate > resources!!! Personally I suspect that without needs testing the "haves" would have had it all a long time ago. I have felt the same frustration, as a small provider, trying to meet the 80% requirement can be almost impossible without gaming the system due to numerous small holes in a small allocation. That said, I worry about any company that could purchase a couple of Billion dollars of IPV4. I think I could make a stronger business case for that than some of the purchases/mergers that have happened over the last 10 years. I've hoped that IPV6 would eliminate that possibility but so far that hasn't happened. I live in a place where there is very little use of much of the licensed radio spectrum. Yet there is none available. Big players have snatched it up to keep from the others. They use it just enough to say they did and then hundreds of miles from here. Many of us fear that if need is not considered in the transfer market the little guys will find that none is available at any price. Like it or not the big guys have an advantage. Let's make sure that "cornering the market" isn't one of them. ----- +1 deregulating a market rarely helps the have-nots. It usually just helps the "haves" to have more. I don't think eliminating the needs requirement would help Steven and other small operators; I think it would make address space unacquirable at a reasonable cost. (Unless there's a secret agenda at work to promote IPv6 :-) Steven, are you the person who has proffered the notion of "right-sizing" as an alternative to needs testing? I think the determination of the right size to allocate to an organization is exactly what needs testing should do. If you (or anyone else) has specific examples of how needs testing as currently implemented fails to accomplish this, then I would be interested in any proposals to fix needs testing to do it right. (There have been many such proposals in the past and many of them have been adopted.) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 _______________________________________________ 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 drc at virtualized.org Thu Jun 5 22:41:45 2014 From: drc at virtualized.org (David Conrad) Date: Thu, 5 Jun 2014 19:41:45 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <1140605212432.46270A-100000@Ives.egh.com> References: <1140605212432.46270A-100000@Ives.egh.com> Message-ID: <54961754-17A9-49C7-9281-7FD43BBD7408@virtualized.org> John, On Jun 5, 2014, at 6:43 PM, John Santos wrote: > I don't think eliminating the needs requirement would help Steven and > other small operators; I think it would make address space unacquirable > at a reasonable cost. I hope this doesn't come as a surprise, but IPv4 addresses are NOT going to be available "at a reasonable cost" regardless of any "demonstrated need" policy. It would seem apparent that there will remain sufficient demand for IPv4 to drive market-based pricing among the folks who can easily demonstrate need and I suspect those folks are going to have way more money than "small operators". The only deck chairs we're rearranging right now are the ones associated with who gets to collect the money. From the perspective of the small operators, I don't suspect it matters if the address space is unavailable because Speculators-R-Us has acquired it for speculation instead of Globespanning-Zillion-Dollar-ISP for renting to their customers at $20 per /32 per month (or whatever). > (Unless there's a secret agenda at work to promote IPv6 :-) I believe one of the problems here has been that the RIRs have distorted the market, hiding the actual long term true cost of IPv4 thereby making the deployment of IPv6 look more expensive by comparison. However, as a proctologist will tell you, "this too shall pass, although it's going to be painful"... Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From owen at delong.com Thu Jun 5 23:39:42 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jun 2014 20:39:42 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD6B4B@ENI-MAIL.eclipse-networks.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.809080 6@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD5AC8@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD6B4B@ENI-MAIL.eclipse-networks.com> Message-ID: <5B26918F-0737-497D-B002-61160BB7A315@delong.com> The current ARIN policies are not stacked at this point. I would have bought (and even championed) that argument several years ago, but I believe that we have made sufficient modifications to the policy that it is no longer the case. Your inference of my intent is absurd and if you look at my voting record or ask anyone who has known me for more than a year, they will say the same thing. ARIN does not make it any harder for a small organization just starting out to get resources than a larger one. I agree that?s not in their mission statement, but I do not agree with your claim that they do so. ARIN?s mission is to allocate resources according to the policies set by the ARIN community. They have done so quite consistently in my experience. Owen On Jun 5, 2014, at 9:07 AM, Steven Ryerse wrote: > And your statement to me sounds like the haves trying to make it harder for the have nots, so that it is harder for the have nots to compete with the haves. The current ARIN policies are stacked against a small organization trying to compete with larger ones for resources. In my opinion that is very anti-competitive and I defy you to show me where in the ARIN mission statement et al it says that that ARIN should make it harder for a small organization just starting out to get resources than larger ones. I repeat that ARIN's mission is to allocate resources and it isn't to find way not to allocate resources!!! > > 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? > > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Thursday, June 05, 2014 3:39 AM > To: Steven Ryerse > Cc: Matthew Kaufman; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > There isn?t. But like many things in the world, sometimes it?s just easier to hire a professional. I know many small organizations that have read the NRPM and applied successfully for various size allocations and/or assignments. > > Your statement, to me, sounds like ?If you need to hire a lawyer to form your corporation, then something is very wrong with the law? or ?If you need to hire a mechanic to fix your car, then something is very wrong with the design of your car.? > > As a general rule, virtually anything you do in business can be done by amateurs, but is usually faster and easier if you involve professionals. > > Owen > > On Jun 4, 2014, at 6:01 PM, Steven Ryerse wrote: > >> No offense, but there should not be a need for any organization to have to hire a consult to try and get the Minimum size allocation. If you need a consultant for that then something is very wrong with the policies! >> >> >> Steven Ryerse >> President >> 100 Ashford Center North, Suite 110, Atlanta, GA 30338 >> www.eclipse-networks.com >> 770.656.1460 - Cell >> 770.399.9099- Office >> >> ? Eclipse Networks, Inc. >> Conquering Complex Networks? >> >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Wednesday, June 04, 2014 8:14 PM >> To: Steven Ryerse >> Cc: Matthew Kaufman; arin-ppml at arin.net >> Subject: Re: [arin-ppml] About needs basis in 8.3 transfers >> >> >> On Jun 4, 2014, at 4:50 PM, Steven Ryerse wrote: >> >>> There are several folks (like me) who want to ditch the needs test and there are several folks who don't want to ditch them. I take it your position is that the folks who want to keep needs tests should somehow prevail in this argument without much or any change, and those of us who wish to ditch them should just accept the status quo with needs tests. In other words you win and we lose! >> >> Not necessarily. I?m open for a good debate of the issue on the merits of the proposal. I?ve attempted to stick to that. >> >>> I saw a lot of folks comment here recently who want to at least loosen needs tests on the smaller block sizes, many many more than I've ever seen before. Since it is obvious a sizable portion of this community desires a change toward loosening policies, why is it that you persist in standing in the way of compromise? >> >> I have not stood in the way of compromise and could not do so even if I wanted to. I am only one of 15 votes on the AC. You only need ten of them to get a policy proposal sent to the board. It is, however, equally obvious that a sizable portion of the community, not merely myself, does not want to eliminate the needs test. Currently, there is no actual proposal on the table for loosening them or compromising. If there were one, I would address the merits of it as I saw them. >> >>> There comes a time when fair is fair - and small organizations are routinely discriminated against because of our small size and not so deep pockets. There is a lot of anger out there over the unfairness of these existing policies. It should be just as easy for us to get resources as it was for T-Mobile and others. I call on all members of this community to at least come to a compromise. After all the world hasn't ended for RIPE with their changes - and it won't end here either if fairness is put back into the policies so that small organizations can get the resources they need too! >> >> Given the number of sole-proprietors with very small budgets that I have obtained IP allocations for over the past several years, I think this is an inaccurate characterization of the facts at hand. Indeed, if you look at my posting history and my voting history throughout my tenure on the AC, you will find that I am one of the biggest advocates that the small organization could find. >> >> It is just as easy (if not easier) for small organizations to get resources as large ones. (I know this full well because I have applied for resources for virtually every size category in the ARIN fee table). >> >> If you are having trouble with a particular application, feel free to contact me off-line with the details. I may be able to help you navigate the ARIN process more effectively. We have, by the way, been making steady progress on loosening the restrictions on needs basis. There used to be no ability to get anything smaller than a /20 from ARIN for conventional uses at one time. Today, that?s down to a /24 and there is progress being made on making that possible without multihoming. >> >> Owen >> > From owen at delong.com Fri Jun 6 00:05:17 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jun 2014 21:05:17 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> Message-ID: <268E77C0-9C5F-4CE6-A753-A205AF6B8EAD@delong.com> On Jun 5, 2014, at 2:15 PM, Milton L Mueller wrote: > Owen, > >> Given the number of sole-proprietors with very small budgets that I have >> obtained IP allocations for over the past several years, I think this is an > > Are you doing this on a consulting basis? I am not accusing you of anything here, just think some additional clarity and perhaps COI disclosure might be appropriate here. Yes, I have done this on a consulting basis for a very long time. I have repeatedly disclosed that I do so to the AC on a regular basis. I have checked with both John Curran and Steve Ryan and confirmed that no general COI exists. Each time a policy has come up which might benefit one or more of my clients, I have disclosed this fact and recused myself from the voting if the policy might have any impact on an active client?s current or pending request that I was aware of. I am also the person responsible for Hurricane Electric?s RIR relations and act as the DMR for some of my clients in the ARIN and APNIC elections. I do the number resource applications for Hurricane Electric and act as a senior counselor to others at Hurricane Electric who do resource requests on behalf of our customers. Thank you for giving me the opportunity to clarify this. I do not believe a COI exists, but if one comes to light, I will certainly disclose it and take appropriate action to the best of my ability. Owen From owen at delong.com Fri Jun 6 00:24:30 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jun 2014 21:24:30 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD8B14@ENI-MAIL.eclipse-networks.com> References: <1140605212432.46270A-100000@Ives.egh.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD8B14@ENI-MAIL.eclipse-networks.com> Message-ID: <7444FE5F-1694-40E2-BDFD-2CF31EBE3D2A@delong.com> On Jun 5, 2014, at 7:10 PM, Steven Ryerse wrote: > My post was in fact the lines below with the single > in front of them. > > Yes I have advocated right-sizing instead of needs testing several times. Right sizing and needs testing have some similarities and in my opinion are easily confused. A needs test ends up in a pass fail or yes no outcome and you either get the requested resources or you don?t. I would add this needs testing can easily be used by the haves to keep the have nots from receiving any resources at all, and in my opinion that is happening. However with a right-sizing test, the outcome always ends up with an allocation being made (or offered) even if it turns out to only be the size of the current policy Minimum. This is a huge difference for a small organization and it levels the playing field for smaller organizations! If that is your definition of needs testing, then in my experience ARIN already engages in ?right-sizing? because many times when I was unable to convince them that my client qualified for what we asked for, they suggested a longer prefix (smaller amount of addresses) that they would approve immediately. We would usually accept their offer with a request that they reserve the original request amount if possible. Then we would implement and fully utilize the original approval and go back for the rest. This usually worked quite well. > I realize that an organization might be allocated (or offered) a smaller allocation than requested, but all organizations can at least get the smallest allocation per the current policy minimum - not always the perfect situation but a lot better than zero resources. Further I don't think this hurts the haves at all (except maybe more competition), and I do not agree that "without needs testing the "haves" would have had it all a long time ago" - as long as right-sizing tests are applied to all. I think that recent policy changes have improved this. I would welcome policy proposals that further improved the situation. Removing needs basis from 8.3 transfers doesn?t do that and it has a number of other harmful outcomes as previously discussed. Owen From narten at us.ibm.com Fri Jun 6 00:53:03 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 06 Jun 2014 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201406060453.s564r3eG019428@rotala.raleigh.ibm.com> Total of 82 messages in the last 7 days. script run at: Fri Jun 6 00:53:02 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 17.07% | 14 | 11.50% | 122120 | owen at delong.com 10.98% | 9 | 15.14% | 160854 | elvis at velea.eu 8.54% | 7 | 11.36% | 120687 | sryerse at eclipse-networks.com 6.10% | 5 | 13.73% | 145887 | cja at daydream.com 6.10% | 5 | 4.13% | 43882 | mike at iptrading.com 6.10% | 5 | 4.13% | 43839 | dmiller at tiggee.com 6.10% | 5 | 3.31% | 35115 | matthew at matthew.at 2.44% | 2 | 6.11% | 64860 | dogwallah at gmail.com 4.88% | 4 | 3.39% | 36013 | david.huberman at microsoft.com 3.66% | 3 | 3.33% | 35371 | farmer at umn.edu 3.66% | 3 | 2.18% | 23155 | jcurran at arin.net 2.44% | 2 | 1.66% | 17663 | drc at virtualized.org 1.22% | 1 | 2.70% | 28708 | john at qxccommunications.com 1.22% | 1 | 2.45% | 26052 | hannigan at gmail.com 1.22% | 1 | 2.34% | 24821 | kkargel at polartel.com 1.22% | 1 | 1.27% | 13442 | rgrant at skywaywest.com 1.22% | 1 | 1.15% | 12255 | aaron at wholesaleinternet.net 1.22% | 1 | 1.12% | 11867 | lar at mwtcorp.net 1.22% | 1 | 1.10% | 11661 | info at arin.net 1.22% | 1 | 0.98% | 10395 | michael at linuxmagic.com 1.22% | 1 | 0.83% | 8809 | ikiris at gmail.com 1.22% | 1 | 0.83% | 8782 | woody at pch.net 1.22% | 1 | 0.79% | 8436 | lsawyer at gci.com 1.22% | 1 | 0.79% | 8362 | heather.skanks at gmail.com 1.22% | 1 | 0.71% | 7534 | gary.buhrmaster at gmail.com 1.22% | 1 | 0.67% | 7069 | john at egh.com 1.22% | 1 | 0.64% | 6809 | narten at us.ibm.com 1.22% | 1 | 0.58% | 6144 | mueller at syr.edu 1.22% | 1 | 0.56% | 6001 | jay at impulse.net 1.22% | 1 | 0.53% | 5672 | ppml at rsuc.gweep.net --------+------+--------+----------+------------------------ 100.00% | 82 |100.00% | 1062265 | Total From SRyerse at eclipse-networks.com Fri Jun 6 01:16:14 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 6 Jun 2014 05:16:14 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <7444FE5F-1694-40E2-BDFD-2CF31EBE3D2A@delong.com> References: <1140605212432.46270A-100000@Ives.egh.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD8B14@ENI-MAIL.eclipse-networks.com> <7444FE5F-1694-40E2-BDFD-2CF31EBE3D2A@delong.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD96EF@ENI-MAIL.eclipse-networks.com> Yes of course there is some right-sizing intertwined with needs testing in existing policies which blurs the actual real-life effect. You make my point in your description of what happens with allocation requests. When a larger organization requests a larger block they probably will come away from it with an allocation, possibly smaller than requested (and prefer) but they are likely to receive an allocation none the less. When a small organization requests the minimum block size and that request is refused because of policy, they get nothing at all. No matter how you slice it that is an un-even playing field and is arbitrary, unfair, and discriminatory against small organizations in favor of larger ones. I have been pointing this out for years and I've said it just about every way I know how. It is time this gets corrected to level the playing field for all. The needs tests need to go! Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, June 6, 2014 12:25 AM To: Steven Ryerse Cc: John Santos; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Jun 5, 2014, at 7:10 PM, Steven Ryerse wrote: > My post was in fact the lines below with the single > in front of them. > > Yes I have advocated right-sizing instead of needs testing several times. Right sizing and needs testing have some similarities and in my opinion are easily confused. A needs test ends up in a pass fail or yes no outcome and you either get the requested resources or you don?t. I would add this needs testing can easily be used by the haves to keep the have nots from receiving any resources at all, and in my opinion that is happening. However with a right-sizing test, the outcome always ends up with an allocation being made (or offered) even if it turns out to only be the size of the current policy Minimum. This is a huge difference for a small organization and it levels the playing field for smaller organizations! If that is your definition of needs testing, then in my experience ARIN already engages in ?right-sizing? because many times when I was unable to convince them that my client qualified for what we asked for, they suggested a longer prefix (smaller amount of addresses) that they would approve immediately. We would usually accept their offer with a request that they reserve the original request amount if possible. Then we would implement and fully utilize the original approval and go back for the rest. This usually worked quite well. > I realize that an organization might be allocated (or offered) a smaller allocation than requested, but all organizations can at least get the smallest allocation per the current policy minimum - not always the perfect situation but a lot better than zero resources. Further I don't think this hurts the haves at all (except maybe more competition), and I do not agree that "without needs testing the "haves" would have had it all a long time ago" - as long as right-sizing tests are applied to all. I think that recent policy changes have improved this. I would welcome policy proposals that further improved the situation. Removing needs basis from 8.3 transfers doesn?t do that and it has a number of other harmful outcomes as previously discussed. Owen From SRyerse at eclipse-networks.com Fri Jun 6 01:28:34 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 6 Jun 2014 05:28:34 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <268E77C0-9C5F-4CE6-A753-A205AF6B8EAD@delong.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.809080 6@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> <268E77C0-9C5F-4CE6-A753-A205AF6B8EAD@delong.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD97FC@ENI-MAIL.eclipse-networks.com> Owen, as best as I can tell you have served this community honorably during your years of service. I would not support removing you or any other (who discloses publicly like you do) because you earn at least part of your income consulting with organizations helping them acquire IP resources thru the complexities of existing ARIN policies. The only question I would ask is, would you support a proposal from a member of this community to make the acquisition of IP resources much simpler if it significantly cut into your income? Would every member who serves do so? It's an age old question that is always difficult to answer. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, June 6, 2014 12:05 AM To: Milton L Mueller Cc: Steven Ryerse; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Jun 5, 2014, at 2:15 PM, Milton L Mueller wrote: > Owen, > >> Given the number of sole-proprietors with very small budgets that I >> have obtained IP allocations for over the past several years, I think >> this is an > > Are you doing this on a consulting basis? I am not accusing you of anything here, just think some additional clarity and perhaps COI disclosure might be appropriate here. Yes, I have done this on a consulting basis for a very long time. I have repeatedly disclosed that I do so to the AC on a regular basis. I have checked with both John Curran and Steve Ryan and confirmed that no general COI exists. Each time a policy has come up which might benefit one or more of my clients, I have disclosed this fact and recused myself from the voting if the policy might have any impact on an active client?s current or pending request that I was aware of. I am also the person responsible for Hurricane Electric?s RIR relations and act as the DMR for some of my clients in the ARIN and APNIC elections. I do the number resource applications for Hurricane Electric and act as a senior counselor to others at Hurricane Electric who do resource requests on behalf of our customers. Thank you for giving me the opportunity to clarify this. I do not believe a COI exists, but if one comes to light, I will certainly disclose it and take appropriate action to the best of my ability. Owen From owen at delong.com Fri Jun 6 01:30:45 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jun 2014 22:30:45 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD96EF@ENI-MAIL.eclipse-networks.com> References: <1140605212432.46270A-100000@Ives.egh.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD8B14@ENI-MAIL.eclipse-networks.com> <7444FE5F-1694-40E2-BDFD-2CF31EBE3D2A@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD96EF@ENI-MAIL.eclipse-networks.com> Message-ID: I?ve never had even the smallest of sole proprietorships come away with nothing, so I find your argument here specious. Owen On Jun 5, 2014, at 10:16 PM, Steven Ryerse wrote: > Yes of course there is some right-sizing intertwined with needs testing in existing policies which blurs the actual real-life effect. You make my point in your description of what happens with allocation requests. When a larger organization requests a larger block they probably will come away from it with an allocation, possibly smaller than requested (and prefer) but they are likely to receive an allocation none the less. When a small organization requests the minimum block size and that request is refused because of policy, they get nothing at all. No matter how you slice it that is an un-even playing field and is arbitrary, unfair, and discriminatory against small organizations in favor of larger ones. I have been pointing this out for years and I've said it just about every way I know how. It is time this gets corrected to level the playing field for all. The needs tests need to go! > > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Friday, June 6, 2014 12:25 AM > To: Steven Ryerse > Cc: John Santos; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > On Jun 5, 2014, at 7:10 PM, Steven Ryerse wrote: > >> My post was in fact the lines below with the single > in front of them. >> >> Yes I have advocated right-sizing instead of needs testing several times. Right sizing and needs testing have some similarities and in my opinion are easily confused. A needs test ends up in a pass fail or yes no outcome and you either get the requested resources or you don?t. I would add this needs testing can easily be used by the haves to keep the have nots from receiving any resources at all, and in my opinion that is happening. However with a right-sizing test, the outcome always ends up with an allocation being made (or offered) even if it turns out to only be the size of the current policy Minimum. This is a huge difference for a small organization and it levels the playing field for smaller organizations! > > If that is your definition of needs testing, then in my experience ARIN already engages in ?right-sizing? because many times when I was unable to convince them that my client qualified for what we asked for, they suggested a longer prefix (smaller amount of addresses) that they would approve immediately. We would usually accept their offer with a request that they reserve the original request amount if possible. Then we would implement and fully utilize the original approval and go back for the rest. This usually worked quite well. > >> I realize that an organization might be allocated (or offered) a smaller allocation than requested, but all organizations can at least get the smallest allocation per the current policy minimum - not always the perfect situation but a lot better than zero resources. Further I don't think this hurts the haves at all (except maybe more competition), and I do not agree that "without needs testing the "haves" would have had it all a long time ago" - as long as right-sizing tests are applied to all. > > I think that recent policy changes have improved this. I would welcome policy proposals that further improved the situation. > > Removing needs basis from 8.3 transfers doesn?t do that and it has a number of other harmful outcomes as previously discussed. > > Owen > From SRyerse at eclipse-networks.com Fri Jun 6 01:36:32 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 6 Jun 2014 05:36:32 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <1140605212432.46270A-100000@Ives.egh.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD8B14@ENI-MAIL.eclipse-networks.com> <7444FE5F-1694-40E2-BDFD-2CF31EBE3D2A@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD96EF@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD98F3@ENI-MAIL.eclipse-networks.com> Then we agree that we disagree - but I stand by my last comment below which is a clear illustration of exactly how the current policies are stacked against small organizations. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, June 6, 2014 1:31 AM To: Steven Ryerse Cc: John Santos; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers I?ve never had even the smallest of sole proprietorships come away with nothing, so I find your argument here specious. Owen On Jun 5, 2014, at 10:16 PM, Steven Ryerse wrote: > Yes of course there is some right-sizing intertwined with needs testing in existing policies which blurs the actual real-life effect. You make my point in your description of what happens with allocation requests. When a larger organization requests a larger block they probably will come away from it with an allocation, possibly smaller than requested (and prefer) but they are likely to receive an allocation none the less. When a small organization requests the minimum block size and that request is refused because of policy, they get nothing at all. No matter how you slice it that is an un-even playing field and is arbitrary, unfair, and discriminatory against small organizations in favor of larger ones. I have been pointing this out for years and I've said it just about every way I know how. It is time this gets corrected to level the playing field for all. The needs tests need to go! > > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Friday, June 6, 2014 12:25 AM > To: Steven Ryerse > Cc: John Santos; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > On Jun 5, 2014, at 7:10 PM, Steven Ryerse wrote: > >> My post was in fact the lines below with the single > in front of them. >> >> Yes I have advocated right-sizing instead of needs testing several times. Right sizing and needs testing have some similarities and in my opinion are easily confused. A needs test ends up in a pass fail or yes no outcome and you either get the requested resources or you don?t. I would add this needs testing can easily be used by the haves to keep the have nots from receiving any resources at all, and in my opinion that is happening. However with a right-sizing test, the outcome always ends up with an allocation being made (or offered) even if it turns out to only be the size of the current policy Minimum. This is a huge difference for a small organization and it levels the playing field for smaller organizations! > > If that is your definition of needs testing, then in my experience ARIN already engages in ?right-sizing? because many times when I was unable to convince them that my client qualified for what we asked for, they suggested a longer prefix (smaller amount of addresses) that they would approve immediately. We would usually accept their offer with a request that they reserve the original request amount if possible. Then we would implement and fully utilize the original approval and go back for the rest. This usually worked quite well. > >> I realize that an organization might be allocated (or offered) a smaller allocation than requested, but all organizations can at least get the smallest allocation per the current policy minimum - not always the perfect situation but a lot better than zero resources. Further I don't think this hurts the haves at all (except maybe more competition), and I do not agree that "without needs testing the "haves" would have had it all a long time ago" - as long as right-sizing tests are applied to all. > > I think that recent policy changes have improved this. I would welcome policy proposals that further improved the situation. > > Removing needs basis from 8.3 transfers doesn?t do that and it has a number of other harmful outcomes as previously discussed. > > Owen > From owen at delong.com Fri Jun 6 01:37:32 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jun 2014 22:37:32 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD97FC@ENI-MAIL.eclipse-networks.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.out look.com><538F3B35.809080 6@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> <268E77C0-9C5F-4CE6-A753-A205AF6B8EAD@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD97FC@ENI-MAIL.eclipse-networks.com> Message-ID: On Jun 5, 2014, at 10:28 PM, Steven Ryerse wrote: > Owen, as best as I can tell you have served this community honorably during your years of service. I would not support removing you or any other (who discloses publicly like you do) because you earn at least part of your income consulting with organizations helping them acquire IP resources thru the complexities of existing ARIN policies. Thank you. > > The only question I would ask is, would you support a proposal from a member of this community to make the acquisition of IP resources much simpler if it significantly cut into your income? Would every member who serves do so? It's an age old question that is always difficult to answer. > If I did not feel it had other overwhelming negative consequences, then I would absolutely support such a policy and I have a track record of doing so. For one thing, it couldn?t ?significantly? cut into my income. I make less than $5,000 per year doing this kind of consulting which is not a significant fraction of my income. While I usually (not always) charge for assisting organizations with their IP requests, it?s not my primary source of income and I do it primarily to help those organizations. I absolutely express my opinions of policy based on my idea of whether it is fair and in the best interests of the full community or not. Many will call me crazy, irresponsible, or whatever other adjective, but I believe that the process works best when people of integrity work towards the interests of the community rather than simply their own interests or those of the organizations that employ them. I will not deny that my experiences and my position likely color my judgment of what that is. However, I try to give any idea fair consideration to the best of my ability. When I oppose a policy proposal, I will always tell you why I oppose it. The same with when I support one. When I look at support of or opposition to a proposal from others, I also look for why they are supporting or opposing it and I look for ways to modify the proposal to bring it to a broader consensus if possible. Owen From matthew at matthew.at Fri Jun 6 04:59:16 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 06 Jun 2014 11:59:16 +0300 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <7444FE5F-1694-40E2-BDFD-2CF31EBE3D2A@delong.com> References: <1140605212432.46270A-100000@Ives.egh.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD8B14@ENI-MAIL.eclipse-networks.com> <7444FE5F-1694-40E2-BDFD-2CF31EBE3D2A@delong.com> Message-ID: <539182E4.2010904@matthew.at> On 6/6/2014 7:24 AM, Owen DeLong wrote: > Removing needs basis from 8.3 transfers doesn?t do that and it has a number of other harmful outcomes as previously discussed. > Can you name a harmful outcome of removing needs basis from 8.3 transfers that doesn't already exist in the form of contracts that lock sellers to future buyers and/or contracts that allow the use of address space by another entity? Matthew Kaufman From owen at delong.com Fri Jun 6 07:31:14 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 6 Jun 2014 12:31:14 +0100 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <539182E4.2010904@matthew.at> References: <1140605212432.46270A-100000@Ives.egh.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD8B14@ENI-MAIL.eclipse-networks.com> <7444FE5F-1694-40E2-BDFD-2CF31EBE3D2A@delong.com> <539182E4.2010904@matthew.at> Message-ID: > On Jun 6, 2014, at 9:59 AM, Matthew Kaufman wrote: > >> On 6/6/2014 7:24 AM, Owen DeLong wrote: >> Removing needs basis from 8.3 transfers doesn?t do that and it has a number of other harmful outcomes as previously discussed. >> > > Can you name a harmful outcome of removing needs basis from 8.3 transfers that doesn't already exist in the form of contracts that lock sellers to future buyers and/or contracts that allow the use of address space by another entity? As I have stated, we cannot block all mechanisms which circumvent policy. Yes, you can still produce the negative outcomes by circumventing the intent of policy. Bad actors will, of course do so. If you have strategies for effectively preventing bad actors from doing so, then I am open to discussing those. If you just want to use the fact that bad actors can circumvent policy by means we cannot control as a justification for eliminating policy, then this has been discussed and I still find that position unconvincing. Owen From michael at linuxmagic.com Fri Jun 6 10:50:58 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Fri, 06 Jun 2014 07:50:58 -0700 Subject: [arin-ppml] Simple question to simplify the rhetoric.. Message-ID: <5391D552.9060504@linuxmagic.com> There is a lot of back and forth now on opinions, and while that is great that people are involved, the message might get lost in the noise, so I suggest that we go back to making it simple, so feedback can help guide ARIN directions.. As a community we have to present a clear message either way, and then move on.. The choices are, simply maintain the current standards, and let people get IP Space as it has been, until we run out and then let the free market take over, or show enough support from the community that ARIN should change direction, and start acting as a 'judge' for whom should receive the remaining IP Space.. IF the later is decided, the we can worry about helping create policies on how to judge those requirements. The current system as it stands, it does make it simpler for the 'speculators' to get IP Space, (I still think we need to help ARIN set policies on how to get space back from speculators or those currently not following the existing policies), and the concern is whether that inhibits the ability of smaller needs based operators getting some before it runs out. Why don't we first of all all express our simple votes.. A) Leave the current system alone, and let the free market work it out B) Enpower ARIN with more abilities to 'judge' who gets the remaining space If we can't get overwhelming support for B, then the needs based argument is moot.. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From mike at iptrading.com Fri Jun 6 10:57:38 2014 From: mike at iptrading.com (Mike Burns) Date: Fri, 6 Jun 2014 10:57:38 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: Message-ID: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> Hi Larry, "Personally I suspect that without needs testing the "haves" would have had it all a long time ago. I have felt the same frustration, as a small provider, trying to meet the 80% requirement can be almost impossible without gaming the system due to numerous small holes in a small allocation. That said, I worry about any company that could purchase a couple of Billion dollars of IPV4." What is being expressed here is a fear of hoarding in the absence of a needs test. A couple of billion dollars of IPv4 at current prices would yield about 15 /8s. Even if some company wanted to risk those funds with IPv6 transition threatening to erase them, there is no single seller who could offer 15 /8s, nor would the sequestration of 15 /8s destroy the market, since this amount represents just 25% of the estimated market size of 1 billion addresses. Since the buyer and seller will be disclosed and registered under any no-needs policy, there is little threat of a stealthy move here, and any buyer seeking to corner or manipulate the market knows he does so at the peril of forcing the IPv6 transition. The best protection against this is continued work towards IPv6 and the establishment of a reliable, open, and global IPv4 market with at least the same level of transparency into registration as we have now. As a broker, I actively sought out speculators to bid for addresses in the Nortel sale. This was a prime opportunity to acquire 660,000 addresses at the floor of the market, but it was regarded as too risky by almost all. In the intervening years I became aware of other opportunities to acquire address space without needs tests, but I never found anybody interested in buying addresses on pure speculation. In any case, this fear can only reasonably be expressed in the context of a complete removal of needs tests, and could not be applied to a more limited removal of the needs test such as that proposed in 2014-14. "Many of us fear that if need is not considered in the transfer market the little guys will find that none is available at any price." We are three years into the open, post-Microsoft/Nortel market and there is no evidence of hoarding in my experience. I have never fielded a phone call or email from any company or individual seeking addresses they didn't plan to utilize at some point, although I have fielded plenty from people seeking addresses that for whatever reason ARIN policy would prohibit them from registering. Perhaps other brokers on the list might report on their experiences. "Like it or not the big guys have an advantage. Let's make sure that "cornering the market" isn't one of them." Little guys benefit from the dropping of needs test for small transfers. No need to navigate the ARIN process if you just need a /24 and you can't get one from your upstream, or not at a reasonable cost, or because you feel more secure with your own space, or because you don't wish to game the system. Support of 2014-14 would allow small companies to have this option while preventing hoarding or speculation through limits on size and number of transfers. Perhaps you care to comment on whether you might consider support of 2014-14 at the current size of /16 or at another size that you might feel more appropriate? Regards, Mike Burns IPTrading.com From mueller at syr.edu Fri Jun 6 11:06:24 2014 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 6 Jun 2014 15:06:24 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> Message-ID: <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> This debate has descended into rather nasty and unconstructive name calling. So if I am not mistaken with the attribution here, we have Woodcock calling Huberman 'idiotic,' a devotee of Ayn Rand (how did she get in here?), the moral equivalent of a slave trader, and a self-indulgent non-adult. May I ask that this stop? Bill, the entire community has already recognized the legitimacy of markets for IPv4 numbers. Transfer markets are institutionalized and have been for 4 years. So any argument that is based on comparing it to the slave/drug trade is gone. All we are debating is the presence or absence of needs assessment as a gatekeeping function for that market. This is a fairly administrative and technical argument, not a moral one. Efficiency is the key criterion (not fairness, really). If you support needs assessments you have to make a case that the costs and burdens associated with it are justified by quantifiable benefits. In this case, inefficiency is unfairness: if the needs assessment process prevents resources from going where they are wanted most, or if the cost burdens associated with the process exceed the value of the numbers acquired for small operators, or if it is shown that large, established companies with well-established relationships to ARIN can navigate the process more easily, then there are signs that needs assessment is unfair because of its inefficiencies. You have to do a better job of explaining why it is "fair" to force a willing seller and a willing buyer to submit to an additional step when that step both limits the quantity of resources available for transfer and raises the cost of participating in the market by a substantial degree. --MM -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Woodcock Your argument that ARIN needs to step out of the way of the human slaves market, recognize its validity, and duly record the transfers of those slaves, because Ayn Rand, is idiotic. And if you think that's not what you just said, you need to step back and reflect a little before touching your keyboard. We self-regulate, rather than wallowing in the trough of self-indulgence, because we are (speaking collectively and aspirationally, at least) adults. As such, we don't want our power to self-regulate removed. From jcurran at arin.net Fri Jun 6 11:21:18 2014 From: jcurran at arin.net (John Curran) Date: Fri, 6 Jun 2014 15:21:18 +0000 Subject: [arin-ppml] Simple question to simplify the rhetoric.. In-Reply-To: <5391D552.9060504@linuxmagic.com> References: <5391D552.9060504@linuxmagic.com> Message-ID: On Jun 6, 2014, at 10:50 AM, Michael Peddemors wrote: > Why don't we first of all all express our simple votes.. > > A) Leave the current system alone, and let the free market work it out > B) Enpower ARIN with more abilities to 'judge' who gets the remaining space Michael - There's actually a matrix of possible conditions, which makes things rather more complicated - In particular, there are the requirements for receiving space from the regional free pool versus requirements for being a recipient of a market transfer. And then, for both of the above cases, there's what requirements should apply at present, as compared to once the regional free pool has effectively depleted (with new requesters being placed on the wait list.) It is possible to discuss of a subset of these conditions (e.g. transfer policy both present and post-depletion, or pre-depletion policy for both free pool and transfers) in order to simplify the discussion, but when doing so it would be best to be rather explicit about the question being asked... Thanks! /John John Curran President and CEO ARIN From michael at linuxmagic.com Fri Jun 6 11:32:58 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Fri, 06 Jun 2014 08:32:58 -0700 Subject: [arin-ppml] Simple question to simplify the rhetoric.. In-Reply-To: References: <5391D552.9060504@linuxmagic.com> Message-ID: <5391DF2A.90803@linuxmagic.com> On 14-06-06 08:21 AM, John Curran wrote: > On Jun 6, 2014, at 10:50 AM, Michael Peddemors wrote: > >> Why don't we first of all all express our simple votes.. >> >> A) Leave the current system alone, and let the free market work it out >> B) Enpower ARIN with more abilities to 'judge' who gets the remaining space > > Michael - > > In particular, there are the requirements for receiving space from the regional > free pool versus requirements for being a recipient of a market transfer. Understood of course, however I believe a consensus or even a productive conversation in either case can't be had, unless the community first agrees in principle to a fundamental change in ARIN's role, where it is transfer's or allocation of new IP(s). -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From ajs at anvilwalrusden.com Fri Jun 6 11:43:59 2014 From: ajs at anvilwalrusden.com (Andrew Sullivan) Date: Fri, 6 Jun 2014 11:43:59 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> References: <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> Message-ID: <20140606154359.GR25470@mx1.yitter.info> On Fri, Jun 06, 2014 at 03:06:24PM +0000, Milton L Mueller wrote: > You have to do a better job of explaining why it is "fair" to force a willing seller and a willing buyer to submit to an additional step when that step both limits the quantity of resources available for transfer and raises the cost of participating in the market by a substantial degree. > Not only that. If you believe that the purpose of self-regulation is to avoid legislators coming in, you need to explain why the self-regulation is not burdensome, lest legislators decide that such a burden is unreasonable and should be taken over by "adults" (where "adults" and "legislators" are conflated). A -- Andrew Sullivan ajs at anvilwalrusden.com From matthew at matthew.at Fri Jun 6 13:04:29 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 06 Jun 2014 20:04:29 +0300 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <1140605212432.46270A-100000@Ives.egh.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD8B14@ENI-MAIL.eclipse-networks.com> <7444FE5F-1694-40E2-BDFD-2CF31EBE3D2A@delong.com> <539182E4.2010904@matthew.at> Message-ID: <5391F49D.1000202@matthew.at> On 6/6/2014 2:31 PM, Owen DeLong wrote: > >> On Jun 6, 2014, at 9:59 AM, Matthew Kaufman wrote: >> >>> On 6/6/2014 7:24 AM, Owen DeLong wrote: >>> Removing needs basis from 8.3 transfers doesn?t do that and it has a number of other harmful outcomes as previously discussed. >>> >> Can you name a harmful outcome of removing needs basis from 8.3 transfers that doesn't already exist in the form of contracts that lock sellers to future buyers and/or contracts that allow the use of address space by another entity? > As I have stated, we cannot block all mechanisms which circumvent policy. Yes, you can still produce the negative outcomes by circumventing the intent of policy. Bad actors will, of course do so. If you have strategies for effectively preventing bad actors from doing so, then I am open to discussing those. > > If you just want to use the fact that bad actors can circumvent policy by means we cannot control as a justification for eliminating policy, then this has been discussed and I still find that position unconvincing. > > That's only the first part of said justification. First off, lets stop calling them "bad actors": A company with shareholders that knows it will need IPv4 space over the next 3 years has employees that are legally obligated to enter contracts that will ensure that they can acquire that space once ARIN can not longer provide it. These contracts will take the form of right of first refusal, lock-ups, or leasing of space and none of them can be controlled or prevented by ARIN. The employees are not acting in bad faith and the companies are not as a result "bad actors". They are simply participants in a market for a limited resource... no need to assign a value judgement to them. And there will be "needs justification"... only it will be done by the interaction of the market and their CFO... the company will work out how much space it needs over what it believes is a reasonable planning horizon and then use that as justification for releasing the funds necessary to enter into those contracts. Next, I and many others believe that there is a danger to the registry once such a market becomes prevalent. Specifically, that the accuracy of the registry will suffer. It will, more and more often, fail to reflect who is using and/or controlling the use of the address space, instead containing some historical trivia. I can foresee an avalanche effect, where as the registry becomes less and less accurate, participants in the IPv4 market find it less and less necessary to ensure that their own transfers or leases are reflected in the registry... a sort of "broken windows" effect where it simply becomes more and more acceptable to not care. If you think that's a likely outcome, and that such a thing would be bad for ARIN, you should support making it easier for people who are doing perfectly legitimate things to record those things in the registry. I do. If you think that the market prices and the long-term risk created by the introduction of IPv6 make hoarding and speculation or even significantly overestimating ones own need unlikely, then there's no reason to oppose removing specific needs justification as a requirement to record a transfer in the registry. I don't. Matthew Kaufman From SRyerse at eclipse-networks.com Fri Jun 6 13:26:22 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 6 Jun 2014 17:26:22 +0000 Subject: [arin-ppml] Simple question to simplify the rhetoric.. In-Reply-To: <5391DF2A.90803@linuxmagic.com> References: <5391D552.9060504@linuxmagic.com> <5391DF2A.90803@linuxmagic.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AADA3E1@ENI-MAIL.eclipse-networks.com> Of course those are not the only two options. We could choose C: Open up the market by removing needs testing along the lines of what RIPE is doing and let the market work that out. We could also D: Embrace and join the private market that has sprung up outside of ARIN and legitimize it and work closely with it at the policy level. (This has the added benefit of improving the accuracy of the Database.) There are probably other options. 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? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Peddemors Sent: Friday, June 06, 2014 11:33 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Simple question to simplify the rhetoric.. On 14-06-06 08:21 AM, John Curran wrote: > On Jun 6, 2014, at 10:50 AM, Michael Peddemors wrote: > >> Why don't we first of all all express our simple votes.. >> >> A) Leave the current system alone, and let the free market work it >> out >> B) Enpower ARIN with more abilities to 'judge' who gets the remaining >> space > > Michael - > > In particular, there are the requirements for receiving space from the regional > free pool versus requirements for being a recipient of a market transfer. Understood of course, however I believe a consensus or even a productive conversation in either case can't be had, unless the community first agrees in principle to a fundamental change in ARIN's role, where it is transfer's or allocation of new IP(s). -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. _______________________________________________ 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 John at qxccommunications.com Fri Jun 6 13:40:18 2014 From: John at qxccommunications.com (John Von Stein) Date: Fri, 6 Jun 2014 17:40:18 +0000 Subject: [arin-ppml] Simple question to simplify the rhetoric.. In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AADA3E1@ENI-MAIL.eclipse-networks.com> References: <5391D552.9060504@linuxmagic.com> <5391DF2A.90803@linuxmagic.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AADA3E1@ENI-MAIL.eclipse-networks.com> Message-ID: My 2-cents on this thread ? Having been in the commodity/derivative/equity trading businesses for 25 years before starting an ISP I concur that a Market will likely evolve for US IPv4. The fundamentals of Supply and Demand for IPv4 will prevail. It?s probably happening already, akin to the ?dark pools? of off-exchange trading that were siphoning large amounts of trading volume away from the regulated equity exchanges. This community, including ARIN, can either embrace and guide this tectonic shift from single source of IP (ARIN) to a Market of IP address suppliers / consumers from the playing field or else be left with absolute control over essentially an empty bag of allocations and watching the aftermarket activity from the sideline. Thank you, John W. Von Stein [cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] 102 NE 2nd Street Suite 136 Boca Raton, FL 33432 Office: 561-288-6989 www.QxCcommunications.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Friday, June 6, 2014 1:26 PM To: Michael Peddemors; arin-ppml at arin.net Subject: Re: [arin-ppml] Simple question to simplify the rhetoric.. Of course those are not the only two options. We could choose C: Open up the market by removing needs testing along the lines of what RIPE is doing and let the market work that out. We could also D: Embrace and join the private market that has sprung up outside of ARIN and legitimize it and work closely with it at the policy level. (This has the added benefit of improving the accuracy of the Database.) There are probably other options. 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? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Peddemors Sent: Friday, June 06, 2014 11:33 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Simple question to simplify the rhetoric.. On 14-06-06 08:21 AM, John Curran wrote: > On Jun 6, 2014, at 10:50 AM, Michael Peddemors > wrote: > >> Why don't we first of all all express our simple votes.. >> >> A) Leave the current system alone, and let the free market work it >> out >> B) Enpower ARIN with more abilities to 'judge' who gets the remaining >> space > > Michael - > > In particular, there are the requirements for receiving space from the regional > free pool versus requirements for being a recipient of a market transfer. Understood of course, however I believe a consensus or even a productive conversation in either case can't be had, unless the community first agrees in principle to a fundamental change in ARIN's role, where it is transfer's or allocation of new IP(s). -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2999 bytes Desc: image001.jpg URL: From jschiller at google.com Fri Jun 6 14:29:25 2014 From: jschiller at google.com (Jason Schiller) Date: Fri, 6 Jun 2014 14:29:25 -0400 Subject: [arin-ppml] Simple question to simplify the rhetoric.. In-Reply-To: References: <5391D552.9060504@linuxmagic.com> <5391DF2A.90803@linuxmagic.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AADA3E1@ENI-MAIL.eclipse-networks.com> Message-ID: I think the question here is does justified need provide value to the community in creating "fairness"? A. Yes, keep measuring justified need as we always have. B. Yes, keep measuring justified need as we always have until something better comes along. C. Yes, I'm not sure this is the most fair, but it has been the rules of the game, and doesn't seem right to change the rules so close to the finish line (especially when people's IPv6 adoption plans are depending on it). D. Yes, but there is a specific problem that results in some class being treated unfairly, so a tweak or two is required. E. Yes, but a needs test only makes sense when addresses can be acquired unrestricted or with flat or tiered pricing or even per low priced IP address pricing. In a limited market, price is the most efficient and most fair mechanism. F. No, there is a better mechanism that is "more fair" we should switch to that immediately. G. Its not justified need isn't fair, but rather the fact that there are a class of users whose justified need will not be fulfilled, such as individuals (not an organization) or organizations that need only a small amount of addressing (less than a /24 which is the arbitrary limit for inetr-AS routing to keep tables small). H. Unrelated... while the current needs based justification is fair, the process is difficult and the end result favors large organizations, those who are growing rapidly (and thus repeated ask for space), those with a dedicated IP management team, those with a dedicated legal team... The process (not the policy) is unfair. __Jason On Fri, Jun 6, 2014 at 1:40 PM, John Von Stein wrote: > My 2-cents on this thread ? > > > > Having been in the commodity/derivative/equity trading businesses for 25 > years before starting an ISP I concur that a Market will likely evolve for > US IPv4. The fundamentals of Supply and Demand for IPv4 will prevail. > It?s probably happening already, akin to the ?dark pools? of off-exchange > trading that were siphoning large amounts of trading volume away from the > regulated equity exchanges. This community, including ARIN, can either > embrace and guide this tectonic shift from single source of IP (ARIN) to a > Market of IP address suppliers / consumers from the playing field or else > be left with absolute control over essentially an empty bag of allocations > and watching the aftermarket activity from the sideline. > > > > Thank you, > > John W. Von Stein > > > > [image: cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] > > > > 102 NE 2nd Street > > Suite 136 > > Boca Raton, FL 33432 > > Office: 561-288-6989 > > www.QxCcommunications.com > > > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Steven Ryerse > Sent: Friday, June 6, 2014 1:26 PM > To: Michael Peddemors; arin-ppml at arin.net > Subject: Re: [arin-ppml] Simple question to simplify the rhetoric.. > > > > Of course those are not the only two options. > > > > We could choose C: Open up the market by removing needs testing along the > lines of what RIPE is doing and let the market work that out. > > > > We could also D: Embrace and join the private market that has sprung up > outside of ARIN and legitimize it and work closely with it at the policy > level. (This has the added benefit of improving the accuracy of the > Database.) > > > > There are probably other options. > > > > 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? > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net > ] On Behalf Of Michael Peddemors > > Sent: Friday, June 06, 2014 11:33 AM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Simple question to simplify the rhetoric.. > > > > On 14-06-06 08:21 AM, John Curran wrote: > > > On Jun 6, 2014, at 10:50 AM, Michael Peddemors > wrote: > > > > > >> Why don't we first of all all express our simple votes.. > > >> > > >> A) Leave the current system alone, and let the free market work it > > >> out > > >> B) Enpower ARIN with more abilities to 'judge' who gets the remaining > > >> space > > > > > > Michael - > > > > > > In particular, there are the requirements for receiving space from > the regional > > > free pool versus requirements for being a recipient of a market > transfer. > > > > Understood of course, however I believe a consensus or even a productive > conversation in either case can't be had, unless the community first agrees > in principle to a fundamental change in ARIN's role, where it is transfer's > or allocation of new IP(s). > > > > > > > > -- > > "Catch the Magic of Linux..." > > ------------------------------------------------------------------------ > > Michael Peddemors, President/CEO LinuxMagic Inc. > > Visit us at http://www.linuxmagic.com @linuxmagic > > ------------------------------------------------------------------------ > > A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a > Registered TradeMark of Wizard Tower TechnoServices Ltd. > > ------------------------------------------------------------------------ > > 604-682-0300 Beautiful British Columbia, Canada > > > > This email and any electronic data contained are confidential and intended > solely for the use of the individual or entity to which they are addressed. > > Please note that any views or opinions presented in this email are solely > those of the author and are not intended to represent those of the company. > > _______________________________________________ > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2999 bytes Desc: not available URL: From jcurran at arin.net Fri Jun 6 14:41:37 2014 From: jcurran at arin.net (John Curran) Date: Fri, 6 Jun 2014 18:41:37 +0000 Subject: [arin-ppml] Simple question to simplify the rhetoric.. In-Reply-To: References: <5391D552.9060504@linuxmagic.com> <5391DF2A.90803@linuxmagic.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AADA3E1@ENI-MAIL.eclipse-networks.com> Message-ID: <68814A1D-9638-45B5-BA22-16A669F02D8E@corp.arin.net> Jason - Are you asking with respect to new issuance from the IPv4 free pool, or with respect to IPv4 transfers, or both? Some folks might choose a different answer from your list depending on which one you are referring. Thanks, /John John Curran President and CEO ARIN On Jun 6, 2014, at 2:29 PM, Jason Schiller > wrote: I think the question here is does justified need provide value to the community in creating "fairness"? A. Yes, keep measuring justified need as we always have. B. Yes, keep measuring justified need as we always have until something better comes along. C. Yes, I'm not sure this is the most fair, but it has been the rules of the game, and doesn't seem right to change the rules so close to the finish line (especially when people's IPv6 adoption plans are depending on it). D. Yes, but there is a specific problem that results in some class being treated unfairly, so a tweak or two is required. E. Yes, but a needs test only makes sense when addresses can be acquired unrestricted or with flat or tiered pricing or even per low priced IP address pricing. In a limited market, price is the most efficient and most fair mechanism. F. No, there is a better mechanism that is "more fair" we should switch to that immediately. G. Its not justified need isn't fair, but rather the fact that there are a class of users whose justified need will not be fulfilled, such as individuals (not an organization) or organizations that need only a small amount of addressing (less than a /24 which is the arbitrary limit for inetr-AS routing to keep tables small). H. Unrelated... while the current needs based justification is fair, the process is difficult and the end result favors large organizations, those who are growing rapidly (and thus repeated ask for space), those with a dedicated IP management team, those with a dedicated legal team... The process (not the policy) is unfair. __Jason On Fri, Jun 6, 2014 at 1:40 PM, John Von Stein > wrote: My 2-cents on this thread ? Having been in the commodity/derivative/equity trading businesses for 25 years before starting an ISP I concur that a Market will likely evolve for US IPv4. The fundamentals of Supply and Demand for IPv4 will prevail. It?s probably happening already, akin to the ?dark pools? of off-exchange trading that were siphoning large amounts of trading volume away from the regulated equity exchanges. This community, including ARIN, can either embrace and guide this tectonic shift from single source of IP (ARIN) to a Market of IP address suppliers / consumers from the playing field or else be left with absolute control over essentially an empty bag of allocations and watching the aftermarket activity from the sideline. Thank you, John W. Von Stein [cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] 102 NE 2nd Street Suite 136 Boca Raton, FL 33432 Office: 561-288-6989 www.QxCcommunications.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: Friday, June 6, 2014 1:26 PM To: Michael Peddemors; arin-ppml at arin.net Subject: Re: [arin-ppml] Simple question to simplify the rhetoric.. Of course those are not the only two options. We could choose C: Open up the market by removing needs testing along the lines of what RIPE is doing and let the market work that out. We could also D: Embrace and join the private market that has sprung up outside of ARIN and legitimize it and work closely with it at the policy level. (This has the added benefit of improving the accuracy of the Database.) There are probably other options. 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? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Peddemors Sent: Friday, June 06, 2014 11:33 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Simple question to simplify the rhetoric.. On 14-06-06 08:21 AM, John Curran wrote: > On Jun 6, 2014, at 10:50 AM, Michael Peddemors > wrote: > >> Why don't we first of all all express our simple votes.. >> >> A) Leave the current system alone, and let the free market work it >> out >> B) Enpower ARIN with more abilities to 'judge' who gets the remaining >> space > > Michael - > > In particular, there are the requirements for receiving space from the regional > free pool versus requirements for being a recipient of a market transfer. Understood of course, however I believe a consensus or even a productive conversation in either case can't be had, unless the community first agrees in principle to a fundamental change in ARIN's role, where it is transfer's or allocation of new IP(s). -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2999 bytes Desc: image001.jpg URL: From farmer at umn.edu Fri Jun 6 15:56:39 2014 From: farmer at umn.edu (David Farmer) Date: Fri, 06 Jun 2014 14:56:39 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <538CA0A1.5080400@umn.edu> References: <1140519223408.47993A-100000@Ives.egh.com> <537B98CA.3030106@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com> <537D069B.5030601@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com> <538A4FE9.9010900@umn.edu> <8695009A81378E48879980039EEDAD28013850D859@MAIL1.polartel.local> <538CA0A1.5080400@umn.edu> Message-ID: <53921CF7.90607@umn.edu> On 6/2/14, 11:04 , David Farmer wrote: > On 6/2/14, 09:26 , Kevin Kargel wrote: >> I will respectfully disagree. What is the point of ?should?? Even in >> the example you gave it would better as ?must unless? or ?shall unless? >> instead of ?should unless? . With ?should? there is no reason for the >> unless because there is no requirement to do otherwise in the first >> place. >> >> Should leaves a loophole that can be easily exploited, i.e. ?you never >> said we had to do that, you just said we should, so I can technically do >> whatever I want?.. > > Sorry, I don't have time to debate this issue in general at this moment. > The PPC at NANOG 61 is just over 24 hours away. > >> It would be perfectly functional to say: >> >> ?The allocation size shall be consistent with the existing ARIN minimum >> allocation sizes, unless small allocations are intended to be explicitly >> part of the experiment.? > > Are you suggesting we should also change that sentence as well? If you > are I need to know ASAP, like I said the PPC is just over 24 hours away > and I have to finalize the presentation ASAP. I would also like to hear > support from a couple others on PPML before opening that sentence also > to changes, as well. I don't feel I got sufficient support to modify this sentences on PPML prior to the PPC. Also, I discussed this sentence with a couple other AC members and with ARIN Staff. Given the "should" is immediately followed by a conditional "unless" the intent seems sufficiently clear, the intent is to create a special-case exception, and "should" seems appropriate. Furthermore, "must" or "shall" followed by "unless" seemed an awkward way to create such an exception. Therefore, I did not include any changes to this sentence in the Editorial Changes presented at the PPC. >> Using ?should? in the statement makes it a no-op. With ?should? you can >> choose not to follow what is only a suggestion. If you use ?shall? or >> ?must? you have enforceable policy. If the policy is not enforceable it >> is nothing more than a best practice statement at best. > > I also respectfully disagree. However, I will discuss the issue with > ARIN staff here at NANOG to understand how they interpret this issue. Staff generally agrees that in most cases for policy "must" is preferred and it is best to avoid "should" in most cases. However, in the sentence above the intent seem clear enough and "should" seems appropriate in that particular case. Thanks -- ================================================ 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 Fri Jun 6 16:00:55 2014 From: farmer at umn.edu (David Farmer) Date: Fri, 06 Jun 2014 15:00:55 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <537A9341.9080804@arin.net> References: <537A9341.9080804@arin.net> Message-ID: <53921DF7.5000108@umn.edu> The following is the final version of Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy presented to the PPC with the Editorial Changes discussed on PPML. The slides presented at the PPC are at; https://www.arin.net/participate/meetings/reports/ppc_nanog61/2014-12.pdf There were no objections raised at the PPC to the AC incorporating the Proposed Editorial Changes based on PPML feedback prior to Last Call. Are there any on PPML? ---- Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy Date: 3 June 2014 Problem Statement: ARIN should not give research organizations permission to hijack prefixes that have already been allocated. Research organizations announcing lit aggregates may receive sensitive production traffic belonging to live networks during periods of instability. Section 11.7 describes more than allocation size therefore updating the section heading to something more accurate is appropriate. Policy statement: Modify the section 11.7 heading to be more accurate. Modify the first sentence to prohibit overlapping assignments. Add text at the end to define how research allocations should be designated. Modify the third sentence to clarify the original policy intent regarding justification for allocations larger than the applicable minimum. 11.7 Resource Allocation Guidelines The Numbering Resources requested come from the global Internet Resource space, do not overlap currently assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resources than stipulated by the applicable minimum allocation size in force at the time of its request, the request must clearly describe and justify why a larger allocation is required. All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. Comments: a. Timetable for implementation: Immediate b. Anything else: -- ================================================ 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 lsawyer at gci.com Fri Jun 6 16:04:54 2014 From: lsawyer at gci.com (Leif Sawyer) Date: Fri, 6 Jun 2014 12:04:54 -0800 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <53921CF7.90607@umn.edu> References: <1140519223408.47993A-100000@Ives.egh.com> <537B98CA.3030106@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com> <537D069B.5030601@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com> <538A4FE9.9010900@umn.edu> <8695009A81378E48879980039EEDAD28013850D859@MAIL1.polartel.local> <538CA0A1.5080400@umn.edu> <53921CF7.90607@umn.edu> Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102C946149A@fnb1mbx01.gci.com> On 6/6/14, 11:04 , David Farmer wrote: > [...]Given the "should" is immediately followed by a conditional "unless" > the intent seems sufficiently clear, the intent is to create a special-case > exception, and "should" seems appropriate. Furthermore, "must" or "shall" > followed by "unless" seemed an awkward way to create such an exception. > > Staff generally agrees that in most cases for policy "must" is preferred > and it is best to avoid "should" in most cases. However, in the sentence > above the intent seem clear enough and "should" seems appropriate in that > particular case. Unfortunately, that still has indirect parsing issues. 1. You should eat an ice-cream cone, unless you ate a taco. [and then you shouldn't...but you still could] 2. You must eat an ice-cream cone, unless you ate a taco. [ sorry, no ice-cream for you, taco-eater. You get a churro instead. ] It's tri-state versus dual-state. If the objective is to refine intent, then we should be most clear about our intent and diminish the grey areas where possible. From bill at tknow.com Fri Jun 6 16:09:57 2014 From: bill at tknow.com (Bill Buhler) Date: Fri, 6 Jun 2014 16:09:57 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102C946149A@fnb1mbx01.gci.com> References: <1140519223408.47993A-100000@Ives.egh.com> <537B98CA.3030106@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com> <537D069B.5030601@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com> <538A4FE9.9010900@umn.edu> <8695009A81378E48879980039EEDAD28013850D859@MAIL1.polartel.local> <538CA0A1.5080400@umn.edu> <53921CF7.90607@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C946149A@fnb1mbx01.gci.com> Message-ID: <66E414654AD098469738606C8E7B03B048A6261318@P1MBX03.HMC1.COMCAST.NET> Seconded, must doesn't hurt the meaning, and is firmer. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leif Sawyer Sent: Friday, June 06, 2014 2:05 PM To: David Farmer; Kevin Kargel; arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy On 6/6/14, 11:04 , David Farmer wrote: > [...]Given the "should" is immediately followed by a conditional "unless" > the intent seems sufficiently clear, the intent is to create a > special-case exception, and "should" seems appropriate. Furthermore, "must" or "shall" > followed by "unless" seemed an awkward way to create such an exception. > > Staff generally agrees that in most cases for policy "must" is > preferred and it is best to avoid "should" in most cases. However, in > the sentence above the intent seem clear enough and "should" seems > appropriate in that particular case. Unfortunately, that still has indirect parsing issues. 1. You should eat an ice-cream cone, unless you ate a taco. [and then you shouldn't...but you still could] 2. You must eat an ice-cream cone, unless you ate a taco. [ sorry, no ice-cream for you, taco-eater. You get a churro instead. ] It's tri-state versus dual-state. If the objective is to refine intent, then we should be most clear about our intent and diminish the grey areas where possible. _______________________________________________ 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 Fri Jun 6 17:04:53 2014 From: jschiller at google.com (Jason Schiller) Date: Fri, 6 Jun 2014 17:04:53 -0400 Subject: [arin-ppml] Simple question to simplify the rhetoric.. In-Reply-To: <68814A1D-9638-45B5-BA22-16A669F02D8E@corp.arin.net> References: <5391D552.9060504@linuxmagic.com> <5391DF2A.90803@linuxmagic.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AADA3E1@ENI-MAIL.eclipse-networks.com> <68814A1D-9638-45B5-BA22-16A669F02D8E@corp.arin.net> Message-ID: I was asking wrt "all of the above". So yes, with respect to pre-ARIN IPv4 depletion, post-ARIN IPv4 depletion, free pool IPv4 address space, IPv4 transfers, IPv6 free pool. I think what Michael was getting at is can we simply express our views on the simple binary question. I think you correctly point out it is not a simple binary question. I was attempting to rephrase the question and keep it simple and get at the essence of the thing people keep arguing about, and come up with a laundry list of the types of answers (A-F). Answer A and E are essentially the same pre-ARIN depletion, but diverge post-ARIN depletion. In my mind, if one believes needs based is fair for ARIN allocations / assignments, but is not fair for transfers because simple market factors are more fair (even per-ARIN depletion) then this fell into the category F "No, there is a better mechanism that is "more fair" we should switch to that immediately." Maybe that is limited thinking on my part. I have inserted a bucket J between E and F (because I think that is where it falls in the spectrum). A. Yes, keep measuring justified need as we always have. B. Yes, keep measuring justified need as we always have until something better comes along. C. Yes, I'm not sure this is the most fair, but it has been the rules of the game, and doesn't seem right to change the rules so close to the finish line (especially when people's IPv6 adoption plans are depending on it). D. Yes, but there is a specific problem that results in some class being treated unfairly, so a tweak or two is required. E. Yes, but a needs test only makes sense when addresses can be acquired unrestricted or with flat or tiered pricing or even per low priced IP address pricing. In a limited market, price is the most efficient and most fair mechanism. J. Yes, keep measuring justified need as we always have for ARIN allocations and assignments because this is the most fair mechanism when there are no market factors in place, but use only market factors for transfer as this is more fair (but sadly can only work for transfers). F. No, there is a better mechanism that is "more fair" we should switch to that immediately. G. Its not justified need isn't fair, but rather the fact that there are a class of users whose justified need will not be fulfilled, such as individuals (not an organization) or organizations that need only a small amount of addressing (less than a /24 which is the arbitrary limit for inetr-AS routing to keep tables small). H. Unrelated... while the current needs based justification is fair, the process is difficult and the end result favors large organizations, those who are growing rapidly (and thus repeated ask for space), those with a dedicated IP management team, those with a dedicated legal team... The process (not the policy) is unfair. My hope was to create a bunch of useful buckets, and see where people stand. These are the loose buckets as I see them based on the part of the conversation I have heard and understood. Certainly I have missed some. __Jason On Fri, Jun 6, 2014 at 2:41 PM, John Curran wrote: > Jason - > > Are you asking with respect to new issuance from the IPv4 free pool, or > with respect to IPv4 transfers, or both? Some folks might choose a > different answer from your list depending on which one you are > referring. > > Thanks, > /John > > John Curran > President and CEO > ARIN > > On Jun 6, 2014, at 2:29 PM, Jason Schiller wrote: > > I think the question here is does justified need provide value to the > community in creating "fairness"? > > A. Yes, keep measuring justified need as we always have. > > B. Yes, keep measuring justified need as we always have until something > better comes along. > > C. Yes, I'm not sure this is the most fair, but it has been the rules of > the game, and doesn't seem right to change the rules so close to the finish > line (especially when people's IPv6 adoption plans are depending on it). > > D. Yes, but there is a specific problem that results in some class being > treated unfairly, so a tweak or two is required. > > E. Yes, but a needs test only makes sense when addresses can be acquired > unrestricted or with flat or tiered pricing or even per low priced IP > address pricing. In a limited market, price is the most efficient and most > fair mechanism. > > F. No, there is a better mechanism that is "more fair" we should switch > to that immediately. > > G. Its not justified need isn't fair, but rather the fact that there are > a class of users whose justified need will not be fulfilled, such as > individuals (not an organization) or organizations that need only a small > amount of addressing (less than a /24 which is the arbitrary limit for > inetr-AS routing to keep tables small). > > H. Unrelated... while the current needs based justification is fair, the > process is difficult and the end result favors large organizations, those > who are growing rapidly (and thus repeated ask for space), those with a > dedicated IP management team, those with a dedicated legal team... The > process (not the policy) is unfair. > > __Jason > > > > On Fri, Jun 6, 2014 at 1:40 PM, John Von Stein > wrote: > >> My 2-cents on this thread ? >> >> >> >> Having been in the commodity/derivative/equity trading businesses for 25 >> years before starting an ISP I concur that a Market will likely evolve for >> US IPv4. The fundamentals of Supply and Demand for IPv4 will prevail. >> It?s probably happening already, akin to the ?dark pools? of off-exchange >> trading that were siphoning large amounts of trading volume away from the >> regulated equity exchanges. This community, including ARIN, can either >> embrace and guide this tectonic shift from single source of IP (ARIN) to a >> Market of IP address suppliers / consumers from the playing field or else >> be left with absolute control over essentially an empty bag of allocations >> and watching the aftermarket activity from the sideline. >> >> >> >> Thank you, >> >> John W. Von Stein >> >> >> >> [image: cid:sigimg0 at 791f5d9d52446f85c6fed00adec61823] >> >> >> >> 102 NE 2nd Street >> >> Suite 136 >> >> Boca Raton, FL 33432 >> >> Office: 561-288-6989 >> >> www.QxCcommunications.com >> >> >> >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they are >> addressed. >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Steven Ryerse >> Sent: Friday, June 6, 2014 1:26 PM >> To: Michael Peddemors; arin-ppml at arin.net >> Subject: Re: [arin-ppml] Simple question to simplify the rhetoric.. >> >> >> >> Of course those are not the only two options. >> >> >> >> We could choose C: Open up the market by removing needs testing along the >> lines of what RIPE is doing and let the market work that out. >> >> >> >> We could also D: Embrace and join the private market that has sprung up >> outside of ARIN and legitimize it and work closely with it at the policy >> level. (This has the added benefit of improving the accuracy of the >> Database.) >> >> >> >> There are probably other options. >> >> >> >> 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? >> >> >> >> >> >> -----Original Message----- >> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net >> ] On Behalf Of Michael Peddemors >> >> Sent: Friday, June 06, 2014 11:33 AM >> >> To: arin-ppml at arin.net >> >> Subject: Re: [arin-ppml] Simple question to simplify the rhetoric.. >> >> >> >> On 14-06-06 08:21 AM, John Curran wrote: >> >> > On Jun 6, 2014, at 10:50 AM, Michael Peddemors >> wrote: >> >> > >> >> >> Why don't we first of all all express our simple votes.. >> >> >> >> >> >> A) Leave the current system alone, and let the free market work it >> >> >> out >> >> >> B) Enpower ARIN with more abilities to 'judge' who gets the remaining >> >> >> space >> >> > >> >> > Michael - >> >> > >> >> > In particular, there are the requirements for receiving space from >> the regional >> >> > free pool versus requirements for being a recipient of a market >> transfer. >> >> >> >> Understood of course, however I believe a consensus or even a productive >> conversation in either case can't be had, unless the community first agrees >> in principle to a fundamental change in ARIN's role, where it is transfer's >> or allocation of new IP(s). >> >> >> >> >> >> >> >> -- >> >> "Catch the Magic of Linux..." >> >> ------------------------------------------------------------------------ >> >> Michael Peddemors, President/CEO LinuxMagic Inc. >> >> Visit us at http://www.linuxmagic.com @linuxmagic >> >> ------------------------------------------------------------------------ >> >> A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a >> Registered TradeMark of Wizard Tower TechnoServices Ltd. >> >> ------------------------------------------------------------------------ >> >> 604-682-0300 Beautiful British Columbia, Canada >> >> >> >> This email and any electronic data contained are confidential and >> intended solely for the use of the individual or entity to which they are >> addressed. >> >> Please note that any views or opinions presented in this email are solely >> those of the author and are not intended to represent those of the company. >> >> _______________________________________________ >> >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2999 bytes Desc: not available URL: From kkargel at polartel.com Fri Jun 6 17:10:42 2014 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 6 Jun 2014 16:10:42 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <53921CF7.90607@umn.edu> References: <1140519223408.47993A-100000@Ives.egh.com> <537B98CA.3030106@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com> <537D069B.5030601@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com> <538A4FE9.9010900@umn.edu> <8695009A81378E48879980039EEDAD28013850D859@MAIL1.polartel.local> <538CA0A1.5080400@umn.edu> <53921CF7.90607@umn.edu> Message-ID: <8695009A81378E48879980039EEDAD2801387EF3C9@MAIL1.polartel.local> David, I understand your position, however in every "should" there is an implied "but", as in "you should (but you don't have to)" or "they should (but they don't)". There is not that issue when you use "You must" or "they will".. As someone else stated - policy has to be binary, it must exactingly lay down procedures and conditions. While it is true that "should" gives staff more freedom, the reason for policy is not to provide ambivalent instruction. Good policy closes loopholes instead of creating them. The same applies with "They must unless" as opposed to "They should (but they don't have to) unless". I maintain that any policy with "should" (or 'may' in absence of 'may not') is a no-op and a waste of time and serves no function at all. While "should" may demonstrate the intent of the rule it is completely unenforceable. Any policy that is unenforceable is actually worse than no policy at all. IMHO, Kevin > -----Original Message----- > From: David Farmer [mailto:farmer at umn.edu] > Sent: Friday, June 06, 2014 2:57 PM > To: Kevin Kargel; arin-ppml at arin.net > Cc: David Farmer > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti- > hijack Policy > > On 6/2/14, 11:04 , David Farmer wrote: > > On 6/2/14, 09:26 , Kevin Kargel wrote: > >> I will respectfully disagree. What is the point of "should"? Even > >> in the example you gave it would better as "must unless" or "shall unless" > >> instead of "should unless" . With "should" there is no reason for > >> the unless because there is no requirement to do otherwise in the > >> first place. > >> > >> Should leaves a loophole that can be easily exploited, i.e. "you > >> never said we had to do that, you just said we should, so I can > >> technically do whatever I want".. > > > > Sorry, I don't have time to debate this issue in general at this moment. > > The PPC at NANOG 61 is just over 24 hours away. > > > >> It would be perfectly functional to say: > >> > >> "The allocation size shall be consistent with the existing ARIN > >> minimum allocation sizes, unless small allocations are intended to be > >> explicitly part of the experiment." > > > > Are you suggesting we should also change that sentence as well? If > > you are I need to know ASAP, like I said the PPC is just over 24 hours > > away and I have to finalize the presentation ASAP. I would also like > > to hear support from a couple others on PPML before opening that > > sentence also to changes, as well. > > I don't feel I got sufficient support to modify this sentences on PPML prior to > the PPC. Also, I discussed this sentence with a couple other AC members and > with ARIN Staff. Given the "should" is immediately followed by a conditional > "unless" the intent seems sufficiently clear, the intent is to create a special- > case exception, and "should" seems appropriate. Furthermore, "must" or > "shall" followed by "unless" seemed an awkward way to create such an > exception. > > Therefore, I did not include any changes to this sentence in the Editorial > Changes presented at the PPC. > > >> Using "should" in the statement makes it a no-op. With "should" you > >> can choose not to follow what is only a suggestion. If you use > >> "shall" or "must" you have enforceable policy. If the policy is not > >> enforceable it is nothing more than a best practice statement at best. > > > > I also respectfully disagree. However, I will discuss the issue with > > ARIN staff here at NANOG to understand how they interpret this issue. > > Staff generally agrees that in most cases for policy "must" is preferred and it > is best to avoid "should" in most cases. However, in the sentence above the > intent seem clear enough and "should" seems appropriate in that particular > case. > > Thanks > > -- > ================================================ > 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 Fri Jun 6 17:39:33 2014 From: farmer at umn.edu (David Farmer) Date: Fri, 06 Jun 2014 16:39:33 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <66E414654AD098469738606C8E7B03B048A6261318@P1MBX03.HMC1.COMCAST.NET> References: <1140519223408.47993A-100000@Ives.egh.com> <537B98CA.3030106@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com> <537D069B.5030601@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com> <538A4FE9.9010900@umn.edu> <8695009A81378E48879980039EEDAD28013850D859@MAIL1.polartel.local> <538CA0A1.5080400@umn.edu> <53921CF7.90607@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C946149A@fnb1mbx01.gci.com> <66E414654AD098469738606C8E7B03B048A6261318@P1MBX03.HMC1.COMCAST.NET> Message-ID: <53923515.1080406@umn.edu> OK, there is an issue, I said I needed to hear from people ASAP, and the PPC was about 24 hours away. On 6/2/14, 11:04 , David Farmer wrote: > On 6/2/14, 09:26 , Kevin Kargel wrote: ... >> It would be perfectly functional to say: >> >> ?The allocation size shall be consistent with the existing ARIN minimum >> allocation sizes, unless small allocations are intended to be >> explicitly part of the experiment.? > > Are you suggesting we should also change that sentence as well? If you are I need to know ASAP, like I said the PPC is just over 24 hours away and I have to finalize the presentation ASAP. I would also like to hear support from a couple others on PPML before opening that sentence also to changes, as well. Kevin, didn't respond and Martin was the only other person that did, I did not take that as sufficient support to open that sentence for changes. Also, I discussed this sentence with staff and other AC members prior to the PPC, no one felt it was necessary to change that sentence. So, I did not present any changes for that sentence at the PPC. Sorry, but it was a judgement call on my part and I had to go with that I had at the time. Here is the issue, the PDP, Part Two says, Section 7. "Last Call" says; If the AC sends a Recommended Draft Policy different than the Recommended Draft Policy presented during the Public Policy Consultation, then the Advisory Council will provide a detailed explanation for all changes to the text and these specific changes must have been discussed during the community consultation. So, I'm not sure we can make any changes to the second sentence since they were not discussed at the PPC. John Curran, am I interpreting that correctly? Therefore, I think the options we have are; 1. Take the text with the editorial changes in the third sentence presented at the PPC to Last Call leaving the second sentence as-is, or; 2. Modify the second sentence, and return this as a Recommended Draft Policy to the PPM in October. Personally, I'm fine with ether option but I need to know what the community wants? Thanks On 6/6/14, 15:09 , Bill Buhler wrote: > Seconded, must doesn't hurt the meaning, and is firmer. > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leif Sawyer > Sent: Friday, June 06, 2014 2:05 PM > To: David Farmer; Kevin Kargel; arin-ppml at arin.net > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy > > On 6/6/14, 11:04 , David Farmer wrote: >> [...]Given the "should" is immediately followed by a conditional "unless" >> the intent seems sufficiently clear, the intent is to create a >> special-case exception, and "should" seems appropriate. Furthermore, "must" or "shall" >> followed by "unless" seemed an awkward way to create such an exception. >> >> Staff generally agrees that in most cases for policy "must" is >> preferred and it is best to avoid "should" in most cases. However, in >> the sentence above the intent seem clear enough and "should" seems >> appropriate in that particular case. > > Unfortunately, that still has indirect parsing issues. > > 1. You should eat an ice-cream cone, unless you ate a taco. > [and then you shouldn't...but you still could] > > 2. You must eat an ice-cream cone, unless you ate a taco. > [ sorry, no ice-cream for you, taco-eater. You get a churro instead. ] > > > It's tri-state versus dual-state. If the objective is to refine intent, then we should be most clear about our intent and diminish the grey areas where possible. -- ================================================ 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 jay at impulse.net Fri Jun 6 18:11:26 2014 From: jay at impulse.net (Jay Hennigan) Date: Fri, 06 Jun 2014 15:11:26 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <66E414654AD098469738606C8E7B03B048A6261318@P1MBX03.HMC1.COMCAST.NET> References: <1140519223408.47993A-100000@Ives.egh.com> <537B98CA.3030106@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com> <537D069B.5030601@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com> <538A4FE9.9010900@umn.edu> <8695009A81378E48879980039EEDAD28013850D859@MAIL1.polartel.local> <538CA0A1.5080400@umn.edu> <53921CF7.90607@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C946149A@fnb1mbx01.gci.com> <66E414654AD098469738606C8E7B03B048A6261318@P1MBX03.HMC1.COMCAST.NET> Message-ID: <53923C8E.80007@impulse.net> On 6/6/14, 1:09 PM, Bill Buhler wrote: > Seconded, must doesn't hurt the meaning, and is firmer. > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leif Sawyer > Sent: Friday, June 06, 2014 2:05 PM > To: David Farmer; Kevin Kargel; arin-ppml at arin.net > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy > > On 6/6/14, 11:04 , David Farmer wrote: >> [...]Given the "should" is immediately followed by a conditional "unless" >> the intent seems sufficiently clear, the intent is to create a >> special-case exception, and "should" seems appropriate. Furthermore, "must" or "shall" >> followed by "unless" seemed an awkward way to create such an exception. >> >> Staff generally agrees that in most cases for policy "must" is >> preferred and it is best to avoid "should" in most cases. However, in >> the sentence above the intent seem clear enough and "should" seems >> appropriate in that particular case. > > Unfortunately, that still has indirect parsing issues. > > 1. You should eat an ice-cream cone, unless you ate a taco. > [and then you shouldn't...but you still could] > > 2. You must eat an ice-cream cone, unless you ate a taco. > [ sorry, no ice-cream for you, taco-eater. You get a churro instead. ] No. 1. Ice cream recommended but optional in all cases, not recommended but permissible for taco-eaters. 2. Ice cream mandatory for non-taco-eaters, optional for taco-eaters. What you are perhaps looking for is: 3. If you ate a taco, you must not eat an ice-cream cone, else you must eat an ice-cream cone. From JOHN at egh.com Fri Jun 6 23:39:45 2014 From: JOHN at egh.com (John Santos) Date: Fri, 6 Jun 2014 23:39:45 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102C946149A@fnb1mbx01.gci.com> Message-ID: <1140606230330.19124C-100000@Ives.egh.com> On Fri, 6 Jun 2014, Leif Sawyer wrote: > On 6/6/14, 11:04 , David Farmer wrote: > > [...]Given the "should" is immediately followed by a conditional "unless" > > the intent seems sufficiently clear, the intent is to create a special-case > > exception, and "should" seems appropriate. Furthermore, "must" or "shall" > > followed by "unless" seemed an awkward way to create such an exception. > > > > Staff generally agrees that in most cases for policy "must" is preferred > > and it is best to avoid "should" in most cases. However, in the sentence > > above the intent seem clear enough and "should" seems appropriate in that > > particular case. > > Unfortunately, that still has indirect parsing issues. I disagree with your parsing of both examples. "Should" implies advice, rather than a requirement. > > 1. You should eat an ice-cream cone, unless you ate a taco. > [and then you shouldn't...but you still could] This statement does NOT imply that you should not eat an ice cream cone if you ate a taco. It says all non-taco eaters are advised to eat an ice-cream cone. It actually says nothing about taco eaters. They can choose whether or not to have an ice-cream cone on their own. > > 2. You must eat an ice-cream cone, unless you ate a taco. > [ sorry, no ice-cream for you, taco-eater. You get a churro instead. ] > Taco eaters can have a cone if they want. It is only non-taco eaters who have a requirement that they eat an ice-cream cone. This statement, like the first. imposes no requirements nor recommendations on taco eaters, one way or the other. > > It's tri-state versus dual-state. If the objective is to refine > intent, then we should be most clear about our intent and diminish > the grey areas where possible. This I agree with. If we're going to go all medieval about language, we must (or should?) do it right. I think all the shoulds should be musts, and also the phrase "experimental documentation" should be replaced by "request" (i.e. "their request must clearly describe and justify why this is required.") However, if the choice is between fixing the bug that causes real world problems (the overlapping allocations of experimental space with allocated space) immediately and fixing all the bugs in 6 months, including those that haven't actually been manifest, I would vote for the immediate fix and would support fixing the rest of the wording later (to answer David's question in a later email.) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From owen at delong.com Sat Jun 7 00:38:50 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 6 Jun 2014 21:38:50 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> Message-ID: On Jun 6, 2014, at 7:57 AM, Mike Burns wrote: > Hi Larry, > > "Personally I suspect that without needs testing the "haves" would have had it all a long time ago. > I have felt the same frustration, as a small provider, trying to meet the 80% requirement can be almost > impossible without gaming the system due to numerous small holes in a small allocation. > That said, I worry about any company that could purchase a couple of Billion dollars of IPV4." > > What is being expressed here is a fear of hoarding in the absence of a needs test. A couple of billion dollars of IPv4 at current prices would yield about 15 /8s. Even if some company wanted to risk those funds with IPv6 transition threatening to erase them, there is no single seller who could offer 15 /8s, nor would the sequestration of 15 /8s destroy the market, since this amount represents just 25% of the estimated market size of 1 billion addresses. Since the buyer and seller will be disclosed and registered under any no-needs policy, there is little threat of a stealthy move here, and any buyer seeking to corner or manipulate the market knows he does so at the peril of forcing the IPv6 transition. The best protection against this is continued work towards IPv6 and the establishment of a reliable, open, and global IPv4 market with at least the same level of transparency into registration as we have now. As a broker, I actively sought out speculators to bid for addresses in the Nortel sale. This was a prime opportunity to acquire 660,000 addresses at the floor of the market, but it was regarded as too risky by almost all. In the intervening years I became aware of other opportunities to acquire address space without needs tests, but I never found anybody interested in buying addresses on pure speculation. In any case, this fear can only reasonably be expressed in the context of a complete removal of needs tests, and could not be applied to a more limited removal of the needs test such as that proposed in 2014-14. Finding 4 actors who want to corner the market probably wouldn?t be very hard. Since 25% is 1/4 of the projected market size, I would say that the rest of your argument is on pretty shaky ground. > "Many of us fear that if need is not considered in the transfer market the little guys will find that none is available at any price." > > We are three years into the open, post-Microsoft/Nortel market and there is no evidence of hoarding in my experience. I have never fielded a phone call or email from any company or individual seeking addresses they didn't plan to utilize at some point, although I have fielded plenty from people seeking addresses that for whatever reason ARIN policy would prohibit them from registering. Perhaps other brokers on the list might report on their experiences. Address space is still available nearly for free from ARIN, especially for smaller organizations, so this isn?t a real test of what will happen post runout and any claim that it is is absurd. > "Like it or not the big guys have an advantage. Let's make sure that "cornering the market" isn't one of them." > > Little guys benefit from the dropping of needs test for small transfers. No need to navigate the ARIN process if you just need a /24 and you can't get one from your upstream, or not at a reasonable cost, or because you feel more secure with your own space, or because you don't wish to game the system. Support of 2014-14 would allow small companies to have this option while preventing hoarding or speculation through limits on size and number of transfers. Perhaps you care to comment on whether you might consider support of 2014-14 at the current size of /16 or at another size that you might feel more appropriate? Again, this is your perspective, but it?s not necessarily entirely true. It?s only true if you assume that the market will have a continuous supply and demand will be lower than supply. I would argue that the number of inter-RIR transfers to the APNIC region which have already been processed would indicate that after exhaustion, this is unlikely to be a persistent state or even last very long at all. Owen From owen at delong.com Sat Jun 7 00:49:06 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 6 Jun 2014 21:49:06 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> Message-ID: On Jun 6, 2014, at 8:06 AM, Milton L Mueller wrote: > This debate has descended into rather nasty and unconstructive name calling. So if I am not mistaken with the attribution here, we have Woodcock calling Huberman 'idiotic,' a devotee of Ayn Rand (how did she get in here?), the moral equivalent of a slave trader, and a self-indulgent non-adult. No, you have Woodcock calling Huberman?s idea idiotic. While I think the term is a bit vitriolic, I agree with Bill that it is, in fact, ill-advised at best. > Bill, the entire community has already recognized the legitimacy of markets for IPv4 numbers. Transfer markets are institutionalized and have been for 4 years. So any argument that is based on comparing it to the slave/drug trade is gone. Yes, but the entire community has also consistently stated that they want to preserve the needs test on those transfers. Drug trade is, therefore, a perfectly valid comparison because some drug sales are permitted by public policy and some are not. Both take place, but there are legitimate public policy reasons for prohibiting them. (No, I am not a fan of current drug policy in the US, but that has nothing to do with the market issues being raised here). > All we are debating is the presence or absence of needs assessment as a gatekeeping function for that market. Correct. > This is a fairly administrative and technical argument, not a moral one. Efficiency is the key criterion (not fairness, really). If you support needs assessments you have to make a case that the costs and burdens associated with it are justified by quantifiable benefits. In this case, inefficiency is unfairness: if the needs assessment process prevents resources from going where they are wanted most, or if the cost burdens associated with the process exceed the value of the numbers acquired for small operators, or if it is shown that large, established companies with well-established relationships to ARIN can navigate the process more easily, then there are signs that needs assessment is unfair because of its inefficiencies. I disagree. There are moral implications and ramifications to what happens if one takes the regulations off of a market and turns it into the wild west. Needs assessment prevents addresses from going unconstrained to the highest bidder. While I realize that from an economists perspective, it is assumed that bid is equivalent to want, in the real world outside of the economists ivory tower, sometimes bid is limited by ability to pay and does not reflect want at all. In addition, there is the question of want vs. need and whether we should allow some greedy entities excessive want to override the rights of someone else?s need. It has repeatedly been shown that small organizations are, in fact, able to navigate ARIN?s process just fine. ARIN has far more small members than large and far more small end-users than large. > You have to do a better job of explaining why it is "fair" to force a willing seller and a willing buyer to submit to an additional step when that step both limits the quantity of resources available for transfer and raises the cost of participating in the market by a substantial degree. It is fair because it protects the rights of entities with legitimate needs from a cornering of the market by those with means. On the other hand, it does not, in fact, substantially increase the cost of participating in the market. At worst, it is a small increase. If you would argue otherwise, then I would say you need to provide evidence to support that and not just on a few corner cases, but evidence of a systemic problem that applies to the majority of requests. Owen > > --MM > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Woodcock > > Your argument that ARIN needs to step out of the way of the human slaves market, recognize its validity, and duly record the transfers of those slaves, because Ayn Rand, is idiotic. And if you think that's not what you just said, you need to step back and reflect a little before touching your keyboard. > > We self-regulate, rather than wallowing in the trough of self-indulgence, because we are (speaking collectively and aspirationally, at least) adults. As such, we don't want our power to self-regulate removed. > > > > > > _______________________________________________ > 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 woody at pch.net Sat Jun 7 03:12:39 2014 From: woody at pch.net (Bill Woodcock) Date: Sat, 7 Jun 2014 00:12:39 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <79501E5F-746D-4785-A079-48FFBC08A76B@pch.net> I would like to apologize to the list, and most especially to David Huberman, for the inexcusable snideness of my reply a couple of days ago. In replying to a posting that I disagreed with, I allowed myself to engage in an escalation of rhetoric that was profoundly disrespectful, and which I never, ever would have used if I had known that I was engaging with someone who I?ve had the honor and privilege of friendship for the better part of twenty years. Milton went to the trouble to check and point out that attribution, which I had been too lazy to do, bringing to my attention the dissonance between my assumptions about how I related to people, and how I was actually behaving. I am deeply chagrined by the realization that I would treat an unidentified person with so very much less compassion and humanity than I would knowingly treat a friend. Lessons learned from the mistakes of others are the least expensive, and I hope some of you will remember how very deeply I regretted this, if you?re tempted to say something on the list, or to someone you don?t know, that you wouldn?t say to a friend, to their face. David, I?m truly and deeply sorry, and I hope that I can regain your trust enough that you?ll honor me with your friendly disagreement again. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From owen at delong.com Sat Jun 7 03:22:53 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 7 Jun 2014 00:22:53 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <20140606154359.GR25470@mx1.yitter.info> References: <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> <20140606154359.GR25470@mx1.yitter.info> Message-ID: <6E475E44-3E6A-4A84-9929-2495D5B06B19@delong.com> On Jun 6, 2014, at 8:43 AM, Andrew Sullivan wrote: > On Fri, Jun 06, 2014 at 03:06:24PM +0000, Milton L Mueller wrote: >> You have to do a better job of explaining why it is "fair" to force a willing seller and a willing buyer to submit to an additional step when that step both limits the quantity of resources available for transfer and raises the cost of participating in the market by a substantial degree. >> > > Not only that. If you believe that the purpose of self-regulation is > to avoid legislators coming in, you need to explain why the > self-regulation is not burdensome, lest legislators decide that such a > burden is unreasonable and should be taken over by "adults" (where > "adults" and "legislators" are conflated). Given that no expansion or increased burden of regulation is being proposed vs. regulations that everyone has accepted for more than a decade, I think that case is pretty well proven. When seeking to reduce regulations, the burden is to prove that such a relaxation of regulations would not be harmful. Owen From owen at delong.com Sat Jun 7 03:34:59 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 7 Jun 2014 00:34:59 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5391F49D.1000202@matthew.at> References: <1140605212432.46270A-100000@Ives.egh.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD8B14@ENI-MAIL.eclipse-networks.com> <7444FE5F-1694-40E2-BDFD-2CF31EBE3D2A@delong.com> <539182E4.2010904@matthew.at> <5391F49D.1000202@matthew.at> Message-ID: <9E03856D-0282-4258-B103-C7D04587D5F5@delong.com> On Jun 6, 2014, at 10:04 AM, Matthew Kaufman wrote: > On 6/6/2014 2:31 PM, Owen DeLong wrote: >> >>> On Jun 6, 2014, at 9:59 AM, Matthew Kaufman wrote: >>> >>>> On 6/6/2014 7:24 AM, Owen DeLong wrote: >>>> Removing needs basis from 8.3 transfers doesn?t do that and it has a number of other harmful outcomes as previously discussed. >>>> >>> Can you name a harmful outcome of removing needs basis from 8.3 transfers that doesn't already exist in the form of contracts that lock sellers to future buyers and/or contracts that allow the use of address space by another entity? >> As I have stated, we cannot block all mechanisms which circumvent policy. Yes, you can still produce the negative outcomes by circumventing the intent of policy. Bad actors will, of course do so. If you have strategies for effectively preventing bad actors from doing so, then I am open to discussing those. >> >> If you just want to use the fact that bad actors can circumvent policy by means we cannot control as a justification for eliminating policy, then this has been discussed and I still find that position unconvincing. >> >> > > That's only the first part of said justification. First off, lets stop calling them "bad actors": A company with shareholders that knows it will need IPv4 space over the next 3 years has employees that are legally obligated to enter contracts that will ensure that they can acquire that space once ARIN can not longer provide it. These contracts will take the form of right of first refusal, lock-ups, or leasing of space and none of them can be controlled or prevented by ARIN. The employees are not acting in bad faith and the companies are not as a result "bad actors". They are simply participants in a market for a limited resource... no need to assign a value judgement to them. Why should I stop calling community members who will choose to circumvent the intent of policy in favor of their own greed over the wishes of the community bad actors? The employees have no such obligation unless the management of the company chooses to move the company in that direction. > And there will be "needs justification"... only it will be done by the interaction of the market and their CFO... the company will work out how much space it needs over what it believes is a reasonable planning horizon and then use that as justification for releasing the funds necessary to enter into those contracts. I call BS. This is the somewhat idealized case. The less idealized case is ?We can gain a market advantage over our competitors by investing a couple of billion dollars in tying up as much of the available address space as possible.? Sure, no one organization is likely to achieve this kind of capture, especially under current policies. However, remove the needs test from policy and you?ve disabled several of the safeguards currently built into policy in favor of a free-for-all where a small number of companies behaving in this manner could, indeed, prevent the vast majority of competing organizations from obtaining address space going forward. > Next, I and many others believe that there is a danger to the registry once such a market becomes prevalent. Specifically, that the accuracy of the registry will suffer. It will, more and more often, fail to reflect who is using and/or controlling the use of the address space, instead containing some historical trivia. Yes, and many people believe in various things ranging from tin foil hats to virgin birth. I prefer to base policy decisions on documented fact rather than religion and FUD. > I can foresee an avalanche effect, where as the registry becomes less and less accurate, participants in the IPv4 market find it less and less necessary to ensure that their own transfers or leases are reflected in the registry... a sort of "broken windows" effect where it simply becomes more and more acceptable to not care. That?s certainly one worst case scenario. I would argue that if that were to occur, it would likely drive IPv6 adoption more than it would actually harm the IPv4 situation. YMMV. > If you think that's a likely outcome, and that such a thing would be bad for ARIN, you should support making it easier for people who are doing perfectly legitimate things to record those things in the registry. I do. I think it?s a very unlikely outcome and I don?t think it would be bad for ARIN. I think it would be bad for those attempting to continue to use the IPv4 internet if it were to happen, but not hugely so, at least initially. I think it would be a slow progression of increasing pain (much like NAT and CGN have already been). You keep calling transfers outside of policy ?perfectly legitimate?, but in reality, they are not perfectly legitimate. Can we please stop trying to call violators of policy and circumventers of policy intent ?perfectly legitimate?? > If you think that the market prices and the long-term risk created by the introduction of IPv6 make hoarding and speculation or even significantly overestimating ones own need unlikely, then there's no reason to oppose removing specific needs justification as a requirement to record a transfer in the registry. I don?t. I do not believe that they do this at all. So I believe that there is reason to oppose removing specific needs justification as a requirement to record a transfer in the registry. Owen From owen at delong.com Sat Jun 7 03:42:00 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 7 Jun 2014 00:42:00 -0700 Subject: [arin-ppml] Simple question to simplify the rhetoric.. In-Reply-To: References: <5391D552.9060504@linuxmagic.com> <5391DF2A.90803@linuxmagic.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AADA3E1@ENI-MAIL.eclipse-networks.com> Message-ID: I am glad you presented the dark pools as an example. Let?s look at how much harm the dark pools and high frequency trading have done and the role of the parasites that profit from this environment and consider whether we want to legitimize or encourage such a thing for internet numbers. I highly recommend the book ?Flash Boys? for those who have not read it. Owen On Jun 6, 2014, at 10:40 AM, John Von Stein wrote: > My 2-cents on this thread ? > > Having been in the commodity/derivative/equity trading businesses for 25 years before starting an ISP I concur that a Market will likely evolve for US IPv4. The fundamentals of Supply and Demand for IPv4 will prevail. It?s probably happening already, akin to the ?dark pools? of off-exchange trading that were siphoning large amounts of trading volume away from the regulated equity exchanges. This community, including ARIN, can either embrace and guide this tectonic shift from single source of IP (ARIN) to a Market of IP address suppliers / consumers from the playing field or else be left with absolute control over essentially an empty bag of allocations and watching the aftermarket activity from the sideline. > > Thank you, > John W. Von Stein > > > > 102 NE 2nd Street > Suite 136 > Boca Raton, FL 33432 > Office: 561-288-6989 > www.QxCcommunications.com > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse > Sent: Friday, June 6, 2014 1:26 PM > To: Michael Peddemors; arin-ppml at arin.net > Subject: Re: [arin-ppml] Simple question to simplify the rhetoric.. > > Of course those are not the only two options. > > We could choose C: Open up the market by removing needs testing along the lines of what RIPE is doing and let the market work that out. > > We could also D: Embrace and join the private market that has sprung up outside of ARIN and legitimize it and work closely with it at the policy level. (This has the added benefit of improving the accuracy of the Database.) > > There are probably other options. > > 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? > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Peddemors > Sent: Friday, June 06, 2014 11:33 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Simple question to simplify the rhetoric.. > > On 14-06-06 08:21 AM, John Curran wrote: > > On Jun 6, 2014, at 10:50 AM, Michael Peddemors wrote: > > > >> Why don't we first of all all express our simple votes.. > >> > >> A) Leave the current system alone, and let the free market work it > >> out > >> B) Enpower ARIN with more abilities to 'judge' who gets the remaining > >> space > > > > Michael - > > > > In particular, there are the requirements for receiving space from the regional > > free pool versus requirements for being a recipient of a market transfer. > > Understood of course, however I believe a consensus or even a productive conversation in either case can't be had, unless the community first agrees in principle to a fundamental change in ARIN's role, where it is transfer's or allocation of new IP(s). > > > > -- > "Catch the Magic of Linux..." > ------------------------------------------------------------------------ > Michael Peddemors, President/CEO LinuxMagic Inc. > Visit us at http://www.linuxmagic.com @linuxmagic > ------------------------------------------------------------------------ > A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. > ------------------------------------------------------------------------ > 604-682-0300 Beautiful British Columbia, Canada > > This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. > Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. > _______________________________________________ > 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 woody at pch.net Sat Jun 7 03:45:51 2014 From: woody at pch.net (Bill Woodcock) Date: Sat, 7 Jun 2014 00:45:51 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> Message-ID: <3BFEA94E-FECB-4A13-B744-5664F8130FEE@pch.net> On Jun 6, 2014, at 8:06 AM, Milton L Mueller wrote: > Why is it "fair" to force a willing seller and a willing buyer to submit to an additional step?? ?Fair? is not a word that I?d use in this context. I would, however, say that the additional regulatory check is ?necessary? when a transaction imposes externalities upon third parties. Because of scarcity, routing-table bloat, and the public interest in availability of addresses for public communication, the externalities of most, if not all, IP address transactions are very broadly distributed. Good regulation preserves the public interest where that differs from private interests. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From owen at delong.com Sat Jun 7 03:55:46 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 7 Jun 2014 00:55:46 -0700 Subject: [arin-ppml] Simple question to simplify the rhetoric.. In-Reply-To: References: <5391D552.9060504@linuxmagic.com> <5391DF2A.90803@linuxmagic.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AADA3E1@ENI-MAIL.eclipse-networks.com> Message-ID: Care to state which of these positions expressed by various community members resonates with you? Owen On Jun 6, 2014, at 11:29 AM, Jason Schiller wrote: > I think the question here is does justified need provide value to the community in creating "fairness"? > > A. Yes, keep measuring justified need as we always have. > > B. Yes, keep measuring justified need as we always have until something better comes along. > > C. Yes, I'm not sure this is the most fair, but it has been the rules of the game, and doesn't seem right to change the rules so close to the finish line (especially when people's IPv6 adoption plans are depending on it). > > D. Yes, but there is a specific problem that results in some class being treated unfairly, so a tweak or two is required. > > E. Yes, but a needs test only makes sense when addresses can be acquired unrestricted or with flat or tiered pricing or even per low priced IP address pricing. In a limited market, price is the most efficient and most fair mechanism. > > F. No, there is a better mechanism that is "more fair" we should switch to that immediately. > > G. Its not justified need isn't fair, but rather the fact that there are a class of users whose justified need will not be fulfilled, such as individuals (not an organization) or organizations that need only a small amount of addressing (less than a /24 which is the arbitrary limit for inetr-AS routing to keep tables small). > > H. Unrelated... while the current needs based justification is fair, the process is difficult and the end result favors large organizations, those who are growing rapidly (and thus repeated ask for space), those with a dedicated IP management team, those with a dedicated legal team... The process (not the policy) is unfair. > > __Jason > > > > On Fri, Jun 6, 2014 at 1:40 PM, John Von Stein wrote: > My 2-cents on this thread ? > > > > Having been in the commodity/derivative/equity trading businesses for 25 years before starting an ISP I concur that a Market will likely evolve for US IPv4. The fundamentals of Supply and Demand for IPv4 will prevail. It?s probably happening already, akin to the ?dark pools? of off-exchange trading that were siphoning large amounts of trading volume away from the regulated equity exchanges. This community, including ARIN, can either embrace and guide this tectonic shift from single source of IP (ARIN) to a Market of IP address suppliers / consumers from the playing field or else be left with absolute control over essentially an empty bag of allocations and watching the aftermarket activity from the sideline. > > > > Thank you, > > John W. Von Stein > > > > > > > > 102 NE 2nd Street > > Suite 136 > > Boca Raton, FL 33432 > > Office: 561-288-6989 > > www.QxCcommunications.com > > > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse > Sent: Friday, June 6, 2014 1:26 PM > To: Michael Peddemors; arin-ppml at arin.net > Subject: Re: [arin-ppml] Simple question to simplify the rhetoric.. > > > > Of course those are not the only two options. > > > > We could choose C: Open up the market by removing needs testing along the lines of what RIPE is doing and let the market work that out. > > > > We could also D: Embrace and join the private market that has sprung up outside of ARIN and legitimize it and work closely with it at the policy level. (This has the added benefit of improving the accuracy of the Database.) > > > > There are probably other options. > > > > 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? > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Peddemors > > Sent: Friday, June 06, 2014 11:33 AM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Simple question to simplify the rhetoric.. > > > > On 14-06-06 08:21 AM, John Curran wrote: > > > On Jun 6, 2014, at 10:50 AM, Michael Peddemors wrote: > > > > > >> Why don't we first of all all express our simple votes.. > > >> > > >> A) Leave the current system alone, and let the free market work it > > >> out > > >> B) Enpower ARIN with more abilities to 'judge' who gets the remaining > > >> space > > > > > > Michael - > > > > > > In particular, there are the requirements for receiving space from the regional > > > free pool versus requirements for being a recipient of a market transfer. > > > > Understood of course, however I believe a consensus or even a productive conversation in either case can't be had, unless the community first agrees in principle to a fundamental change in ARIN's role, where it is transfer's or allocation of new IP(s). > > > > > > > > -- > > "Catch the Magic of Linux..." > > ------------------------------------------------------------------------ > > Michael Peddemors, President/CEO LinuxMagic Inc. > > Visit us at http://www.linuxmagic.com @linuxmagic > > ------------------------------------------------------------------------ > > A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. > > ------------------------------------------------------------------------ > > 604-682-0300 Beautiful British Columbia, Canada > > > > This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. > > Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. > > _______________________________________________ > > 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 owen at delong.com Sat Jun 7 03:57:51 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 7 Jun 2014 00:57:51 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102C946149A@fnb1mbx01.gci.com> References: <1140519223408.47993A-100000@Ives.egh.com> <537B98CA.3030106@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com> <537D069B.5030601@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com> <538A4FE9.9010900@umn.edu> <8695009A81378E48879980039EEDAD28013850D859@MAIL1.polartel.local> <538CA0A1.5080400@umn.edu> <53921CF7.90607@umn.edu> <18B2C6E38A3A324986B392B2D18ABC5102C946149A@fnb1mbx01.gci.com> Message-ID: <238D89DB-080E-45AF-B397-3A679E7506D2@delong.com> On Jun 6, 2014, at 1:04 PM, Leif Sawyer wrote: > On 6/6/14, 11:04 , David Farmer wrote: >> [...]Given the "should" is immediately followed by a conditional "unless" >> the intent seems sufficiently clear, the intent is to create a special-case >> exception, and "should" seems appropriate. Furthermore, "must" or "shall" >> followed by "unless" seemed an awkward way to create such an exception. >> >> Staff generally agrees that in most cases for policy "must" is preferred >> and it is best to avoid "should" in most cases. However, in the sentence >> above the intent seem clear enough and "should" seems appropriate in that >> particular case. > > Unfortunately, that still has indirect parsing issues. > > 1. You should eat an ice-cream cone, unless you ate a taco. > [and then you shouldn't...but you still could] > > 2. You must eat an ice-cream cone, unless you ate a taco. > [ sorry, no ice-cream for you, taco-eater. You get a churro instead. ] I parse sentence one as permitting an ice-cream cone after a taco, but giving one the option of not eating an ice cream cone in either case. I parse sentence two as requiring me to eat an ice cream cone unless I eat a taco. However, if I eat a taco, I still have the option of eating an ice cream cone if I wish. As such, I don?t believe it accomplishes your stated intent, in fact. Owen From mike at iptrading.com Sat Jun 7 09:59:08 2014 From: mike at iptrading.com (Mike Burns) Date: Sat, 7 Jun 2014 09:59:08 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers References: <1140605212432.46270A-100000@Ives.egh.com><5B9E90747FA2974D91A54FCFA1B8AD12015AAD8B14@ENI-MAIL.eclipse-networks.com><7444FE5F-1694-40E2-BDFD-2CF31EBE3D2A@delong.com><539182E4.2010904@matthew.at><5391F49D.1000202@matthew.at> <9E03856D-0282-4258-B103-C7D04587D5F5@delong.com> Message-ID: <128DDB8F992448939B2332453B5AFB17@ncsscfoipoxes4> Hi Owen, Sorry for the top-post. Owen, you continue to deny the danger to the registry posed by the needs test, comparing it to crackpot beliefs and describing it as FUD. It is indeed hard to demonstrate registry inaccuracies, even when aware of them, due to registry access, confidentiality, and non-disclosure agreements. But earlier in this thread I mentioned the presence of what I called zombie corporations in the registry. These are companies in many states of dormancy whose sole asset is their address allocation and a vague corporate state. These entities are sold to those who can not demonstrate need. ARIN is not notified. Whois does not change. But the visibility into the real owner of the registration is practically nil. This is a direct result of the needs test. Nobody wants to pay real-estate-sized prices and not have their investment recorded in Whois. The people who do this do it because they need the addresses and can't get them "legitimately". This problem was acknowledged by John Curran as a potential route for those who want addresses but can't justify their entire purchase. He also mentioned contracts that lock up addresses, to be transferred over time as ARIN needs tests permit. Both these problems exist in the real world and I have been party to these agreements. Zombie corporation acquisitions fall within policy, so I refuse to wear the bad actor label. I also pointed out that the public information in the Microsoft/Nortel deal included the fact that none of the blocks sold were registered in Whois to Nortel.Which means that if Microsoft had not decided after the auction finished that they would cut a secret modified LRSA with ARIN, they could have purchased the corporate husks of the original registrants, the Bay Networks and Synoptics and Wellfleet corporate shells and ip address assets. Then Microsoft would have had no problems advertising, routing, and using the space. The only issue would have been Whois. That apparently was not much of an issue for Nortel, which never did anything to change Whois after acquiring those companies in the decade after their acquisition. This is a real danger which I have seen in the wild many times, one which John Curran acknowledged, and one which leads directly counter to our primary stewardship role of registering the addresses accurately. It's fine to make a decision based on balancing conservation, which you feel applies to priced space, with registration, which you agree is our primary role. But you can't reach an appropriate balance if you deny the facts, which you seem to do by demanding some sort of proof of this apparent danger to the registry. Many of us are not so sanguine about registry accuracy in the face of the current situation, and to your credit you are willing to compromise in the direction of making temporary changes to the needs test requirement in hopes of finding evidence one way or the other. This conversation is not in the context of 2014-14, a proposal to remove the needs test from some IPv4 transfers, with size and frequency limits which are designed to prevent any fear of hoarding or speculation. In the context of 2014-14, then, arguments about hoarding and speculation can be distracting. I'm sure people like Matthew Kaufman, Milton Mueller, David Huberman and many others believe that the needs test should be removed entirely. I fall in this camp, too. So 2014-14 is a request for these people to also compromise, as it only removes the needs test for smaller transfers, and only one such transfer per year per registrant. Perhaps both sides can come together using the size of the needs-free transfer as a method of fine-tuning their compromise. Owen thinks a temporary size of /20 is worthy of consideration, and McTim thinks a /24 is the right size. I invite anybody who agrees that a compromise here is in order to volunteer what sized block would, in this context, make the proposal worthy of your support. Regards, Mike ----- Original Message ----- From: "Owen DeLong" To: "Matthew Kaufman" Cc: Sent: Saturday, June 07, 2014 3:34 AM Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Jun 6, 2014, at 10:04 AM, Matthew Kaufman wrote: > On 6/6/2014 2:31 PM, Owen DeLong wrote: >> >>> On Jun 6, 2014, at 9:59 AM, Matthew Kaufman wrote: >>> >>>> On 6/6/2014 7:24 AM, Owen DeLong wrote: >>>> Removing needs basis from 8.3 transfers doesn?t do that and it has a >>>> number of other harmful outcomes as previously discussed. >>>> >>> Can you name a harmful outcome of removing needs basis from 8.3 >>> transfers that doesn't already exist in the form of contracts that lock >>> sellers to future buyers and/or contracts that allow the use of address >>> space by another entity? >> As I have stated, we cannot block all mechanisms which circumvent policy. >> Yes, you can still produce the negative outcomes by circumventing the >> intent of policy. Bad actors will, of course do so. If you have >> strategies for effectively preventing bad actors from doing so, then I am >> open to discussing those. >> >> If you just want to use the fact that bad actors can circumvent policy by >> means we cannot control as a justification for eliminating policy, then >> this has been discussed and I still find that position unconvincing. >> >> > > That's only the first part of said justification. First off, lets stop > calling them "bad actors": A company with shareholders that knows it will > need IPv4 space over the next 3 years has employees that are legally > obligated to enter contracts that will ensure that they can acquire that > space once ARIN can not longer provide it. These contracts will take the > form of right of first refusal, lock-ups, or leasing of space and none of > them can be controlled or prevented by ARIN. The employees are not acting > in bad faith and the companies are not as a result "bad actors". They are > simply participants in a market for a limited resource... no need to > assign a value judgement to them. Why should I stop calling community members who will choose to circumvent the intent of policy in favor of their own greed over the wishes of the community bad actors? The employees have no such obligation unless the management of the company chooses to move the company in that direction. > And there will be "needs justification"... only it will be done by the > interaction of the market and their CFO... the company will work out how > much space it needs over what it believes is a reasonable planning horizon > and then use that as justification for releasing the funds necessary to > enter into those contracts. I call BS. This is the somewhat idealized case. The less idealized case is ?We can gain a market advantage over our competitors by investing a couple of billion dollars in tying up as much of the available address space as possible.? Sure, no one organization is likely to achieve this kind of capture, especially under current policies. However, remove the needs test from policy and you?ve disabled several of the safeguards currently built into policy in favor of a free-for-all where a small number of companies behaving in this manner could, indeed, prevent the vast majority of competing organizations from obtaining address space going forward. > Next, I and many others believe that there is a danger to the registry > once such a market becomes prevalent. Specifically, that the accuracy of > the registry will suffer. It will, more and more often, fail to reflect > who is using and/or controlling the use of the address space, instead > containing some historical trivia. Yes, and many people believe in various things ranging from tin foil hats to virgin birth. I prefer to base policy decisions on documented fact rather than religion and FUD. > I can foresee an avalanche effect, where as the registry becomes less and > less accurate, participants in the IPv4 market find it less and less > necessary to ensure that their own transfers or leases are reflected in > the registry... a sort of "broken windows" effect where it simply becomes > more and more acceptable to not care. That?s certainly one worst case scenario. I would argue that if that were to occur, it would likely drive IPv6 adoption more than it would actually harm the IPv4 situation. YMMV. > If you think that's a likely outcome, and that such a thing would be bad > for ARIN, you should support making it easier for people who are doing > perfectly legitimate things to record those things in the registry. I do. I think it?s a very unlikely outcome and I don?t think it would be bad for ARIN. I think it would be bad for those attempting to continue to use the IPv4 internet if it were to happen, but not hugely so, at least initially. I think it would be a slow progression of increasing pain (much like NAT and CGN have already been). You keep calling transfers outside of policy ?perfectly legitimate?, but in reality, they are not perfectly legitimate. Can we please stop trying to call violators of policy and circumventers of policy intent ?perfectly legitimate?? > If you think that the market prices and the long-term risk created by the > introduction of IPv6 make hoarding and speculation or even significantly > overestimating ones own need unlikely, then there's no reason to oppose > removing specific needs justification as a requirement to record a > transfer in the registry. I don?t. I do not believe that they do this at all. So I believe that there is reason to oppose removing specific needs justification as a requirement to record a transfer in the registry. Owen _______________________________________________ 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 mike at iptrading.com Sat Jun 7 10:15:21 2014 From: mike at iptrading.com (Mike Burns) Date: Sat, 7 Jun 2014 10:15:21 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> Message-ID: <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> Hi Owen, Finding 4 actors who want to corner the market probably wouldn?t be very hard. Since 25% is 1/4 of the projected market size, I would say that the rest of your argument is on pretty shaky ground. It's not nearly so simple. First you would have to find four players willing to risk $8 billion dollars. Second you would have to have them create an inherently unstable cartel. Third you would have to find sellers with that much space, and this would likely mean hundreds of sellers at the least and a years-long endeavor. Fourth you would have to process those sales in a transparent market where your purchases are recorded for all to see. Fifth you would have to believe that there would be no reaction to this public information vis a vis price. Sixth you would also have to believe that these four billionaires ignored any risk of driving the IPv6 transition which would make their efforts worthless. Seventh you would have to ignore the fact that there are already methods of acquiring space without need which to my knowledge have not been used by speculators, and in fact there is zero evidence that speculators even exist. > We are three years into the open, post-Microsoft/Nortel market and there > is no evidence of hoarding in my experience. I have never fielded a phone > call or email from any company or individual seeking addresses they didn't > plan to utilize at some point, although I have fielded plenty from people > seeking addresses that for whatever reason ARIN policy would prohibit them > from registering. Perhaps other brokers on the list might report on their > experiences. Address space is still available nearly for free from ARIN, especially for smaller organizations, so this isn?t a real test of what will happen post runout and any claim that it is is absurd. Are you saying that my claim of never having heard from a speculator is absurd? Have you forgotten that APNIC and RIPE ran out years ago? (after which point they both dropped the needs test for transfers). > Little guys benefit from the dropping of needs test for small transfers. > No need to navigate the ARIN process if you just need a /24 and you can't > get one from your upstream, or not at a reasonable cost, or because you > feel more secure with your own space, or because you don't wish to game > the system. Support of 2014-14 would allow small companies to have this > option while preventing hoarding or speculation through limits on size and > number of transfers. Perhaps you care to comment on whether you might > consider support of 2014-14 at the current size of /16 or at another size > that you might feel more appropriate? Again, this is your perspective, but it?s not necessarily entirely true. It?s only true if you assume that the market will have a continuous supply and demand will be lower than supply. I would argue that the number of inter-RIR transfers to the APNIC region which have already been processed would indicate that after exhaustion, this is unlikely to be a persistent state or even last very long at all. Owen I have brokered more transfers to APNIC than anybody in the world. Nothing I said requires that there be a continuous situation where demand is lower than supply. However I can report without much understanding that there is indeed more supply than demand in the transfer market today, based on my own experiences and those I have heard from other brokers. Regards, Mike From info at arin.net Mon Jun 9 11:53:57 2014 From: info at arin.net (ARIN) Date: Mon, 09 Jun 2014 11:53:57 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - May 2014 In-Reply-To: <537672AB.1060606@arin.net> References: <537672AB.1060606@arin.net> Message-ID: <5395D895.6080706@arin.net> > The AC abandoned ARIN-2014-2. 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 May 15 meeting have been published: https://www.arin.net/about_us/ac/ac2014_0515.html The petition deadline for ARIN-2014-2 is 16 June 2014. 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 5/16/14, 4:18 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process (PDP), the ARIN > Advisory Council (AC) met on 15 May 2014. > > The AC recommended the following to the ARIN Board for adoption: > > Recommended Draft Policy ARIN-2014-4: Remove 4.2.5 Web Hosting Policy > Recommended Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation > Conservation Update > Recommended Draft Policy ARIN-2014-10: Remove Sections 4.6 and 4.7 > > The AC moved the following to last call: > > Recommended Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup > > The AC accepted the following as Draft Policies. They will be > posted separately to the Public Policy Mailing List (PPML). > > ARIN-prop-209 Change Utilization Requirements from last-allocation to > total-aggregate > ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24 > ARIN-prop-207 Section 4.10 Austerity Policy Update > ARIN-prop-205 Allow Inter-RIR ASN Transfers > ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers > > Having found the following to be fully developed and meeting ARIN's > Principles of Internet Number Resource Policy, the AC recommended these > for adoption (each to be posted separately for discussion as a > Recommended Draft Policy): > > Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple > Discrete Networks > Draft Policy ARIN-2414-12: Anti-hijack Policy > Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment > Units to /24 > > The AC remanded the following proposal to the originator after the > proposal originator asked to withdraw the proposal. > > ARIN-prop-206 Implement IPv6 from IPv4 Without an Outage > > The AC abandoned the following: > > Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip Language > > The AC provided the following statement: > > "Review of the PPML, the record of discussion and polling at the Chicago > PPM and the original author's statement of willingness to withdraw the > proposal indicate a lack of consensus. The ARIN AC has therefore decided > to abandon Draft Policy 2014-2 Improving 8.4 Anti-Flip Language. The AC > recognizes that some community members believe this to be an important > issue and encourages those members to investigate a means to solve the > problem statement that the Draft Policy was focused upon. You may find a > record of this on the ARIN website." > > The AC abandoned ARIN-2014-2. 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 > > The AC is continuing to work on the following: > > Draft Policy ARIN-2014-1: Out of Region Use > Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and 8.4 Minimum IPv4 > Block Size Requirements > Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations > Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs] > Draft Policy ARIN-2014-8: Alignment of 8.3 Needs Requirements to > Reality of Business > Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 > Utilization Requirements > Draft Policy ARIN-2014-11: Improved Registry Accuracy Proposal > > 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 owen at delong.com Mon Jun 9 13:30:21 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 9 Jun 2014 10:30:21 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> Message-ID: On Jun 7, 2014, at 07:15 , Mike Burns wrote: > Hi Owen, > > Finding 4 actors who want to corner the market probably wouldn?t be very hard. Since 25% is 1/4 of the projected market size, I would say that the rest of your argument is on pretty shaky ground. > > > It's not nearly so simple. First you would have to find four players willing to risk $8 billion dollars. Second you would have to have them create an inherently unstable cartel. Third you would have to find sellers with that much space, and this would likely mean hundreds of sellers at the least and a years-long endeavor. Fourth you would have to process those sales in a transparent market where your purchases are recorded for all to see. Fifth you would have to believe that there would be no reaction to this public information vis a vis price. Sixth you would also have to believe that these four billionaires ignored any risk of driving the IPv6 transition which would make their efforts worthless. Seventh you would have to ignore the fact that there are already methods of acquiring space without need which to my knowledge have not been used by speculators, and in fact there is zero evidence that speculators even exist. Nope, this doesn't have to be a cartel. It only has to be 4 or more actors each willing to invest an average of $2b and each of whom wants to see as many of their competitors as possible put at a substantial disadvantage in the near term future of the access market. Now I realize that large $TELCOS and large $CABLECOS and such would never engage in such anticompetitive practices and are staunch defenders of all good things like network neutrality, free and open peering policies and fantastic customer service with good bandwidth and fair prices. However, since pretty much everything in that last sentence has been repeatedly proven false, I don't think I'm on quite so shaky a ground after all. Your third item is absurd. If they don't find sellers with that much space, then it means the market isn't as large as described and the problem is even worse and market capture is even easier. Without a needs test or the other restrictions in 8.3, it would not take years, it would take days. Address space would be swept away as fast as it came available on the market. It would be IP lotto for the uber-wealthy corporations. As to fourth, yes and no. What's so transparent if $MEGACORP spins up lots of $IP_ADDRESS_HOLDING_CORPS just waiting to pounce on available space, much like the test-the-waters orders placed in various markets and dark pools looking for high-frequency trading victims? The stock market is allegedly just such an open market and is rife with just this kind of gouging. As to 6, no, they just have to decide that the risk of said transition occurring in less than time_T where T is their idea of investment recovery time given the expected advantage is relatively low. That's not so far fetched, since the average F500 corporation hasn't really started any sort of transition in earnest and will likely need 2 or more years to actually achieve a complete transition. Speculation in the face of an existing free pool is pretty nonsensical. Further, the entities I would expect to engage in this kind of speculation would likely consider it not worth the risk unless they can get the addresses registered to them in the recognized registry. >> We are three years into the open, post-Microsoft/Nortel market and there is no evidence of hoarding in my experience. I have never fielded a phone call or email from any company or individual seeking addresses they didn't plan to utilize at some point, although I have fielded plenty from people seeking addresses that for whatever reason ARIN policy would prohibit them from registering. Perhaps other brokers on the list might report on their experiences. > > Address space is still available nearly for free from ARIN, especially for smaller organizations, so this isn?t a real test of what will happen post runout and any claim that it is is absurd. > > > Are you saying that my claim of never having heard from a speculator is absurd? Have you forgotten that APNIC and RIPE ran out years ago? (after which point they both dropped the needs test for transfers). Shortly after dropping the needs test, APNIC reinstated it. While you may not have heard from a speculator, others have. I have, in fact, received offers from speculators even for my tiny little /23 and /24. >> Little guys benefit from the dropping of needs test for small transfers. No need to navigate the ARIN process if you just need a /24 and you can't get one from your upstream, or not at a reasonable cost, or because you feel more secure with your own space, or because you don't wish to game the system. Support of 2014-14 would allow small companies to have this option while preventing hoarding or speculation through limits on size and number of transfers. Perhaps you care to comment on whether you might consider support of 2014-14 at the current size of /16 or at another size that you might feel more appropriate? > > Again, this is your perspective, but it?s not necessarily entirely true. It?s only true if you assume that the market will have a continuous supply and demand will be lower than supply. I would argue that the number of inter-RIR transfers to the APNIC region which have already been processed would indicate that after exhaustion, this is unlikely to be a persistent state or even last very long at all. > > Owen I have brokered more transfers to APNIC than anybody in the world. Nothing I said requires that there be a continuous situation where demand is lower than supply. However I can report without much understanding that there is indeed more supply than demand in the transfer market today, based on my own experiences and those I have heard from other brokers. I don't doubt that today as there remains a free pool in the ARIN region. I do not see that persisting more than a year or so with needs basis in place and even faster if needs basis is removed once the ARIN and LACNIC free pools are exhausted. Owen From rudi.daniel at gmail.com Mon Jun 9 13:44:58 2014 From: rudi.daniel at gmail.com (Rudi Daniel) Date: Mon, 09 Jun 2014 17:44:58 -0000 Subject: [arin-ppml] ARIN-PPML proposal 208 min. Allocation. Message-ID: Still support this re /24 Rudi Daniel arin-ppml-request at arin.net wrote: >Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml >or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > >You can reach the person managing the list at > arin-ppml-owner at arin.net > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of ARIN-PPML digest..." > > >Today's Topics: > > 1. Re: ARIN-prop-208 Reduce All Minimum Allocation/Assignment > Units to /24 (Paul S.) > 2. Re: ARIN-prop-208 Reduce All Minimum Allocation/Assignment > Units to /24 (William Herrin) > 3. Re: ARIN-prop-208 Reduce All Minimum Allocation/Assignment > Units to /24 (Owen DeLong) > 4. Re: ARIN-prop-208 Reduce All Minimum Allocation/Assignment > Units to /24 (Mike Burns) > 5. Re: ARIN-prop-208 Reduce All Minimum Allocation/Assignment > Units to /24 (Michael Peddemors) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Tue, 06 May 2014 12:47:03 +0600 >From: "Paul S." >To: arin-ppml at arin.net >Subject: Re: [arin-ppml] ARIN-prop-208 Reduce All Minimum > Allocation/Assignment Units to /24 >Message-ID: <53688567.2040608 at winterei.se> >Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > >Not seeing anything I disagree with in the PDF, so just as I supported >the original, I support this too. > > >On 5/6/2014 7:44 AM, Kevin Blumberg wrote: >> I'm sending out a revised version of prop-208. Included is an attachment with a redline version to assist. >> >> I would appreciate any feedback of support or questions. >> >> Thanks, >> >> Kevin Blumberg >> >> ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24 >> Proposal Originator: Owen DeLong >> Date: 5 May 2014 >> Problem Statement: >> As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units for IPv4 to /24 across the board. >> >> Policy statement: >> >> Remove all references to minimum allocations /20 and /22 replacing them with the term allocation or with /24 when referencing minimum size blocks. >> >> Change the title of 4.2.2.1 to "ISP Requirements" with revised text stating: >> >> All ISP organizations must satisfy the following requirements...thus eliminating the entire Multi-homed section and subsections along with other superfluous example text. >> >> Delete the special case allocations/assignments for the Caribbean as the new /24 minimums are an improvement. >> >> Comments: >> a. Timetable for implementation: Immediate b. A red line version has been included >> >> Full text version of changes for easy reference: >> >> 4.2.1.5. Minimum allocation >> In general, ARIN allocates /24 and larger IP address prefixes to ISPs. If allocations smaller than /24 are needed, ISPs should request address space from their upstream provider. >> >> 4.2.2.1 ISP Requirements >> All ISP organizations must satisfy the following requirements: >> >> 4.2.2.1.1 Use of /24 >> The efficient utilization of an entire previously allocated /24 from their upstream ISP. This allocation may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space. >> >> 4.2.2.1.4. Renumber and return >> ISPs receiving a new allocation may wish to renumber out of their previously allocated space. In this case, an ISP must use the new allocation to renumber out of that previously allocated block of address space and must return the space to its upstream provider. >> >> 4.2.2.2. [section number retired] >> >> 4.3.2 Minimum assignment >> >> 4.3.2.1. [section moved to 4.3.2] >> The minimum block of IP address space assigned by ARIN to end-users is a /24. If assignments smaller than /24 are needed, end-users should contact their upstream provider. >> >> 4.3.2.2 [section number retired] >> >> 4.9 [section number retired] >> >> >> >> _______________________________________________ >> 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: > >------------------------------ > >Message: 2 >Date: Tue, 6 May 2014 02:49:38 -0400 >From: William Herrin >To: Kevin Blumberg >Cc: "arin-ppml at arin.net List \(arin-ppml at arin.net\)" > >Subject: Re: [arin-ppml] ARIN-prop-208 Reduce All Minimum > Allocation/Assignment Units to /24 >Message-ID: > ; In-Reply-To: References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> Message-ID: Hi Owen, Thanks for your reply. Fears of hoarding and speculation don't apply to 2014-14, unless you think that ARIN staff would be unable to discern a series of spun-up holding corps with hidden ownership. In any case, our different perspectives of the risks involved are not applicable to 2014-14, which I know was not the context of your earlier post. And I would like to move the discussion towards 2014-14 and away from fears of an unregulated market. APNIC reinstated their needs test only because ARIN supply was held hostage, I believe you may have been involved? What's more, like ARIN's previous CEO and unlike ARIN's current CEO, RIPE never took the position that RIPE policy applies to legacy space. So there has always been a needs-free market for RIPE ERX space, but that market remains untapped by speculators, both before and after RIPE exhaust. And, of course, since needs are no longer tested for RIPE transfers, we can use RIPE as our experiment to see if speculators attempt to take advantage of that. RIPE publishes transfer statistics. Would you consider a review of those statistics a reasonable way to discern the presence of speculators? The idea that somebody would contact /23 and /24 holders in order to speculate fills me with mirth. I kind of think a speculator would be more efficient if he called a couple of brokers. Regards, Mike -----Original Message----- From: Owen DeLong Sent: Monday, June 09, 2014 1:30 PM To: Mike Burns Cc: lar at mwtcorp.net ; Steven Ryerse ; arin-ppml at arin.net List (arin-ppml at arin.net) Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Jun 7, 2014, at 07:15 , Mike Burns wrote: > Hi Owen, > > Finding 4 actors who want to corner the market probably wouldn?t be very > hard. Since 25% is 1/4 of the projected market size, I would say that the > rest of your argument is on pretty shaky ground. > > > It's not nearly so simple. First you would have to find four players > willing to risk $8 billion dollars. Second you would have to have them > create an inherently unstable cartel. Third you would have to find > sellers with that much space, and this would likely mean hundreds of > sellers at the least and a years-long endeavor. Fourth you would have to > process those sales in a transparent market where your purchases are > recorded for all to see. Fifth you would have to believe that there would > be no reaction to this public information vis a vis price. Sixth you would > also have to believe that these four billionaires ignored any risk of > driving the IPv6 transition which would make their efforts worthless. > Seventh you would have to ignore the fact that there are already methods > of acquiring space without need which to my knowledge have not been used > by speculators, and in fact there is zero evidence that speculators even > exist. Nope, this doesn't have to be a cartel. It only has to be 4 or more actors each willing to invest an average of $2b and each of whom wants to see as many of their competitors as possible put at a substantial disadvantage in the near term future of the access market. Now I realize that large $TELCOS and large $CABLECOS and such would never engage in such anticompetitive practices and are staunch defenders of all good things like network neutrality, free and open peering policies and fantastic customer service with good bandwidth and fair prices. However, since pretty much everything in that last sentence has been repeatedly proven false, I don't think I'm on quite so shaky a ground after all. Your third item is absurd. If they don't find sellers with that much space, then it means the market isn't as large as described and the problem is even worse and market capture is even easier. Without a needs test or the other restrictions in 8.3, it would not take years, it would take days. Address space would be swept away as fast as it came available on the market. It would be IP lotto for the uber-wealthy corporations. As to fourth, yes and no. What's so transparent if $MEGACORP spins up lots of $IP_ADDRESS_HOLDING_CORPS just waiting to pounce on available space, much like the test-the-waters orders placed in various markets and dark pools looking for high-frequency trading victims? The stock market is allegedly just such an open market and is rife with just this kind of gouging. As to 6, no, they just have to decide that the risk of said transition occurring in less than time_T where T is their idea of investment recovery time given the expected advantage is relatively low. That's not so far fetched, since the average F500 corporation hasn't really started any sort of transition in earnest and will likely need 2 or more years to actually achieve a complete transition. Speculation in the face of an existing free pool is pretty nonsensical. Further, the entities I would expect to engage in this kind of speculation would likely consider it not worth the risk unless they can get the addresses registered to them in the recognized registry. >> We are three years into the open, post-Microsoft/Nortel market and there >> is no evidence of hoarding in my experience. I have never fielded a phone >> call or email from any company or individual seeking addresses they >> didn't plan to utilize at some point, although I have fielded plenty from >> people seeking addresses that for whatever reason ARIN policy would >> prohibit them from registering. Perhaps other brokers on the list might >> report on their experiences. > > Address space is still available nearly for free from ARIN, especially for > smaller organizations, so this isn?t a real test of what will happen post > runout and any claim that it is is absurd. > > > Are you saying that my claim of never having heard from a speculator is > absurd? Have you forgotten that APNIC and RIPE ran out years ago? (after > which point they both dropped the needs test for transfers). Shortly after dropping the needs test, APNIC reinstated it. While you may not have heard from a speculator, others have. I have, in fact, received offers from speculators even for my tiny little /23 and /24. >> Little guys benefit from the dropping of needs test for small transfers. >> No need to navigate the ARIN process if you just need a /24 and you can't >> get one from your upstream, or not at a reasonable cost, or because you >> feel more secure with your own space, or because you don't wish to game >> the system. Support of 2014-14 would allow small companies to have this >> option while preventing hoarding or speculation through limits on size >> and number of transfers. Perhaps you care to comment on whether you >> might consider support of 2014-14 at the current size of /16 or at >> another size that you might feel more appropriate? > > Again, this is your perspective, but it?s not necessarily entirely true. > It?s only true if you assume that the market will have a continuous supply > and demand will be lower than supply. I would argue that the number of > inter-RIR transfers to the APNIC region which have already been processed > would indicate that after exhaustion, this is unlikely to be a persistent > state or even last very long at all. > > Owen I have brokered more transfers to APNIC than anybody in the world. > Nothing I said requires that there be a continuous situation where demand > is lower than supply. However I can report without much understanding that > there is indeed more supply than demand in the transfer market today, > based on my own experiences and those I have heard from other brokers. I don't doubt that today as there remains a free pool in the ARIN region. I do not see that persisting more than a year or so with needs basis in place and even faster if needs basis is removed once the ARIN and LACNIC free pools are exhausted. Owen From michael at linuxmagic.com Mon Jun 9 14:53:45 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Mon, 09 Jun 2014 11:53:45 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfersarin-ppml@arin.net List (arin-ppml@arin.net); In-Reply-To: References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> Message-ID: <539602B9.1020309@linuxmagic.com> On 14-06-09 11:36 AM, Mike Burns wrote: > unless you think that ARIN staff would be unable to discern a series of > spun-up holding corps with hidden ownership. We do see what appears to be that now (or at least engineering of whois records to make it seem like they are different companies) in existing records. Ability to 'discern' is already a problem, and what to do about it (enforcement) is also something to discuss.. If the problem exists now, it does have an argument for discussing what to do about that problem in the future, and ARIN's role. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From jcurran at arin.net Mon Jun 9 14:55:32 2014 From: jcurran at arin.net (John Curran) Date: Mon, 9 Jun 2014 18:55:32 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfersarin-ppml@arin.net List (arin-ppml@arin.net); In-Reply-To: References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> Message-ID: <42E285B9-3AF4-4851-8E62-65733428DC54@corp.arin.net> On Jun 9, 2014, at 2:36 PM, Mike Burns wrote: > What's more, like ARIN's previous CEO and unlike ARIN's current CEO, RIPE never took the position that RIPE policy applies to legacy space. Mike - Your statement is factually incorrect in multiple ways; you probably are unaware that adherence to the needs-based assignment criteria for purpose of transfers actually originates in RFC 2050 ("INTERNET REGISTRY IP ALLOCATION GUIDELINES"), dated November 1996 (and before my involvement in the Internet registry system.) The document authors are staff from RIPE, APNIC, and InterNIC and assert it to be an accurate representation of the current practice of the IP address registries at that time. From - " 7. The transfer of IP addresses from one party to another must be approved by the regional registries. The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR." When the ARIN community developed an explicit transfer policy, the more recent community set policy took precedence. The needs-based requirements in NRPM 8.3 remain in place because the ARIN community has not seen to remove them; i.e. they are under the control of this community via the policy development process and that has little to do with the staff or Board views on this matter. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Mon Jun 9 15:03:27 2014 From: jcurran at arin.net (John Curran) Date: Mon, 9 Jun 2014 19:03:27 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfersarin-ppml@arin.net List (arin-ppml@arin.net); In-Reply-To: <539602B9.1020309@linuxmagic.com> References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> <539602B9.1020309@linuxmagic.com> Message-ID: <940E0A96-1CBB-4368-AE32-F2F0BB8EFF12@corp.arin.net> On Jun 9, 2014, at 2:53 PM, Michael Peddemors wrote: > On 14-06-09 11:36 AM, Mike Burns wrote: >> unless you think that ARIN staff would be unable to discern a series of >> spun-up holding corps with hidden ownership. > > We do see what appears to be that now (or at least engineering of whois records to make it seem like they are different companies) in existing records. That is correct; discerning these situations is not assured by any means, although we do routinely detect and take accordingly accordingly. Any policy developed needs to consider potential aspects for gaming and take a realistic view that ARIN's enforcement must balance the benefits of taking action against the potential impacts of harming an innocent party (particularly when such must be based on subjective judgements rather then objective facts.) FYI, /John John Curran President and CEO ARIN From owen at delong.com Mon Jun 9 15:13:53 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 9 Jun 2014 12:13:53 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfersarin-ppml@arin.net List (arin-ppml@arin.net); In-Reply-To: References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> Message-ID: <1F7F9293-BAB4-4B7C-83B2-3B1AC2F28610@delong.com> On Jun 9, 2014, at 11:36 , Mike Burns wrote: > Hi Owen, > > Thanks for your reply. Fears of hoarding and speculation don't apply to 2014-14, unless you think that ARIN staff would be unable to discern a series of spun-up holding corps with hidden ownership. In any case, our different perspectives of the risks involved are not applicable to 2014-14, which I know was not the context of your earlier post. And I would like to move the discussion towards 2014-14 and away from fears of an unregulated market. I have no reason to believe that they could not. However, I have also made my position on 2014-14 clear and I believe it carries other risks. I have proposed a compromise which I thought was acceptable and basically met the anti-needs crowd approximately half-way (proposed /16, I proposed /24, /20 seems about as "in the middle" as is feasible). > APNIC reinstated their needs test only because ARIN supply was held hostage, I believe you may have been involved? I don't see it that way, but if you are asking if I was involved in the ARIN policy process and/or talking to APNIC about the issues at the time, then, yes, I was. I find your use of the term "hostage" offensive and inaccurate. > What's more, like ARIN's previous CEO and unlike ARIN's current CEO, RIPE never took the position that RIPE policy applies to legacy space. So there has always been a needs-free market for RIPE ERX space, but that market remains untapped by speculators, both before and after RIPE exhaust. And, of course, since needs are no longer tested for RIPE transfers, we can use RIPE as our experiment to see if speculators attempt to take advantage of that. RIPE publishes transfer statistics. Would you consider a review of those statistics a reasonable way to discern the presence of speculators? Not until some time after the ARIN free pool is exhausted, no. > The idea that somebody would contact /23 and /24 holders in order to speculate fills me with mirth. I kind of think a speculator would be more efficient if he called a couple of brokers. I don't believe I said the speculators would necessarily not work through brokers. What makes you think I expect them to necessarily deal directly? Owen > > Regards, > Mike > > > > > -----Original Message----- From: Owen DeLong > Sent: Monday, June 09, 2014 1:30 PM > To: Mike Burns > Cc: lar at mwtcorp.net ; Steven Ryerse ; arin-ppml at arin.net List (arin-ppml at arin.net) > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > On Jun 7, 2014, at 07:15 , Mike Burns wrote: > >> Hi Owen, >> >> Finding 4 actors who want to corner the market probably wouldn?t be very hard. Since 25% is 1/4 of the projected market size, I would say that the rest of your argument is on pretty shaky ground. >> >> >> It's not nearly so simple. First you would have to find four players willing to risk $8 billion dollars. Second you would have to have them create an inherently unstable cartel. Third you would have to find sellers with that much space, and this would likely mean hundreds of sellers at the least and a years-long endeavor. Fourth you would have to process those sales in a transparent market where your purchases are recorded for all to see. Fifth you would have to believe that there would be no reaction to this public information vis a vis price. Sixth you would also have to believe that these four billionaires ignored any risk of driving the IPv6 transition which would make their efforts worthless. Seventh you would have to ignore the fact that there are already methods of acquiring space without need which to my knowledge have not been used by speculators, and in fact there is zero evidence that speculators even exist. > > Nope, this doesn't have to be a cartel. It only has to be 4 or more actors each willing to invest an average of $2b and each of whom wants to see as many of their competitors as possible put at a substantial disadvantage in the near term future of the access market. > > Now I realize that large $TELCOS and large $CABLECOS and such would never engage in such anticompetitive practices and are staunch defenders of all good things like network neutrality, free and open peering policies and fantastic customer service with good bandwidth and fair prices. However, since pretty much everything in that last sentence has been repeatedly proven false, I don't think I'm on quite so shaky a ground after all. > > Your third item is absurd. If they don't find sellers with that much space, then it means the market isn't as large as described and the problem is even worse and market capture is even easier. Without a needs test or the other restrictions in 8.3, it would not take years, it would take days. Address space would be swept away as fast as it came available on the market. It would be IP lotto for the uber-wealthy corporations. > > As to fourth, yes and no. What's so transparent if $MEGACORP spins up lots of $IP_ADDRESS_HOLDING_CORPS just waiting to pounce on available space, much like the test-the-waters orders placed in various markets and dark pools looking for high-frequency trading victims? The stock market is allegedly just such an open market and is rife with just this kind of gouging. > > As to 6, no, they just have to decide that the risk of said transition occurring in less than time_T where T is their idea of investment recovery time given the expected advantage is relatively low. That's not so far fetched, since the average F500 corporation hasn't really started any sort of transition in earnest and will likely need 2 or more years to actually achieve a complete transition. > > Speculation in the face of an existing free pool is pretty nonsensical. Further, the entities I would expect to engage in this kind of speculation would likely consider it not worth the risk unless they can get the addresses registered to them in the recognized registry. > >>> We are three years into the open, post-Microsoft/Nortel market and there is no evidence of hoarding in my experience. I have never fielded a phone call or email from any company or individual seeking addresses they didn't plan to utilize at some point, although I have fielded plenty from people seeking addresses that for whatever reason ARIN policy would prohibit them from registering. Perhaps other brokers on the list might report on their experiences. >> >> Address space is still available nearly for free from ARIN, especially for smaller organizations, so this isn?t a real test of what will happen post runout and any claim that it is is absurd. >> >> >> Are you saying that my claim of never having heard from a speculator is absurd? Have you forgotten that APNIC and RIPE ran out years ago? (after which point they both dropped the needs test for transfers). > > Shortly after dropping the needs test, APNIC reinstated it. > > While you may not have heard from a speculator, others have. I have, in fact, received offers from speculators even for my tiny little /23 and /24. > >>> Little guys benefit from the dropping of needs test for small transfers. No need to navigate the ARIN process if you just need a /24 and you can't get one from your upstream, or not at a reasonable cost, or because you feel more secure with your own space, or because you don't wish to game the system. Support of 2014-14 would allow small companies to have this option while preventing hoarding or speculation through limits on size and number of transfers. Perhaps you care to comment on whether you might consider support of 2014-14 at the current size of /16 or at another size that you might feel more appropriate? >> >> Again, this is your perspective, but it?s not necessarily entirely true. It?s only true if you assume that the market will have a continuous supply and demand will be lower than supply. I would argue that the number of inter-RIR transfers to the APNIC region which have already been processed would indicate that after exhaustion, this is unlikely to be a persistent state or even last very long at all. >> >> Owen I have brokered more transfers to APNIC than anybody in the world. Nothing I said requires that there be a continuous situation where demand is lower than supply. However I can report without much understanding that there is indeed more supply than demand in the transfer market today, based on my own experiences and those I have heard from other brokers. > > I don't doubt that today as there remains a free pool in the ARIN region. I do not see that persisting more than a year or so with needs basis in place and even faster if needs basis is removed once the ARIN and LACNIC free pools are exhausted. > > Owen From mike at iptrading.com Mon Jun 9 15:34:07 2014 From: mike at iptrading.com (Mike Burns) Date: Mon, 9 Jun 2014 15:34:07 -0400 Subject: [arin-ppml] About needs basis in 8.3transfersarin-ppml@arin.net List (arin-ppml@arin.net); In-Reply-To: <42E285B9-3AF4-4851-8E62-65733428DC54@corp.arin.net> References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> <42E285B9-3AF4-4851-8E62-65733428DC54@corp.arin.net> Message-ID: <09701469CE984AA69E4C7E093FBEFAAA@MPC> Hi John, That RFC 2050 stuff is just FUD. I was saying that Plzak declared in court that ARIN's policies did not apply to legacy space. But you have said that they do. On the other hand, RIPE ERX has been transferable without need because of its legacy status. The statement you extracted was tangential and distracting to the needs-based discussion. It was made simply in the context of demonstrating that such a needs-free market has existed for some time without evidence of speculation. If I were to re-write it, I would leave you out, since I am guilty of the same distraction. Regards, Mike -----Original Message----- From: John Curran Sent: Monday, June 09, 2014 2:55 PM To: Mike Burns Cc: Owen DeLong ; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3transfersarin-ppml at arin.net List (arin-ppml at arin.net); On Jun 9, 2014, at 2:36 PM, Mike Burns wrote: > What's more, like ARIN's previous CEO and unlike ARIN's current CEO, RIPE > never took the position that RIPE policy applies to legacy space. Mike - Your statement is factually incorrect in multiple ways; you probably are unaware that adherence to the needs-based assignment criteria for purpose of transfers actually originates in RFC 2050 ("INTERNET REGISTRY IP ALLOCATION GUIDELINES"), dated November 1996 (and before my involvement in the Internet registry system.) The document authors are staff from RIPE, APNIC, and InterNIC and assert it to be an accurate representation of the current practice of the IP address registries at that time. From - " 7. The transfer of IP addresses from one party to another must be approved by the regional registries. The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR." When the ARIN community developed an explicit transfer policy, the more recent community set policy took precedence. The needs-based requirements in NRPM 8.3 remain in place because the ARIN community has not seen to remove them; i.e. they are under the control of this community via the policy development process and that has little to do with the staff or Board views on this matter. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Mon Jun 9 15:45:37 2014 From: jcurran at arin.net (John Curran) Date: Mon, 9 Jun 2014 19:45:37 +0000 Subject: [arin-ppml] About needs basis in 8.3transfersarin-ppml@arin.net List (arin-ppml@arin.net); In-Reply-To: <09701469CE984AA69E4C7E093FBEFAAA@MPC> References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> <42E285B9-3AF4-4851-8E62-65733428DC54@corp.arin.net> <09701469CE984AA69E4C7E093FBEFAAA@MPC> Message-ID: <8B9DFF6B-C740-4846-85BA-C73C4CC8F019@arin.net> On Jun 9, 2014, at 3:34 PM, Mike Burns wrote: > The statement you extracted was tangential and distracting to the needs-based discussion. Tangential or not, such a statement on ppml will not go uncorrected. FYI, /John John Curran President and CEO ARIN From andrew.dul at quark.net Mon Jun 9 18:55:09 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 09 Jun 2014 15:55:09 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> Message-ID: <53963B4D.5050808@quark.net> On 6/6/2014 8:06 AM, Milton L Mueller wrote: > All we are debating is the presence or absence of needs assessment as a gatekeeping function for that market. > This is a fairly administrative and technical argument, not a moral one. Efficiency is the key criterion (not fairness, really). If you support needs assessments you have to make a case that the costs and burdens associated with it are justified by quantifiable benefits. In this case, inefficiency is unfairness: if the needs assessment process prevents resources from going where they are wanted most, or if the cost burdens associated with the process exceed the value of the numbers acquired for small operators, or if it is shown that large, established companies with well-established relationships to ARIN can navigate the process more easily, then there are signs that needs assessment is unfair because of its inefficiencies. > > You have to do a better job of explaining why it is "fair" to force a willing seller and a willing buyer to submit to an additional step when that step both limits the quantity of resources available for transfer and raises the cost of participating in the market by a substantial degree. > Milton, Thank you for this two paragraph summary of what we are debating here. Are there, in your opinion, any reasonable "steps" (e.g. policy elements) that the registry community should implement as policy between a buyer and a seller that are not the "existing traditional needs assessment" which would provide a benefit to the IPv4 market and Internet community as a whole? Andrew From andrew.dul at quark.net Mon Jun 9 19:13:02 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 09 Jun 2014 16:13:02 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate In-Reply-To: <53767336.4080001@arin.net> References: <53767336.4080001@arin.net> Message-ID: <53963F7E.1030007@quark.net> Hello, Thank you to those of you who were able to participate at the PPC last week at NANOG. Below are some thoughts based on the feedback I heard. I heard some support for this policy with the caveat that this policy would allow some organizations to apply for address space sooner. Some postulated that the downside to this policy would be short and likely small for the remainder of the free pool, but it would also make it easier to qualify for transfer space sooner on the transfer market. I heard that this policy shouldn't impact organizations which currently use the MDN 4.5 policies and that the current MDN policy does not have the same issue as it uses a 80% per site metric to meet utilization requirements. The other issue which is related to this draft that I heard at the PPC was that ARIN in the past year or so updated its operational practice to more closely follow the current policy of " efficiently utilized all previous allocations" (4.2.4.1) and this is also making harder for some organizations to meet utilization guidelines at the time of request for additional space. Do other organizations also believe the new operational practice is an issue and the policy should be changed? As I stated at the PPC, so far I've seen a little support for this and some opposition for this proposal, but at this point not enough to move it forward to a recommended policy based on the current feedback. If you support this policy, please post your support to the mailing-list otherwise as the policy shepherd I will likely be recommending that the AC abandon this draft at a future AC meeting. Thanks for your input, Andrew On 5/16/2014 1:21 PM, ARIN wrote: > > ## * ## > > > Draft Policy ARIN-2014-17 > Change Utilization Requirements from last-allocation to total-aggregate > > Date: 16 May 2014 > > Problem Statement: > > Utilization requirements for new requests is being calculated on a per > allocation basis rather than in aggregate. For example, if an > organization has 4 x /22 and 3 of them are utilized 100% and the > fourth utilized at 75%, that request would be denied. This is a bit > out of balance as an organization with a single /20 utilized at 80% > would have less efficient utilization but would be eligible to request > additional space. > > Policy statement: > > Section 4.2.4.1- Change text to read: "ISPs must have efficiently > utilized all previous allocations, in aggregate, to at least 80% in > order to receive additional space. This includes all space reassigned > to their customers. Please note that until your prior utilization is > verified to meet the 80% requirement, ARIN can neither process nor > approve a request for additional addresses." > > Section 4.3.6.1- Change text to read: "End-users must have efficiently > utilized all previous assignments, in aggregate, to at least 80% in > order to receive additional space, and must provide ARIN with > utilization details. The prefix size for an additional assignment is > determined by applying the policies found in Section 4.3 of the NRPM." > > Comments: > > a. Timetable for implementation: Immediate, possibly through board > action. > b. Per originator, This does not currently extend into MDN (aka > 4.5.4), and I'm not really sure how to reconcile it against 4.5.5, but > OP expressed some concern that there may be undue restrictions there. > It might be better served by a separate proposal. > c. There should probably also be an attempt to clean up the language > between 4.2.4.1 and 4.3.6.1, as they're both currently very clunky. From dogwallah at gmail.com Mon Jun 9 21:23:23 2014 From: dogwallah at gmail.com (McTim) Date: Mon, 9 Jun 2014 20:23:23 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> Message-ID: Hi Milton, On Fri, Jun 6, 2014 at 10:06 AM, Milton L Mueller wrote: > > This debate has descended into rather nasty and unconstructive name calling. So if I am not mistaken with the attribution here, we have Woodcock calling Huberman 'idiotic,' a devotee of Ayn Rand (how did she get in here?), the moral equivalent of a slave trader, and a self-indulgent non-adult. > > May I ask that this stop? > > Bill, the entire community has already recognized the legitimacy of markets for IPv4 numbers. Transfer markets are institutionalized and have been for 4 years. So any argument that is based on comparing it to the slave/drug trade is gone. > > All we are debating is the presence or absence of needs assessment as a gatekeeping function for that market. > This is a fairly administrative and technical argument, not a moral one. Efficiency is the key criterion (not fairness, really). > If you support needs assessments you have to make a case that the costs and burdens associated with it are justified by quantifiable benefits. Is it the case that those support the status quo need to make a case to keep the status quo, or is it the case that those who seek change need to convince the rest of the community that those changes are justified? The latter has not been done IMHO. > In this case, inefficiency is unfairness: if the needs assessment process prevents resources from going where they are wanted most, ummmm, of course a "needs" assessment will prevent "want" from being fulfilled. it won't prevent "need" from being fulfilled however, or at least, it should not. or if the cost burdens >associated with the process exceed the value of the numbers acquired for small operators, or if it is shown that large, established companies with well-> established relationships to ARIN can navigate the process more easily, then there are signs that needs assessment is unfair because of its inefficiencies. > > > You have to do a better job of explaining why it is "fair" to force a willing seller and a willing buyer to submit to an additional step when that step both limits the quantity of resources available for transfer and raises the cost of participating in the market by a substantial degree. How much is a "substantial degree"? Is it like "how long is a piece of string?" -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From springer at inlandnet.com Mon Jun 9 23:28:00 2014 From: springer at inlandnet.com (John Springer) Date: Mon, 9 Jun 2014 20:28:00 -0700 (PDT) Subject: [arin-ppml] Draft Policy 2014-14, WAS Re: About needs basis in 8.3 transfers In-Reply-To: <53963B4D.5050808@quark.net> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> <53963B4D.5050808@quark.net> Message-ID: OP of "[arin-ppml] About needs basis in 8.3 transfers", I hope this has been useful to you. And the speech in Bellevue. As shepherd of 2014-14, I am less sure of what I may make of it. It is a lovely philosophical discussion. Clearly an excellent opportunity for adherents of two diametrically opposed camps to ascend the lofty pulpit and orate, without the messy necessity of voicing support or opposition to the Draft Policy that theoretically all of this refers to, this being a list for the discussion of public policy. Comments to each of my esteemed collegues below. On Mon, 9 Jun 2014, Andrew Dul wrote: > On 6/6/2014 8:06 AM, Milton L Mueller wrote: >> All we are debating is the presence or absence of needs assessment as a >> gatekeeping function for that market. Not precisely. For unless you are just commenting generally about an unconnected bunch of opinionating, you are commenting about 2014-14, which, while it is about "the presence or absence of needs assessment" may not be relegated to a simplistic gatekeeping function by your merely stating that it is so. 2014-14 seeks to address a specific issue (transfer request processing time) that happens to fall within a much larger context (access to number resource rights). Using one to draw conclusions about the other runs immediately afoul of the several ergo propter hocs. Unless you are not referring to 2014-14, in which case carry on, my bad. >> This is a fairly administrative and technical argument, not a moral one. Not really. For instance, what argument is that? And I sure thought I read some moralizing in this long thread which is not invalidated by the previous statement. >> Efficiency is the key criterion (not fairness, really). 2014-14 or not, you decide. >> If you support needs assessments you have to make a case that the costs >> and burdens associated with it are justified by quantifiable benefits. In what context? 2014-14? If so, you're getting way too fancy. IMO, that is what the proposal author is trying to do, (make the case, not get fancy). To express support for the DP, (if that's what you are trying to do), all the double negatives here are kinda confusing. If you are speaking to an opponent of the DP, they do not in fact have to make the case as you describe. I sort of have to make the opposite case. >> In this case, inefficiency is unfairness: if the needs assessment >> process prevents resources from going where they are wanted most, or if >> the cost burdens associated with the process exceed the value of the >> numbers acquired for small operators, or if it is shown that large, >> established companies with well-established relationships to ARIN can >> navigate the process more easily, then there are signs that needs >> assessment is unfair because of its inefficiencies. You said above efficiency and fairness were not really the key criterion, here you say they are the same (or rather that their opposites are, which implies...). Which do you mean? >> You have to do a better job of explaining why it is "fair" to force a >> willing seller and a willing buyer to submit to an additional step when >> that step both limits the quantity of resources available for transfer >> and raises the cost of participating in the market by a substantial >> degree. Again, if you are trying to help rebut opponents of 2014-14, this is not their job. The failure to prove the converse leads to status quo. Whomever you might be addressing with this comment apparently needs no encouragement to continue to make this exact case at some length. I would find more useful, comments why this is _NOT_ fair. Call me kooky. > Milton, > > Thank you for this two paragraph summary of what we are debating here. So, Andrew. As one shepherd of 2014-14 to another, what are we to do with "Re: [arin-ppml] About needs basis in 8.3 transfers" WRT 2014-14? Are arguments there able to be applied wholesale to 2014-14, mapping (divining?) pro-needs basis logic as anti-2014-14 and vice verse? If not, is it all to be discounted by saying that the authors did not explicitly express either support or opposition and therefore we are not permitted to read anything into their statements? All list posters who posted to "About needs basis in 8.3 transfers", is it OK to read your minds about this or do you want to come back and state what you mean clearly in a context that is unambiguous? > Are there, in your opinion, any reasonable "steps" (e.g. policy > elements) that the registry community should implement as policy between > a buyer and a seller that are not the "existing traditional needs > assessment" which would provide a benefit to the IPv4 market and > Internet community as a whole? Excellent question, such commentary would be valuable and welcome, and if so, what? John Springer > Andrew > > _______________________________________________ > 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 Jun 10 00:01:02 2014 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 10 Jun 2014 04:01:02 +0000 Subject: [arin-ppml] Draft Policy 2014-14, WAS Re: About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> <53963B4D.5050808@quark.net>, Message-ID: <74e82ba2a1c144ee8bd5a10674b7fd68@DM2PR03MB398.namprd03.prod.outlook.com> As the OP, yes, I think this has been useful. We have very very low participation but I sincerely thank those who take the time to participate. I agree with the poster who characterized the debate about needs basis and 8.3 transfers to be two diametrically opposed positions. But again, I'm not sure 10-15 people on a mailing list is representative of anything. :( David R Huberman Microsoft Corporation Senior IT/OPS Program Manager (GFS) ________________________________________ From: arin-ppml-bounces at arin.net on behalf of John Springer Sent: Monday, June 9, 2014 8:28:00 PM To: Andrew Dul Cc: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy 2014-14, WAS Re: About needs basis in 8.3 transfers OP of "[arin-ppml] About needs basis in 8.3 transfers", I hope this has been useful to you. And the speech in Bellevue. As shepherd of 2014-14, I am less sure of what I may make of it. It is a lovely philosophical discussion. Clearly an excellent opportunity for adherents of two diametrically opposed camps to ascend the lofty pulpit and orate, without the messy necessity of voicing support or opposition to the Draft Policy that theoretically all of this refers to, this being a list for the discussion of public policy. Comments to each of my esteemed collegues below. On Mon, 9 Jun 2014, Andrew Dul wrote: > On 6/6/2014 8:06 AM, Milton L Mueller wrote: >> All we are debating is the presence or absence of needs assessment as a >> gatekeeping function for that market. Not precisely. For unless you are just commenting generally about an unconnected bunch of opinionating, you are commenting about 2014-14, which, while it is about "the presence or absence of needs assessment" may not be relegated to a simplistic gatekeeping function by your merely stating that it is so. 2014-14 seeks to address a specific issue (transfer request processing time) that happens to fall within a much larger context (access to number resource rights). Using one to draw conclusions about the other runs immediately afoul of the several ergo propter hocs. Unless you are not referring to 2014-14, in which case carry on, my bad. >> This is a fairly administrative and technical argument, not a moral one. Not really. For instance, what argument is that? And I sure thought I read some moralizing in this long thread which is not invalidated by the previous statement. >> Efficiency is the key criterion (not fairness, really). 2014-14 or not, you decide. >> If you support needs assessments you have to make a case that the costs >> and burdens associated with it are justified by quantifiable benefits. In what context? 2014-14? If so, you're getting way too fancy. IMO, that is what the proposal author is trying to do, (make the case, not get fancy). To express support for the DP, (if that's what you are trying to do), all the double negatives here are kinda confusing. If you are speaking to an opponent of the DP, they do not in fact have to make the case as you describe. I sort of have to make the opposite case. >> In this case, inefficiency is unfairness: if the needs assessment >> process prevents resources from going where they are wanted most, or if >> the cost burdens associated with the process exceed the value of the >> numbers acquired for small operators, or if it is shown that large, >> established companies with well-established relationships to ARIN can >> navigate the process more easily, then there are signs that needs >> assessment is unfair because of its inefficiencies. You said above efficiency and fairness were not really the key criterion, here you say they are the same (or rather that their opposites are, which implies...). Which do you mean? >> You have to do a better job of explaining why it is "fair" to force a >> willing seller and a willing buyer to submit to an additional step when >> that step both limits the quantity of resources available for transfer >> and raises the cost of participating in the market by a substantial >> degree. Again, if you are trying to help rebut opponents of 2014-14, this is not their job. The failure to prove the converse leads to status quo. Whomever you might be addressing with this comment apparently needs no encouragement to continue to make this exact case at some length. I would find more useful, comments why this is _NOT_ fair. Call me kooky. > Milton, > > Thank you for this two paragraph summary of what we are debating here. So, Andrew. As one shepherd of 2014-14 to another, what are we to do with "Re: [arin-ppml] About needs basis in 8.3 transfers" WRT 2014-14? Are arguments there able to be applied wholesale to 2014-14, mapping (divining?) pro-needs basis logic as anti-2014-14 and vice verse? If not, is it all to be discounted by saying that the authors did not explicitly express either support or opposition and therefore we are not permitted to read anything into their statements? All list posters who posted to "About needs basis in 8.3 transfers", is it OK to read your minds about this or do you want to come back and state what you mean clearly in a context that is unambiguous? > Are there, in your opinion, any reasonable "steps" (e.g. policy > elements) that the registry community should implement as policy between > a buyer and a seller that are not the "existing traditional needs > assessment" which would provide a benefit to the IPv4 market and > Internet community as a whole? Excellent question, such commentary would be valuable and welcome, and if so, what? John Springer > Andrew > > _______________________________________________ > 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 mueller at syr.edu Tue Jun 10 02:15:54 2014 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 10 Jun 2014 06:15:54 +0000 Subject: [arin-ppml] Draft Policy 2014-14, WAS Re: About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> <53963B4D.5050808@quark.net> Message-ID: > -----Original Message----- > Not precisely. For unless you are just commenting generally about an > unconnected bunch of opinionating, That is precisely what I was doing! ;-) My mailbox was so full of that that I hadn't time to drill down to its origin, and as you seem to have recognized by changing the message header, the topic seemed to be generic "needs basis in 8.3 transfers..." So. Carry on.... From andrew.dul at quark.net Tue Jun 10 12:42:37 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 10 Jun 2014 09:42:37 -0700 Subject: [arin-ppml] Draft Policy 2014-14, WAS Re: About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> <53963B4D.5050808@quark.net> Message-ID: <5397357D.1060802@quark.net> On 6/9/2014 8:28 PM, John Springer wrote: > So, Andrew. As one shepherd of 2014-14 to another, what are we to do > with "Re: [arin-ppml] About needs basis in 8.3 transfers" WRT 2014-14? > Are arguments there able to be applied wholesale to 2014-14, mapping > (divining?) pro-needs basis logic as anti-2014-14 and vice verse? If > not, is it all to be discounted by saying that the authors did not > explicitly express either support or opposition and therefore we are > not permitted to read anything into their statements? > While 2014-14 has been narrowly crafted currently to be about alleviating ARIN staffing issues associated with transfers, I believe the author's intent is to remove needs basis testing from "small" block transfers and then moving toward "larger" blocks later. While I cannot speak for the author directly, his comments on the list and to me have lead me to this conclusion. Thus, while the policy draft is construed as being narrow about one issue, in effect it is opening the debate about 8.3 transfer needs assessment. Given that we have been discussing needs basis in 8.3 transfer, not fixing the ARIN staffing issue, which could be resolved in other manners than this policy change, I believe that the discussion "About needs basis in 8.3 transfers" is germane to the discussion of this policy and should be taken into consideration. Based upon the assertion that the general discussion about needs assessment in 8.3 transfers, I do not see consensus currently forming around the current draft policy. Given, we do not have consensus on the current draft, I see the following options available to us which are all not mutually exclusive: 1. Move to abandon the current draft policy, if the community disagrees with this approach, I invite them to petition the abandonment by the AC if it occurs. 2. Update the policy text to allow up to a /20 to be transferred without the needs assessment. We have had posts by some authors who believe /16 is to big but would support a smaller block. 3. Update the problem statement of the draft to better highlight the other issues that the policy is addressing, notably that there are organizations and individuals who believe that the current needs assessment needs to be updated in a post-exhaustion IPv4 world. 4. Work with members of the community to see if there are areas of common ground which could be used to rework the current policy into something that might gain consensus in the future. (See my discusiion about the needs basis continuum below) 5. Continue to allow the draft policy to be debated and look for additional ideas from the community to refine and update the policy sometime in the future. >> Are there, in your opinion, any reasonable "steps" (e.g. policy >> elements) that the registry community should implement as policy between >> a buyer and a seller that are not the "existing traditional needs >> assessment" which would provide a benefit to the IPv4 market and >> Internet community as a whole? > > Excellent question, such commentary would be valuable and welcome, and > if so, what? > Others ideas are certainly desired here... In my opinion, not speaking as the shepherd here, needs basis testing is not a binary operation, instead it is a continuum from "no needs" to somewhere near the current needs based policies. One could imagine this continuum as a series of steps which move from no restrictions toward more restrictions. Overtime the RIRs generally added restrictions to promote conservation and efficient use. Given that we now will have market forces applying to the IPv4 address rights, it makes sense to reexamine the current needs basis criteria. Perhaps, now is the time to move downward from the current criteria toward the "no needs" side of the continuum. I, personally, believe there is value in retaining some aspect of needs testing specifically the two attestations enumerated below. There may also be value in retaining some backward looking auditing of utilization at additional allocations. There may also be other restrictions which could be valuable the the Internet community as a whole such as anti-flipping restrictions on transfers. There may also be value in some other policy elements that I have not enumerated here. No needs testing V Attestation of legal use V Operation need attestation V Backward looking auditing of utilization* at additional allocations V Forward looking projection of utilization* at additional allocations V Additional restrictions at additional allocations * Utilization can also be weakly or strongly defined. I would consider current policy quite strongly defined, but one could envision a policy which was much weaker. (e.g. 50% utilization rather than the current 80%) Andrew From dogwallah at gmail.com Tue Jun 10 14:29:00 2014 From: dogwallah at gmail.com (McTim) Date: Tue, 10 Jun 2014 13:29:00 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> References: <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> Message-ID: Hi Steven, On Wed, Jun 4, 2014 at 6:50 PM, Steven Ryerse wrote: > There are several folks (like me) who want to ditch the needs test and > there are several folks who don't want to ditch them. I take it your > position is that the folks who want to keep needs tests should somehow > prevail in this argument without much or any change, and those of us who > wish to ditch them should just accept the status quo with needs tests. In > other words you win and we lose! > > I saw a lot of folks comment here recently who want to at least loosen > needs tests on the smaller block sizes, many many more than I've ever seen > before. Since it is obvious a sizable portion of this community desires a > change toward loosening policies, why is it that you persist in standing in > the way of compromise? > As for me, I think relaxing (not eliminating needs assessment at a /24 boundary is plenty of compromise. See Andrew Dul's most recent mail for possible scenario's. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel > > There comes a time when fair is fair - and small organizations are > routinely discriminated against because of our small size and not so deep > pockets. There is a lot of anger out there over the unfairness of these > existing policies. It should be just as easy for us to get resources as it > was for T-Mobile and others. I call on all members of this community to at > least come to a compromise. After all the world hasn't ended for RIPE with > their changes - and it won't end here either if fairness is put back into > the policies so that small organizations can get the resources they need > too! > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > www.eclipse-networks.com > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Wednesday, June 04, 2014 7:25 PM > To: Matthew Kaufman > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > > > Matthew Kaufman > > > > ps. I'd also note that "policy that expresses the general intent of the > community" may in fact *be* policy that lets post-runout transfers be > performed without a needs test, as "the community" consists of a lot more > than "Owen?. > > Indeed, it does. However, many people have also repeatedly stood up in > defense of needs basis, so singling me out as if I am the lone supporter of > preserving needs basis is as specious as many of your other arguments. > > Owen > > _______________________________________________ > 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 SRyerse at eclipse-networks.com Tue Jun 10 14:54:57 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 10 Jun 2014 18:54:57 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <538F3B35.80908 06@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com><5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AB03F52@ENI-MAIL.eclipse-networks.com> Wow! A whole /24 ? that?s pretty generous of you! What a large compromise that is . . . . 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: McTim [mailto:dogwallah at gmail.com] Sent: Tuesday, June 10, 2014 2:29 PM To: Steven Ryerse Cc: Owen DeLong; Matthew Kaufman; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers Hi Steven, On Wed, Jun 4, 2014 at 6:50 PM, Steven Ryerse > wrote: There are several folks (like me) who want to ditch the needs test and there are several folks who don't want to ditch them. I take it your position is that the folks who want to keep needs tests should somehow prevail in this argument without much or any change, and those of us who wish to ditch them should just accept the status quo with needs tests. In other words you win and we lose! I saw a lot of folks comment here recently who want to at least loosen needs tests on the smaller block sizes, many many more than I've ever seen before. Since it is obvious a sizable portion of this community desires a change toward loosening policies, why is it that you persist in standing in the way of compromise? As for me, I think relaxing (not eliminating needs assessment at a /24 boundary is plenty of compromise. See Andrew Dul's most recent mail for possible scenario's. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel There comes a time when fair is fair - and small organizations are routinely discriminated against because of our small size and not so deep pockets. There is a lot of anger out there over the unfairness of these existing policies. It should be just as easy for us to get resources as it was for T-Mobile and others. I call on all members of this community to at least come to a compromise. After all the world hasn't ended for RIPE with their changes - and it won't end here either if fairness is put back into the policies so that small organizations can get the resources they need too! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Wednesday, June 04, 2014 7:25 PM To: Matthew Kaufman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > Matthew Kaufman > > ps. I'd also note that "policy that expresses the general intent of the community" may in fact *be* policy that lets post-runout transfers be performed without a needs test, as "the community" consists of a lot more than "Owen?. Indeed, it does. However, many people have also repeatedly stood up in defense of needs basis, so singling me out as if I am the lone supporter of preserving needs basis is as specious as many of your other arguments. Owen _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From dogwallah at gmail.com Tue Jun 10 15:30:03 2014 From: dogwallah at gmail.com (McTim) Date: Tue, 10 Jun 2014 14:30:03 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AB03F52@ENI-MAIL.eclipse-networks.com> References: <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB03F52@ENI-MAIL.eclipse-networks.com> Message-ID: Is is indeed a significant shift in my position. I think that is something you should recognise. I'm all for giving small orgs the space they need, which seems to be what you want. However, ido not believe that this policyt does that for you, or indeed for anyone in a way that is cheaper than getting the space from the RIR. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel On Tue, Jun 10, 2014 at 1:54 PM, Steven Ryerse wrote: > Wow! A whole /24 ? that?s pretty generous of you! What a large > compromise that is . . . . > > > > *Steven Ryerse* > > *President* > > *100 Ashford Center North, Suite 110, Atlanta, GA 30338* > > *770.656.1460 <770.656.1460> - Cell* > > *770.399.9099 <770.399.9099>- Office* > > > > [image: Description: Description: Eclipse Networks Logo_small.png]? Eclipse > Networks, Inc. > > Conquering Complex Networks? > > > > *From:* McTim [mailto:dogwallah at gmail.com] > *Sent:* Tuesday, June 10, 2014 2:29 PM > *To:* Steven Ryerse > *Cc:* Owen DeLong; Matthew Kaufman; arin-ppml at arin.net > > *Subject:* Re: [arin-ppml] About needs basis in 8.3 transfers > > > > Hi Steven, > > > > On Wed, Jun 4, 2014 at 6:50 PM, Steven Ryerse < > SRyerse at eclipse-networks.com> wrote: > > There are several folks (like me) who want to ditch the needs test and > there are several folks who don't want to ditch them. I take it your > position is that the folks who want to keep needs tests should somehow > prevail in this argument without much or any change, and those of us who > wish to ditch them should just accept the status quo with needs tests. In > other words you win and we lose! > > I saw a lot of folks comment here recently who want to at least loosen > needs tests on the smaller block sizes, many many more than I've ever seen > before. Since it is obvious a sizable portion of this community desires a > change toward loosening policies, why is it that you persist in standing in > the way of compromise? > > > > As for me, I think relaxing (not eliminating needs assessment at a /24 > boundary is plenty of compromise. > > See Andrew Dul's most recent mail for possible scenario's. > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A route > indicates how we get there." Jon Postel > > > > There comes a time when fair is fair - and small organizations are > routinely discriminated against because of our small size and not so deep > pockets. There is a lot of anger out there over the unfairness of these > existing policies. It should be just as easy for us to get resources as it > was for T-Mobile and others. I call on all members of this community to at > least come to a compromise. After all the world hasn't ended for RIPE with > their changes - and it won't end here either if fairness is put back into > the policies so that small organizations can get the resources they need > too! > > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > www.eclipse-networks.com > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Wednesday, June 04, 2014 7:25 PM > To: Matthew Kaufman > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > > > > Matthew Kaufman > > > > ps. I'd also note that "policy that expresses the general intent of the > community" may in fact *be* policy that lets post-runout transfers be > performed without a needs test, as "the community" consists of a lot more > than "Owen?. > > Indeed, it does. However, many people have also repeatedly stood up in > defense of needs basis, so singling me out as if I am the lone supporter of > preserving needs basis is as specious as many of your other arguments. > > Owen > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: not available URL: From SRyerse at eclipse-networks.com Tue Jun 10 15:40:35 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 10 Jun 2014 19:40:35 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <973FD910-966B- 42E1-83B9-DA485445D04E@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com>< CACAaNxi5KzXXpGD0W+_TGRTv2GUABajh=peJMdf+BcoktC1WZA@mail.gmail.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB03F52@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AB04062@ENI-MAIL.eclipse-networks.com> If I understood your comment below, you are now agreeable to remove SOME of the needs tests on only a /24. I suppose that is a change but not much of one at all and it will only help the smallest of the needs out there MAYBE if they can pass whatever your relaxed needs test would be. Yes maybe that is a slight shift in your position but pretty negligible and NOT IMHO what is really needed. If this was 10 or 15 years ago and I was in a position to block an allocation request of yours for say a /22 that you really needed, I doubt you would be very happy if I told you that you could only have a /24 and then only if you could pass some arbitrary test that I came up with. In the real world folks need real allocations and current policy stands in the way. 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: McTim [mailto:dogwallah at gmail.com] Sent: Tuesday, June 10, 2014 3:30 PM To: Steven Ryerse Cc: Owen DeLong; Matthew Kaufman; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers Is is indeed a significant shift in my position. I think that is something you should recognise. I'm all for giving small orgs the space they need, which seems to be what you want. However, ido not believe that this policyt does that for you, or indeed for anyone in a way that is cheaper than getting the space from the RIR. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel On Tue, Jun 10, 2014 at 1:54 PM, Steven Ryerse > wrote: Wow! A whole /24 ? that?s pretty generous of you! What a large compromise that is . . . . 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: McTim [mailto:dogwallah at gmail.com] Sent: Tuesday, June 10, 2014 2:29 PM To: Steven Ryerse Cc: Owen DeLong; Matthew Kaufman; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers Hi Steven, On Wed, Jun 4, 2014 at 6:50 PM, Steven Ryerse > wrote: There are several folks (like me) who want to ditch the needs test and there are several folks who don't want to ditch them. I take it your position is that the folks who want to keep needs tests should somehow prevail in this argument without much or any change, and those of us who wish to ditch them should just accept the status quo with needs tests. In other words you win and we lose! I saw a lot of folks comment here recently who want to at least loosen needs tests on the smaller block sizes, many many more than I've ever seen before. Since it is obvious a sizable portion of this community desires a change toward loosening policies, why is it that you persist in standing in the way of compromise? As for me, I think relaxing (not eliminating needs assessment at a /24 boundary is plenty of compromise. See Andrew Dul's most recent mail for possible scenario's. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel There comes a time when fair is fair - and small organizations are routinely discriminated against because of our small size and not so deep pockets. There is a lot of anger out there over the unfairness of these existing policies. It should be just as easy for us to get resources as it was for T-Mobile and others. I call on all members of this community to at least come to a compromise. After all the world hasn't ended for RIPE with their changes - and it won't end here either if fairness is put back into the policies so that small organizations can get the resources they need too! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Wednesday, June 04, 2014 7:25 PM To: Matthew Kaufman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > Matthew Kaufman > > ps. I'd also note that "policy that expresses the general intent of the community" may in fact *be* policy that lets post-runout transfers be performed without a needs test, as "the community" consists of a lot more than "Owen?. Indeed, it does. However, many people have also repeatedly stood up in defense of needs basis, so singling me out as if I am the lone supporter of preserving needs basis is as specious as many of your other arguments. Owen _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From dogwallah at gmail.com Tue Jun 10 15:45:38 2014 From: dogwallah at gmail.com (McTim) Date: Tue, 10 Jun 2014 14:45:38 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AB04062@ENI-MAIL.eclipse-networks.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB03F52@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB04062@ENI-MAIL.eclipse-networks.com> Message-ID: On Tue, Jun 10, 2014 at 2:40 PM, Steven Ryerse wrote: > If I understood your comment below, you are now agreeable to remove SOME > of the needs tests on only a /24. I suppose that is a change but not much > of one at all and it will only help the smallest of the needs out there > MAYBE if they can pass whatever your relaxed needs test would be. Yes > maybe that is a slight shift in your position but pretty negligible > it's a huge paradigm shift for me. > and NOT IMHO what is really needed. > it is not at all what is needed for your org, certainly. > > > If this was 10 or 15 years ago and I was in a position to block an > allocation request of yours for say a /22 that you really needed, I doubt > you would be very happy if I told you that you could only have a /24 and > then only if you could pass some arbitrary test that I came up with. In > the real world folks need real allocations and current policy stands in the > way. > If it was 10-15 years ago and I NEEDED it, I could have shown that easily and gotten my /whatever. 10-15 years ago i was a RIR hostmaster. The bar is NOT very high to show need, it certainly wasn't then, and I don't think it has gone up! > > > *Steven Ryerse* > > *President* > > *100 Ashford Center North, Suite 110, Atlanta, GA 30338* > > *770.656.1460 <770.656.1460> - Cell* > > *770.399.9099 <770.399.9099>- Office* > > > > [image: Description: Description: Eclipse Networks Logo_small.png]? Eclipse > Networks, Inc. > > Conquering Complex Networks? > > > > *From:* McTim [mailto:dogwallah at gmail.com] > *Sent:* Tuesday, June 10, 2014 3:30 PM > > *To:* Steven Ryerse > *Cc:* Owen DeLong; Matthew Kaufman; arin-ppml at arin.net > *Subject:* Re: [arin-ppml] About needs basis in 8.3 transfers > > > > Is is indeed a significant shift in my position. > > I think that is something you should recognise. > > I'm all for giving small orgs the space they need, which seems to be what > you want. However, ido not believe that this policyt does that for you, or > indeed for anyone in a way that is cheaper than getting the space from the > RIR. > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A route > indicates how we get there." Jon Postel > > On Tue, Jun 10, 2014 at 1:54 PM, Steven Ryerse < > SRyerse at eclipse-networks.com> wrote: > > Wow! A whole /24 ? that?s pretty generous of you! What a large > compromise that is . . . . > > > > *Steven Ryerse* > > *President* > > *100 Ashford Center North, Suite 110, Atlanta, GA 30338* > > *770.656.1460 <770.656.1460> - Cell* > > *770.399.9099 <770.399.9099>- Office* > > > > [image: Description: Description: Eclipse Networks Logo_small.png]? Eclipse > Networks, Inc. > > Conquering Complex Networks? > > > > *From:* McTim [mailto:dogwallah at gmail.com] > *Sent:* Tuesday, June 10, 2014 2:29 PM > *To:* Steven Ryerse > *Cc:* Owen DeLong; Matthew Kaufman; arin-ppml at arin.net > > > *Subject:* Re: [arin-ppml] About needs basis in 8.3 transfers > > > > Hi Steven, > > > > On Wed, Jun 4, 2014 at 6:50 PM, Steven Ryerse < > SRyerse at eclipse-networks.com> wrote: > > There are several folks (like me) who want to ditch the needs test and > there are several folks who don't want to ditch them. I take it your > position is that the folks who want to keep needs tests should somehow > prevail in this argument without much or any change, and those of us who > wish to ditch them should just accept the status quo with needs tests. In > other words you win and we lose! > > I saw a lot of folks comment here recently who want to at least loosen > needs tests on the smaller block sizes, many many more than I've ever seen > before. Since it is obvious a sizable portion of this community desires a > change toward loosening policies, why is it that you persist in standing in > the way of compromise? > > > > As for me, I think relaxing (not eliminating needs assessment at a /24 > boundary is plenty of compromise. > > See Andrew Dul's most recent mail for possible scenario's. > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A route > indicates how we get there." Jon Postel > > > > There comes a time when fair is fair - and small organizations are > routinely discriminated against because of our small size and not so deep > pockets. There is a lot of anger out there over the unfairness of these > existing policies. It should be just as easy for us to get resources as it > was for T-Mobile and others. I call on all members of this community to at > least come to a compromise. After all the world hasn't ended for RIPE with > their changes - and it won't end here either if fairness is put back into > the policies so that small organizations can get the resources they need > too! > > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > www.eclipse-networks.com > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Wednesday, June 04, 2014 7:25 PM > To: Matthew Kaufman > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > > > > Matthew Kaufman > > > > ps. I'd also note that "policy that expresses the general intent of the > community" may in fact *be* policy that lets post-runout transfers be > performed without a needs test, as "the community" consists of a lot more > than "Owen?. > > Indeed, it does. However, many people have also repeatedly stood up in > defense of needs basis, so singling me out as if I am the lone supporter of > preserving needs basis is as specious as many of your other arguments. > > Owen > > _______________________________________________ > 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. > > > > > > -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel -------------- 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: not available URL: From SRyerse at eclipse-networks.com Tue Jun 10 16:11:15 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 10 Jun 2014 20:11:15 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <5B9E90747FA297 4D91A54FCFA1B8AD12015AAD58EE@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974 D91A54FCFA1B8AD12015AB03F52@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB04062@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AB041AB@ENI-MAIL.eclipse-networks.com> Get used to it because even if this Community doesn?t relent and ease up on needs requirements, the marketplace will take up the slack outside of ARIN - and a 2nd (or more) defacto marketplace will be created. It is inevitable and short of a law being past you and I can?t stop it. As you probably know this is already happening with the IP brokers out there and I could easily see another RIR who is out of resources joining up with significant 3rd party brokers to fill IPv4 needs at market prices worldwide. There is another supply of IPv4 resources out there in the form of all those Legacy /8?s that were given out many years ago, and I suspect that demand will bring some of those resources to market. That supply could defer switching to IPv6 for years and not everyone likes IPv6. I just don?t understand why ARIN & Community would sit pat when their allocation will be gone in a year or two and life will change around them. Seems prudent for ARIN & Community to join the fray instead of digging in against it. Loosening up needs testing on just a /24 is so far from joining the fray it is hard for me to see why someone as knowledgeable as you doesn?t want to see the forest from the trees. 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: McTim [mailto:dogwallah at gmail.com] Sent: Tuesday, June 10, 2014 3:46 PM To: Steven Ryerse Cc: Owen DeLong; Matthew Kaufman; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Tue, Jun 10, 2014 at 2:40 PM, Steven Ryerse > wrote: If I understood your comment below, you are now agreeable to remove SOME of the needs tests on only a /24. I suppose that is a change but not much of one at all and it will only help the smallest of the needs out there MAYBE if they can pass whatever your relaxed needs test would be. Yes maybe that is a slight shift in your position but pretty negligible it's a huge paradigm shift for me. and NOT IMHO what is really needed. it is not at all what is needed for your org, certainly. If this was 10 or 15 years ago and I was in a position to block an allocation request of yours for say a /22 that you really needed, I doubt you would be very happy if I told you that you could only have a /24 and then only if you could pass some arbitrary test that I came up with. In the real world folks need real allocations and current policy stands in the way. If it was 10-15 years ago and I NEEDED it, I could have shown that easily and gotten my /whatever. 10-15 years ago i was a RIR hostmaster. The bar is NOT very high to show need, it certainly wasn't then, and I don't think it has gone up! 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: McTim [mailto:dogwallah at gmail.com] Sent: Tuesday, June 10, 2014 3:30 PM To: Steven Ryerse Cc: Owen DeLong; Matthew Kaufman; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers Is is indeed a significant shift in my position. I think that is something you should recognise. I'm all for giving small orgs the space they need, which seems to be what you want. However, ido not believe that this policyt does that for you, or indeed for anyone in a way that is cheaper than getting the space from the RIR. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel On Tue, Jun 10, 2014 at 1:54 PM, Steven Ryerse > wrote: Wow! A whole /24 ? that?s pretty generous of you! What a large compromise that is . . . . 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: McTim [mailto:dogwallah at gmail.com] Sent: Tuesday, June 10, 2014 2:29 PM To: Steven Ryerse Cc: Owen DeLong; Matthew Kaufman; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers Hi Steven, On Wed, Jun 4, 2014 at 6:50 PM, Steven Ryerse > wrote: There are several folks (like me) who want to ditch the needs test and there are several folks who don't want to ditch them. I take it your position is that the folks who want to keep needs tests should somehow prevail in this argument without much or any change, and those of us who wish to ditch them should just accept the status quo with needs tests. In other words you win and we lose! I saw a lot of folks comment here recently who want to at least loosen needs tests on the smaller block sizes, many many more than I've ever seen before. Since it is obvious a sizable portion of this community desires a change toward loosening policies, why is it that you persist in standing in the way of compromise? As for me, I think relaxing (not eliminating needs assessment at a /24 boundary is plenty of compromise. See Andrew Dul's most recent mail for possible scenario's. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel There comes a time when fair is fair - and small organizations are routinely discriminated against because of our small size and not so deep pockets. There is a lot of anger out there over the unfairness of these existing policies. It should be just as easy for us to get resources as it was for T-Mobile and others. I call on all members of this community to at least come to a compromise. After all the world hasn't ended for RIPE with their changes - and it won't end here either if fairness is put back into the policies so that small organizations can get the resources they need too! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Wednesday, June 04, 2014 7:25 PM To: Matthew Kaufman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > Matthew Kaufman > > ps. I'd also note that "policy that expresses the general intent of the community" may in fact *be* policy that lets post-runout transfers be performed without a needs test, as "the community" consists of a lot more than "Owen?. Indeed, it does. However, many people have also repeatedly stood up in defense of needs basis, so singling me out as if I am the lone supporter of preserving needs basis is as specious as many of your other arguments. Owen _______________________________________________ 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. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel -------------- 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 lar at mwtcorp.net Tue Jun 10 16:15:01 2014 From: lar at mwtcorp.net (lar at mwtcorp.net) Date: Tue, 10 Jun 2014 14:15:01 -0600 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AB041AB@ENI-MAIL.eclipse-networks.com> References: Message-ID: On Tue, 10 Jun 2014 20:11:15 +0000 Steven Ryerse wrote: > Get used to it because even if this Community doesn?t relent and ease up on needs requirements, the marketplace will take up the >slack outside of ARIN - and a 2nd (or more) defacto marketplace will be created. It is inevitable and short of a law being past >you and I can?t stop it. As you probably know this is already happening with the IP brokers out there and I could easily see >another RIR who is out of resources joining up with significant 3rd party brokers to fill IPv4 needs at market prices worldwide. > There is another supply of IPv4 resources out there in the form of all those Legacy /8?s that were given out many years ago, and >I suspect that demand will bring some of those resources to market. That supply could defer switching to IPv6 for years and not >everyone likes IPv6. > Then maybe the discussion we should be having is how to reclaim un-needed IPV4 space. > I just don?t understand why ARIN & Community would sit pat when their allocation will be gone in a year or two and life will >change around them. Seems prudent for ARIN & Community to join the fray instead of digging in against it. Loosening up needs >testing on just a /24 is so far from joining the fray it is hard for me to see why someone as knowledgeable as you doesn?t want >to see the forest from the trees. > > 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: McTim [mailto:dogwallah at gmail.com] > Sent: Tuesday, June 10, 2014 3:46 PM > To: Steven Ryerse > Cc: Owen DeLong; Matthew Kaufman; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > > On Tue, Jun 10, 2014 at 2:40 PM, Steven Ryerse > wrote: > If I understood your comment below, you are now agreeable to remove SOME of the needs tests on only a /24. I suppose that is a >change but not much of one at all and it will only help the smallest of the needs out there MAYBE if they can pass whatever your >relaxed needs test would be. Yes maybe that is a slight shift in your position but pretty negligible > > it's a huge paradigm shift for me. > > > and NOT IMHO what is really needed. > > it is not at all what is needed for your org, certainly. > > > > > If this was 10 or 15 years ago and I was in a position to block an allocation request of yours for say a /22 that you really >needed, I doubt you would be very happy if I told you that you could only have a /24 and then only if you could pass some >arbitrary test that I came up with. In the real world folks need real allocations and current policy stands in the way. > > > If it was 10-15 years ago and I NEEDED it, I could have shown that easily and gotten my /whatever. > > 10-15 years ago i was a RIR hostmaster. The bar is NOT very high to show need, it certainly wasn't then, and I don't think it >has gone up! > > > > > > > > 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: McTim [mailto:dogwallah at gmail.com] > Sent: Tuesday, June 10, 2014 3:30 PM > > To: Steven Ryerse > Cc: Owen DeLong; Matthew Kaufman; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > Is is indeed a significant shift in my position. > I think that is something you should recognise. > I'm all for giving small orgs the space they need, which seems to be what you want. However, ido not believe that this policyt >does that for you, or indeed for anyone in a way that is cheaper than getting the space from the RIR. > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel > On Tue, Jun 10, 2014 at 1:54 PM, Steven Ryerse > wrote: > Wow! A whole /24 ? that?s pretty generous of you! What a large compromise that is . . . . > > 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: McTim [mailto:dogwallah at gmail.com] > Sent: Tuesday, June 10, 2014 2:29 PM > To: Steven Ryerse > Cc: Owen DeLong; Matthew Kaufman; arin-ppml at arin.net > > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > Hi Steven, > > On Wed, Jun 4, 2014 at 6:50 PM, Steven Ryerse > wrote: > There are several folks (like me) who want to ditch the needs test and there are several folks who don't want to ditch them. I >take it your position is that the folks who want to keep needs tests should somehow prevail in this argument without much or any >change, and those of us who wish to ditch them should just accept the status quo with needs tests. In other words you win and we >lose! > > I saw a lot of folks comment here recently who want to at least loosen needs tests on the smaller block sizes, many many more >than I've ever seen before. Since it is obvious a sizable portion of this community desires a change toward loosening policies, >why is it that you persist in standing in the way of compromise? > > As for me, I think relaxing (not eliminating needs assessment at a /24 boundary is plenty of compromise. > See Andrew Dul's most recent mail for possible scenario's. > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel > > > There comes a time when fair is fair - and small organizations are routinely discriminated against because of our small size and >not so deep pockets. There is a lot of anger out there over the unfairness of these existing policies. It should be just as >easy for us to get resources as it was for T-Mobile and others. I call on all members of this community to at least come to a >compromise. After all the world hasn't ended for RIPE with their changes - and it won't end here either if fairness is put back >into the policies so that small organizations can get the resources they need too! > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > www.eclipse-networks.com > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- >From: arin-ppml-bounces at arin.net >[mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong > Sent: Wednesday, June 04, 2014 7:25 PM > To: Matthew Kaufman > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > >> >> Matthew Kaufman >> >> ps. I'd also note that "policy that expresses the general intent of the community" may in fact *be* policy that lets post-runout >>transfers be performed without a needs test, as "the community" consists of a lot more than "Owen?. > > Indeed, it does. However, many people have also repeatedly stood up in defense of needs basis, so singling me out as if I am the >lone supporter of preserving needs basis is as specious as many of your other arguments. > > Owen > > _______________________________________________ > 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. > > > > > > > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From elvis at velea.eu Tue Jun 10 16:27:51 2014 From: elvis at velea.eu (Elvis Velea) Date: Tue, 10 Jun 2014 22:27:51 +0200 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate In-Reply-To: <53963F7E.1030007@quark.net> References: <53767336.4080001@arin.net> <53963F7E.1030007@quark.net> Message-ID: <53976A47.1090200@velea.eu> Hi Andrew, after an other read of the policy proposal, I now understand that removal of demonstrated need from policy would be a secondary effect. You were actually trying to reduce the load on the ARIN Registration Department's work and reduce approval time. I am wondering if ARIN RS staff could actually produce some statistics showing how work-loaded they are (these may already be available online, but I don't know how to get to them). Something in the lines of: - for the tree sizes discussed here: /24, /20 and /16 + total - number of requests per month - average time until initial response - average number of mails sent in the request by ARIN staff - average time needed for approval - number of requested sizes that were reduced and by how much We could then form an opinion on how much would this proposal impact on one side, the organisations that make the requests, and on the other side, ARIN staff. Off course, removing the DN from small requests may create more workload for ARIN as number of transfer requests will increase :) cheers, elvis On 10/06/14 01:13, Andrew Dul wrote: > Hello, > > Thank you to those of you who were able to participate at the PPC last > week at NANOG. Below are some thoughts based on the feedback I heard. > > I heard some support for this policy with the caveat that this policy > would allow some organizations to apply for address space sooner. Some > postulated that the downside to this policy would be short and likely > small for the remainder of the free pool, but it would also make it > easier to qualify for transfer space sooner on the transfer market. > > I heard that this policy shouldn't impact organizations which currently > use the MDN 4.5 policies and that the current MDN policy does not have > the same issue as it uses a 80% per site metric to meet utilization > requirements. > > The other issue which is related to this draft that I heard at the PPC > was that ARIN in the past year or so updated its operational practice to > more closely follow the current policy of " efficiently utilized all > previous allocations" (4.2.4.1) and this is also making harder for some > organizations to meet utilization guidelines at the time of request for > additional space. Do other organizations also believe the new > operational practice is an issue and the policy should be changed? > > As I stated at the PPC, so far I've seen a little support for this and > some opposition for this proposal, but at this point not enough to move > it forward to a recommended policy based on the current feedback. If > you support this policy, please post your support to the mailing-list > otherwise as the policy shepherd I will likely be recommending that the > AC abandon this draft at a future AC meeting. > > Thanks for your input, > Andrew > > On 5/16/2014 1:21 PM, ARIN wrote: >> ## * ## >> >> >> Draft Policy ARIN-2014-17 >> Change Utilization Requirements from last-allocation to total-aggregate >> >> Date: 16 May 2014 >> >> Problem Statement: >> >> Utilization requirements for new requests is being calculated on a per >> allocation basis rather than in aggregate. For example, if an >> organization has 4 x /22 and 3 of them are utilized 100% and the >> fourth utilized at 75%, that request would be denied. This is a bit >> out of balance as an organization with a single /20 utilized at 80% >> would have less efficient utilization but would be eligible to request >> additional space. >> >> Policy statement: >> >> Section 4.2.4.1- Change text to read: "ISPs must have efficiently >> utilized all previous allocations, in aggregate, to at least 80% in >> order to receive additional space. This includes all space reassigned >> to their customers. Please note that until your prior utilization is >> verified to meet the 80% requirement, ARIN can neither process nor >> approve a request for additional addresses." >> >> Section 4.3.6.1- Change text to read: "End-users must have efficiently >> utilized all previous assignments, in aggregate, to at least 80% in >> order to receive additional space, and must provide ARIN with >> utilization details. The prefix size for an additional assignment is >> determined by applying the policies found in Section 4.3 of the NRPM." >> >> Comments: >> >> a. Timetable for implementation: Immediate, possibly through board >> action. >> b. Per originator, This does not currently extend into MDN (aka >> 4.5.4), and I'm not really sure how to reconcile it against 4.5.5, but >> OP expressed some concern that there may be undue restrictions there. >> It might be better served by a separate proposal. >> c. There should probably also be an attempt to clean up the language >> between 4.2.4.1 and 4.3.6.1, as they're both currently very clunky. > _______________________________________________ > 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 elvis at velea.eu Tue Jun 10 16:39:42 2014 From: elvis at velea.eu (Elvis Velea) Date: Tue, 10 Jun 2014 22:39:42 +0200 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: Message-ID: <53976D0E.50509@velea.eu> On 10/06/14 22:15, lar at mwtcorp.net wrote: > On Tue, 10 Jun 2014 20:11:15 +0000 > Steven Ryerse wrote: >> Get used to it because even if this Community doesn?t relent and ease >> up on needs requirements, the marketplace will take up the slack >> outside of ARIN - and a 2nd (or more) defacto marketplace will be >> created. It is inevitable and short of a law being past you and I >> can?t stop it. As you probably know this is already happening with >> the IP brokers out there and I could easily see another RIR who is >> out of resources joining up with significant 3rd party brokers to >> fill IPv4 needs at market prices worldwide. There is another supply >> of IPv4 resources out there in the form of all those Legacy /8?s that >> were given out many years ago, and I suspect that demand will bring >> some of those resources to market. That supply could defer switching >> to IPv6 for years and not everyone likes IPv6. >> > > Then maybe the discussion we should be having is how to reclaim > un-needed IPV4 space. this discussion should have happened 10 years ago. Now, it's too late. Everyone knows that IP addresses are worth a buck or two.. The marketplace exists and at least 3 RIRs acknowledge it and their communities have built policies for it. Would you give them up if you would be having a (large) number of unused IPs; IPs that may bring your organization the money needed to invest in new equipment and skills and migrate to IPv6 :) cheers, elvis From SRyerse at eclipse-networks.com Tue Jun 10 16:41:43 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 10 Jun 2014 20:41:43 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AB042B0@ENI-MAIL.eclipse-networks.com> If an organization is blocked now by policy of getting the allocation they need, why would significantly increasing ARINs supply be any different than the status quo today. I have no knowledge about it at all but I would be surprised if ARIN or IANA hasn't had conversations with the large Legacy holders about the possibility of releasing some resources. There have been rumors for a couple of years of a whole /8 that is available but of course it is a rumor. Maybe ARIN already knows of significant available IPv4 resources and hasn't shared that info with the Community. As I said I have absolutely no knowledge of this but it only makes sense that conversations with the large Legacy holders have taken place to gauge availability. 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? -----Original Message----- From: lar at mwtcorp.net [mailto:lar at mwtcorp.net] Sent: Tuesday, June 10, 2014 4:15 PM To: Steven Ryerse; McTim Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Tue, 10 Jun 2014 20:11:15 +0000 Steven Ryerse wrote: > Get used to it because even if this Community doesn?t relent and ease >up on needs requirements, the marketplace will take up the slack >outside of ARIN - and a 2nd (or more) defacto marketplace will be >created. It is inevitable and short of a law being past you and I can?t stop it. As you probably know this is already happening with the IP brokers out there and I could easily see another RIR who is out of resources joining up with significant 3rd party brokers to fill IPv4 needs at market prices worldwide. > There is another supply of IPv4 resources out there in the form of all >those Legacy /8?s that were given out many years ago, and I suspect >that demand will bring some of those resources to market. That supply could defer switching to IPv6 for years and not everyone likes IPv6. > Then maybe the discussion we should be having is how to reclaim un-needed IPV4 space. > I just don?t understand why ARIN & Community would sit pat when their allocation will be gone in a year or two and life will >change around them. Seems prudent for ARIN & Community to join the fray instead of digging in against it. Loosening up needs >testing on just a /24 is so far from joining the fray it is hard for me to see why someone as knowledgeable as you doesn?t want >to see the forest from the trees. > > 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: McTim [mailto:dogwallah at gmail.com] > Sent: Tuesday, June 10, 2014 3:46 PM > To: Steven Ryerse > Cc: Owen DeLong; Matthew Kaufman; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > > On Tue, Jun 10, 2014 at 2:40 PM, Steven Ryerse > wrote: > If I understood your comment below, you are now agreeable to remove SOME of the needs tests on only a /24. I suppose that is a >change but not much of one at all and it will only help the smallest of the needs out there MAYBE if they can pass whatever your >relaxed needs test would be. Yes maybe that is a slight shift in your position but pretty negligible > > it's a huge paradigm shift for me. > > > and NOT IMHO what is really needed. > > it is not at all what is needed for your org, certainly. > > > > > If this was 10 or 15 years ago and I was in a position to block an allocation request of yours for say a /22 that you really >needed, I doubt you would be very happy if I told you that you could only have a /24 and then only if you could pass some >arbitrary test that I came up with. In the real world folks need real allocations and current policy stands in the way. > > > If it was 10-15 years ago and I NEEDED it, I could have shown that easily and gotten my /whatever. > > 10-15 years ago i was a RIR hostmaster. The bar is NOT very high to show need, it certainly wasn't then, and I don't think it >has gone up! > > > > > > > > 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: McTim [mailto:dogwallah at gmail.com] > Sent: Tuesday, June 10, 2014 3:30 PM > > To: Steven Ryerse > Cc: Owen DeLong; Matthew Kaufman; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > Is is indeed a significant shift in my position. > I think that is something you should recognise. > I'm all for giving small orgs the space they need, which seems to be what you want. However, ido not believe that this policyt >does that for you, or indeed for anyone in a way that is cheaper than getting the space from the RIR. > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel > On Tue, Jun 10, 2014 at 1:54 PM, Steven Ryerse > wrote: > Wow! A whole /24 ? that?s pretty generous of you! What a large compromise that is . . . . > > 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: McTim [mailto:dogwallah at gmail.com] > Sent: Tuesday, June 10, 2014 2:29 PM > To: Steven Ryerse > Cc: Owen DeLong; Matthew Kaufman; arin-ppml at arin.net > > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > Hi Steven, > > On Wed, Jun 4, 2014 at 6:50 PM, Steven Ryerse > wrote: > There are several folks (like me) who want to ditch the needs test and there are several folks who don't want to ditch them. I >take it your position is that the folks who want to keep needs tests should somehow prevail in this argument without much or any >change, and those of us who wish to ditch them should just accept the status quo with needs tests. In other words you win and we >lose! > > I saw a lot of folks comment here recently who want to at least loosen needs tests on the smaller block sizes, many many more >than I've ever seen before. Since it is obvious a sizable portion of this community desires a change toward loosening policies, >why is it that you persist in standing in the way of compromise? > > As for me, I think relaxing (not eliminating needs assessment at a /24 boundary is plenty of compromise. > See Andrew Dul's most recent mail for possible scenario's. > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel > > > There comes a time when fair is fair - and small organizations are routinely discriminated against because of our small size and >not so deep pockets. There is a lot of anger out there over the unfairness of these existing policies. It should be just as >easy for us to get resources as it was for T-Mobile and others. I call on all members of this community to at least come to a >compromise. After all the world hasn't ended for RIPE with their changes - and it won't end here either if fairness is put back >into the policies so that small organizations can get the resources they need too! > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > www.eclipse-networks.com > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- >From: arin-ppml-bounces at arin.net >[mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong > Sent: Wednesday, June 04, 2014 7:25 PM > To: Matthew Kaufman > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > >> >> Matthew Kaufman >> >> ps. I'd also note that "policy that expresses the general intent of the community" may in fact *be* policy that lets post-runout >>transfers be performed without a needs test, as "the community" consists of a lot more than "Owen?. > > Indeed, it does. However, many people have also repeatedly stood up in defense of needs basis, so singling me out as if I am the >lone supporter of preserving needs basis is as specious as many of your other arguments. > > Owen > > _______________________________________________ > 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. > > > > > > > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From SRyerse at eclipse-networks.com Tue Jun 10 16:47:51 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 10 Jun 2014 20:47:51 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <53976D0E.50509@velea.eu> References: <53976D0E.50509@velea.eu> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> Yes I agree it should have happened years ago and I agree that an outside marketplace already exists, but it isn't too late for ARIN to engage and embrace the new marketplace. I certainly do understand why those large Legacy holders would just watch and wait to see what happened in the marketplace once all of the RIRs run out of resources. It is in their interest to do so. 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? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Elvis Velea Sent: Tuesday, June 10, 2014 4:40 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On 10/06/14 22:15, lar at mwtcorp.net wrote: > On Tue, 10 Jun 2014 20:11:15 +0000 > Steven Ryerse wrote: >> Get used to it because even if this Community doesn?t relent and ease >> up on needs requirements, the marketplace will take up the slack >> outside of ARIN - and a 2nd (or more) defacto marketplace will be >> created. It is inevitable and short of a law being past you and I >> can?t stop it. As you probably know this is already happening with >> the IP brokers out there and I could easily see another RIR who is >> out of resources joining up with significant 3rd party brokers to >> fill IPv4 needs at market prices worldwide. There is another supply >> of IPv4 resources out there in the form of all those Legacy /8?s that >> were given out many years ago, and I suspect that demand will bring >> some of those resources to market. That supply could defer switching >> to IPv6 for years and not everyone likes IPv6. >> > > Then maybe the discussion we should be having is how to reclaim > un-needed IPV4 space. this discussion should have happened 10 years ago. Now, it's too late. Everyone knows that IP addresses are worth a buck or two.. The marketplace exists and at least 3 RIRs acknowledge it and their communities have built policies for it. Would you give them up if you would be having a (large) number of unused IPs; IPs that may bring your organization the money needed to invest in new equipment and skills and migrate to IPv6 :) cheers, elvis _______________________________________________ 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 dogwallah at gmail.com Tue Jun 10 17:24:23 2014 From: dogwallah at gmail.com (McTim) Date: Tue, 10 Jun 2014 16:24:23 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> References: <53976D0E.50509@velea.eu> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> Message-ID: On Tue, Jun 10, 2014 at 3:47 PM, Steven Ryerse wrote: > Yes I agree it should have happened years ago and I agree that an outside > marketplace already exists, but it isn't too late for ARIN to engage and > embrace the new marketplace. They have embraced it, fully: https://arin.net/resources/request/transfers_8_3.html > I certainly do understand why those large Legacy holders would just watch > and wait to see what happened in the marketplace once all of the RIRs run > out of resources. It is in their interest to do so. > but there have been cases of good net-citizenship where entities have returned large blocks (even entire /8's) in recent years. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel > > 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? > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Elvis Velea > Sent: Tuesday, June 10, 2014 4:40 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > On 10/06/14 22:15, lar at mwtcorp.net wrote: > > On Tue, 10 Jun 2014 20:11:15 +0000 > > Steven Ryerse wrote: > >> Get used to it because even if this Community doesn?t relent and ease > >> up on needs requirements, the marketplace will take up the slack > >> outside of ARIN - and a 2nd (or more) defacto marketplace will be > >> created. It is inevitable and short of a law being past you and I > >> can?t stop it. As you probably know this is already happening with > >> the IP brokers out there and I could easily see another RIR who is > >> out of resources joining up with significant 3rd party brokers to > >> fill IPv4 needs at market prices worldwide. There is another supply > >> of IPv4 resources out there in the form of all those Legacy /8?s that > >> were given out many years ago, and I suspect that demand will bring > >> some of those resources to market. That supply could defer switching > >> to IPv6 for years and not everyone likes IPv6. > >> > > > > Then maybe the discussion we should be having is how to reclaim > > un-needed IPV4 space. > > this discussion should have happened 10 years ago. Now, it's too late. > > Everyone knows that IP addresses are worth a buck or two.. The marketplace > exists and at least 3 RIRs acknowledge it and their communities have built > policies for it. Would you give them up if you would be having a (large) > number of unused IPs; IPs that may bring your organization the money needed > to invest in new equipment and skills and migrate to IPv6 :) > > cheers, > elvis > > _______________________________________________ > 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 SRyerse at eclipse-networks.com Tue Jun 10 17:43:21 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 10 Jun 2014 21:43:21 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <53976D0E.50509@velea.eu> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> Yes some blocks have been returned and that is a good thing. My question for your first point then is why are so many transfers (in this region) of resources happening outside of ARIN and the ?Transfers to Specified Recipients? policy (or other applicable ARIN policies)? After all I think we would get a near unanimous consensus that when the database doesn?t get updated after a transfer it is a negative thing? So it is not desirable for transfers to take place outside of ARIN but it keeps happening anyway. Why? 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: McTim [mailto:dogwallah at gmail.com] Sent: Tuesday, June 10, 2014 5:24 PM To: Steven Ryerse Cc: elvis at velea.eu; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Tue, Jun 10, 2014 at 3:47 PM, Steven Ryerse > wrote: Yes I agree it should have happened years ago and I agree that an outside marketplace already exists, but it isn't too late for ARIN to engage and embrace the new marketplace. They have embraced it, fully: https://arin.net/resources/request/transfers_8_3.html I certainly do understand why those large Legacy holders would just watch and wait to see what happened in the marketplace once all of the RIRs run out of resources. It is in their interest to do so. but there have been cases of good net-citizenship where entities have returned large blocks (even entire /8's) in recent years. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel 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? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Elvis Velea Sent: Tuesday, June 10, 2014 4:40 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On 10/06/14 22:15, lar at mwtcorp.net wrote: > On Tue, 10 Jun 2014 20:11:15 +0000 > Steven Ryerse > wrote: >> Get used to it because even if this Community doesn?t relent and ease >> up on needs requirements, the marketplace will take up the slack >> outside of ARIN - and a 2nd (or more) defacto marketplace will be >> created. It is inevitable and short of a law being past you and I >> can?t stop it. As you probably know this is already happening with >> the IP brokers out there and I could easily see another RIR who is >> out of resources joining up with significant 3rd party brokers to >> fill IPv4 needs at market prices worldwide. There is another supply >> of IPv4 resources out there in the form of all those Legacy /8?s that >> were given out many years ago, and I suspect that demand will bring >> some of those resources to market. That supply could defer switching >> to IPv6 for years and not everyone likes IPv6. >> > > Then maybe the discussion we should be having is how to reclaim > un-needed IPV4 space. this discussion should have happened 10 years ago. Now, it's too late. Everyone knows that IP addresses are worth a buck or two.. The marketplace exists and at least 3 RIRs acknowledge it and their communities have built policies for it. Would you give them up if you would be having a (large) number of unused IPs; IPs that may bring your organization the money needed to invest in new equipment and skills and migrate to IPv6 :) cheers, elvis _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From cja at daydream.com Tue Jun 10 17:47:51 2014 From: cja at daydream.com (CJ Aronson) Date: Tue, 10 Jun 2014 15:47:51 -0600 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <53976D0E.50509@velea.eu> References: <53976D0E.50509@velea.eu> Message-ID: Elvis.. ARIN has had 8.3 transfers since 2009. We long ago accepted that there would be a market for IP addresses. I believe ARIN was the first RIR to have such a policy. The link to the archive is here https://www.arin.net/policy/proposals/2009_1.html Soon after we worked on the listing service as well. This policy has been used and I am sure the ARIN staff has numbers of how many such transfers have taken place. Just because this region has historically been in favor of justified need doesn't mean that folks haven't accepted that there would be a market. Thanks! ----Cathy On Tue, Jun 10, 2014 at 2:39 PM, Elvis Velea wrote: > > On 10/06/14 22:15, lar at mwtcorp.net wrote: > >> On Tue, 10 Jun 2014 20:11:15 +0000 >> Steven Ryerse wrote: >> >>> Get used to it because even if this Community doesn?t relent and ease up >>> on needs requirements, the marketplace will take up the slack outside of >>> ARIN - and a 2nd (or more) defacto marketplace will be created. It is >>> inevitable and short of a law being past you and I can?t stop it. As you >>> probably know this is already happening with the IP brokers out there and I >>> could easily see another RIR who is out of resources joining up with >>> significant 3rd party brokers to fill IPv4 needs at market prices >>> worldwide. There is another supply of IPv4 resources out there in the form >>> of all those Legacy /8?s that were given out many years ago, and I suspect >>> that demand will bring some of those resources to market. That supply >>> could defer switching to IPv6 for years and not everyone likes IPv6. >>> >>> >> Then maybe the discussion we should be having is how to reclaim un-needed >> IPV4 space. >> > > this discussion should have happened 10 years ago. Now, it's too late. > > Everyone knows that IP addresses are worth a buck or two.. The marketplace > exists and at least 3 RIRs acknowledge it and their communities have built > policies for it. Would you give them up if you would be having a (large) > number of unused IPs; IPs that may bring your organization the money needed > to invest in new equipment and skills and migrate to IPv6 :) > > cheers, > elvis > > _______________________________________________ > 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 Timothy.S.Morizot at irs.gov Tue Jun 10 17:54:57 2014 From: Timothy.S.Morizot at irs.gov (Morizot Timothy S) Date: Tue, 10 Jun 2014 21:54:57 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <53976D0E.50509@velea.eu> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> Message-ID: <968C470DAC25FB419E0159952F28F0C06A7D02A0@MEM0200CP3XF04.ds.irsnet.gov> From McTim: > ?I certainly do understand why those large Legacy holders would just watch and > wait to see what happened in the marketplace once all of the RIRs run out of > resources. It is in their interest to do so. > but there have been cases of good net-citizenship where entities have > returned large blocks (even entire /8's) in recent years. Indeed. However, just from knowing the sorts of organizations that received many of the larger legacy allocations, I would wager that those who have not already taken some sort of similar action are probably not interested in either returning or selling those allocations. There are a number of smaller legacy allocations that will likely find their way onto the market. And there are a number where the registered recipient may be defunct. Our /13, /15, and /24 don't really qualify as the sort of "large" legacy allocation under discussion, but I know we have no interest in selling them. And we also have no interest in returning them during any timeframe in which there would still be a demand for new IPv4 on the Internet. Out of the legacy holders, only commercial entities are likely to be significantly swayed by market demand for IPv4. And out of the commercial holders of large allocations of legacy space, most of those remain large companies. They are unlikely to treat their legacy holdings any different than their non-legacy IPv4 holdings. I've seen, for example, Lee Howard's analyses. Legacy or not, commercial entities are most likely to sell IPv4 only if and when they bring more on the market than technologies like CGN cost. There may be movement in parts of the smaller legacy allocations when there's a financial incentive to do so, but I don't anticipate some large-scale stampede to the v4 market. Anyway, given that IPv4 will be a tightly constrained resource during the initial phase of exhaustion where inequalities of scale definitely come into play (large players are better positioned to buy more than they need in an effort to disadvantage smaller players) I'm not at all convinced that "market magic" will naturally ensue if needs basis is eliminated for transfers. I remain unconvinced by the arguments presented. And if limiting markets by continuing to require a needs basis leads some organizations to do things that end making IPv4 even less attractive moving forward, I'm not convinced that's a negative side effect. I don't believe there's any stopping the Internet's switch to IPv6 at this point. I was concerned for quite a while, but the major deployments by access networks this year and the major upward trend in IPv6 traffic (in the US) have done a great deal to alleviate those concerns. By this time next year, I expect we'll be having very different discussions. Scott From elvis at velea.eu Tue Jun 10 18:03:29 2014 From: elvis at velea.eu (Elvis Velea) Date: Wed, 11 Jun 2014 00:03:29 +0200 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <53976D0E.50509@velea.eu> Message-ID: <539780B1.70604@velea.eu> Hey Cathy, I know that ARIN was the first RIR to have transfers allowed by policy. I also know there have been a few organizations that have returned addresses. Even a /8 was returned not long time ago (I think just a /16 was still used by the organization). I was just answering to the question on whether ARIN (or any other RIR) should do more to reclaim unused addresses back. My opinion is that time has passed. I think that now, once everyone knows there's a possible profit to be made out of the IPs and since the policies allow transfer of unused space, it will be very difficult to reclaim address space (and I'm not even talking about legacy space, I'm talking about space that was allocated by ARIN). The RIRs have always said that even if they reclaim the unused space, it will only increase their free pool with such amounts that it will take with just a few weeks (maybe months) longer to reach exhaustion. cheers, elvis On 10/06/14 23:47, CJ Aronson wrote: > Elvis.. > > ARIN has had 8.3 transfers since 2009. We long ago accepted that > there would be a market for IP addresses. I believe ARIN was the > first RIR to have such a policy. The link to the archive is here > https://www.arin.net/policy/proposals/2009_1.html > > Soon after we worked on the listing service as well. This policy has > been used and I am sure the ARIN staff has numbers of how many such > transfers have taken place. > > Just because this region has historically been in favor of justified > need doesn't mean that folks haven't accepted that there would be a > market. > > Thanks! > ----Cathy > > > On Tue, Jun 10, 2014 at 2:39 PM, Elvis Velea > wrote: > > > On 10/06/14 22:15, lar at mwtcorp.net wrote: > > On Tue, 10 Jun 2014 20:11:15 +0000 > Steven Ryerse > wrote: > > Get used to it because even if this Community doesn?t > relent and ease up on needs requirements, the marketplace > will take up the slack outside of ARIN - and a 2nd (or > more) defacto marketplace will be created. It is > inevitable and short of a law being past you and I can?t > stop it. As you probably know this is already happening > with the IP brokers out there and I could easily see > another RIR who is out of resources joining up with > significant 3rd party brokers to fill IPv4 needs at market > prices worldwide. There is another supply of IPv4 > resources out there in the form of all those Legacy /8?s > that were given out many years ago, and I suspect that > demand will bring some of those resources to market. That > supply could defer switching to IPv6 for years and not > everyone likes IPv6. > > > Then maybe the discussion we should be having is how to > reclaim un-needed IPV4 space. > > > this discussion should have happened 10 years ago. Now, it's too late. > > Everyone knows that IP addresses are worth a buck or two.. The > marketplace exists and at least 3 RIRs acknowledge it and their > communities have built policies for it. Would you give them up if > you would be having a (large) number of unused IPs; IPs that may > bring your organization the money needed to invest in new > equipment and skills and migrate to IPv6 :) > > cheers, > elvis > > _______________________________________________ > 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 bross at pobox.com Tue Jun 10 19:39:10 2014 From: bross at pobox.com (Brandon Ross) Date: Tue, 10 Jun 2014 19:39:10 -0400 (EDT) Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> Message-ID: On Mon, 9 Jun 2014, Owen DeLong wrote: > Your third item is absurd. If they don't find sellers with that much > space, then it means the market isn't as large as described and the > problem is even worse and market capture is even easier. Without a needs > test or the other restrictions in 8.3, it would not take years, it would > take days. Address space would be swept away as fast as it came > available on the market. It would be IP lotto for the uber-wealthy > corporations. If these bad actors are willing to spend such amounts of money to capture the market, why wouldn't they do this with the needs test in place simply by locking up all the space under contracts instead? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From matthew at matthew.at Tue Jun 10 20:07:50 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 10 Jun 2014 17:07:50 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> Message-ID: <485F99DF-5E1E-4298-8894-0E582B9B9732@matthew.at> Maybe they have? Matthew Kaufman (Sent from my iPhone) > On Jun 10, 2014, at 4:39 PM, Brandon Ross wrote: > >> On Mon, 9 Jun 2014, Owen DeLong wrote: >> >> Your third item is absurd. If they don't find sellers with that much space, then it means the market isn't as large as described and the problem is even worse and market capture is even easier. Without a needs test or the other restrictions in 8.3, it would not take years, it would take days. Address space would be swept away as fast as it came available on the market. It would be IP lotto for the uber-wealthy corporations. > > If these bad actors are willing to spend such amounts of money to capture the market, why wouldn't they do this with the needs test in place simply by locking up all the space under contracts instead? > > -- > Brandon Ross Yahoo & AIM: BrandonNRoss > +1-404-635-6667 ICQ: 2269442 > Skype: brandonross > Schedule a meeting: http://www.doodle.com/bross > _______________________________________________ > 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 Wed Jun 11 01:26:44 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 10 Jun 2014 22:26:44 -0700 Subject: [arin-ppml] Draft Policy 2014-14, WAS Re: About needs basis in 8.3 transfers In-Reply-To: References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> <538F3B35.8090806@matthew.at> <973FD910-966B-42E1-83B9-DA485445D04E@delong.com> <20140604235227.GA93629@gweep.net> <2902945421bd4f46a16a61c7eb313deb@DM2PR03MB398.namprd03.prod.outlook.com> <538FDB05.3070700@tiggee.com> <538FDC86.9070600@velea.eu> <538FE5E1.3010105@tiggee.com> <85CC4AE0-887C-4B32-8F79-26A8F4BB1E31@pch.net> <6f42191b790d4bafb33e73d463ad0548@EX13-MBX-13.ad.syr.edu> <53963B4D.5050808@quark.net> Message-ID: The majority of my comments were intended towards the general question posed (8.3 transfers and needs basis). My comments which should be considered in the context of 2014-14 should be strictly limited to those where I expressed an opinion on 2014-14. Namely: 1. I oppose 2014-14 as written. 2. I consider that a /16 and a permanent policy are both too much of a floodgate and too much uncharted and dangerous territory. 3. As a compromise, I proposed a 12 month policy experiment (add a clause which would terminate 2014-14 12 months after it becomes active) with a /20 maximum prefix limit which could be used to gather additional data for the community to consider whether or not such policy improves registry accuracy while not allowing large enough blocks to drive any serious harm to the stewardship of the address space. Below are some of my reasons for holding this position, but they should not be taken as direct commentary on 2014-14, but rather more general comment on the need to continue Needs Basis as currently practiced even beyond free-pool runout. It is unfortunate that economists use language differently from the rest of us and that the plain english reading of words from an economist often results in a completely skewed view of what they have said. For example, the term efficiency, when used by an economist should mean "every resource is optimally allocated to serve each person in the best way while minimizing waste and inefficiency". Unfortunately, in the current context, the meaning seems to be defined more along the lines of "every resource is migrated to those best able to pay the most money for it." Needs, as most people would define them are completely ignored, and instead, the combination of ability and desire to pay are the only criteria which are applied as an evaluation of "the best way possible". To an economist, the goal of fairness seems to be an absurd concept and, as my esteemed colleague Mr. Mueller has stated should be replaced with "efficiency is the key concern". Unfortunately, for his argument, ARIN's mission statement and the policy development process refer to a requirement that policies be fair, but do not say anything about efficiency other than this sentence under PDP section 4.2 (Technically Sound): > Support both conservation and efficient utilization of Internet number resources to the extent feasible. Policy should maximize number resource availability to parties with operational need. > Contrast this sub-bullet of "Technically sound" with the title of the previous paragraph: > 4.1. Enabling Fair and Impartial Number Resource Administration > > Internet number resources must be managed with appropriate stewardship and care. Internet number resource policy must provide for fair and impartial management of resources according to unambiguous guidelines and criteria. All policy statements must be clear, complete, and concise, and any criteria that are defined in policy must be simple and obtainable. Policy statements must be unambiguous and not subject to varying degrees of interpretation. And it becomes quite clear that "Fairness" is, in fact, much more of a key concern in policy development than efficiency as an economist would seem to define it. Of course, it is hard to blame them. "Allocation by sheer greed" is such an ugly term while "Allocation Efficiency" sounds so much more positive. Obviously, if one can get away with it, redefining "Allocation Efficiency" to mean the same thing, then it becomes much easier to sell the idea. However, direct redefinition would be too obvious and people might see through the sales pitch, so instead, more slight of hand is required. First, we change the way we define words like "best way" and "minimizing waste" and "inefficiency". If we can redefine those terms in strictly monetary units so that "best way" means the way that provides the lowest price possible in the immediate circumstance and further define "minimizing waste" as reducing the ancillary transaction costs and other economic contributors to the cost of goods sold and finally redefine "inefficiency" as transaction costs not borne from the underlying cost of the resource being purchased, then suddenly the phrase "allocated to serve each person in the best way while minimizing waste and inefficiency" no longer has any regard for any aspects of those words beyond those which can be mapped into dollars and cents, thus eliminating many of what I believe to be the more important meanings of those terms. Owen On Jun 9, 2014, at 20:28 , John Springer wrote: > OP of "[arin-ppml] About needs basis in 8.3 transfers", I hope this has been useful to you. And the speech in Bellevue. As shepherd of 2014-14, I am less sure of what I may make of it. > > It is a lovely philosophical discussion. Clearly an excellent opportunity for adherents of two diametrically opposed camps to ascend the lofty pulpit and orate, without the messy necessity of voicing support or opposition to the Draft Policy that theoretically all of this refers to, this being a list for the discussion of public policy. > > Comments to each of my esteemed collegues below. > > On Mon, 9 Jun 2014, Andrew Dul wrote: > >> On 6/6/2014 8:06 AM, Milton L Mueller wrote: >>> All we are debating is the presence or absence of needs assessment as a gatekeeping function for that market. > > Not precisely. For unless you are just commenting generally about an unconnected bunch of opinionating, you are commenting about 2014-14, which, while it is about "the presence or absence of needs assessment" may not be relegated to a simplistic gatekeeping function by your merely stating that it is so. 2014-14 seeks to address a specific issue (transfer request processing time) that happens to fall within a much larger context (access to number resource rights). Using one to draw conclusions about the other runs immediately afoul of the several ergo propter hocs. Unless you are not referring to 2014-14, in which case carry on, my bad. > >>> This is a fairly administrative and technical argument, not a moral one. > > Not really. For instance, what argument is that? And I sure thought I read some moralizing in this long thread which is not invalidated by the previous statement. > >>> Efficiency is the key criterion (not fairness, really). > > 2014-14 or not, you decide. > >>> If you support needs assessments you have to make a case that the costs and burdens associated with it are justified by quantifiable benefits. > > In what context? 2014-14? If so, you're getting way too fancy. IMO, that is what the proposal author is trying to do, (make the case, not get fancy). To express support for the DP, (if that's what you are trying to do), all the double negatives here are kinda confusing. If you are speaking to an opponent of the DP, they do not in fact have to make the case as you describe. I sort of have to make the opposite case. > >>> In this case, inefficiency is unfairness: if the needs assessment process prevents resources from going where they are wanted most, or if the cost burdens associated with the process exceed the value of the numbers acquired for small operators, or if it is shown that large, established companies with well-established relationships to ARIN can navigate the process more easily, then there are signs that needs assessment is unfair because of its inefficiencies. > > You said above efficiency and fairness were not really the key criterion, here you say they are the same (or rather that their opposites are, which implies...). Which do you mean? > >>> You have to do a better job of explaining why it is "fair" to force a willing seller and a willing buyer to submit to an additional step when that step both limits the quantity of resources available for transfer and raises the cost of participating in the market by a substantial degree. > > Again, if you are trying to help rebut opponents of 2014-14, this is not their job. The failure to prove the converse leads to status quo. Whomever you might be addressing with this comment apparently needs no encouragement to continue to make this exact case at some length. I would find more useful, comments why this is _NOT_ fair. Call me kooky. > >> Milton, >> >> Thank you for this two paragraph summary of what we are debating here. > > So, Andrew. As one shepherd of 2014-14 to another, what are we to do with "Re: [arin-ppml] About needs basis in 8.3 transfers" WRT 2014-14? Are arguments there able to be applied wholesale to 2014-14, mapping (divining?) pro-needs basis logic as anti-2014-14 and vice verse? If not, is it all to be discounted by saying that the authors did not explicitly express either support or opposition and therefore we are not permitted to read anything into their statements? > > All list posters who posted to "About needs basis in 8.3 transfers", is it OK to read your minds about this or do you want to come back and state what you mean clearly in a context that is unambiguous? > >> Are there, in your opinion, any reasonable "steps" (e.g. policy >> elements) that the registry community should implement as policy between >> a buyer and a seller that are not the "existing traditional needs >> assessment" which would provide a benefit to the IPv4 market and >> Internet community as a whole? > > Excellent question, such commentary would be valuable and welcome, and if so, what? > > John Springer > >> Andrew >> >> _______________________________________________ >> 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 owen at delong.com Wed Jun 11 02:32:18 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 10 Jun 2014 23:32:18 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate In-Reply-To: <53976A47.1090200@velea.eu> References: <53767336.4080001@arin.net> <53963F7E.1030007@quark.net> <53976A47.1090200@velea.eu> Message-ID: <8276EF18-9485-4389-B425-CDF5EA4DA5CD@delong.com> I believe this comment is about 2014-14 (Removing Needs Test from Small IPv4 Transfers) rather than 2014-17. Can you please confirm that and, if so, repost it in the appropriate thread? The comments below seem unrelated to 2014-17 (Change Utilization Requirements from last-allocation to total-aggreagate). Owne On Jun 10, 2014, at 13:27 , Elvis Velea wrote: > Hi Andrew, > > after an other read of the policy proposal, I now understand that removal of demonstrated need from policy would be a secondary effect. You were actually trying to reduce the load on the ARIN Registration Department's work and reduce approval time. > > I am wondering if ARIN RS staff could actually produce some statistics showing how work-loaded they are (these may already be available online, but I don't know how to get to them). > > Something in the lines of: > - for the tree sizes discussed here: /24, /20 and /16 + total > - number of requests per month > - average time until initial response > - average number of mails sent in the request by ARIN staff > - average time needed for approval > - number of requested sizes that were reduced and by how much > > We could then form an opinion on how much would this proposal impact on one side, the organisations that make the requests, and on the other side, ARIN staff. > Off course, removing the DN from small requests may create more workload for ARIN as number of transfer requests will increase :) > > cheers, > elvis > > > On 10/06/14 01:13, Andrew Dul wrote: >> Hello, >> >> Thank you to those of you who were able to participate at the PPC last >> week at NANOG. Below are some thoughts based on the feedback I heard. >> >> I heard some support for this policy with the caveat that this policy >> would allow some organizations to apply for address space sooner. Some >> postulated that the downside to this policy would be short and likely >> small for the remainder of the free pool, but it would also make it >> easier to qualify for transfer space sooner on the transfer market. >> >> I heard that this policy shouldn't impact organizations which currently >> use the MDN 4.5 policies and that the current MDN policy does not have >> the same issue as it uses a 80% per site metric to meet utilization >> requirements. >> >> The other issue which is related to this draft that I heard at the PPC >> was that ARIN in the past year or so updated its operational practice to >> more closely follow the current policy of " efficiently utilized all >> previous allocations" (4.2.4.1) and this is also making harder for some >> organizations to meet utilization guidelines at the time of request for >> additional space. Do other organizations also believe the new >> operational practice is an issue and the policy should be changed? >> >> As I stated at the PPC, so far I've seen a little support for this and >> some opposition for this proposal, but at this point not enough to move >> it forward to a recommended policy based on the current feedback. If >> you support this policy, please post your support to the mailing-list >> otherwise as the policy shepherd I will likely be recommending that the >> AC abandon this draft at a future AC meeting. >> >> Thanks for your input, >> Andrew >> >> On 5/16/2014 1:21 PM, ARIN wrote: >>> ## * ## >>> >>> >>> Draft Policy ARIN-2014-17 >>> Change Utilization Requirements from last-allocation to total-aggregate >>> >>> Date: 16 May 2014 >>> >>> Problem Statement: >>> >>> Utilization requirements for new requests is being calculated on a per >>> allocation basis rather than in aggregate. For example, if an >>> organization has 4 x /22 and 3 of them are utilized 100% and the >>> fourth utilized at 75%, that request would be denied. This is a bit >>> out of balance as an organization with a single /20 utilized at 80% >>> would have less efficient utilization but would be eligible to request >>> additional space. >>> >>> Policy statement: >>> >>> Section 4.2.4.1- Change text to read: "ISPs must have efficiently >>> utilized all previous allocations, in aggregate, to at least 80% in >>> order to receive additional space. This includes all space reassigned >>> to their customers. Please note that until your prior utilization is >>> verified to meet the 80% requirement, ARIN can neither process nor >>> approve a request for additional addresses." >>> >>> Section 4.3.6.1- Change text to read: "End-users must have efficiently >>> utilized all previous assignments, in aggregate, to at least 80% in >>> order to receive additional space, and must provide ARIN with >>> utilization details. The prefix size for an additional assignment is >>> determined by applying the policies found in Section 4.3 of the NRPM." >>> >>> Comments: >>> >>> a. Timetable for implementation: Immediate, possibly through board >>> action. >>> b. Per originator, This does not currently extend into MDN (aka >>> 4.5.4), and I'm not really sure how to reconcile it against 4.5.5, but >>> OP expressed some concern that there may be undue restrictions there. >>> It might be better served by a separate proposal. >>> c. There should probably also be an attempt to clean up the language >>> between 4.2.4.1 and 4.3.6.1, as they're both currently very clunky. >> _______________________________________________ >> 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 Wed Jun 11 03:07:11 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 11 Jun 2014 00:07:11 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <53976D0E.50509@velea.eu> References: <53976D0E.50509@velea.eu> Message-ID: <1574F0C2-F27E-44E7-8247-C524D8C89CD0@delong.com> On Jun 10, 2014, at 13:39 , Elvis Velea wrote: > > On 10/06/14 22:15, lar at mwtcorp.net wrote: >> On Tue, 10 Jun 2014 20:11:15 +0000 >> Steven Ryerse wrote: >>> Get used to it because even if this Community doesn?t relent and ease up on needs requirements, the marketplace will take up the slack outside of ARIN - and a 2nd (or more) defacto marketplace will be created. It is inevitable and short of a law being past you and I can?t stop it. As you probably know this is already happening with the IP brokers out there and I could easily see another RIR who is out of resources joining up with significant 3rd party brokers to fill IPv4 needs at market prices worldwide. There is another supply of IPv4 resources out there in the form of all those Legacy /8?s that were given out many years ago, and I suspect that demand will bring some of those resources to market. That supply could defer switching to IPv6 for years and not everyone likes IPv6. >>> >> >> Then maybe the discussion we should be having is how to reclaim un-needed IPV4 space. > > this discussion should have happened 10 years ago. Now, it's too late. This discussion happened 20 years ago and it was too late then. The determination at the time was the same as it is now... The real solution is to deploy IPv6. Reclaiming IPv4 addresses would result in only a few (perhaps several) months worth of address supply and would tie up vast amounts of human and capital resources that should be much better spent on IPv6 rollout. > Everyone knows that IP addresses are worth a buck or two.. The marketplace exists and at least 3 RIRs acknowledge it and their communities have built policies for it. Would you give them up if you would be having a (large) number of unused IPs; IPs that may bring your organization the money needed to invest in new equipment and skills and migrate to IPv6 :) The market was accepted as a low-cost alternative to reclamation. Essentially, it is a stop-gap for those most determined to avoid a true solution. Owen From owen at delong.com Wed Jun 11 03:12:51 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 11 Jun 2014 00:12:51 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> Message-ID: <469A588F-3A36-4FDB-8A81-59ECD4F4F722@delong.com> On Jun 10, 2014, at 16:39 , Brandon Ross wrote: > On Mon, 9 Jun 2014, Owen DeLong wrote: > >> Your third item is absurd. If they don't find sellers with that much space, then it means the market isn't as large as described and the problem is even worse and market capture is even easier. Without a needs test or the other restrictions in 8.3, it would not take years, it would take days. Address space would be swept away as fast as it came available on the market. It would be IP lotto for the uber-wealthy corporations. > > If these bad actors are willing to spend such amounts of money to capture the market, why wouldn't they do this with the needs test in place simply by locking up all the space under contracts instead? I can't guarantee that they won't. However, if it gets discovered that they have, the collusion required to do so might have interesting implications under the Sherman act. I might be wrong, but I think it would be much harder to make a Sherman Act case if community policy permitted the unrestricted outright sale and transfer. Owen From owen at delong.com Wed Jun 11 03:09:00 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 11 Jun 2014 00:09:00 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> References: <53976D0E.50509@velea.eu> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> Message-ID: Please put a number on "so many" and provide documentation to support that number. Owen On Jun 10, 2014, at 14:43 , Steven Ryerse wrote: > Yes some blocks have been returned and that is a good thing. My question for your first point then is why are so many transfers (in this region) of resources happening outside of ARIN and the ?Transfers to Specified Recipients? policy (or other applicable ARIN policies)? After all I think we would get a near unanimous consensus that when the database doesn?t get updated after a transfer it is a negative thing? So it is not desirable for transfers to take place outside of ARIN but it keeps happening anyway. Why? > > 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: McTim [mailto:dogwallah at gmail.com] > Sent: Tuesday, June 10, 2014 5:24 PM > To: Steven Ryerse > Cc: elvis at velea.eu; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > > > On Tue, Jun 10, 2014 at 3:47 PM, Steven Ryerse wrote: > Yes I agree it should have happened years ago and I agree that an outside marketplace already exists, but it isn't too late for ARIN to engage and embrace the new marketplace. > > > They have embraced it, fully: > > https://arin.net/resources/request/transfers_8_3.html > > > > > I certainly do understand why those large Legacy holders would just watch and wait to see what happened in the marketplace once all of the RIRs run out of resources. It is in their interest to do so. > > > but there have been cases of good net-citizenship where entities have returned large blocks (even entire /8's) in recent years. > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel > > > > 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? > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Elvis Velea > Sent: Tuesday, June 10, 2014 4:40 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > On 10/06/14 22:15, lar at mwtcorp.net wrote: > > On Tue, 10 Jun 2014 20:11:15 +0000 > > Steven Ryerse wrote: > >> Get used to it because even if this Community doesn?t relent and ease > >> up on needs requirements, the marketplace will take up the slack > >> outside of ARIN - and a 2nd (or more) defacto marketplace will be > >> created. It is inevitable and short of a law being past you and I > >> can?t stop it. As you probably know this is already happening with > >> the IP brokers out there and I could easily see another RIR who is > >> out of resources joining up with significant 3rd party brokers to > >> fill IPv4 needs at market prices worldwide. There is another supply > >> of IPv4 resources out there in the form of all those Legacy /8?s that > >> were given out many years ago, and I suspect that demand will bring > >> some of those resources to market. That supply could defer switching > >> to IPv6 for years and not everyone likes IPv6. > >> > > > > Then maybe the discussion we should be having is how to reclaim > > un-needed IPV4 space. > > this discussion should have happened 10 years ago. Now, it's too late. > > Everyone knows that IP addresses are worth a buck or two.. The marketplace exists and at least 3 RIRs acknowledge it and their communities have built policies for it. Would you give them up if you would be having a (large) number of unused IPs; IPs that may bring your organization the money needed to invest in new equipment and skills and migrate to IPv6 :) > > cheers, > elvis > > _______________________________________________ > 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 dogwallah at gmail.com Wed Jun 11 07:08:45 2014 From: dogwallah at gmail.com (McTim) Date: Wed, 11 Jun 2014 06:08:45 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <53976D0E.50509@velea.eu> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> Message-ID: On Wed, Jun 11, 2014 at 2:09 AM, Owen DeLong wrote: > Please put a number on "so many" and provide documentation to support that > number. My reaction as well. While we are at it, if we want to get a sense of how much of the total "Registry inaccuracy" is due to undocumented (grey or black market) transfers, those numbers would be extraordinarily useful in seeing the problem statement clearly. No clue how to gauge these numbers however! -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel > > Owen > > On Jun 10, 2014, at 14:43 , Steven Ryerse > wrote: > > Yes some blocks have been returned and that is a good thing. My question > for your first point then is why are so many transfers (in this region) of > resources happening outside of ARIN and the ?Transfers to Specified > Recipients? policy (or other applicable ARIN policies)? After all I think > we would get a near unanimous consensus that when the database doesn?t get > updated after a transfer it is a negative thing? So it is not desirable for > transfers to take place outside of ARIN but it keeps happening anyway. Why? > > 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: McTim [mailto:dogwallah at gmail.com] > Sent: Tuesday, June 10, 2014 5:24 PM > To: Steven Ryerse > Cc: elvis at velea.eu; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > > > > On Tue, Jun 10, 2014 at 3:47 PM, Steven Ryerse > wrote: > Yes I agree it should have happened years ago and I agree that an outside > marketplace already exists, but it isn't too late for ARIN to engage and > embrace the new marketplace. > > > > They have embraced it, fully: > > https://arin.net/resources/request/transfers_8_3.html > > > > > I certainly do understand why those large Legacy holders would just watch > and wait to see what happened in the marketplace once all of the RIRs run > out of resources. It is in their interest to do so. > > > > but there have been cases of good net-citizenship where entities have > returned large blocks (even entire /8's) in recent years. > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A route > indicates how we get there." Jon Postel > > > > > 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? > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Elvis Velea > Sent: Tuesday, June 10, 2014 4:40 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > On 10/06/14 22:15, lar at mwtcorp.net wrote: >> On Tue, 10 Jun 2014 20:11:15 +0000 >> Steven Ryerse wrote: >>> Get used to it because even if this Community doesn?t relent and ease >>> up on needs requirements, the marketplace will take up the slack >>> outside of ARIN - and a 2nd (or more) defacto marketplace will be >>> created. It is inevitable and short of a law being past you and I >>> can?t stop it. As you probably know this is already happening with >>> the IP brokers out there and I could easily see another RIR who is >>> out of resources joining up with significant 3rd party brokers to >>> fill IPv4 needs at market prices worldwide. There is another supply >>> of IPv4 resources out there in the form of all those Legacy /8?s that >>> were given out many years ago, and I suspect that demand will bring >>> some of those resources to market. That supply could defer switching >>> to IPv6 for years and not everyone likes IPv6. >>> >> >> Then maybe the discussion we should be having is how to reclaim >> un-needed IPV4 space. > > this discussion should have happened 10 years ago. Now, it's too late. > > Everyone knows that IP addresses are worth a buck or two.. The marketplace > exists and at least 3 RIRs acknowledge it and their communities have built > policies for it. Would you give them up if you would be having a (large) > number of unused IPs; IPs that may bring your organization the money needed > to invest in new equipment and skills and migrate to IPv6 :) > > cheers, > elvis > > _______________________________________________ > 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 mpetach at netflight.com Wed Jun 11 09:42:23 2014 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 11 Jun 2014 06:42:23 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <53976D0E.50509@velea.eu> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> Message-ID: On Tue, Jun 3, 2014 at 12:31 PM, David Huberman < David.Huberman at microsoft.com> wrote: > We had a discussion today at NANOG in the ARIN PPC about needs-basis in > 8.3 transfers. > > > > I?d like to state the following, and then let?s see where the discussion > takes us: > > > > My team runs an AS. And yep, we?re a pretty big company. We rely on IPv4 > today for most of our numbering, and will continue to do so for the next > couple of years.[1] In the coming year, when we can?t get space from ARIN > or other RIRs, we have to turn to the market for our IP address needs. We > may choose to buy more than a 2 year supply, because it may make business > sense for us to do so. ARIN policy, however, only allows us to take the > IP addresses we buy and transfer the portion which represents a 2 year > need. The rest will remain in the name of whoever sold the IP addresses > to us. > > > > Why is this result good for the operator community? Wouldn?t it be better > if ARIN rules allowed us to transfer into our name all the IP addresses > which we now own? > > > > Regards, > > /david > > > > [1] We?re working on increasing IPv6 presence in our network and our > products, but large corporations move slowly ;) > See, this is why I support maintaining the needs-based decisionmaking around number allocations. Because it's far too easy for a really big company with a couple of billion dollars in the bank to decide that IPv6 is just too hard, and it's easier to buy up large blocks of IPv4 space, and keep their critical resources on v4 addresses--which, if those resources are crucial enough, could artificially drive up demand for IPv4. As a purely hypothetical exercise, let's consider the three major smartphone OS vendors; each of them have over $100B in assets in the bank at the moment; and each of them have a relative lock on the mobile phone OS for a given set of handset hardware. If they each decided that IPv6 was too hard, and they could get enough IPv4 space on the unrestricted market (remember, with over $100B each in assets, at $12/IP, each of them could in theory be able to afford every remaining IP address on the planet, with cash left over). If they kept their software update servers on IPv4, they'd have a lock on over a *billion* endpoints[1] that they would force a requirement for IPv4 onto. That would generate an ongoing demand for IPv4 resources which they would have an ironfisted control over. Any mobile carrier that wanted to provide service for a smartphone would have to ensure the phone could reach the IPv4-only software update servers. Yes, this is a bit of hyperbole; I'm not expecting the big three smartphone OS vendors to go out and buy up all the IPv4 space remaining, just to have absolute control over the global portable communications infrastructure. But the numbers do indicate that would be a not-infeasible scenario. Even Apple alone, with their assets in the bank, could afford to buy up every remaining IPv4 address at current market prices; requiring just ios devices alone to speak IPv4 to get software updates would force pretty much every major mobile carrier in the world to have to maintain IPv4 infrastructure for the foreseeable future, and could potentially put them into a situation where they would have to lease IPv4 addresses for their handsets from Apple, in order to be able to provision their own customers. The ability for one entity to control both ends of the connection; at the client device, and on the server side, and with enough cash and assets to create a monopoly on the means by which those two endpoints communicate...see, that's why I will continue to vote in favour of needs-based justification for resources; because the temptation to have that level of absolute control over a resource is too risky to leave without some level of community input as well. Thanks! Matt (being paranoid, yes--but also recognizing that greed can drive anti-social behaviours) P.S. Apologies to Apple--I used you simply as an example to highlight that in responding to David, I did not mean to imply in any way that my concern was only about Microsoft; any of the dominant smartphone OS vendors has the same level of capability at this point in time. [1] http://www.bloomberg.com/news/2012-10-17/smartphones-in-use-surpass-1-billion-will-double-by-2015.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at velea.eu Wed Jun 11 10:05:56 2014 From: elvis at velea.eu (Elvis Velea) Date: Wed, 11 Jun 2014 16:05:56 +0200 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers In-Reply-To: <8276EF18-9485-4389-B425-CDF5EA4DA5CD@delong.com> References: <53767336.4080001@arin.net> <53963F7E.1030007@quark.net> <53976A47.1090200@velea.eu> <8276EF18-9485-4389-B425-CDF5EA4DA5CD@delong.com> Message-ID: <53986244.8090805@velea.eu> Hi Owen, you were right, I mixed two different policy proposal numbers. The stats I was asking for were for the 2014-14 policy proposal. Kind regards, Elvis On 11/06/14 08:32, Owen DeLong wrote: > I believe this comment is about 2014-14 (Removing Needs Test from Small IPv4 Transfers) rather than 2014-17. > > Can you please confirm that and, if so, repost it in the appropriate thread? > > The comments below seem unrelated to 2014-17 (Change Utilization Requirements from last-allocation to total-aggreagate). > > Owne > > On Jun 10, 2014, at 13:27 , Elvis Velea wrote: > >> Hi Andrew, >> >> after an other read of the policy proposal, I now understand that removal of demonstrated need from policy would be a secondary effect. You were actually trying to reduce the load on the ARIN Registration Department's work and reduce approval time. >> >> I am wondering if ARIN RS staff could actually produce some statistics showing how work-loaded they are (these may already be available online, but I don't know how to get to them). >> >> Something in the lines of: >> - for the tree sizes discussed here: /24, /20 and /16 + total >> - number of requests per month >> - average time until initial response >> - average number of mails sent in the request by ARIN staff >> - average time needed for approval >> - number of requested sizes that were reduced and by how much >> >> We could then form an opinion on how much would this proposal impact on one side, the organisations that make the requests, and on the other side, ARIN staff. >> Off course, removing the DN from small requests may create more workload for ARIN as number of transfer requests will increase :) >> >> cheers, >> elvis >> >> >> On 10/06/14 01:13, Andrew Dul wrote: >>> Hello, >>> >>> Thank you to those of you who were able to participate at the PPC last >>> week at NANOG. Below are some thoughts based on the feedback I heard. >>> >>> I heard some support for this policy with the caveat that this policy >>> would allow some organizations to apply for address space sooner. Some >>> postulated that the downside to this policy would be short and likely >>> small for the remainder of the free pool, but it would also make it >>> easier to qualify for transfer space sooner on the transfer market. >>> >>> I heard that this policy shouldn't impact organizations which currently >>> use the MDN 4.5 policies and that the current MDN policy does not have >>> the same issue as it uses a 80% per site metric to meet utilization >>> requirements. >>> >>> The other issue which is related to this draft that I heard at the PPC >>> was that ARIN in the past year or so updated its operational practice to >>> more closely follow the current policy of " efficiently utilized all >>> previous allocations" (4.2.4.1) and this is also making harder for some >>> organizations to meet utilization guidelines at the time of request for >>> additional space. Do other organizations also believe the new >>> operational practice is an issue and the policy should be changed? >>> >>> As I stated at the PPC, so far I've seen a little support for this and >>> some opposition for this proposal, but at this point not enough to move >>> it forward to a recommended policy based on the current feedback. If >>> you support this policy, please post your support to the mailing-list >>> otherwise as the policy shepherd I will likely be recommending that the >>> AC abandon this draft at a future AC meeting. >>> >>> Thanks for your input, >>> Andrew >>> >>> On 5/16/2014 1:21 PM, ARIN wrote: >>>> ## * ## >>>> >>>> >>>> Draft Policy ARIN-2014-17 >>>> Change Utilization Requirements from last-allocation to total-aggregate >>>> >>>> Date: 16 May 2014 >>>> >>>> Problem Statement: >>>> >>>> Utilization requirements for new requests is being calculated on a per >>>> allocation basis rather than in aggregate. For example, if an >>>> organization has 4 x /22 and 3 of them are utilized 100% and the >>>> fourth utilized at 75%, that request would be denied. This is a bit >>>> out of balance as an organization with a single /20 utilized at 80% >>>> would have less efficient utilization but would be eligible to request >>>> additional space. >>>> >>>> Policy statement: >>>> >>>> Section 4.2.4.1- Change text to read: "ISPs must have efficiently >>>> utilized all previous allocations, in aggregate, to at least 80% in >>>> order to receive additional space. This includes all space reassigned >>>> to their customers. Please note that until your prior utilization is >>>> verified to meet the 80% requirement, ARIN can neither process nor >>>> approve a request for additional addresses." >>>> >>>> Section 4.3.6.1- Change text to read: "End-users must have efficiently >>>> utilized all previous assignments, in aggregate, to at least 80% in >>>> order to receive additional space, and must provide ARIN with >>>> utilization details. The prefix size for an additional assignment is >>>> determined by applying the policies found in Section 4.3 of the NRPM." >>>> >>>> Comments: >>>> >>>> a. Timetable for implementation: Immediate, possibly through board >>>> action. >>>> b. Per originator, This does not currently extend into MDN (aka >>>> 4.5.4), and I'm not really sure how to reconcile it against 4.5.5, but >>>> OP expressed some concern that there may be undue restrictions there. >>>> It might be better served by a separate proposal. >>>> c. There should probably also be an attempt to clean up the language >>>> between 4.2.4.1 and 4.3.6.1, as they're both currently very clunky. >>> _______________________________________________ >>> 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 mike at iptrading.com Wed Jun 11 10:59:09 2014 From: mike at iptrading.com (Mike Burns) Date: Wed, 11 Jun 2014 10:59:09 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <53976D0E.50509@velea.eu><5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> Message-ID: Hi Matt, I put my comments below your signature. Regards, Mike See, this is why I support maintaining the needs-based decisionmaking around number allocations. Because it's far too easy for a really big company with a couple of billion dollars in the bank to decide that IPv6 is just too hard, and it's easier to buy up large blocks of IPv4 space, and keep their critical resources on v4 addresses--which, if those resources are crucial enough, could artificially drive up demand for IPv4. Matt Hi Matthew, It would be simple to see that somebody is buying up IPv4 addresses and the price would rise accordingly, thwarting his plans. Anybody engaged in that behavior would have to first find the sellers, a considerable problem, and impossible to do silently. Then he would have to do hundreds and hundreds of transactions, which would take a long time and everybody would see it in the public transfer lists posted by the RIRs. Worldwide there have been less than 1500 transfers. My rough number is about 24 million total addresses have been bought or sold since 2010, leaving out intra-company transfers. You seem to think there is somebody, somewhere you can tap on the shoulder and offer a couple of billion and he can transfer hundreds of millions of addresses to you. Without the needs test, you can be sure every transfer will be booked and visible, unlike those transfers driven underground by the needs test. That visibility, and innate seller fragmentation, is our protection against this kind of scheme. IMO, the mobile phone operators are not going to invest and risk billions of dollars on a reputationally dangerous ploy like this. Instead they simply appropriate some DoD space and run CGN. Or they could turn on IPv6, which is not ?hard? but which is fruitless in today?s Internet. Although we may not agree on the risks here, are you in agreement that limiting needs-free transfers to one /16 per year per registrant would effectively obviate the fears of the activity you describe? Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From lar at mwtcorp.net Wed Jun 11 11:48:28 2014 From: lar at mwtcorp.net (lar at mwtcorp.net) Date: Wed, 11 Jun 2014 09:48:28 -0600 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <1574F0C2-F27E-44E7-8247-C524D8C89CD0@delong.com> References: <53976D0E.50509@velea.eu> <1574F0C2-F27E-44E7-8247-C524D8C89CD0@delong.com> Message-ID: On Wed, 11 Jun 2014 00:07:11 -0700 Owen DeLong wrote: > > On Jun 10, 2014, at 13:39 , Elvis Velea wrote: > >> >> On 10/06/14 22:15, lar at mwtcorp.net wrote: >>> On Tue, 10 Jun 2014 20:11:15 +0000 >>> Steven Ryerse wrote: >>>> Get used to it because even if this Community doesn?t relent and ease up on needs requirements, the marketplace will take up the >>>>slack outside of ARIN - and a 2nd (or more) defacto marketplace will be created. It is inevitable and short of a law being past >>>>you and I can?t stop it. As you probably know this is already happening with the IP brokers out there and I could easily see >>>>another RIR who is out of resources joining up with significant 3rd party brokers to fill IPv4 needs at market prices worldwide. >>>>There is another supply of IPv4 resources out there in the form of all those Legacy /8?s that were given out many years ago, and >>>>I suspect that demand will bring some of those resources to market. That supply could defer switching to IPv6 for years and not >>>>everyone likes IPv6. >>>> >>> >>> Larry: Then maybe the discussion we should be having is how to reclaim un-needed IPV4 space. >> >> this discussion should have happened 10 years ago. Now, it's too late. > > This discussion happened 20 years ago and it was too late then. > > The determination at the time was the same as it is now... The real solution is to deploy IPv6. Reclaiming IPv4 addresses would >result in only a few (perhaps several) months worth of address supply and would tie up vast amounts of human and capital >resources that should be much better spent on IPv6 rollout. > Larry: I took Steven's post as "If you don't make policy this way we're going to ignore it", My reply was intended to say then we need to put more teeth in the policy. I can't think there is any future in either. >> Everyone knows that IP addresses are worth a buck or two.. The marketplace exists and at least 3 RIRs acknowledge it and their >>communities have built policies for it. Would you give them up if you would be having a (large) number of unused IPs; IPs that >>may bring your organization the money needed to invest in new equipment and skills and migrate to IPv6 :) > > The market was accepted as a low-cost alternative to reclamation. Essentially, it is a stop-gap for those most determined to >avoid a true solution. > Larry: I personally believe that the proposal of liberalizing transfers of up to /20 (as compared to a /16) a generous compromise and would support that as a fair start. In the mean time IPv6 is slowly marching forward. > > Owen > Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From SRyerse at eclipse-networks.com Wed Jun 11 13:40:10 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 11 Jun 2014 17:40:10 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <53976D0E.50509 @velea.eu> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com>< CACAaNxizG3+D3QHZpyjHKnCJQEX=_c7w=TwW4O9jDSvpNEZpNw@mail.gmail.com><5B9E907 47FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> Even one transfer that doesn't update the database is one too many and I'm sure just by reading Mike Burns post today it is more than a few. Mike used the phrase "driven underground" in his post today and that is what is happening. I read your resume a while back and it is impressive. You spend a lot more of your time dealing with these issues than I do. So I ask again - why are so many transfers (in this region) of resources happening outside of ARIN's ?Transfers to Specified Recipients? policy? 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? -----Original Message----- From: McTim [mailto:dogwallah at gmail.com] Sent: Wednesday, June 11, 2014 7:09 AM To: Owen DeLong Cc: Steven Ryerse; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Wed, Jun 11, 2014 at 2:09 AM, Owen DeLong wrote: > Please put a number on "so many" and provide documentation to support > that number. My reaction as well. While we are at it, if we want to get a sense of how much of the total "Registry inaccuracy" is due to undocumented (grey or black market) transfers, those numbers would be extraordinarily useful in seeing the problem statement clearly. No clue how to gauge these numbers however! -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel > > Owen > > On Jun 10, 2014, at 14:43 , Steven Ryerse > > wrote: > > Yes some blocks have been returned and that is a good thing. My > question for your first point then is why are so many transfers (in > this region) of resources happening outside of ARIN and the ?Transfers > to Specified Recipients? policy (or other applicable ARIN policies)? > After all I think we would get a near unanimous consensus that when > the database doesn?t get updated after a transfer it is a negative > thing? So it is not desirable for transfers to take place outside of ARIN but it keeps happening anyway. Why? > > 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: McTim [mailto:dogwallah at gmail.com] > Sent: Tuesday, June 10, 2014 5:24 PM > To: Steven Ryerse > Cc: elvis at velea.eu; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > > > > On Tue, Jun 10, 2014 at 3:47 PM, Steven Ryerse > wrote: > Yes I agree it should have happened years ago and I agree that an > outside marketplace already exists, but it isn't too late for ARIN to > engage and embrace the new marketplace. > > > > They have embraced it, fully: > > https://arin.net/resources/request/transfers_8_3.html > > > > > I certainly do understand why those large Legacy holders would just > watch and wait to see what happened in the marketplace once all of the > RIRs run out of resources. It is in their interest to do so. > > > > but there have been cases of good net-citizenship where entities have > returned large blocks (even entire /8's) in recent years. > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there." Jon Postel > > > > > 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? > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of Elvis Velea > Sent: Tuesday, June 10, 2014 4:40 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > On 10/06/14 22:15, lar at mwtcorp.net wrote: >> On Tue, 10 Jun 2014 20:11:15 +0000 >> Steven Ryerse wrote: >>> Get used to it because even if this Community doesn?t relent and >>> ease up on needs requirements, the marketplace will take up the >>> slack outside of ARIN - and a 2nd (or more) defacto marketplace will >>> be created. It is inevitable and short of a law being past you and >>> I can?t stop it. As you probably know this is already happening >>> with the IP brokers out there and I could easily see another RIR who >>> is out of resources joining up with significant 3rd party brokers to >>> fill IPv4 needs at market prices worldwide. There is another supply >>> of IPv4 resources out there in the form of all those Legacy /8?s >>> that were given out many years ago, and I suspect that demand will >>> bring some of those resources to market. That supply could defer >>> switching to IPv6 for years and not everyone likes IPv6. >>> >> >> Then maybe the discussion we should be having is how to reclaim >> un-needed IPV4 space. > > this discussion should have happened 10 years ago. Now, it's too late. > > Everyone knows that IP addresses are worth a buck or two.. The > marketplace exists and at least 3 RIRs acknowledge it and their > communities have built policies for it. Would you give them up if you > would be having a (large) number of unused IPs; IPs that may bring > your organization the money needed to invest in new equipment and > skills and migrate to IPv6 :) > > cheers, > elvis > > _______________________________________________ > 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 bross at pobox.com Wed Jun 11 13:40:13 2014 From: bross at pobox.com (Brandon Ross) Date: Wed, 11 Jun 2014 13:40:13 -0400 (EDT) Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <469A588F-3A36-4FDB-8A81-59ECD4F4F722@delong.com> References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> <469A588F-3A36-4FDB-8A81-59ECD4F4F722@delong.com> Message-ID: On Wed, 11 Jun 2014, Owen DeLong wrote: > On Jun 10, 2014, at 16:39 , Brandon Ross wrote: > >> On Mon, 9 Jun 2014, Owen DeLong wrote: >> >>> Your third item is absurd. If they don't find sellers with that much space, then it means the market isn't as large as described and the problem is even worse and market capture is even easier. Without a needs test or the other restrictions in 8.3, it would not take years, it would take days. Address space would be swept away as fast as it came available on the market. It would be IP lotto for the uber-wealthy corporations. >> >> If these bad actors are willing to spend such amounts of money to capture the market, why wouldn't they do this with the needs test in place simply by locking up all the space under contracts instead? > > I can't guarantee that they won't. However, if it gets discovered that > they have, the collusion required to do so might have interesting > implications under the Sherman act. I might be wrong, but I think it > would be much harder to make a Sherman Act case if community policy > permitted the unrestricted outright sale and transfer. Then can I assume that there's no evidence that shows that the Sherman Act is easier to enforce with or without supporting community policy? And if so, since we agree that this can be done with or without a needs basis, doesn't the costs to the community to continue to enforce the needs basis outweigh any measurable benefit? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From mpetach at netflight.com Wed Jun 11 13:42:55 2014 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 11 Jun 2014 10:42:55 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <53976D0E.50509@velea.eu> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> Message-ID: On Wed, Jun 11, 2014 at 7:59 AM, Mike Burns wrote: > Hi Matt, > > I put my comments below your signature. > > Regards, > Mike > > > See, this is why I support maintaining the > needs-based decisionmaking around number > allocations. > > Because it's far too easy for a really big company > with a couple of billion dollars in the bank to decide > that IPv6 is just too hard, and it's easier to buy up > large blocks of IPv4 space, and keep their critical > resources on v4 addresses--which, if those resources > are crucial enough, could artificially drive up demand > for IPv4. > > Matt > > Hi Matthew, > > It would be simple to see that somebody is buying up IPv4 addresses and > the price would rise accordingly, thwarting his plans. > Anybody engaged in that behavior would have to first find the sellers, a > considerable problem, and impossible to do silently. > Except that one conspicuous feature of a market is that it brings together the sellers in one place so that the buyers can find them. The stock market wouldn't work terribly well if everyone did everything individually. It only works because there's a common place where buyers and sellers congregate together. > Then he would have to do hundreds and hundreds of transactions, which > would take a long time and everybody would see it in the public transfer > lists posted by the RIRs. > As every hostile takeover expert in investment banking on wall street can tell you, you don't do the transactions under your own name; you have holding companies start doing the transactions, a bit at a time, so that you can fly under the radar as long as you can, until it's too late for anyone else to react and change the outcome. > Worldwide there have been less than 1500 transfers. > My rough number is about 24 million total addresses have been bought or > sold since 2010, leaving out intra-company transfers. > > You seem to think there is somebody, somewhere you can tap on the shoulder > and offer a couple of billion and he can transfer hundreds of millions of > addresses to you. Without the needs test, you can be sure every transfer > will be booked and visible, unlike those transfers driven underground by > the needs test. That visibility, and innate seller fragmentation, is our > protection against this kind of scheme. > And that open visibility works *so* well for preventing hostile takeovers in the stock market, right? Oh wait--that's why companies enact poison pill clauses; because often the transactions are so distributed and so randomized that by the time you realize you're being taken over, it's too late to stop it; so the poison pill allows you to dilute the stock to the point where the hostile takeover has to chase an asymptotic curve. Unfortunately, in 32-bit land, there's no such safety belt; we can't issue additional number resources to prevent a hostile takeover situation like that. > > IMO, the mobile phone operators are not going to invest and risk billions > of dollars on a reputationally dangerous ploy like this. Instead they > simply appropriate some DoD space and run CGN. Or they could turn on IPv6, > which is not ?hard? but which is fruitless in today?s Internet. > I didn't say the mobile phone operators. They only control one piece of the equation; they can't effectively lock the communication channel down. I said the OS vendors. They have the capital and the control of both ends of the socket; the client device, and the OS upgrade/patch servers. Those are the players I'm most afraid of right now. And having one of the big three that has already made one of the biggest IP space acquisition bids in history step forward and say "hey, we need to be able to do more of this in an unfettered manner" scares the bejeezus out of me--and I don't even know what a bejeezus is. > > Although we may not agree on the risks here, are you in agreement that > limiting needs-free transfers to one /16 per year per registrant would > effectively obviate the fears of the activity you describe? > A /16 is really freakin' big. When I'm being paid (which I'm not at the moment, so these paranoid delusions are entirely my own, and do not represent any official stance of any corporate entity of any sort), it's to run herd over several dozen different networks, with many different org-IDs. That would effectively allow me to do 50 /16 transfers per year with no justification needed, under different names; in half a decade, that would allow me to suck up a /8 with no justification needed. And $eventual_dayjob isn't even one of the really big players; for the really big players, it would be relatively straightforward to suck up a /8 per year this way. I remain unconvinced that removing needs-based justification for transfers is a healthy notion for a resource that is absolutely and finitely bounded, and for which there are billion hostages around the planet under the control of 3 entities. I realize I'm paranoid; but that means it's going to take a lot more confidence in this marketplace to get me to the point where I'd feel comfortable changing my vote. Thanks! Matt > > Regards, > Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpetach at netflight.com Wed Jun 11 14:00:30 2014 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 11 Jun 2014 11:00:30 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> <469A588F-3A36-4FDB-8A81-59ECD4F4F722@delong.com> Message-ID: On Wed, Jun 11, 2014 at 10:40 AM, Brandon Ross wrote: > On Wed, 11 Jun 2014, Owen DeLong wrote: > > On Jun 10, 2014, at 16:39 , Brandon Ross wrote: >> >> On Mon, 9 Jun 2014, Owen DeLong wrote: >>> >>> Your third item is absurd. If they don't find sellers with that much >>>> space, then it means the market isn't as large as described and the problem >>>> is even worse and market capture is even easier. Without a needs test or >>>> the other restrictions in 8.3, it would not take years, it would take days. >>>> Address space would be swept away as fast as it came available on the >>>> market. It would be IP lotto for the uber-wealthy corporations. >>>> >>> >>> If these bad actors are willing to spend such amounts of money to >>> capture the market, why wouldn't they do this with the needs test in place >>> simply by locking up all the space under contracts instead? >>> >> >> I can't guarantee that they won't. However, if it gets discovered that >> they have, the collusion required to do so might have interesting >> implications under the Sherman act. I might be wrong, but I think it would >> be much harder to make a Sherman Act case if community policy permitted the >> unrestricted outright sale and transfer. >> > > Then can I assume that there's no evidence that shows that the Sherman Act > is easier to enforce with or without supporting community policy? And if > so, since we agree that this can be done with or without a needs basis, > doesn't the costs to the community to continue to enforce the needs basis > outweigh any measurable benefit? I cannot absolutely prevent you from stealing my furniture if you so desire. However, that doesn't mean I'm not going to put a lock on my front door to at least make it harder for you, and make it patently clear that you're doing so against my express desires. Likewise, the community cannot absolutely prevent people from absconding with number resources; but we can put a lock on the door, so that when the theft takes place, the person making off with the goods has to do a fair amount of work, and is absolutely aware that what they are doing is against the desire and will of the community. People are only in favour of needs-free transfers because they think they can be one of the first people in line to get while the getting's good. I guarantee you, when all the available addresses have been hoovered up, everyone on this list that cried out for a free-for-all in the IP market will be coming back to complain bitterly that there's nothing left, and that we should have handled things differently. And I'll further warrant that their next target will be the transition blocks that have been set aside. I'll ask plainly; for everyone voting for needs-free transfers; would you still vote that way, *if in doing so, you were guaranteed to not be able to obtain any number resources under the new policy*? If not, I would claim your votes are not guided by the good of the community; they're guided by self-interest, and a hope and desire that you can get something for less effort than you can by following the current guidelines. It's no different than people pushing a pyramid scheme; "if I get in quickly, I can make out like a bandit, and leave everyone else later holding the bag." *sigh* I'm sorry. I'm going to start saying things that will offend people, and I'll end up with a bunch of pissed off people if I continue. Simply put, needs-free transfers is a recipe for disaster, and I cannot in good conscience support it. I'll keep locking my car, and closing my front door and locking it when I leave, to make it clear to those around that even though I cannot prevent them being taken, at least those doing the taking will be under no pretense they are anything but bad actors when doing so. :/ Thanks! Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Wed Jun 11 14:15:17 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 11 Jun 2014 18:15:17 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <7D51B0FD40554C4E9DE275DEA58B8B8B @MPC><679948D066BC47828F06 48291A9886E7@ncsscfoipoxes4><469A588F-3A36-4FDB-8A81-59EC D4F4F722@delong.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0EE5A@ENI-MAIL.eclipse-networks.com> Per your last 3 paragraphs, the IP world hasn?t come to an end in the RIPE region and I think that is an important observation for this discussion. Per your voting question: If my options are to get none now and none later or to get some now and none later ? I would take the 2nd option. The only difference between today and the day ARIN?s pool is exhausted is time - and probably not very much time. I appreciation your input. 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 Matthew Petach Sent: Wednesday, June 11, 2014 2:01 PM Cc: arin-ppml at arin.net List (arin-ppml at arin.net) Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Wed, Jun 11, 2014 at 10:40 AM, Brandon Ross > wrote: On Wed, 11 Jun 2014, Owen DeLong wrote: On Jun 10, 2014, at 16:39 , Brandon Ross > wrote: On Mon, 9 Jun 2014, Owen DeLong wrote: Your third item is absurd. If they don't find sellers with that much space, then it means the market isn't as large as described and the problem is even worse and market capture is even easier. Without a needs test or the other restrictions in 8.3, it would not take years, it would take days. Address space would be swept away as fast as it came available on the market. It would be IP lotto for the uber-wealthy corporations. If these bad actors are willing to spend such amounts of money to capture the market, why wouldn't they do this with the needs test in place simply by locking up all the space under contracts instead? I can't guarantee that they won't. However, if it gets discovered that they have, the collusion required to do so might have interesting implications under the Sherman act. I might be wrong, but I think it would be much harder to make a Sherman Act case if community policy permitted the unrestricted outright sale and transfer. Then can I assume that there's no evidence that shows that the Sherman Act is easier to enforce with or without supporting community policy? And if so, since we agree that this can be done with or without a needs basis, doesn't the costs to the community to continue to enforce the needs basis outweigh any measurable benefit? I cannot absolutely prevent you from stealing my furniture if you so desire. However, that doesn't mean I'm not going to put a lock on my front door to at least make it harder for you, and make it patently clear that you're doing so against my express desires. Likewise, the community cannot absolutely prevent people from absconding with number resources; but we can put a lock on the door, so that when the theft takes place, the person making off with the goods has to do a fair amount of work, and is absolutely aware that what they are doing is against the desire and will of the community. People are only in favour of needs-free transfers because they think they can be one of the first people in line to get while the getting's good. I guarantee you, when all the available addresses have been hoovered up, everyone on this list that cried out for a free-for-all in the IP market will be coming back to complain bitterly that there's nothing left, and that we should have handled things differently. And I'll further warrant that their next target will be the transition blocks that have been set aside. I'll ask plainly; for everyone voting for needs-free transfers; would you still vote that way, *if in doing so, you were guaranteed to not be able to obtain any number resources under the new policy*? If not, I would claim your votes are not guided by the good of the community; they're guided by self-interest, and a hope and desire that you can get something for less effort than you can by following the current guidelines. It's no different than people pushing a pyramid scheme; "if I get in quickly, I can make out like a bandit, and leave everyone else later holding the bag." *sigh* I'm sorry. I'm going to start saying things that will offend people, and I'll end up with a bunch of pissed off people if I continue. Simply put, needs-free transfers is a recipe for disaster, and I cannot in good conscience support it. I'll keep locking my car, and closing my front door and locking it when I leave, to make it clear to those around that even though I cannot prevent them being taken, at least those doing the taking will be under no pretense they are anything but bad actors when doing so. :/ Thanks! Matt -------------- 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 gary.buhrmaster at gmail.com Wed Jun 11 14:46:51 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 11 Jun 2014 18:46:51 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> Message-ID: On Wed, Jun 11, 2014 at 5:40 PM, Steven Ryerse wrote: > Even one transfer that doesn't update the database is one too many Playing devils advocate then, I take it you are in favor of moving to rescind (and then re-issue) any IP Numbers for which the whois validation has not been confirmed (by the yearly POC validation emails)? And perhaps with an officer attestation saying that the numbers of fully utilized per RSA? Historically, the ARIN community has never been willing to take that step (and, I would likely not support it), but perhaps the tides have changed, and community now believes that whois accuracy is the most important thing. I will look forward to your policy proposal to put teeth into whois validation. Gary From SRyerse at eclipse-networks.com Wed Jun 11 15:15:31 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 11 Jun 2014 19:15:31 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <5B9E90747FA297 4D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0F0B6@ENI-MAIL.eclipse-networks.com> The existence of Legacy holders makes that a murky legal question and thus is probably not feasible. However, I would support attempting something like that if it was voluntary. We might be surprised by the amount of cooperation if it was voluntary and some sort of amnesty was offered. 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? -----Original Message----- From: Gary Buhrmaster [mailto:gary.buhrmaster at gmail.com] Sent: Wednesday, June 11, 2014 2:47 PM To: Steven Ryerse Cc: McTim; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Wed, Jun 11, 2014 at 5:40 PM, Steven Ryerse wrote: > Even one transfer that doesn't update the database is one too many Playing devils advocate then, I take it you are in favor of moving to rescind (and then re-issue) any IP Numbers for which the whois validation has not been confirmed (by the yearly POC validation emails)? And perhaps with an officer attestation saying that the numbers of fully utilized per RSA? Historically, the ARIN community has never been willing to take that step (and, I would likely not support it), but perhaps the tides have changed, and community now believes that whois accuracy is the most important thing. I will look forward to your policy proposal to put teeth into whois validation. Gary From mike at iptrading.com Wed Jun 11 15:31:48 2014 From: mike at iptrading.com (Mike Burns) Date: Wed, 11 Jun 2014 15:31:48 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> Message-ID: On Wed, Jun 11, 2014 at 5:40 PM, Steven Ryerse wrote: > Even one transfer that doesn't update the database is one too many Playing devils advocate then, I take it you are in favor of moving to rescind (and then re-issue) any IP Numbers for which the whois validation has not been confirmed (by the yearly POC validation emails)? And perhaps with an officer attestation saying that the numbers of fully utilized per RSA? I will look forward to your policy proposal to put teeth into whois validation. Gary Hi Gary, The two are not equal propositions. Your proposal to rescind non validated space, like removing needs, will indeed tend towards more registry accuracy. But your proposal is fraught with legal peril for ARIN, certainly in legacy space, whereas removing the needs test reduces legal peril, in the opinion of this non-lawyer, because it makes the transfer of address rights more closely comport with the existing legal framework which deals with the transfer of valuable items. Steven and I have expressed a desire for more Whois accuracy and there is a proposal on the table (2014-14) which I think will tend towards more Whois accuracy while at the same time protecting against market manipulation and reducing the need for ARIN staff to spend team time doing needs tests for small transfers where the buyer is already displaying his need with his dollars. Zombies registrants in Whois are real, there are restrictions on identifying them, their continued existence is facilitated by the needs test. We need to stop worrying about fictional billionaire fraudsters and start considering whether any undemonstrated benefits of retaining the needs test for small transfers are worth the undemonstrated costs. To that end some who had been against any relaxing of the needs test have moderated their positions, with Owen offering the additional caveat that the policy have a sunset, in the hopes that we may garner more information on the potential for abuse and the potential for registration benefits. And I think McTim's /24 represents a seismic change, thank you McTim. Hopefully those who support a complete removal of the needs-test for transfers will also offer support for the more limited 2014-14. Regards, Mike From kkargel at polartel.com Wed Jun 11 15:50:40 2014 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 11 Jun 2014 14:50:40 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0F0B6@ENI-MAIL.eclipse-networks.com> References: <5B9E90747FA297 4D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0F0B6@ENI-MAIL.eclipse-networks.com> Message-ID: <8695009A81378E48879980039EEDAD2801387EF851@MAIL1.polartel.local> It already is voluntary. Nobody is stopping anyone from returning unused resources. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Steven Ryerse > Sent: Wednesday, June 11, 2014 2:16 PM > To: Gary Buhrmaster > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > The existence of Legacy holders makes that a murky legal question and thus > is probably not feasible. However, I would support attempting something > like that if it was voluntary. We might be surprised by the amount of > cooperation if it was voluntary and some sort of amnesty was offered. > > 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? > > > -----Original Message----- > From: Gary Buhrmaster [mailto:gary.buhrmaster at gmail.com] > Sent: Wednesday, June 11, 2014 2:47 PM > To: Steven Ryerse > Cc: McTim; arin-ppml at arin.net > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > On Wed, Jun 11, 2014 at 5:40 PM, Steven Ryerse networks.com> wrote: > > Even one transfer that doesn't update the database is one too many > > Playing devils advocate then, I take it you are in favor of moving to rescind > (and then re-issue) any IP Numbers for which the whois validation has not > been confirmed (by the yearly POC validation emails)? And perhaps with an > officer attestation saying that the numbers of fully utilized per RSA? > > Historically, the ARIN community has never been willing to take that step > (and, I would likely not support it), but perhaps the tides have changed, and > community now believes that whois accuracy is the most important thing. > > I will look forward to your policy proposal to put teeth into whois validation. > > Gary > _______________________________________________ > 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 gary.buhrmaster at gmail.com Wed Jun 11 15:51:32 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 11 Jun 2014 19:51:32 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> Message-ID: On Wed, Jun 11, 2014 at 7:31 PM, Mike Burns wrote: .... > Hi Gary, > > The two are not equal propositions. Never claimed they were. However, Steven stated that even one transfer not being recorded in the database was unacceptable. We now learn that accuracy is not actually a fundamental principal. I will choose to dismiss such assertions in the future as being a distraction from the real issues being discussed. .... > where the buyer is already displaying his need with his > dollars. "need" is not the same as "want" (see the $10K red button app that was offered for awhile; can anyone explain why anyone would "need" it). And while some may exchange money for only "want"s, those that can demonstrate "need" can get those transfers approved today and have the registry updated today. Only the "wants" are having a hard time. And, in my opinion, that is as it should be. From mike at iptrading.com Wed Jun 11 16:10:43 2014 From: mike at iptrading.com (Mike Burns) Date: Wed, 11 Jun 2014 16:10:43 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> Message-ID: <68DBABB50DB7469A837BE66C8985FB80@MPC> Never claimed they were. However, Steven stated that even one transfer not being recorded in the database was unacceptable. We now learn that accuracy is not actually a fundamental principal. I will choose to dismiss such assertions in the future as being a distraction from the real issues being discussed. Gary Hi Gary, Accuracy is indeed a fundamental principle of our stewardship, and an argument in support of 2014-14. Just because Steven won't leap to your command to submit a proposal to your liking regarding reclamation (not a right of ARIN anyway, per the current RSA), you can't reasonably dismiss the argument that retaining the needs tests works against the fundamental principle of registry accuracy. If you want to offer such a proposal, I would give it serious consideration as I feel valid contacts are a key function of the registry, but I don't think we can create policy to reclaim legacy blocks for invalid contacts. Regards, Mike From rbf+arin-ppml at panix.com Wed Jun 11 16:30:28 2014 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Wed, 11 Jun 2014 15:30:28 -0500 Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate In-Reply-To: <53963F7E.1030007@quark.net> References: <53767336.4080001@arin.net> <53963F7E.1030007@quark.net> Message-ID: <20140611203028.GA10411@panix.com> On Mon, Jun 09, 2014 at 04:13:02PM -0700, Andrew Dul wrote: > Hello, > > would allow some organizations to apply for address space sooner. Some > postulated that the downside to this policy would be short and likely > small for the remainder of the free pool, but it would also make it > easier to qualify for transfer space sooner on the transfer market. > > I heard that this policy shouldn't impact organizations which currently > use the MDN 4.5 policies and that the current MDN policy does not have > the same issue as it uses a 80% per site metric to meet utilization > requirements. > > The other issue which is related to this draft that I heard at the PPC > was that ARIN in the past year or so updated its operational practice to > more closely follow the current policy of " efficiently utilized all > previous allocations" (4.2.4.1) and this is also making harder for some > organizations to meet utilization guidelines at the time of request for > additional space. Do other organizations also believe the new > operational practice is an issue and the policy should be changed? > > As I stated at the PPC, so far I've seen a little support for this and > some opposition for this proposal, but at this point not enough to move > it forward to a recommended policy based on the current feedback. If > you support this policy, please post your support to the mailing-list > otherwise as the policy shepherd I will likely be recommending that the > AC abandon this draft at a future AC meeting. Strongly support. Current policy (1) treats someone holding two /16s obtained at separate times differently from someone holding one /15, and (2) creates incentive in the former case for the holder to renumber internally to shift utilization from the more-utilized block to the lesser-utilized block to be able to justify additional addresses. Both of these are undesirable. Efficient utilization should be a function of what resources an organization has and how that organization is utilizing them; whether they were acquired at the same or different times and whether they are documented as one or two (or more) entries in a database should not be relevant. Policy should not be unnecessarily creating incentives for activities (such as renumbering to move utilization between blocks) that adds no real value. (Additionally, organizations are incented by current policy to immediately stop using existing allocations, and start assigning from new allocations, as soon as a new allocation is received. This, too, is a negative-value-add consequence of current policy.) -- Brett From bross at pobox.com Wed Jun 11 16:36:21 2014 From: bross at pobox.com (Brandon Ross) Date: Wed, 11 Jun 2014 16:36:21 -0400 (EDT) Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> <469A588F-3A36-4FDB-8A81-59ECD4F4F722@delong.com> Message-ID: On Wed, 11 Jun 2014, Matthew Petach wrote: > I cannot absolutely prevent you from stealing my furniture > if you so desire. However, that doesn't mean I'm not going > to put a lock on my front door to at least make it harder for > you, and make it patently clear that you're doing so against > my express desires. As has been mentioned here before, stealing furnature is a criminal offence, writing a contract giving exclusive rights to address space is not. That's a pretty crucial difference. If breaking and entering and stealing furnature were legal, the small help of a lock on my porch screen door would make little difference to a "bad actor". Locks keep honest people honest, but if an activity is not widely agreed to be immoral, locks won't help. > I'll ask plainly; for everyone voting for needs-free > transfers; would you still vote that way, *if in doing > so, you were guaranteed to not be able to obtain > any number resources under the new policy*? I don't have any address resources now, and I don't ever plan on having any in the future, so sure, why not? > If not, I would claim your votes are not guided by > the good of the community; they're guided by > self-interest, and a hope and desire that you can > get something for less effort than you can by following > the current guidelines. Oh really? Much like Owen, I have a nice little business of helping small organizations navigate the ARIN process to get address space. It's not a majority of my income, but it's pretty nice and easy work for me. If needs basis goes away, guess what else goes away? Even though Owen and I are on opposite sides of this coversation, I can guarantee you right now that both of us, without fail, are arguing solely for what we think is best for the community. It's quite ironic that I would make more money by arguing on your side of the issue, isn't it? Or maybe my conspiracy is to get v4 to run out faster so I can make more money on v6 deployment? > I'm sorry. I'm going to start saying things that > will offend people, and I'll end up with a bunch > of pissed off people if I continue. I believe you already have. Please only question my motives when you have evidence. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From SRyerse at eclipse-networks.com Wed Jun 11 19:47:18 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 11 Jun 2014 23:47:18 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0FA1F@ENI-MAIL.eclipse-networks.com> Exactly, you just made the case I've been making in your real life terms. Nobody including me wants anyone to corner the market. If the ARIN policies are so hard to meet, that they have the effect of denying resources to real organizations with real needs, then the policies need to be fixed. Simple as that. Sounds like policies are denying your company needs. Your company should be able to get right sized resources. ARIN was created to allocate resources and not to find reasons not to allocate them. By the way no apology necessary for expressing an honest opinion. I appreciate an honest discussion. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: lar at mwtcorp.net [mailto:lar at mwtcorp.net] Sent: Wednesday, June 11, 2014 7:17 PM To: Steven Ryerse Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Wed, 11 Jun 2014 18:29:40 +0000 Steven Ryerse wrote: > I'm not sure why my post below was taken as "If you don't make policy this way we're going to ignore it". I was saying that >there are already transactions taking place that the parties involved are ignoring ARINs policy. > If I mis-interpreted your statement I apologize. I have had trouble meeting the needs requirement so I am aware and sympathize with the problem. I just feel there needs to be some method to be sure he who gets does really need, not just thinks he needs or worse yet can afford to stockpile more than he could ever use just in case. If there is a middle ground I'm all for it. The idea of /20 for no needs test seemed reasonable to me. Maybe dialing back how need is defined. Personally I've always hated the 80% yardstick that seemed somewhat arbitrary and almost unattainable if your assigning small networks to customers. Mostly we need to see IPv4 die and move on. The route table problem might kill it a long time sooner than exhaustion. > I am a CEO of a small company and I don't allow our employees to walk >down the hall and grab all of the computers and furniture they want, >but I do give them the proper amount of resources to get their job >completed, and I don't expect them to be able to get their job done with zero resources. I don't advocate allowing any organization to automatically get any sized resource they want, but as I've described several times before, I do want organizations to be able to get resources they deem they need that >are sized according to their size. (Small orgs CAN get small resources, medium sized orgs CAN get medium sized resources, and >so forth.) > > 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? > > Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From mpetach at netflight.com Wed Jun 11 20:12:57 2014 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 11 Jun 2014 17:12:57 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> <469A588F-3A36-4FDB-8A81-59ECD4F4F722@delong.com> Message-ID: On Wed, Jun 11, 2014 at 1:36 PM, Brandon Ross wrote: > On Wed, 11 Jun 2014, Matthew Petach wrote: > > I cannot absolutely prevent you from stealing my furniture >> if you so desire. However, that doesn't mean I'm not going >> to put a lock on my front door to at least make it harder for >> you, and make it patently clear that you're doing so against >> my express desires. >> > > As has been mentioned here before, stealing furnature is a criminal > offence, writing a contract giving exclusive rights to address space is > not. That's a pretty crucial difference. If breaking and entering and > stealing furnature were legal, the small help of a lock on my porch screen > door would make little difference to a "bad actor". Locks keep honest > people honest, but if an activity is not widely agreed to be immoral, locks > won't help. The only way an action becomes a criminal offense is if we bring the government in for enforcement. Thus far, as a community, we've been doing our best to not reach out to governments, which means nothing within the realm of number policy can ever be a criminal offense. I would think the community would still consider some of the number resource activities to be of a nature equivalent to what would be called a criminal activity, even if it does not hold that official designation according to the laws of the land. (That is, if I were to willfully announce IP space registered to someone else, the community would designate that as "wrong" and consider it to be a criminal act, even though no law of the land says that 32-bit address space has the same level of consideration as property.) Putting it another way--it is perfectly legal for me to hijack your IP space; there is no law that disallows it. Doesn't make it right according to our community. So, arguing that one case is a criminal offense while the other is not a criminal offense does not make the non-criminal offense any less wrong; it just means we don't yet have a law on the books defining it as such. > > I'll ask plainly; for everyone voting for needs-free > transfers; would you still vote that way, *if in doing > so, you were guaranteed to not be able to obtain > any number resources under the new policy*? > I don't have any address resources now, and I don't ever plan on having any > in the future, so sure, why not? My apologies; I misunderstood what your position was--and I thank you for your feedback to my question. > > > If not, I would claim your votes are not guided by >> the good of the community; they're guided by >> self-interest, and a hope and desire that you can >> get something for less effort than you can by following >> the current guidelines. >> > > Oh really? > > Much like Owen, I have a nice little business of helping small > organizations navigate the ARIN process to get address space. It's not a > majority of my income, but it's pretty nice and easy work for me. If needs > basis goes away, guess what else goes away? > > Even though Owen and I are on opposite sides of this coversation, I can > guarantee you right now that both of us, without fail, are arguing solely > for what we think is best for the community. > > It's quite ironic that I would make more money by arguing on your side of > the issue, isn't it? > > Or maybe my conspiracy is to get v4 to run out faster so I can make more > money on v6 deployment? I apologize; I meant the "you" to be addressed to the broader community, not to a particular individual. I was not aware of your activity in this arena, and it is good background to be aware of; but the statement was addressed to the plural "you" rather than the singular "you"--dratted English, not giving us a distinctly plural form of "you" we can use to make it explicit. I *will* note that I'm surprised--if you have no interest in obtaining number resources, what would make you vote one way vs the other, if the outcome is exactly the same for you either way? > > > I'm sorry. I'm going to start saying things that >> will offend people, and I'll end up with a bunch >> of pissed off people if I continue. >> > > I believe you already have. > > Please only question my motives when you have evidence. Would it help to say that I was questioning everyone's motives, not just yours? Or would that simply make my sin that much more inclusive? :/ Thanks for the attitude correction--sometimes it's good to be smacked in the head when I get too fired up and start making overly broad generalizations. Thanks! Matt > > > -- > Brandon Ross Yahoo & AIM: > BrandonNRoss > +1-404-635-6667 ICQ: > 2269442 > Skype: > brandonross > Schedule a meeting: http://www.doodle.com/bross > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From billdarte at gmail.com Thu Jun 12 06:37:07 2014 From: billdarte at gmail.com (Bill Darte) Date: Thu, 12 Jun 2014 05:37:07 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> Message-ID: Gary said... "need" is not the same as "want" (see the $10K red button app that was offered for awhile; can anyone explain why anyone would "need" it). And while some may exchange money for only "want"s, those that can demonstrate "need" can get those transfers approved today and have the registry updated today. Only the "wants" are having a hard time. And, in my opinion, that is as it should be. big +1 Bill Darte ____________________ On Wed, Jun 11, 2014 at 2:51 PM, Gary Buhrmaster wrote: > On Wed, Jun 11, 2014 at 7:31 PM, Mike Burns wrote: > .... > > Hi Gary, > > > > The two are not equal propositions. > > Never claimed they were. However, Steven stated > that even one transfer not being recorded in the > database was unacceptable. We now learn that > accuracy is not actually a fundamental principal. > I will choose to dismiss such assertions in the > future as being a distraction from the real issues > being discussed. > > .... > > where the buyer is already displaying his need with his > > dollars. > > "need" is not the same as "want" (see the > $10K red button app that was offered for > awhile; can anyone explain why anyone > would "need" it). And while some may > exchange money for only "want"s, those > that can demonstrate "need" can get those > transfers approved today and have the > registry updated today. Only the "wants" > are having a hard time. And, in my opinion, > that is as it should be. > _______________________________________________ > 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 drc at virtualized.org Thu Jun 12 07:50:34 2014 From: drc at virtualized.org (David Conrad) Date: Thu, 12 Jun 2014 07:50:34 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> Message-ID: <3188AABF-7D5F-4BBA-A8C9-AAA609B4A136@virtualized.org> Gary and Bill, On Jun 12, 2014, at 6:37 AM, Bill Darte wrote: > Gary said... >> "need" is not the same as "want" (see the >> $10K red button app that was offered for >> awhile; can anyone explain why anyone >> would "need" it). And while some may >> exchange money for only "want"s, those >> that can demonstrate "need" can get those >> transfers approved today and have the >> registry updated today. Only the "wants" >> are having a hard time. And, in my opinion, >> that is as it should be. > > big +1 While I consider the angst associated with speculators (or whoever) buying up all the address space overblown (hint: it would merely shorten the already short time horizon of when IPv4 addresses are no longer practically available), the issue I'm most concerned with is "and have the registry updated today." I do not believe given sufficient "want" and money that the lack of updating the registry would sufficient deterrent to preclude a "transfer" from occurring. The end result being that the address space is no longer traceable after the transfer. Use of the registry database for policy enforcement is not supportive of the primary reason for the existence of the registry system (there is a reason it's called a "registry"). It is also self-defeating. Get enough folks doing "transfers" outside of registry database and the database is no longer meaningful. I would have no issue with using other tools at ARIN's disposal for policy enforcement, e.g., removing reverse delegations, marking entries in the database as "out of policy" and letting ISPs decide for themselves whether to accept a prefix for routing, invoking contractual penalties, etc. Regards, -drc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From owen at delong.com Thu Jun 12 08:54:02 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Jun 2014 05:54:02 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <53976D0E.50509@velea.eu><5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> Message-ID: <90676DEE-D76E-4666-999E-6FDDFB3F18C1@delong.com> > > Hi Matthew, > > It would be simple to see that somebody is buying up IPv4 addresses and the price would rise accordingly, thwarting his plans. > Anybody engaged in that behavior would have to first find the sellers, a considerable problem, and impossible to do silently. > Then he would have to do hundreds and hundreds of transactions, which would take a long time and everybody would see it in the public transfer lists posted by the RIRs. Why? Why couldn?t the transactions all be completed before the first one is filed with an RIR? After all, if you?re willing to circumvent policy to the extent mentioned by David in his other messages, surely it is trivial to make those purchase agreements in such a way that the transaction is finalized well ahead of a coordinated notification to the RIR(s). > Worldwide there have been less than 1500 transfers. No RIR is completely out of IPv4 yet, either. > My rough number is about 24 million total addresses have been bought or sold since 2010, leaving out intra-company transfers. The point being? > You seem to think there is somebody, somewhere you can tap on the shoulder and offer a couple of billion and he can transfer hundreds of millions of addresses to you. Without the needs test, you can be sure every transfer will be booked and visible, unlike those transfers driven underground by the needs test. That visibility, and innate seller fragmentation, is our protection against this kind of scheme. How can we be sure of that? What assurance do we have that this is the case? What assurance can you offer that they will be made visible immediately? Really, there is no such assurance and pretending that there is strikes me as very questionable. > IMO, the mobile phone operators are not going to invest and risk billions of dollars on a reputationally dangerous ploy like this. Instead they simply appropriate some DoD space and run CGN. Or they could turn on IPv6, which is not ?hard? but which is fruitless in today?s Internet. I agree? I don?t think it is the mobile operators who are most likely to be the problem here. Most of them are actually showing pretty strong support for IPv6 (AT&T and SPRINT notwithstanding). Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jun 12 09:23:55 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Jun 2014 06:23:55 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <68DBABB50DB7469A837BE66C8985FB80@MPC> References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> <68DBABB50DB7469A837BE66C8985FB80@MPC> Message-ID: On Jun 11, 2014, at 1:10 PM, Mike Burns wrote: > Never claimed they were. However, Steven stated > that even one transfer not being recorded in the > database was unacceptable. We now learn that > accuracy is not actually a fundamental principal. > > I will choose to dismiss such assertions in the > future as being a distraction from the real issues > being discussed. > > Gary > > Hi Gary, > > Accuracy is indeed a fundamental principle of our stewardship, and an argument in support of 2014-14. Except that you have offered nothing but conjecture to support the idea that 2014-14 will somehow improve accuracy. You continue to claim the existence of an unknown number of zombie registrants, but even if we take that as a given, you?ve given nothing to prove that these zombies would somehow magically step forward and register if the needs test were removed. There are all kinds of reasons people may not record transfers that go far beyond the issue of the needs test. Owen From owen at delong.com Thu Jun 12 09:30:53 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Jun 2014 06:30:53 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <7D51B0FD40554C4E9DE275DEA58B8B8B@MPC> <679948D066BC47828F0648291A9886E7@ncsscfoipoxes4> <469A588F-3A36-4FDB-8A81-59ECD4F4F722@delong.com> Message-ID: On Jun 11, 2014, at 1:36 PM, Brandon Ross wrote: > On Wed, 11 Jun 2014, Matthew Petach wrote: > >> I cannot absolutely prevent you from stealing my furniture >> if you so desire. However, that doesn't mean I'm not going >> to put a lock on my front door to at least make it harder for >> you, and make it patently clear that you're doing so against >> my express desires. > > As has been mentioned here before, stealing furnature is a criminal offence, writing a contract giving exclusive rights to address space is not. That's a pretty crucial difference. If breaking and entering and stealing furnature were legal, the small help of a lock on my porch screen door would make little difference to a "bad actor". Locks keep honest people honest, but if an activity is not widely agreed to be immoral, locks won't help. This is a distinction without a difference. The fact that IP number policy does not have the force of government regulation doesn?t change the fact that circumventing community adopted policy for your own greed is tantamount to stealing someone?s furniture. Arguing that because policy doesn?t carry the force of law, we shouldn?t have policy is not, IMHO, what you want to do here. That basically serves as a request for real regulators to come in and develop number resource regulation in place of our lack of policy. At its core, the internet is built on cooperation among the various entities connecting to the network. That cooperation is governed by rules built through a community consensus process. While I agree the process isn?t perfect, I would argue that it has worked far better than any legislative processes I have observed and that we probably prefer to keep it. >> I'll ask plainly; for everyone voting for needs-free >> transfers; would you still vote that way, *if in doing >> so, you were guaranteed to not be able to obtain >> any number resources under the new policy*? > > I don't have any address resources now, and I don't ever plan on having any in the future, so sure, why not? > >> If not, I would claim your votes are not guided by >> the good of the community; they're guided by >> self-interest, and a hope and desire that you can >> get something for less effort than you can by following >> the current guidelines. > > Oh really? I think he was more talking about Mike B. and Steven R., than you, Brandon. > Much like Owen, I have a nice little business of helping small organizations navigate the ARIN process to get address space. It's not a majority of my income, but it's pretty nice and easy work for me. If needs basis goes away, guess what else goes away? > > Even though Owen and I are on opposite sides of this coversation, I can guarantee you right now that both of us, without fail, are arguing solely for what we think is best for the community. > > It's quite ironic that I would make more money by arguing on your side of the issue, isn't it? > > Or maybe my conspiracy is to get v4 to run out faster so I can make more money on v6 deployment? It could be. I?m OK with that. ;-) Owen From mike at iptrading.com Thu Jun 12 09:38:45 2014 From: mike at iptrading.com (Mike Burns) Date: Thu, 12 Jun 2014 09:38:45 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <90676DEE-D76E-4666-999E-6FDDFB3F18C1@delong.com> References: <53976D0E.50509@velea.eu><5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> <90676DEE-D76E-4666-999E-6FDDFB3F18C1@delong.com> Message-ID: <53AF0CBCE6D2402C903B4CBD0407ED48@MPC> You seem to think there is somebody, somewhere you can tap on the shoulder and offer a couple of billion and he can transfer hundreds of millions of addresses to you. Without the needs test, you can be sure every transfer will be booked and visible, unlike those transfers driven underground by the needs test. That visibility, and innate seller fragmentation, is our protection against this kind of scheme. How can we be sure of that? What assurance do we have that this is the case? What assurance can you offer that they will be made visible immediately? Really, there is no such assurance and pretending that there is strikes me as very questionable. Hi Owen, By policy, all the RIRs that allow transfers mandate the publishing of that information. So we know every block that was transferred in Whois. And by decades-long processes, address distribution has been fragmented, with owners of large and small blocks scattered around the globe. I suggest that it would be impossible to dragoon enough sellers into a silent coalition bent on market manipulation to effect such. And who wants to pay large amounts of money for an asset and not have the ownership booked in the authoritative database? It is a normal business incentive to do this, but sometimes the needs-test requirement precludes it, and poof! turns good companies into bad actors. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Thu Jun 12 09:51:54 2014 From: jcurran at arin.net (John Curran) Date: Thu, 12 Jun 2014 13:51:54 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> <68DBABB50DB7469A837BE66C8985FB80@MPC> Message-ID: On Jun 12, 2014, at 9:23 AM, Owen DeLong wrote: > You continue to claim the existence of an unknown number of zombie registrants, but even if we take that as a given, you?ve given nothing to prove that these zombies would somehow magically step forward and register if the needs test were removed. There are all kinds of reasons people may not record transfers that go far beyond the issue of the needs test. Correct. A major operational network may not like the current 24-month needs-test because of the lack of long-term certainty for access to IPv4 address space that results, but that discomfort can be addressed by finding a supplier and locking up options for access to number resources in the future access if so desired. They also have, one could imagine, the potential of bypassing the registry completely, but that comes with some significant risk of trying to enforce those theoretically obtained rights if the registrant changes their story later (or turns out not to be the proper rights holder from the beginning, since one did not actually go to the registry and have the asserted address holder validated.) From what I can tell, the vast majority of operational network has preferred to work within the community policy, even those for whom the current needs-based qualification in policy is problematic. This is not the case with those who are not operating networks and only wish to use the IP addresses for very short-term (e.g. until the IP block reputation is ruined), in these cases, they don't intend to be using the address blocks over the long-term; removing the needs-assessment hurdle may not meaningfully change their desire to update the registration info FYI, /John John Curran President and CEO ARIN From mike at iptrading.com Thu Jun 12 10:05:58 2014 From: mike at iptrading.com (Mike Burns) Date: Thu, 12 Jun 2014 10:05:58 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-network s.com><5B9 E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com><68DBABB50 DB7469A837BE66C8985FB80@MPC> Message-ID: <8C5582100E044BA891F0C445C9BF466A@MPC> -----Original Message----- From: John Curran Sent: Thursday, June 12, 2014 9:51 AM To: Owen DeLong Cc: Mike Burns ; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Jun 12, 2014, at 9:23 AM, Owen DeLong wrote: > You continue to claim the existence of an unknown number of zombie > registrants, but even if we take that as a given, you?ve given nothing to > prove that these zombies would somehow magically step forward and register > if the needs test were removed. There are all kinds of reasons people may > not record transfers that go far beyond the issue of the needs test. Correct. A major operational network may not like the current 24-month needs-test because of the lack of long-term certainty for access to IPv4 address space that results, but that discomfort can be addressed by finding a supplier and locking up options for access to number resources in the future access if so desired. They also have, one could imagine, the potential of bypassing the registry completely, but that comes with some significant risk of trying to enforce those theoretically obtained rights if the registrant changes their story later (or turns out not to be the proper rights holder from the beginning, since one did not actually go to the registry and have the asserted address holder validated.) From what I can tell, the vast majority of operational network has preferred to work within the community policy, even those for whom the current needs-based qualification in policy is problematic. This is not the case with those who are not operating networks and only wish to use the IP addresses for very short-term (e.g. until the IP block reputation is ruined), in these cases, they don't intend to be using the address blocks over the long-term; removing the needs-assessment hurdle may not meaningfully change their desire to update the registration info FYI, /John Hi John, What you are saying is that zombie corporations are real, and are a legal and policy-compliant option for those who don't like the needs test. You are also saying that corporations who don't like the needs test are also purchasing options on the IP address holdings of other companies, effectively controlling those addresses although not having them registered. Would you also say that corporations which go this option route, and corporations which purchase zombie companies would actually prefer to be the listed registrants? In my experience they would prefer this. Excepting spammers, who usually lease, not purchase, space for obvious reasons, and who have no part in this conversation. Regards, Mike From jcurran at arin.net Thu Jun 12 10:38:59 2014 From: jcurran at arin.net (John Curran) Date: Thu, 12 Jun 2014 14:38:59 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <8C5582100E044BA891F0C445C9BF466A@MPC> References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-network s.com><5B9 E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com><68DBABB50 DB7469A837BE66C8985FB80@MPC> <8C5582100E044BA891F0C445C9BF466A@MPC> Message-ID: <9A0634A6-38EE-44A2-966E-AEA59B71101D@arin.net> On Jun 12, 2014, at 10:05 AM, Mike Burns wrote: > What you are saying is that zombie corporations are real, and are a legal and policy-compliant option for those who don't like the needs test. No, not at all. What I am saying is that we have seen address blocks hijacked by organizations (or routed via false LOA) which are only going to use the address space for a short-period. > You are also saying that corporations who don't like the needs test are also purchasing options on the IP address holdings of other companies, effectively controlling those addresses although not having them registered. Are you suggesting that ARIN should become involved in a private contract between two organizations that doesn't involve transfer of the registration of an address block, but only future potential of same? I can enter into an agreement with you that you will not sell a book (or your car, or your laptop) to another party within first coming to me; that is likely to be seen as valid contractual agreement that does not involve any other parties. > Would you also say that corporations which go this option route, and corporations which purchase zombie companies would actually prefer to be the listed registrants? In my experience they would prefer this. I have no idea; you would expect that they'd perform a transfer in accordance with community policy if they preferred that route. > Excepting spammers, who usually lease, not purchase, space for obvious reasons, Exactly to Owen's point... there are parties which do not desire accurate registration for their own reasons, and these parties are quite willing to permanently transfer address space if it meets their needs. > and who have no part in this conversation. That is correct only to the extent that there is not a high overlap between those who wish to bypass the community policy and those who wish to operate various spam & botnet services. I imagine there are parties that want to interconnect with the other service providers for legitimate business but still not follow their policies, but such disingenuous behavior is frequently shown by those abuse the network. FYI, /John John Curran President and CEO ARIN From owen at delong.com Thu Jun 12 10:57:35 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Jun 2014 07:57:35 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <53AF0CBCE6D2402C903B4CBD0407ED48@MPC> References: <53976D0E.50509@velea.eu><5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> <90676DEE-D76E-4666-999E-6FDDFB3F18C1@delong.com> <53AF0CBCE6D2402C903B4CBD0407ED48@MPC> Message-ID: <9894E661-1A66-478B-BAE1-BEFA5684AE5A@delong.com> On Jun 12, 2014, at 6:38 AM, Mike Burns wrote: > You seem to think there is somebody, somewhere you can tap on the shoulder and offer a couple of billion and he can transfer hundreds of millions of addresses to you. Without the needs test, you can be sure every transfer will be booked and visible, unlike those transfers driven underground by the needs test. That visibility, and innate seller fragmentation, is our protection against this kind of scheme. > > How can we be sure of that? What assurance do we have that this is the case? What assurance can you offer that they will be made visible immediately? > > Really, there is no such assurance and pretending that there is strikes me as very questionable. > > > > Hi Owen, > > By policy, all the RIRs that allow transfers mandate the publishing of that information. So we know every block that was transferred in Whois. Yes? But what assurance do we have that removal of needs basis would somehow magically get more of these transfers recorded in whois? > And by decades-long processes, address distribution has been fragmented, with owners of large and small blocks scattered around the globe. > I suggest that it would be impossible to dragoon enough sellers into a silent coalition bent on market manipulation to effect such. Why? You think that offering someone lots of money for a transaction and asking them to work with you on the recording date of the transaction with the RIR is difficult? I don?t. I don?t think it would be hard at all. > And who wants to pay large amounts of money for an asset and not have the ownership booked in the authoritative database? It is a normal business incentive to do this, but sometimes the needs-test requirement precludes it, and poof! turns good companies into bad actors. Someone who doesn?t want their actions publicly known for a variety of reasons. This happens all the time with hostile takeovers as was previously noted. The needs test does not turn good companies into bad actors. Good companies that actually need the address space and conform to policy have no trouble getting their transfers recorded. Changing the definition of bad actors can, indeed, make a bunch of bad actors now fit the reformed definition of ?good companies?, but similarly, repealing laws against bank robbers would then make bank robbers no longer defined as criminals. I find this rather tautological argument very unpersuasive. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Thu Jun 12 11:07:38 2014 From: jcurran at arin.net (John Curran) Date: Thu, 12 Jun 2014 15:07:38 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <9894E661-1A66-478B-BAE1-BEFA5684AE5A@delong.com> References: <53976D0E.50509@velea.eu><5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> <90676DEE-D76E-4666-999E-6FDDFB3F18C1@delong.com> <53AF0CBCE6D2402C903B4CBD0407ED48@MPC> <9894E661-1A66-478B-BAE1-BEFA5684AE5A@delong.com> Message-ID: <73F55572-37A4-4A5F-AB18-45020C9B2745@corp.arin.net> On Jun 12, 2014, at 10:57 AM, Owen DeLong > wrote: Changing the definition of bad actors can, indeed, make a bunch of bad actors now fit the reformed definition of ?good companies?, but similarly, repealing laws against bank robbers would then make bank robbers no longer defined as criminals. Owen - Let's save use of the term "criminal" for those actually violating public laws; the phrase "bad actors" applies quite well to those who violate community expectations, whether that be address policy, handling unsolicited bulk emailers, route deaggregators, etc. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Thu Jun 12 11:09:11 2014 From: mike at iptrading.com (Mike Burns) Date: Thu, 12 Jun 2014 11:09:11 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <9A0634A6-38EE-44A2-966E-AEA59B71101D@arin.net> References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-network s.com><5B9 E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com><68DBABB50 DB7469A837BE66C8985FB80@MPC> <8C5582100E044BA891F0C445C9BF466A@MPC> <9A0634A6-38EE-44A2-966E-AEA59B71101D@arin.net> Message-ID: <467A896F9FD142BA952AC5B5167D8C35@MPC> Hi John, It seems like you are trying to conflate spammers and botnets with companies who wish to avoid registration simply because of the needs policy. We can all agree that spammers and botnets do not seek registration for reasons other than the needs test, no policy proposal is directed at that issue. To your point about buying IP address options which are opaque to Whois, my answer is that this is only happening due to the needs test. Same thing with zombie corporations, the existence of which are driven by the needs test. Spammers don't buy zombie corporations, because they know they will damage the only asset. Instead they hijack or lease, two completely separate issues, neither of which is addressed by a current policy proposal. Regards, Mike -----Original Message----- From: John Curran Sent: Thursday, June 12, 2014 10:38 AM To: Mike Burns Cc: Owen DeLong ; arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Jun 12, 2014, at 10:05 AM, Mike Burns wrote: > What you are saying is that zombie corporations are real, and are a legal > and policy-compliant option for those who don't like the needs test. No, not at all. What I am saying is that we have seen address blocks hijacked by organizations (or routed via false LOA) which are only going to use the address space for a short-period. > You are also saying that corporations who don't like the needs test are > also purchasing options on the IP address holdings of other companies, > effectively controlling those addresses although not having them > registered. Are you suggesting that ARIN should become involved in a private contract between two organizations that doesn't involve transfer of the registration of an address block, but only future potential of same? I can enter into an agreement with you that you will not sell a book (or your car, or your laptop) to another party within first coming to me; that is likely to be seen as valid contractual agreement that does not involve any other parties. > Would you also say that corporations which go this option route, and > corporations which purchase zombie companies would actually prefer to be > the listed registrants? In my experience they would prefer this. I have no idea; you would expect that they'd perform a transfer in accordance with community policy if they preferred that route. > Excepting spammers, who usually lease, not purchase, space for obvious > reasons, Exactly to Owen's point... there are parties which do not desire accurate registration for their own reasons, and these parties are quite willing to permanently transfer address space if it meets their needs. > and who have no part in this conversation. That is correct only to the extent that there is not a high overlap between those who wish to bypass the community policy and those who wish to operate various spam & botnet services. I imagine there are parties that want to interconnect with the other service providers for legitimate business but still not follow their policies, but such disingenuous behavior is frequently shown by those abuse the network. FYI, /John John Curran President and CEO ARIN = From jcurran at arin.net Thu Jun 12 11:22:44 2014 From: jcurran at arin.net (John Curran) Date: Thu, 12 Jun 2014 15:22:44 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <467A896F9FD142BA952AC5B5167D8C35@MPC> References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-network s.com><5B9 E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com><68DBABB50 DB7469A837BE66C8985FB80@MPC> <8C5582100E044BA891F0C445C9BF466A@MPC> <9A0634A6-38EE-44A2-966E-AEA59B71101D@arin.net> <467A896F9FD142BA952AC5B5167D8C35@MPC> Message-ID: <35E5D5FF-458A-46BD-B696-8D596D82C831@arin.net> On Jun 12, 2014, at 11:09 AM, Mike Burns wrote: > ... > Same thing with zombie corporations, the existence of which are driven by the needs test. Spammers don't buy zombie corporations, because they know they will damage the only asset. Instead they hijack or lease, two completely separate issues, neither of which is addressed by a current policy proposal. Mike - You assert that spammers don't buy zombie corporations, but it comes down to simple economics, and the availability of a large clean address block can easily generate enough revenue over its short-lifespan to make it worth purchasing. Remember, we already see quite a bit of investment going on to enable successful hijacking, including shell companies, law firms, storefronts, etc.; my point is only that the needs-based test does raise the bar for some who would otherwise go the market but have no intent of following community expectations... The reason they want resources to be registered in their asserted name is because its makes it faster to put in use and slower to block when abused. FYI, /John John Curran President and CEO ARIN From mike at iptrading.com Thu Jun 12 11:26:21 2014 From: mike at iptrading.com (Mike Burns) Date: Thu, 12 Jun 2014 11:26:21 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <9894E661-1A66-478B-BAE1-BEFA5684AE5A@delong.com> References: <53976D0E.50509@velea.eu><5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> <90676DEE-D76E-4666-999E-6FDDFB3F18C1@delong.com> <53AF0CBCE6D2402C903B4CBD0407ED48@MPC> <9894E661-1A66-478B-BAE1-BEFA5684AE5A@delong.com> Message-ID: <7B21A564414B4CF6A0CB510A2455D49F@MPC> Yes? But what assurance do we have that removal of needs basis would somehow magically get more of these transfers recorded in whois? Owen, I am not appealing to magic. I am applying basic business logic that I think most people on the list understand. If you buy a real estate, you generally want the deed published. Sure there are some who don?t, for one reason or another, but the vast majority do want their ownership registered in the authoritative list. You think that offering someone lots of money for a transaction and asking them to work with you on the recording date of the transaction with the RIR is difficult? I don?t. I don?t think it would be hard at all. Owen, there is no ?someone?. There are tens of thousands of address rights owners, with a constantly fluctuating amount of underutilized space which might be for sale. From the perspective of one who is actively seeking out sellers, the idea that you could not only find enough of them, but organize them silently towards a massive single transactional event is laughable. Most of the large holders are unsuprisingly large organizations. Getting them to march together in this way for this purpose is inconceivable. But we can agree to disagree on this likelihood while understanding that limiting needs-free transfers to one small amount per year like a /20 would preclude this eventuality. Someone who doesn?t want their actions publicly known for a variety of reasons. This happens all the time with hostile takeovers as was previously noted. Owen, nobody is denying that there are other reasons why people avoid registration. No proposal on the table seeks to address those issues. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Thu Jun 12 12:16:47 2014 From: jcurran at arin.net (John Curran) Date: Thu, 12 Jun 2014 16:16:47 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <7B21A564414B4CF6A0CB510A2455D49F@MPC> References: <53976D0E.50509@velea.eu><5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> <90676DEE-D76E-4666-999E-6FDDFB3F18C1@delong.com> <53AF0CBCE6D2402C903B4CBD0407ED48@MPC> <9894E661-1A66-478B-BAE1-BEFA5684AE5A@delong.com> <7B21A564414B4CF6A0CB510A2455D49F@MPC> Message-ID: On Jun 12, 2014, at 11:26 AM, Mike Burns > wrote: Owen, there is no ?someone?. There are tens of thousands of address rights owners, with a constantly fluctuating amount of underutilized space which might be for sale. Mike - As someone actively seeking them out, perhaps you could organize a few of them to undertake a simpler (but quite worthwhile) activity? Specifically, the task of participating remotely in the next ARIN public policy consultation and showing support for those policy changes that reflect their perspective? Tens of thousands is not necessary; even a few dozen that cared enough to participate could likely significantly change the outcome of the policy development process. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From billdarte at gmail.com Thu Jun 12 12:32:56 2014 From: billdarte at gmail.com (Bill Darte) Date: Thu, 12 Jun 2014 11:32:56 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <3188AABF-7D5F-4BBA-A8C9-AAA609B4A136@virtualized.org> References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> <3188AABF-7D5F-4BBA-A8C9-AAA609B4A136@virtualized.org> Message-ID: David said: "Use of the registry database for policy enforcement is not supportive of the primary reason for the existence of the registry system (there is a reason it's called a "registry"). It is also self-defeating. Get enough folks doing "transfers" outside of registry database and the database is no longer meaningful." Yup, I suppose....and I guess it's no fault blaming those individuals who do not heed the community's standards by going outside of policy....no, let's consider ARIN to be at fault for responding to community consensus. I know that what this back and forth is about....policy discussion and development....to see whether the community has had a see change...but what I see is that a few people who want it their way...continue to flame the status quo for maintaining its focus...to my mind...where it still should be. Scare resource? Given them to people who NEED them. If the community should be outrage about something, it should be those who contribute to the weakness of he database, not those who's stewardship has not failed. bd On Thu, Jun 12, 2014 at 6:50 AM, David Conrad wrote: > Gary and Bill, > > On Jun 12, 2014, at 6:37 AM, Bill Darte wrote: > > Gary said... > > "need" is not the same as "want" (see the > $10K red button app that was offered for > awhile; can anyone explain why anyone > would "need" it). And while some may > exchange money for only "want"s, those > that can demonstrate "need" can get those > transfers approved today and have the > registry updated today. Only the "wants" > are having a hard time. And, in my opinion, > that is as it should be. > > > big +1 > > > While I consider the angst associated with speculators (or whoever) buying > up all the address space overblown (hint: it would merely shorten the > already short time horizon of when IPv4 addresses are no longer practically > available), the issue I'm most concerned with is "and have the registry > updated today." > > I do not believe given sufficient "want" and money that the lack of > updating the registry would sufficient deterrent to preclude a "transfer" > from occurring. The end result being that the address space is no longer > traceable after the transfer. > > Use of the registry database for policy enforcement is not supportive of > the primary reason for the existence of the registry system (there is a > reason it's called a "registry"). It is also self-defeating. Get enough > folks doing "transfers" outside of registry database and the database is no > longer meaningful. > > I would have no issue with using other tools at ARIN's disposal for policy > enforcement, e.g., removing reverse delegations, marking entries in the > database as "out of policy" and letting ISPs decide for themselves whether > to accept a prefix for routing, invoking contractual penalties, etc. > > Regards, > -drc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Thu Jun 12 12:46:20 2014 From: mike at iptrading.com (Mike Burns) Date: Thu, 12 Jun 2014 12:46:20 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <53976D0E.50509@velea.eu><5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> <90676DEE-D76E-4666-999E-6FDDFB3F18C1@delong.com> <53AF0CBCE6D2402C903B4CBD0407ED48@MPC> <9894E661-1A66-478B-BAE1-BEFA5684AE5A@delong.com> <7B21A564414B4CF6A0CB510A2455D49F@MPC> Message-ID: <3217EBC60EB94228B1E07EEFD41AEC8F@MPC> Mike - As someone actively seeking them out, perhaps you could organize a few of them to undertake a simpler (but quite worthwhile) activity? Specifically, the task of participating remotely in the next ARIN public policy consultation and showing support for those policy changes that reflect their perspective? Tens of thousands is not necessary; even a few dozen that cared enough to participate could likely significantly change the outcome of the policy development process. Thanks! /John John Curran President and CEO ARIN Hi John, Early on in my list participation I considered the option of actively soliciting like-minded participants to post to the list. I probably could post to Reason magazine or some other libertarian venue. But I didn?t feel comfortable doing that. However, what you are suggesting is something different, and I have recently begun to solicit such support in a gentle way on my website. Believe it or not there is a lot of fear of ARIN and many who are most affected by the needs-test barrier to transfer are looking to make whatever deal works for them. You can understand why they don?t want their visibility raised by posting support for removing needs transfers in a venue so assiduously monitored by ARIN?s CEO! Also I often have problems with remote participation, I am jabber-ignorant and usually have issues with that. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wlEmoticon-winkingsmile[1].png Type: image/png Size: 1135 bytes Desc: not available URL: From owen at delong.com Thu Jun 12 13:06:21 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Jun 2014 10:06:21 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <7B21A564414B4CF6A0CB510A2455D49F@MPC> References: <53976D0E.50509@velea.eu><5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com> <90676DEE-D76E-4666-999E-6FDDFB3F18C1@delong.com> <53AF0CBCE6D2402C903B4CBD0407ED48@MPC> <9894E661-1A66-478B-BAE1-BEFA5684AE5A@delong.com> <7B21A564414B4CF6A0CB510A2455D49F@MPC> Message-ID: On Jun 12, 2014, at 8:26 AM, Mike Burns wrote: > > Yes? But what assurance do we have that removal of needs basis would somehow magically get more of these transfers recorded in whois? > > Owen, I am not appealing to magic. I am applying basic business logic that I think most people on the list understand. If you buy a real estate, you generally want the deed published. Sure there are some who don?t, for one reason or another, but the vast majority do want their ownership registered in the authoritative list. But IP addresses are not real estate and many of the concerns expressed look much more like the trading of stock in a hostile takeover. In those transactions, there are, basic business logic reasons to hide the transaction(s) for some time and register them at a later date. Timing can be important. You are making multiple assertions. Bottom line, yes, the people you are considering in your proposal are likely to register their transfers absent needs test. What you continue to refuse to acknowledge is that they are not a complete set of those who would transfer address space and many of the others may or may not register. I argue that the ones you are describing also represent a tiny fraction of the improperly or unregistered utilization out there today, so therefore your proposal does not really solve a (significant) problem, but creates many more. > > > You think that offering someone lots of money for a transaction and asking them to work with you on the recording date of the transaction with the RIR is difficult? I don?t. I don?t think it would be hard at all. > > Owen, there is no ?someone?. There are tens of thousands of address rights owners, with a constantly fluctuating amount of underutilized space which might be for sale. From the perspective of one who is actively seeking out sellers, the idea that you could not only find enough of them, but organize them silently towards a massive single transactional event is laughable. Most of the large holders are unsuprisingly large organizations. Getting them to march together in this way for this purpose is inconceivable. But we can agree to disagree on this likelihood while understanding that limiting needs-free transfers to one small amount per year like a /20 would preclude this eventuality. If offering someone that deal will succeed, then offering several someones that same deal is also likely to succeed. You don?t have to organize them, all you have to do is get them to agree to let you take care of the registration process at a later unspecified date and not to disclose the transaction until then. The idea that this is difficult is what is absurd. > > > > Someone who doesn?t want their actions publicly known for a variety of reasons. This happens all the time with hostile takeovers as was previously noted. > > > Owen, nobody is denying that there are other reasons why people avoid registration. No proposal on the table seeks to address those issues. Correct. However, you continuously state that this proposal is a panacea for the inaccuracies in whois, so I will continue to point out that this is not, in fact, true. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Thu Jun 12 13:14:32 2014 From: mike at iptrading.com (Mike Burns) Date: Thu, 12 Jun 2014 13:14:32 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com><3188AABF-7D5F-4BBA-A8C9-AAA609B4A136@virtualized.org> Message-ID: "Use of the registry database for policy enforcement is not supportive of the primary reason for the existence of the registry system (there is a reason it's called a "registry"). It is also self-defeating. Get enough folks doing "transfers" outside of registry database and the database is no longer meaningful." Yup, I suppose....and I guess it's no fault blaming those individuals who do not heed the community's standards by going outside of policy....no, let's consider ARIN to be at fault for responding to community consensus. Hi Bill, We consider ARIN policy to be at fault and are seeking community consensus to change that policy, Do you have a problem with that approach? I know that what this back and forth is about....policy discussion and development....to see whether the community has had a see change...but what I see is that a few people who want it their way...continue to flame the status quo for maintaining its focus...to my mind...where it still should be. Scare resource? Given them to people who NEED them. If the community should be outrage about something, it should be those who contribute to the weakness of he database, not those who's stewardship has not failed. bd Bill, nobody is *giving* addresses to anybody, regardless of their NEEDS, so you can disabuse yourself of that pie-eyed notion. And what is flaming the status quo? Way to encourage participation. I suppose it?s better to leave the community in their repose of silent focus. Let?s cut out the stewardship failed nonsense, you are accusing both RIPE and APNIC communities of failed stewardship because their opinion doesn?t match your personal one. Regards, Mike On Thu, Jun 12, 2014 at 6:50 AM, David Conrad wrote: Gary and Bill, On Jun 12, 2014, at 6:37 AM, Bill Darte wrote: Gary said... "need" is not the same as "want" (see the $10K red button app that was offered for awhile; can anyone explain why anyone would "need" it). And while some may exchange money for only "want"s, those that can demonstrate "need" can get those transfers approved today and have the registry updated today. Only the "wants" are having a hard time. And, in my opinion, that is as it should be. big +1 While I consider the angst associated with speculators (or whoever) buying up all the address space overblown (hint: it would merely shorten the already short time horizon of when IPv4 addresses are no longer practically available), the issue I'm most concerned with is "and have the registry updated today." I do not believe given sufficient "want" and money that the lack of updating the registry would sufficient deterrent to preclude a "transfer" from occurring. The end result being that the address space is no longer traceable after the transfer. Use of the registry database for policy enforcement is not supportive of the primary reason for the existence of the registry system (there is a reason it's called a "registry"). It is also self-defeating. Get enough folks doing "transfers" outside of registry database and the database is no longer meaningful. I would have no issue with using other tools at ARIN's disposal for policy enforcement, e.g., removing reverse delegations, marking entries in the database as "out of policy" and letting ISPs decide for themselves whether to accept a prefix for routing, invoking contractual penalties, etc. Regards, -drc -------------------------------------------------------------------------------- _______________________________________________ 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 billdarte at gmail.com Thu Jun 12 14:43:12 2014 From: billdarte at gmail.com (Bill Darte) Date: Thu, 12 Jun 2014 13:43:12 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> <3188AABF-7D5F-4BBA-A8C9-AAA609B4A136@virtualized.org> Message-ID: Hi Bill, We consider ARIN policy to be at fault and are seeking community consensus to change that policy, Do you have a problem with that approach? ----Of course you do and did I not grant in my post that this back and forth WAS the policy development process engaged? I have supported that process for many years and believe it IS the way things must be done. And, I understand that you are seeking community consensus in that discussion....I just note that there seems to be little support to change the policy in the ARIN region. I know that what this back and forth is about....policy discussion and development....to see whether the community has had a see change...but what I see is that a few people who want it their way...continue to flame the status quo for maintaining its focus...to my mind...where it still should be. Scare resource? Given them to people who NEED them. If the community should be outrage about something, it should be those who contribute to the weakness of he database, not those who's stewardship has not failed. bd Bill, nobody is *giving* addresses to anybody, regardless of their NEEDS, so you can disabuse yourself of that pie-eyed notion. And what is flaming the status quo? Way to encourage participation. I suppose it?s better to leave the community in their repose of silent focus. --- you are correct, nobody gives addresses away. Needs-based allocation or transfer, I submit is likely to cost those receiving addresses less overall. Still, there is a financial burden either way. 'Repose of silent focus'. I daresay that the community has been quite vocal in their creation and support of the status quo. And as far as participation goes, I only wish that every constituent with the ARIN community would come out and have their say..one time...about this issue whichever way they choose. See, I'm for consensus either way because I do believe in the process. Let?s cut out the stewardship failed nonsense, you are accusing both RIPE and APNIC communities of failed stewardship because their opinion doesn?t match your personal one. --- notice that my comment was not about 'failed stewardship', but the lack thereof on ARIN's part....my belief that needs-based allocations are proper stewardship for ARIN in no way disparages the RIPE and APNIC communities for their policies. There are 5 RIRs so that the local community can decide for themselves what policies should exist in their respective communities. So please don't attribute those accusations to me. As I said above, I have my opinion, but it is the consensus of the community that counts. I'd hope that everyone feels the same. bd On Thu, Jun 12, 2014 at 12:14 PM, Mike Burns wrote: > > "Use of the registry database for policy enforcement is not supportive > of the primary reason for the existence of the registry system (there is a > reason it's called a "registry"). It is also self-defeating. Get enough > folks doing "transfers" outside of registry database and the database is no > longer meaningful." > > Yup, I suppose....and I guess it's no fault blaming those individuals who > do not heed the community's standards by going outside of policy....no, > let's consider ARIN to be at fault for responding to community consensus. > > Hi Bill, > We consider ARIN policy to be at fault and are seeking community consensus > to change that policy, Do you have a problem with that approach? > > > I know that what this back and forth is about....policy discussion and > development....to see whether the community has had a see change...but what > I see is that a few people who want it their way...continue to flame the > status quo for maintaining its focus...to my mind...where it still should > be. Scare resource? Given them to people who NEED them. If the community > should be outrage about something, it should be those who contribute to the > weakness of he database, not those who's stewardship has not failed. > > bd > > Bill, nobody is *giving* addresses to anybody, regardless of their NEEDS, > so you can disabuse yourself of that pie-eyed notion. And what is flaming > the status quo? Way to encourage participation. I suppose it?s better to > leave the community in their repose of silent focus. > > Let?s cut out the stewardship failed nonsense, you are accusing both RIPE > and APNIC communities of failed stewardship because their opinion doesn?t > match your personal one. > > Regards, > Mike > > > > > On Thu, Jun 12, 2014 at 6:50 AM, David Conrad wrote: > >> Gary and Bill, >> >> On Jun 12, 2014, at 6:37 AM, Bill Darte wrote: >> >> Gary said... >> >> "need" is not the same as "want" (see the >> $10K red button app that was offered for >> awhile; can anyone explain why anyone >> would "need" it). And while some may >> exchange money for only "want"s, those >> that can demonstrate "need" can get those >> transfers approved today and have the >> registry updated today. Only the "wants" >> are having a hard time. And, in my opinion, >> that is as it should be. >> >> >> big +1 >> >> >> While I consider the angst associated with speculators (or whoever) >> buying up all the address space overblown (hint: it would merely shorten >> the already short time horizon of when IPv4 addresses are no longer >> practically available), the issue I'm most concerned with is "and have the >> registry updated today." >> >> I do not believe given sufficient "want" and money that the lack of >> updating the registry would sufficient deterrent to preclude a "transfer" >> from occurring. The end result being that the address space is no longer >> traceable after the transfer. >> >> Use of the registry database for policy enforcement is not supportive of >> the primary reason for the existence of the registry system (there is a >> reason it's called a "registry"). It is also self-defeating. Get enough >> folks doing "transfers" outside of registry database and the database is no >> longer meaningful. >> >> I would have no issue with using other tools at ARIN's disposal for >> policy enforcement, e.g., removing reverse delegations, marking entries in >> the database as "out of policy" and letting ISPs decide for themselves >> whether to accept a prefix for routing, invoking contractual penalties, >> etc. >> >> Regards, >> -drc >> >> > > > ------------------------------ > _______________________________________________ > 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 SRyerse at eclipse-networks.com Thu Jun 12 14:46:16 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 12 Jun 2014 18:46:16 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <7D51B0FD40554C4E9DE275DEA58B8B8B @MPC><679948D066BC47828F06 48291A9886E7@ncsscfoipoxes4><469A588F-3A36-4FDB-8A81-59EC D4F4F722@delong.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AB12DE2@ENI-MAIL.eclipse-networks.com> Owen, I would turn your argument around where you said " The fact that IP number policy does not have the force of government regulation doesn?t change the fact that circumventing community adopted policy for your own greed is tantamount to stealing someone?s furniture." I wouldn't use the word greed but I would say that denying real resources to real organizations now is stealing their future too! 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? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Thursday, June 12, 2014 9:31 AM To: Brandon Ross Cc: arin-ppml at arin.net List (arin-ppml at arin.net) Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Jun 11, 2014, at 1:36 PM, Brandon Ross wrote: > On Wed, 11 Jun 2014, Matthew Petach wrote: > >> I cannot absolutely prevent you from stealing my furniture if you so >> desire. However, that doesn't mean I'm not going to put a lock on my >> front door to at least make it harder for you, and make it patently >> clear that you're doing so against my express desires. > > As has been mentioned here before, stealing furnature is a criminal offence, writing a contract giving exclusive rights to address space is not. That's a pretty crucial difference. If breaking and entering and stealing furnature were legal, the small help of a lock on my porch screen door would make little difference to a "bad actor". Locks keep honest people honest, but if an activity is not widely agreed to be immoral, locks won't help. This is a distinction without a difference. The fact that IP number policy does not have the force of government regulation doesn?t change the fact that circumventing community adopted policy for your own greed is tantamount to stealing someone?s furniture. Arguing that because policy doesn?t carry the force of law, we shouldn?t have policy is not, IMHO, what you want to do here. That basically serves as a request for real regulators to come in and develop number resource regulation in place of our lack of policy. At its core, the internet is built on cooperation among the various entities connecting to the network. That cooperation is governed by rules built through a community consensus process. While I agree the process isn?t perfect, I would argue that it has worked far better than any legislative processes I have observed and that we probably prefer to keep it. >> I'll ask plainly; for everyone voting for needs-free transfers; would >> you still vote that way, *if in doing so, you were guaranteed to not >> be able to obtain any number resources under the new policy*? > > I don't have any address resources now, and I don't ever plan on having any in the future, so sure, why not? > >> If not, I would claim your votes are not guided by the good of the >> community; they're guided by self-interest, and a hope and desire >> that you can get something for less effort than you can by following >> the current guidelines. > > Oh really? I think he was more talking about Mike B. and Steven R., than you, Brandon. > Much like Owen, I have a nice little business of helping small organizations navigate the ARIN process to get address space. It's not a majority of my income, but it's pretty nice and easy work for me. If needs basis goes away, guess what else goes away? > > Even though Owen and I are on opposite sides of this coversation, I can guarantee you right now that both of us, without fail, are arguing solely for what we think is best for the community. > > It's quite ironic that I would make more money by arguing on your side of the issue, isn't it? > > Or maybe my conspiracy is to get v4 to run out faster so I can make more money on v6 deployment? It could be. I?m OK with that. ;-) Owen _______________________________________________ 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 michael at linuxmagic.com Thu Jun 12 14:50:09 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Thu, 12 Jun 2014 11:50:09 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB0EC21@ENI-MAIL.eclipse-networks.com> <3188AABF-7D5F-4BBA-A8C9-AAA609B4A136@virtualized.org> Message-ID: <5399F661.2010104@linuxmagic.com> On 14-06-12 11:43 AM, Bill Darte wrote: > ...continue to flame And I should point out, this thread has gone on too long with only a few individuals chiming in.. Too many messages and people start ignoring the conversation, and it was pointed out that not enough people are on this list, if the volume gets too high on a back and forth.. people will unsubscribe, and the list will have even less people. Points of view have been made, arguments for and against should be kept to a minimum I think.. or some other medium used for that.. Just my 2cents.. (Almost missed draft policy postings in all the noise) -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From billdarte at gmail.com Thu Jun 12 14:53:07 2014 From: billdarte at gmail.com (Bill Darte) Date: Thu, 12 Jun 2014 13:53:07 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AB12DE2@ENI-MAIL.eclipse-networks.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB12DE2@ENI-MAIL.eclipse-networks.com> Message-ID: Steven said.... "Owen, I would turn your argument around where you said " The fact that IP number policy does not have the force of government regulation doesn?t change the fact that circumventing community adopted policy for your own greed is tantamount to stealing someone?s furniture." I wouldn't use the word greed but I would say that denying real resources to real organizations now is stealing their future too!" --- I think denying real resources to real organizations now...that cannot comply with current policy...is not stealing their future...it is bringing their future in line with current policy....can't see theft in that.... bd On Thu, Jun 12, 2014 at 1:46 PM, Steven Ryerse wrote: > Owen, I would turn your argument around where you said " The fact that IP > number policy does not have the force of government regulation doesn?t > change the fact that circumventing community adopted policy for your own > greed is tantamount to stealing someone?s furniture." > > I wouldn't use the word greed but I would say that denying real resources > to real organizations now is stealing their future too! > > 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? > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Thursday, June 12, 2014 9:31 AM > To: Brandon Ross > Cc: arin-ppml at arin.net List (arin-ppml at arin.net) > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > On Jun 11, 2014, at 1:36 PM, Brandon Ross wrote: > > > On Wed, 11 Jun 2014, Matthew Petach wrote: > > > >> I cannot absolutely prevent you from stealing my furniture if you so > >> desire. However, that doesn't mean I'm not going to put a lock on my > >> front door to at least make it harder for you, and make it patently > >> clear that you're doing so against my express desires. > > > > As has been mentioned here before, stealing furnature is a criminal > offence, writing a contract giving exclusive rights to address space is > not. That's a pretty crucial difference. If breaking and entering and > stealing furnature were legal, the small help of a lock on my porch screen > door would make little difference to a "bad actor". Locks keep honest > people honest, but if an activity is not widely agreed to be immoral, locks > won't help. > > This is a distinction without a difference. The fact that IP number policy > does not have the force of government regulation doesn?t change the fact > that circumventing community adopted policy for your own greed is > tantamount to stealing someone?s furniture. > > Arguing that because policy doesn?t carry the force of law, we shouldn?t > have policy is not, IMHO, what you want to do here. That basically serves > as a request for real regulators to come in and develop number resource > regulation in place of our lack of policy. > > At its core, the internet is built on cooperation among the various > entities connecting to the network. That cooperation is governed by rules > built through a community consensus process. While I agree the process > isn?t perfect, I would argue that it has worked far better than any > legislative processes I have observed and that we probably prefer to keep > it. > > >> I'll ask plainly; for everyone voting for needs-free transfers; would > >> you still vote that way, *if in doing so, you were guaranteed to not > >> be able to obtain any number resources under the new policy*? > > > > I don't have any address resources now, and I don't ever plan on having > any in the future, so sure, why not? > > > >> If not, I would claim your votes are not guided by the good of the > >> community; they're guided by self-interest, and a hope and desire > >> that you can get something for less effort than you can by following > >> the current guidelines. > > > > Oh really? > > I think he was more talking about Mike B. and Steven R., than you, Brandon. > > > Much like Owen, I have a nice little business of helping small > organizations navigate the ARIN process to get address space. It's not a > majority of my income, but it's pretty nice and easy work for me. If needs > basis goes away, guess what else goes away? > > > > Even though Owen and I are on opposite sides of this coversation, I can > guarantee you right now that both of us, without fail, are arguing solely > for what we think is best for the community. > > > > It's quite ironic that I would make more money by arguing on your side > of the issue, isn't it? > > > > Or maybe my conspiracy is to get v4 to run out faster so I can make more > money on v6 deployment? > > It could be. I?m OK with that. ;-) > > Owen > > > _______________________________________________ > 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 SRyerse at eclipse-networks.com Thu Jun 12 14:59:15 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Thu, 12 Jun 2014 18:59:15 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <73F55572-37A4-4A5F-AB18-45020C9B2745@corp.arin.net> References: <53976D0E.50509 @velea.eu><5B9E90747FA2974D91A54FCFA1B8AD12015AB0437F@ENI-MAIL.eclipse-netw orks.com><5B9E90747FA2974D91A54FCFA1B8AD12015AB0446F@ENI-MAIL.eclipse-networks.com >< 90676DEE-D76E-4666-999E-6FDDFB3F18C1@delong.com><53AF0CBCE6D2402C903B4CBD04 07ED48@MPC><9894E661-1A66-478B-BAE1-BEFA5684AE5A@delong.com> <73F55572-37A4-4A5F-AB18-45020C9B2745@corp.arin.net> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AB12EF4@ENI-MAIL.eclipse-networks.com> I would echo Mike?s earlier comment that just because they don?t adhere to a policy of ARINs does not in itself make them Bad. If a Legacy holder decides to sell his IP block to another party as an example that does not somehow make them bad. By your definition it may make them an Actor but not necessarily a Bad Actor. My two 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 John Curran Sent: Thursday, June 12, 2014 11:08 AM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] About needs basis in 8.3 transfers On Jun 12, 2014, at 10:57 AM, Owen DeLong > wrote: Changing the definition of bad actors can, indeed, make a bunch of bad actors now fit the reformed definition of ?good companies?, but similarly, repealing laws against bank robbers would then make bank robbers no longer defined as criminals. Owen - Let's save use of the term "criminal" for those actually violating public laws; the phrase "bad actors" applies quite well to those who violate community expectations, whether that be address policy, handling unsolicited bulk emailers, route deaggregators, etc. Thanks! /John John Curran President and CEO ARIN -------------- 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 narten at us.ibm.com Fri Jun 13 00:53:02 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 13 Jun 2014 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201406130453.s5D4r2IQ010741@rotala.raleigh.ibm.com> Total of 125 messages in the last 7 days. script run at: Fri Jun 13 00:53:02 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 19.20% | 24 | 19.28% | 314466 | owen at delong.com 12.80% | 16 | 18.72% | 305421 | sryerse at eclipse-networks.com 11.20% | 14 | 9.25% | 150900 | mike at iptrading.com 8.00% | 10 | 6.63% | 108137 | jcurran at arin.net 4.80% | 6 | 6.60% | 107620 | dogwallah at gmail.com 3.20% | 4 | 4.65% | 75801 | billdarte at gmail.com 3.20% | 4 | 4.57% | 74624 | mpetach at netflight.com 1.60% | 2 | 4.67% | 76242 | jschiller at google.com 3.20% | 4 | 2.93% | 47752 | elvis at velea.eu 3.20% | 4 | 1.65% | 26846 | michael at linuxmagic.com 2.40% | 3 | 1.79% | 29154 | farmer at umn.edu 2.40% | 3 | 1.74% | 28460 | andrew.dul at quark.net 2.40% | 3 | 1.44% | 23510 | bross at pobox.com 2.40% | 3 | 1.20% | 19529 | matthew at matthew.at 0.80% | 1 | 2.13% | 34705 | john at qxccommunications.com 1.60% | 2 | 1.31% | 21308 | lar at mwtcorp.net 1.60% | 2 | 1.02% | 16650 | kkargel at polartel.com 1.60% | 2 | 0.96% | 15646 | woody at pch.net 1.60% | 2 | 0.92% | 14928 | mueller at syr.edu 1.60% | 2 | 0.80% | 12974 | gary.buhrmaster at gmail.com 0.80% | 1 | 0.82% | 13332 | drc at virtualized.org 0.80% | 1 | 0.80% | 13128 | david.huberman at microsoft.com 0.80% | 1 | 0.75% | 12248 | cja at daydream.com 0.80% | 1 | 0.66% | 10761 | springer at inlandnet.com 0.80% | 1 | 0.65% | 10590 | rudi.daniel at gmail.com 0.80% | 1 | 0.55% | 8944 | timothy.s.morizot at irs.gov 0.80% | 1 | 0.54% | 8754 | info at arin.net 0.80% | 1 | 0.48% | 7836 | narten at us.ibm.com 0.80% | 1 | 0.45% | 7347 | rbf+arin-ppml at panix.com 0.80% | 1 | 0.44% | 7222 | jay at impulse.net 0.80% | 1 | 0.43% | 7027 | bill at tknow.com 0.80% | 1 | 0.43% | 6937 | john at egh.com 0.80% | 1 | 0.40% | 6594 | lsawyer at gci.com 0.80% | 1 | 0.36% | 5803 | ajs at anvilwalrusden.com --------+------+--------+----------+------------------------ 100.00% | 125 |100.00% | 1631196 | Total From Tim.Gimmel at metronetinc.com Fri Jun 13 16:50:08 2014 From: Tim.Gimmel at metronetinc.com (Tim Gimmel) Date: Fri, 13 Jun 2014 20:50:08 +0000 Subject: [arin-ppml] Policy discussion - Method of calculating utilization Message-ID: <428fdbbbb3c5446995d03b091893dc66@EXCHMB-03.ad.qservco.com> I not really sure where this policy discussion is at the moment, but I want to assert the current method places a strain on small carriers just trying to do business. We are in the process of implementing IPv6, but is will be a long journey. Overall I am way past 80% utilization, but because my last allocation (and this is based on actual usage, not just what has been 'swiped') has not yet reached 80% we are practically stymied. Tim's 2 cents! Tim Tim Gimmel Metronet | Senior Network Engineer 3701 Communications Way | Evansville, IN 47715 Office: 812.456.4750 www.MetronetInc.com > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Friday, May 02, 2014 8:14 PM > To: Jeffrey Lyon > Cc: arin-ppml at arin.net List > Subject: Re: [arin-ppml] Policy discussion - Method of calculating > utilization > > While I support Jeffry's proposal for changing the calculation method, in > terms of changing the threshold, I'd like to say that I really think it is > time to stop trying to re-arrange the IPv4 deck chairs and get on board > the IPv6 luxury liners that have come to rescue us from the sinking IPv4 > ship. > > Owen > > On May 2, 2014, at 6:04 PM, Jeffrey Lyon > wrote: > > > On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess wrote: > >> On Fri, May 2, 2014 at 7:33 PM, John Santos wrote: > >>> On Fri, 2 May 2014, Jimmy Hess wrote: > >> > >>> I think 95% is too high, if the previous example of 3 /24's at 100% > >>> and > >>> 1 /24 at 75% is realistic. That works out to 93.75% aggregate > >>> utilization, not quite reaching the bar, so 90% might be a better > threshold. > >> > >> For 3 /24s yes. The difficulty here, is trying to pick a single > >> utilization proportion that works regardless of the aggregate > >> allocation size, to allow for the loss of the oddball /26 or /27 that > >> can neither be returned nor reused, perhaps another method is in > >> order than presuming a single aggregate utilization criterion is > >> the most proper. > >> > >> > >> The more resources you are allocated, the more opportunity to make > >> your resource allocation efficient. By the time you get down to a > >> /26, an entire /24 is less than 0.4%. > >> > >> Aggregate Resources Allocated Required Aggregate > >> Utilization criterion > >> more than a /25 75% > >> more than a /22, 80% > >> more than a /20 85% > >> more than a /19 90% > >> more than a /18 95% > >> more than a /17 97% > >> more than a /16 98% > >> more than a /15 99% > >> > >> > >> > >>> > >>> OTOH, /24's are pretty small and maybe that example was just for > >>> illustration. If people really in this situation have much larger > >>> allocations, they would be easier to slice and dice and thus use > >>> (relatively) efficiently. 75% of a /24 leaves just 64 addresses (a > >>> /26) unused, which even if contiguous are hard to redeploy for some > >>> other use. 75% of a /16 would leave 16384 unused addresses, which > could be utilized much more easily. > >>> > >>> > >>> Personally, I don't much care since my company has its /24, and > >>> that's probably all the IPv4 we'll ever need :-) > >>> > >>> > >>> -- > >>> John Santos > >>> Evans Griffiths & Hart, Inc. > >>> 781-861-0670 ext 539 > >>> > >> > >> > >> > >> -- > >> -JH > >> _______________________________________________ > >> 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. > > > > Jimmy, > > > > I would not support scaling this beyond 80% except at the larger > > allocation levels (eg. perhaps /17 and shorter, aggregate). > > > > As a practical matter I believe these measures should be handled as > > separate policy proposals. The current proposal should be limited to > > the calculation method and perhaps you could write a new proposal if > > you wanted to change the utilization threshold? > > > > Thanks, > > -- > > Jeffrey A. Lyon, CISSP-ISSMP > > Fellow, Black Lotus Communications > > mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: > > blacklotus.net _______________________________________________ > > 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 jeffrey.lyon at blacklotus.net Fri Jun 13 18:41:06 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 14 Jun 2014 07:41:06 +0900 Subject: [arin-ppml] Policy discussion - Method of calculating utilization In-Reply-To: <428fdbbbb3c5446995d03b091893dc66@EXCHMB-03.ad.qservco.com> References: <428fdbbbb3c5446995d03b091893dc66@EXCHMB-03.ad.qservco.com> Message-ID: Tim, I am also uncertain of the current status but would like to see some progress. Thanks, Jeff On Sat, Jun 14, 2014 at 5:50 AM, Tim Gimmel wrote: > I not really sure where this policy discussion is at the moment, but I want to assert the current method places a strain on small carriers just trying to do business. We are in the process of implementing IPv6, but is will be a long journey. > Overall I am way past 80% utilization, but because my last allocation (and this is based on actual usage, not just what has been 'swiped') has not yet reached 80% we are practically stymied. > > Tim's 2 cents! > > Tim > > Tim Gimmel > Metronet | Senior Network Engineer > 3701 Communications Way | Evansville, IN 47715 > Office: 812.456.4750 > www.MetronetInc.com > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Owen DeLong >> Sent: Friday, May 02, 2014 8:14 PM >> To: Jeffrey Lyon >> Cc: arin-ppml at arin.net List >> Subject: Re: [arin-ppml] Policy discussion - Method of calculating >> utilization >> >> While I support Jeffry's proposal for changing the calculation method, in >> terms of changing the threshold, I'd like to say that I really think it is >> time to stop trying to re-arrange the IPv4 deck chairs and get on board >> the IPv6 luxury liners that have come to rescue us from the sinking IPv4 >> ship. >> >> Owen >> >> On May 2, 2014, at 6:04 PM, Jeffrey Lyon >> wrote: >> >> > On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess wrote: >> >> On Fri, May 2, 2014 at 7:33 PM, John Santos wrote: >> >>> On Fri, 2 May 2014, Jimmy Hess wrote: >> >> >> >>> I think 95% is too high, if the previous example of 3 /24's at 100% >> >>> and >> >>> 1 /24 at 75% is realistic. That works out to 93.75% aggregate >> >>> utilization, not quite reaching the bar, so 90% might be a better >> threshold. >> >> >> >> For 3 /24s yes. The difficulty here, is trying to pick a single >> >> utilization proportion that works regardless of the aggregate >> >> allocation size, to allow for the loss of the oddball /26 or /27 that >> >> can neither be returned nor reused, perhaps another method is in >> >> order than presuming a single aggregate utilization criterion is >> >> the most proper. >> >> >> >> >> >> The more resources you are allocated, the more opportunity to make >> >> your resource allocation efficient. By the time you get down to a >> >> /26, an entire /24 is less than 0.4%. >> >> >> >> Aggregate Resources Allocated Required Aggregate >> >> Utilization criterion >> >> more than a /25 75% >> >> more than a /22, 80% >> >> more than a /20 85% >> >> more than a /19 90% >> >> more than a /18 95% >> >> more than a /17 97% >> >> more than a /16 98% >> >> more than a /15 99% >> >> >> >> >> >> >> >>> >> >>> OTOH, /24's are pretty small and maybe that example was just for >> >>> illustration. If people really in this situation have much larger >> >>> allocations, they would be easier to slice and dice and thus use >> >>> (relatively) efficiently. 75% of a /24 leaves just 64 addresses (a >> >>> /26) unused, which even if contiguous are hard to redeploy for some >> >>> other use. 75% of a /16 would leave 16384 unused addresses, which >> could be utilized much more easily. >> >>> >> >>> >> >>> Personally, I don't much care since my company has its /24, and >> >>> that's probably all the IPv4 we'll ever need :-) >> >>> >> >>> >> >>> -- >> >>> John Santos >> >>> Evans Griffiths & Hart, Inc. >> >>> 781-861-0670 ext 539 >> >>> >> >> >> >> >> >> >> >> -- >> >> -JH >> >> _______________________________________________ >> >> 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. >> > >> > Jimmy, >> > >> > I would not support scaling this beyond 80% except at the larger >> > allocation levels (eg. perhaps /17 and shorter, aggregate). >> > >> > As a practical matter I believe these measures should be handled as >> > separate policy proposals. The current proposal should be limited to >> > the calculation method and perhaps you could write a new proposal if >> > you wanted to change the utilization threshold? >> > >> > Thanks, >> > -- >> > Jeffrey A. Lyon, CISSP-ISSMP >> > Fellow, Black Lotus Communications >> > mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: >> > blacklotus.net _______________________________________________ >> > 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. -- Jeffrey A. Lyon, CISSP-ISSMP Fellow, Black Lotus Communications mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net From lsawyer at gci.com Fri Jun 13 19:33:59 2014 From: lsawyer at gci.com (Leif Sawyer) Date: Fri, 13 Jun 2014 15:33:59 -0800 Subject: [arin-ppml] Policy discussion - Method of calculating utilization In-Reply-To: References: <428fdbbbb3c5446995d03b091893dc66@EXCHMB-03.ad.qservco.com> Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102C9C45855@fnb1mbx01.gci.com> I was really hoping somebody would suggest, perhaps, some sort of easy-to-apply scaling algorithm so that it makes it easier for the smaller guys to get the space they need, but harder for the bigger guys to game the system. I'm sure there's some sort of curve that fits, but my advanced maths are limited to Pythagoras. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon Sent: Friday, June 13, 2014 2:41 PM To: Tim Gimmel Cc: arin-ppml at arin.net List Subject: Re: [arin-ppml] Policy discussion - Method of calculating utilization Tim, I am also uncertain of the current status but would like to see some progress. Thanks, Jeff On Sat, Jun 14, 2014 at 5:50 AM, Tim Gimmel wrote: > I not really sure where this policy discussion is at the moment, but I want to assert the current method places a strain on small carriers just trying to do business. We are in the process of implementing IPv6, but is will be a long journey. > Overall I am way past 80% utilization, but because my last allocation (and this is based on actual usage, not just what has been 'swiped') has not yet reached 80% we are practically stymied. > > Tim's 2 cents! > > Tim > > Tim Gimmel > Metronet | Senior Network Engineer > 3701 Communications Way | Evansville, IN 47715 > Office: 812.456.4750 > www.MetronetInc.com > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >> On Behalf Of Owen DeLong >> Sent: Friday, May 02, 2014 8:14 PM >> To: Jeffrey Lyon >> Cc: arin-ppml at arin.net List >> Subject: Re: [arin-ppml] Policy discussion - Method of calculating >> utilization >> >> While I support Jeffry's proposal for changing the calculation >> method, in terms of changing the threshold, I'd like to say that I >> really think it is time to stop trying to re-arrange the IPv4 deck >> chairs and get on board the IPv6 luxury liners that have come to >> rescue us from the sinking IPv4 ship. >> >> Owen >> >> On May 2, 2014, at 6:04 PM, Jeffrey Lyon >> >> wrote: >> >> > On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess wrote: >> >> On Fri, May 2, 2014 at 7:33 PM, John Santos wrote: >> >>> On Fri, 2 May 2014, Jimmy Hess wrote: >> >> >> >>> I think 95% is too high, if the previous example of 3 /24's at >> >>> 100% and >> >>> 1 /24 at 75% is realistic. That works out to 93.75% aggregate >> >>> utilization, not quite reaching the bar, so 90% might be a better >> threshold. >> >> >> >> For 3 /24s yes. The difficulty here, is trying to pick a single >> >> utilization proportion that works regardless of the aggregate >> >> allocation size, to allow for the loss of the oddball /26 or /27 that >> >> can neither be returned nor reused, perhaps another method is in >> >> order than presuming a single aggregate utilization criterion is >> >> the most proper. >> >> >> >> >> >> The more resources you are allocated, the more opportunity to make >> >> your resource allocation efficient. By the time you get down to a >> >> /26, an entire /24 is less than 0.4%. >> >> >> >> Aggregate Resources Allocated Required Aggregate >> >> Utilization criterion >> >> more than a /25 75% >> >> more than a /22, 80% >> >> more than a /20 85% >> >> more than a /19 90% >> >> more than a /18 95% >> >> more than a /17 97% >> >> more than a /16 98% >> >> more than a /15 99% >> >> >> >> >> >> >> >>> >> >>> OTOH, /24's are pretty small and maybe that example was just for >> >>> illustration. If people really in this situation have much >> >>> larger allocations, they would be easier to slice and dice and >> >>> thus use >> >>> (relatively) efficiently. 75% of a /24 leaves just 64 addresses >> >>> (a >> >>> /26) unused, which even if contiguous are hard to redeploy for >> >>> some other use. 75% of a /16 would leave 16384 unused addresses, >> >>> which >> could be utilized much more easily. >> >>> >> >>> >> >>> Personally, I don't much care since my company has its /24, and >> >>> that's probably all the IPv4 we'll ever need :-) >> >>> >> >>> >> >>> -- >> >>> John Santos >> >>> Evans Griffiths & Hart, Inc. >> >>> 781-861-0670 ext 539 >> >>> >> >> >> >> >> >> >> >> -- >> >> -JH >> >> _______________________________________________ >> >> 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. >> > >> > Jimmy, >> > >> > I would not support scaling this beyond 80% except at the larger >> > allocation levels (eg. perhaps /17 and shorter, aggregate). >> > >> > As a practical matter I believe these measures should be handled as >> > separate policy proposals. The current proposal should be limited >> > to the calculation method and perhaps you could write a new >> > proposal if you wanted to change the utilization threshold? >> > >> > Thanks, >> > -- >> > Jeffrey A. Lyon, CISSP-ISSMP >> > Fellow, Black Lotus Communications >> > mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: >> > blacklotus.net _______________________________________________ >> > 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. -- Jeffrey A. Lyon, CISSP-ISSMP Fellow, Black Lotus Communications mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net _______________________________________________ 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 Sat Jun 14 09:59:39 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 14 Jun 2014 06:59:39 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AB12DE2@ENI-MAIL.eclipse-networks.com> References: <7D51B0FD40554C4E9DE275DEA58B8B8B @MPC><679948D066BC47828F06 48291A9886E7@ncsscfoipoxes4><469A588F-3A36-4FDB-8A81-59EC D4F4F722@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AB12DE2@ENI-MAIL.eclipse-networks.com> Message-ID: <5AE88771-F659-4502-9458-A56A25A02107@delong.com> Nobody is denying resources to organizations that can document need. I don?t know what your persistent failure is in this regard or why you are finding it difficult. However, I have yet to see a case where any reasonable need was turned away by ARIN unless one or more of the following circumstances existed: 1. The requestor refused to submit sufficient documentation. 2. The requestor refused to sign the RSA 3. The requestor refused to comply with community developed policy. 4. The requestor?s need was so small that they could not qualify under policy. Note: This last one has been so completely reduced in recent policy cycles that it is hard to imagine a scenario where it would apply to any but the most deliberate and stubborn of corner cases. As such, I?m sorry, but absent your willingness to disclose specific examples in detail, I find your argument suspect at best. Owen On Jun 12, 2014, at 11:46 AM, Steven Ryerse wrote: > Owen, I would turn your argument around where you said " The fact that IP number policy does not have the force of government regulation doesn?t change the fact that circumventing community adopted policy for your own greed is tantamount to stealing someone?s furniture." > > I wouldn't use the word greed but I would say that denying real resources to real organizations now is stealing their future too! > > 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? > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong > Sent: Thursday, June 12, 2014 9:31 AM > To: Brandon Ross > Cc: arin-ppml at arin.net List (arin-ppml at arin.net) > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > On Jun 11, 2014, at 1:36 PM, Brandon Ross wrote: > >> On Wed, 11 Jun 2014, Matthew Petach wrote: >> >>> I cannot absolutely prevent you from stealing my furniture if you so >>> desire. However, that doesn't mean I'm not going to put a lock on my >>> front door to at least make it harder for you, and make it patently >>> clear that you're doing so against my express desires. >> >> As has been mentioned here before, stealing furnature is a criminal offence, writing a contract giving exclusive rights to address space is not. That's a pretty crucial difference. If breaking and entering and stealing furnature were legal, the small help of a lock on my porch screen door would make little difference to a "bad actor". Locks keep honest people honest, but if an activity is not widely agreed to be immoral, locks won't help. > > This is a distinction without a difference. The fact that IP number policy does not have the force of government regulation doesn?t change the fact that circumventing community adopted policy for your own greed is tantamount to stealing someone?s furniture. > > Arguing that because policy doesn?t carry the force of law, we shouldn?t have policy is not, IMHO, what you want to do here. That basically serves as a request for real regulators to come in and develop number resource regulation in place of our lack of policy. > > At its core, the internet is built on cooperation among the various entities connecting to the network. That cooperation is governed by rules built through a community consensus process. While I agree the process isn?t perfect, I would argue that it has worked far better than any legislative processes I have observed and that we probably prefer to keep it. > >>> I'll ask plainly; for everyone voting for needs-free transfers; would >>> you still vote that way, *if in doing so, you were guaranteed to not >>> be able to obtain any number resources under the new policy*? >> >> I don't have any address resources now, and I don't ever plan on having any in the future, so sure, why not? >> >>> If not, I would claim your votes are not guided by the good of the >>> community; they're guided by self-interest, and a hope and desire >>> that you can get something for less effort than you can by following >>> the current guidelines. >> >> Oh really? > > I think he was more talking about Mike B. and Steven R., than you, Brandon. > >> Much like Owen, I have a nice little business of helping small organizations navigate the ARIN process to get address space. It's not a majority of my income, but it's pretty nice and easy work for me. If needs basis goes away, guess what else goes away? >> >> Even though Owen and I are on opposite sides of this coversation, I can guarantee you right now that both of us, without fail, are arguing solely for what we think is best for the community. >> >> It's quite ironic that I would make more money by arguing on your side of the issue, isn't it? >> >> Or maybe my conspiracy is to get v4 to run out faster so I can make more money on v6 deployment? > > It could be. I?m OK with that. ;-) > > Owen > > > _______________________________________________ > 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 mysidia at gmail.com Sat Jun 14 11:10:54 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 14 Jun 2014 10:10:54 -0500 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> References: <3229ccc805d948e29b21f5b1f393b3e4@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: On Tue, Jun 3, 2014 at 2:31 PM, David Huberman wrote: > or other RIRs, we have to turn to the market for our IP address needs. > We may choose to buy more than a 2 year supply, because it may make business > sense for us to do so. ARIN policy, however, only allows us to take the IP > addresses we buy and transfer the portion which represents a 2 year need. > The rest will remain in the name of whoever sold the IP addresses to us. This is different from the WHOIS information merely being out of date due to neglect by the resource holder failing to update their contact information -- this falls under willful deception: intentionally deceiving the RIR about the usage of resources under its stewardship... Specifically: It is an intentional deception to agree to "transfer rights" between organizations -- outside the normal manner in which an ISP is allowed to allocate resources, and without following the required process or rules given by policy, Or also.... the act of agreeing to "report" a smaller amount as transferred, and proceeding as if the transfer was allowed, before requesting the transfer. And the deception, would clearly be intended to provide financial gain at the cost of the community (Obtaining resources earlier, and in larger number, than justified need requirements would allow). This would be no different than someone with a site-license for software writing up a contract to "sell" 100 of their product keys without notifying the software vendor, even though the licenses are only allowed to be transferred through the vendor. They are "just numbers"; however, the registry's right (through the community) to control the manner in which the numbers are distributed is vital to stewardship of the resources. A resource holder allowing a 3rd party to intentionally take full rights to the resources, while representing to the registry that the original holder is continuing to administer and use the resources would be fraudulent, and a serious threat to the RIR's capability to provide needs-based stewardship of the address space. In other words, the seller will have committed a fraud, by purporting to sell IP addresses, which neither the ARIN EULA / RSA, nor the RFC (for legacy holders) provided a way for anyone to do ("cannot sell what is not your property," the registration belongs to the registry and is subject to their rules), And the 8.3 application will also have been a material misrepresentation, and These are circumstances under which revokation of resources by ARIN or other RIRs might be appropriate. Any case where it can be shown an "agreement" to assign "rights" to IP addresses was made privately in a manner inconsistent with policy and not allowed by the RSA. -- -JH From hannigan at gmail.com Sat Jun 14 14:12:15 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Sat, 14 Jun 2014 14:12:15 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5AE88771-F659-4502-9458-A56A25A02107@delong.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB12DE2@ENI-MAIL.eclipse-networks.com> <5AE88771-F659-4502-9458-A56A25A02107@delong.com> Message-ID: I disagree. It's not as clear cut as you'd like to fantasize it is. Best, -M< On Saturday, June 14, 2014, Owen DeLong wrote: > Nobody is denying resources to organizations that can document need. I > don?t know what your persistent failure is in this regard or why you are > finding it difficult. However, I have yet to see a case where any > reasonable need was turned away by ARIN unless one or more of the following > circumstances existed: > > 1. The requestor refused to submit sufficient documentation. > 2. The requestor refused to sign the RSA > 3. The requestor refused to comply with community developed > policy. > 4. The requestor?s need was so small that they could not > qualify under policy. > Note: This last one has been so completely reduced in > recent policy cycles that it is hard to imagine a scenario where it would > apply to any > but the most deliberate and stubborn of corner cases. > > As such, I?m sorry, but absent your willingness to disclose specific > examples in detail, I find your argument suspect at best. > > Owen > > On Jun 12, 2014, at 11:46 AM, Steven Ryerse > wrote: > > > Owen, I would turn your argument around where you said " The fact that > IP number policy does not have the force of government regulation doesn?t > change the fact that circumventing community adopted policy for your own > greed is tantamount to stealing someone?s furniture." > > > > I wouldn't use the word greed but I would say that denying real > resources to real organizations now is stealing their future too! > > > > 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? > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > > Sent: Thursday, June 12, 2014 9:31 AM > > To: Brandon Ross > > Cc: arin-ppml at arin.net List (arin-ppml at arin.net) > > Subject: Re: [arin-ppml] About needs basis in 8.3 transfers > > > > > > On Jun 11, 2014, at 1:36 PM, Brandon Ross wrote: > > > >> On Wed, 11 Jun 2014, Matthew Petach wrote: > >> > >>> I cannot absolutely prevent you from stealing my furniture if you so > >>> desire. However, that doesn't mean I'm not going to put a lock on my > >>> front door to at least make it harder for you, and make it patently > >>> clear that you're doing so against my express desires. > >> > >> As has been mentioned here before, stealing furnature is a criminal > offence, writing a contract giving exclusive rights to address space is > not. That's a pretty crucial difference. If breaking and entering and > stealing furnature were legal, the small help of a lock on my porch screen > door would make little difference to a "bad actor". Locks keep honest > people honest, but if an activity is not widely agreed to be immoral, locks > won't help. > > > > This is a distinction without a difference. The fact that IP number > policy does not have the force of government regulation doesn?t change the > fact that circumventing community adopted policy for your own greed is > tantamount to stealing someone?s furniture. > > > > Arguing that because policy doesn?t carry the force of law, we shouldn?t > have policy is not, IMHO, what you want to do here. That basically serves > as a request for real regulators to come in and develop number resource > regulation in place of our lack of policy. > > > > At its core, the internet is built on cooperation among the various > entities connecting to the network. That cooperation is governed by rules > built through a community consensus process. While I agree the process > isn?t perfect, I would argue that it has worked far better than any > legislative processes I have observed and that we probably prefer to keep > it. > > > >>> I'll ask plainly; for everyone voting for needs-free transfers; would > >>> you still vote that way, *if in doing so, you were guaranteed to not > >>> be able to obtain any number resources under the new policy*? > >> > >> I don't have any address resources now, and I don't ever plan on having > any in the future, so sure, why not? > >> > >>> If not, I would claim your votes are not guided by the good of the > >>> community; they're guided by self-interest, and a hope and desire > >>> that you can get something for less effort than you can by following > >>> the current guidelines. > >> > >> Oh really? > > > > I think he was more talking about Mike B. and Steven R., than you, > Brandon. > > > >> Much like Owen, I have a nice little business of helping small > organizations navigate the ARIN process to get address space. It's not a > majority of my income, but it's pretty nice and easy work for me. If needs > basis goes away, guess what else goes away? > >> > >> Even though Owen and I are on opposite sides of this coversation, I can > guarantee you right now that both of us, without fail, are arguing solely > for what we think is best for the community. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.buhrmaster at gmail.com Sat Jun 14 15:12:42 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sat, 14 Jun 2014 19:12:42 +0000 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12015AB12DE2@ENI-MAIL.eclipse-networks.com> <5AE88771-F659-4502-9458-A56A25A02107@delong.com> Message-ID: On Sat, Jun 14, 2014 at 6:12 PM, Martin Hannigan wrote: > > I disagree. It's not as clear cut as you'd like to fantasize it is. It never is. But I have found myself supporting policy changes when clear, real life, examples were presented that showed that good policy resulted in badness (or rocks met hard places; the least bad choice had to be supported). So, "Show me the beef", and I may be able to support a policy that eliminates needs requirements, or grants the evil genius Gru and his minion Dave the ability to control the entire global IPv4 number space. Good case studies can produce good policy, and find support even from those that otherwise are opposed to abstract spin cycles. Gary From andrew.dul at quark.net Mon Jun 16 13:53:15 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 16 Jun 2014 10:53:15 -0700 Subject: [arin-ppml] Policy discussion - Method of calculating utilization ARIN-2014-17 In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102C9C45855@fnb1mbx01.gci.com> References: <428fdbbbb3c5446995d03b091893dc66@EXCHMB-03.ad.qservco.com> <18B2C6E38A3A324986B392B2D18ABC5102C9C45855@fnb1mbx01.gci.com> Message-ID: <539F2F0B.5040402@quark.net> Hello, I sent a longer summary of where this policy discussion is last week, I've pasted a link below to that message in the archive. http://lists.arin.net/pipermail/arin-ppml/2014-June/028654.html In general, I would say that this draft policy is stalled at this point. The 80% utilization policy underpins a large majority of the current policies and thus is a substantial change. There have been a few people who have voiced their support, but not enough that I believe would allow this policy to move forward as a recommended draft at this point. I would also point out that they current policy also constrains larger providers but in a different way as ARIN is now more closely enforcing the current policy of "efficiently utilized all previous allocations" (4.2.4.1) as noted during the NANOG PPC. Leif, I don't think there is an easy scaling algorithm to apply to utilization. The problem with a scaling algorithm is it likely will be perceived as "unfair" by organizations on one side of the size continuum. (We tried HD ratio for v6 and that was not easily understood, and lead to lots of confusion.) Thanks, Andrew On 6/13/2014 4:33 PM, Leif Sawyer wrote: > I was really hoping somebody would suggest, perhaps, some sort > of easy-to-apply scaling algorithm so that it makes it easier for > the smaller guys to get the space they need, but harder for the bigger > guys to game the system. > > I'm sure there's some sort of curve that fits, but my advanced maths > are limited to Pythagoras. > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon > Sent: Friday, June 13, 2014 2:41 PM > To: Tim Gimmel > Cc: arin-ppml at arin.net List > Subject: Re: [arin-ppml] Policy discussion - Method of calculating utilization > > Tim, > > I am also uncertain of the current status but would like to see some progress. > > Thanks, Jeff > > On Sat, Jun 14, 2014 at 5:50 AM, Tim Gimmel wrote: >> I not really sure where this policy discussion is at the moment, but I want to assert the current method places a strain on small carriers just trying to do business. We are in the process of implementing IPv6, but is will be a long journey. >> Overall I am way past 80% utilization, but because my last allocation (and this is based on actual usage, not just what has been 'swiped') has not yet reached 80% we are practically stymied. >> >> Tim's 2 cents! >> >> Tim >> >> Tim Gimmel >> Metronet | Senior Network Engineer >> 3701 Communications Way | Evansville, IN 47715 >> Office: 812.456.4750 >> www.MetronetInc.com >> >> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>> On Behalf Of Owen DeLong >>> Sent: Friday, May 02, 2014 8:14 PM >>> To: Jeffrey Lyon >>> Cc: arin-ppml at arin.net List >>> Subject: Re: [arin-ppml] Policy discussion - Method of calculating >>> utilization >>> >>> While I support Jeffry's proposal for changing the calculation >>> method, in terms of changing the threshold, I'd like to say that I >>> really think it is time to stop trying to re-arrange the IPv4 deck >>> chairs and get on board the IPv6 luxury liners that have come to >>> rescue us from the sinking IPv4 ship. >>> >>> Owen >>> >>> On May 2, 2014, at 6:04 PM, Jeffrey Lyon >>> >>> wrote: >>> >>>> On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess wrote: >>>>> On Fri, May 2, 2014 at 7:33 PM, John Santos wrote: >>>>>> On Fri, 2 May 2014, Jimmy Hess wrote: >>>>>> I think 95% is too high, if the previous example of 3 /24's at >>>>>> 100% and >>>>>> 1 /24 at 75% is realistic. That works out to 93.75% aggregate >>>>>> utilization, not quite reaching the bar, so 90% might be a better >>> threshold. >>>>> For 3 /24s yes. The difficulty here, is trying to pick a single >>>>> utilization proportion that works regardless of the aggregate >>>>> allocation size, to allow for the loss of the oddball /26 or /27 that >>>>> can neither be returned nor reused, perhaps another method is in >>>>> order than presuming a single aggregate utilization criterion is >>>>> the most proper. >>>>> >>>>> >>>>> The more resources you are allocated, the more opportunity to make >>>>> your resource allocation efficient. By the time you get down to a >>>>> /26, an entire /24 is less than 0.4%. >>>>> >>>>> Aggregate Resources Allocated Required Aggregate >>>>> Utilization criterion >>>>> more than a /25 75% >>>>> more than a /22, 80% >>>>> more than a /20 85% >>>>> more than a /19 90% >>>>> more than a /18 95% >>>>> more than a /17 97% >>>>> more than a /16 98% >>>>> more than a /15 99% >>>>> >>>>> >>>>> >>>>>> OTOH, /24's are pretty small and maybe that example was just for >>>>>> illustration. If people really in this situation have much >>>>>> larger allocations, they would be easier to slice and dice and >>>>>> thus use >>>>>> (relatively) efficiently. 75% of a /24 leaves just 64 addresses >>>>>> (a >>>>>> /26) unused, which even if contiguous are hard to redeploy for >>>>>> some other use. 75% of a /16 would leave 16384 unused addresses, >>>>>> which >>> could be utilized much more easily. >>>>>> >>>>>> Personally, I don't much care since my company has its /24, and >>>>>> that's probably all the IPv4 we'll ever need :-) >>>>>> >>>>>> >>>>>> -- >>>>>> John Santos >>>>>> Evans Griffiths & Hart, Inc. >>>>>> 781-861-0670 ext 539 >>>>>> >>>>> >>>>> >>>>> -- >>>>> -JH >>>>> _______________________________________________ >>>>> 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. >>>> Jimmy, >>>> >>>> I would not support scaling this beyond 80% except at the larger >>>> allocation levels (eg. perhaps /17 and shorter, aggregate). >>>> >>>> As a practical matter I believe these measures should be handled as >>>> separate policy proposals. The current proposal should be limited >>>> to the calculation method and perhaps you could write a new >>>> proposal if you wanted to change the utilization threshold? >>>> >>>> Thanks, >>>> -- >>>> Jeffrey A. Lyon, CISSP-ISSMP >>>> Fellow, Black Lotus Communications >>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: >>>> blacklotus.net _______________________________________________ >>>> 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. > > > -- > Jeffrey A. Lyon, CISSP-ISSMP > Fellow, Black Lotus Communications > mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net _______________________________________________ > 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 David.Huberman at microsoft.com Mon Jun 16 14:13:08 2014 From: David.Huberman at microsoft.com (David Huberman) Date: Mon, 16 Jun 2014 18:13:08 +0000 Subject: [arin-ppml] Policy discussion - Method of calculating utilization ARIN-2014-17 In-Reply-To: <539F2F0B.5040402@quark.net> References: <428fdbbbb3c5446995d03b091893dc66@EXCHMB-03.ad.qservco.com> <18B2C6E38A3A324986B392B2D18ABC5102C9C45855@fnb1mbx01.gci.com>, <539F2F0B.5040402@quark.net> Message-ID: <92382919dbc54ce2b4a67ba387fac15a@DM2PR03MB398.namprd03.prod.outlook.com> I believe we should discuss in Baltimore in front of a more substantial audience. There are by enough people participating here, in my opinion, for any "sense of the room" to make sense. David R Huberman Microsoft Corporation Senior IT/OPS Program Manager (GFS) ________________________________________ From: arin-ppml-bounces at arin.net on behalf of Andrew Dul Sent: Monday, June 16, 2014 10:53:15 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy discussion - Method of calculating utilization ARIN-2014-17 Hello, I sent a longer summary of where this policy discussion is last week, I've pasted a link below to that message in the archive. http://lists.arin.net/pipermail/arin-ppml/2014-June/028654.html In general, I would say that this draft policy is stalled at this point. The 80% utilization policy underpins a large majority of the current policies and thus is a substantial change. There have been a few people who have voiced their support, but not enough that I believe would allow this policy to move forward as a recommended draft at this point. I would also point out that they current policy also constrains larger providers but in a different way as ARIN is now more closely enforcing the current policy of "efficiently utilized all previous allocations" (4.2.4.1) as noted during the NANOG PPC. Leif, I don't think there is an easy scaling algorithm to apply to utilization. The problem with a scaling algorithm is it likely will be perceived as "unfair" by organizations on one side of the size continuum. (We tried HD ratio for v6 and that was not easily understood, and lead to lots of confusion.) Thanks, Andrew On 6/13/2014 4:33 PM, Leif Sawyer wrote: > I was really hoping somebody would suggest, perhaps, some sort > of easy-to-apply scaling algorithm so that it makes it easier for > the smaller guys to get the space they need, but harder for the bigger > guys to game the system. > > I'm sure there's some sort of curve that fits, but my advanced maths > are limited to Pythagoras. > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon > Sent: Friday, June 13, 2014 2:41 PM > To: Tim Gimmel > Cc: arin-ppml at arin.net List > Subject: Re: [arin-ppml] Policy discussion - Method of calculating utilization > > Tim, > > I am also uncertain of the current status but would like to see some progress. > > Thanks, Jeff > > On Sat, Jun 14, 2014 at 5:50 AM, Tim Gimmel wrote: >> I not really sure where this policy discussion is at the moment, but I want to assert the current method places a strain on small carriers just trying to do business. We are in the process of implementing IPv6, but is will be a long journey. >> Overall I am way past 80% utilization, but because my last allocation (and this is based on actual usage, not just what has been 'swiped') has not yet reached 80% we are practically stymied. >> >> Tim's 2 cents! >> >> Tim >> >> Tim Gimmel >> Metronet | Senior Network Engineer >> 3701 Communications Way | Evansville, IN 47715 >> Office: 812.456.4750 >> www.MetronetInc.com >> >> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>> On Behalf Of Owen DeLong >>> Sent: Friday, May 02, 2014 8:14 PM >>> To: Jeffrey Lyon >>> Cc: arin-ppml at arin.net List >>> Subject: Re: [arin-ppml] Policy discussion - Method of calculating >>> utilization >>> >>> While I support Jeffry's proposal for changing the calculation >>> method, in terms of changing the threshold, I'd like to say that I >>> really think it is time to stop trying to re-arrange the IPv4 deck >>> chairs and get on board the IPv6 luxury liners that have come to >>> rescue us from the sinking IPv4 ship. >>> >>> Owen >>> >>> On May 2, 2014, at 6:04 PM, Jeffrey Lyon >>> >>> wrote: >>> >>>> On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess wrote: >>>>> On Fri, May 2, 2014 at 7:33 PM, John Santos wrote: >>>>>> On Fri, 2 May 2014, Jimmy Hess wrote: >>>>>> I think 95% is too high, if the previous example of 3 /24's at >>>>>> 100% and >>>>>> 1 /24 at 75% is realistic. That works out to 93.75% aggregate >>>>>> utilization, not quite reaching the bar, so 90% might be a better >>> threshold. >>>>> For 3 /24s yes. The difficulty here, is trying to pick a single >>>>> utilization proportion that works regardless of the aggregate >>>>> allocation size, to allow for the loss of the oddball /26 or /27 that >>>>> can neither be returned nor reused, perhaps another method is in >>>>> order than presuming a single aggregate utilization criterion is >>>>> the most proper. >>>>> >>>>> >>>>> The more resources you are allocated, the more opportunity to make >>>>> your resource allocation efficient. By the time you get down to a >>>>> /26, an entire /24 is less than 0.4%. >>>>> >>>>> Aggregate Resources Allocated Required Aggregate >>>>> Utilization criterion >>>>> more than a /25 75% >>>>> more than a /22, 80% >>>>> more than a /20 85% >>>>> more than a /19 90% >>>>> more than a /18 95% >>>>> more than a /17 97% >>>>> more than a /16 98% >>>>> more than a /15 99% >>>>> >>>>> >>>>> >>>>>> OTOH, /24's are pretty small and maybe that example was just for >>>>>> illustration. If people really in this situation have much >>>>>> larger allocations, they would be easier to slice and dice and >>>>>> thus use >>>>>> (relatively) efficiently. 75% of a /24 leaves just 64 addresses >>>>>> (a >>>>>> /26) unused, which even if contiguous are hard to redeploy for >>>>>> some other use. 75% of a /16 would leave 16384 unused addresses, >>>>>> which >>> could be utilized much more easily. >>>>>> >>>>>> Personally, I don't much care since my company has its /24, and >>>>>> that's probably all the IPv4 we'll ever need :-) >>>>>> >>>>>> >>>>>> -- >>>>>> John Santos >>>>>> Evans Griffiths & Hart, Inc. >>>>>> 781-861-0670 ext 539 >>>>>> >>>>> >>>>> >>>>> -- >>>>> -JH >>>>> _______________________________________________ >>>>> 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. >>>> Jimmy, >>>> >>>> I would not support scaling this beyond 80% except at the larger >>>> allocation levels (eg. perhaps /17 and shorter, aggregate). >>>> >>>> As a practical matter I believe these measures should be handled as >>>> separate policy proposals. The current proposal should be limited >>>> to the calculation method and perhaps you could write a new >>>> proposal if you wanted to change the utilization threshold? >>>> >>>> Thanks, >>>> -- >>>> Jeffrey A. Lyon, CISSP-ISSMP >>>> Fellow, Black Lotus Communications >>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: >>>> blacklotus.net _______________________________________________ >>>> 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. > > > -- > Jeffrey A. Lyon, CISSP-ISSMP > Fellow, Black Lotus Communications > mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net _______________________________________________ > 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 jeffrey.lyon at blacklotus.net Mon Jun 16 14:19:51 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 16 Jun 2014 14:19:51 -0400 Subject: [arin-ppml] Policy discussion - Method of calculating utilization ARIN-2014-17 In-Reply-To: <92382919dbc54ce2b4a67ba387fac15a@DM2PR03MB398.namprd03.prod.outlook.com> References: <428fdbbbb3c5446995d03b091893dc66@EXCHMB-03.ad.qservco.com> <18B2C6E38A3A324986B392B2D18ABC5102C9C45855@fnb1mbx01.gci.com> <539F2F0B.5040402@quark.net> <92382919dbc54ce2b4a67ba387fac15a@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: Agreed re Baltimore Thanks, Jeff On Jun 16, 2014 2:13 PM, "David Huberman" wrote: > > > I believe we should discuss in Baltimore in front of a more substantial > audience. There are by enough people participating here, in my opinion, for > any "sense of the room" to make sense. > > David R Huberman > Microsoft Corporation > Senior IT/OPS Program Manager (GFS) > > ________________________________________ > From: arin-ppml-bounces at arin.net on behalf > of Andrew Dul > Sent: Monday, June 16, 2014 10:53:15 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy discussion - Method of calculating > utilization ARIN-2014-17 > > Hello, > > I sent a longer summary of where this policy discussion is last week, > I've pasted a link below to that message in the archive. > > http://lists.arin.net/pipermail/arin-ppml/2014-June/028654.html > > In general, I would say that this draft policy is stalled at this > point. The 80% utilization policy underpins a large majority of the > current policies and thus is a substantial change. There have been a > few people who have voiced their support, but not enough that I believe > would allow this policy to move forward as a recommended draft at this > point. > > I would also point out that they current policy also constrains larger > providers but in a different way as ARIN is now more closely enforcing > the current policy of "efficiently utilized all previous allocations" > (4.2.4.1) as noted during the NANOG PPC. > > Leif, I don't think there is an easy scaling algorithm to apply to > utilization. The problem with a scaling algorithm is it likely will be > perceived as "unfair" by organizations on one side of the size > continuum. (We tried HD ratio for v6 and that was not easily > understood, and lead to lots of confusion.) > > Thanks, > Andrew > > > > On 6/13/2014 4:33 PM, Leif Sawyer wrote: > > I was really hoping somebody would suggest, perhaps, some sort > > of easy-to-apply scaling algorithm so that it makes it easier for > > the smaller guys to get the space they need, but harder for the bigger > > guys to game the system. > > > > I'm sure there's some sort of curve that fits, but my advanced maths > > are limited to Pythagoras. > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Jeffrey Lyon > > Sent: Friday, June 13, 2014 2:41 PM > > To: Tim Gimmel > > Cc: arin-ppml at arin.net List > > Subject: Re: [arin-ppml] Policy discussion - Method of calculating > utilization > > > > Tim, > > > > I am also uncertain of the current status but would like to see some > progress. > > > > Thanks, Jeff > > > > On Sat, Jun 14, 2014 at 5:50 AM, Tim Gimmel > wrote: > >> I not really sure where this policy discussion is at the moment, but I > want to assert the current method places a strain on small carriers just > trying to do business. We are in the process of implementing IPv6, but is > will be a long journey. > >> Overall I am way past 80% utilization, but because my last allocation > (and this is based on actual usage, not just what has been 'swiped') has > not yet reached 80% we are practically stymied. > >> > >> Tim's 2 cents! > >> > >> Tim > >> > >> Tim Gimmel > >> Metronet | Senior Network Engineer > >> 3701 Communications Way | Evansville, IN 47715 > >> Office: 812.456.4750 > >> www.MetronetInc.com > >> > >> > >>> -----Original Message----- > >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > >>> On Behalf Of Owen DeLong > >>> Sent: Friday, May 02, 2014 8:14 PM > >>> To: Jeffrey Lyon > >>> Cc: arin-ppml at arin.net List > >>> Subject: Re: [arin-ppml] Policy discussion - Method of calculating > >>> utilization > >>> > >>> While I support Jeffry's proposal for changing the calculation > >>> method, in terms of changing the threshold, I'd like to say that I > >>> really think it is time to stop trying to re-arrange the IPv4 deck > >>> chairs and get on board the IPv6 luxury liners that have come to > >>> rescue us from the sinking IPv4 ship. > >>> > >>> Owen > >>> > >>> On May 2, 2014, at 6:04 PM, Jeffrey Lyon > >>> > >>> wrote: > >>> > >>>> On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess wrote: > >>>>> On Fri, May 2, 2014 at 7:33 PM, John Santos wrote: > >>>>>> On Fri, 2 May 2014, Jimmy Hess wrote: > >>>>>> I think 95% is too high, if the previous example of 3 /24's at > >>>>>> 100% and > >>>>>> 1 /24 at 75% is realistic. That works out to 93.75% aggregate > >>>>>> utilization, not quite reaching the bar, so 90% might be a better > >>> threshold. > >>>>> For 3 /24s yes. The difficulty here, is trying to pick a > single > >>>>> utilization proportion that works regardless of the aggregate > >>>>> allocation size, to allow for the loss of the oddball /26 or /27 that > >>>>> can neither be returned nor reused, perhaps another method is in > >>>>> order than presuming a single aggregate utilization criterion is > >>>>> the most proper. > >>>>> > >>>>> > >>>>> The more resources you are allocated, the more opportunity to make > >>>>> your resource allocation efficient. By the time you get down to a > >>>>> /26, an entire /24 is less than 0.4%. > >>>>> > >>>>> Aggregate Resources Allocated Required Aggregate > >>>>> Utilization criterion > >>>>> more than a /25 75% > >>>>> more than a /22, 80% > >>>>> more than a /20 85% > >>>>> more than a /19 90% > >>>>> more than a /18 95% > >>>>> more than a /17 97% > >>>>> more than a /16 98% > >>>>> more than a /15 99% > >>>>> > >>>>> > >>>>> > >>>>>> OTOH, /24's are pretty small and maybe that example was just for > >>>>>> illustration. If people really in this situation have much > >>>>>> larger allocations, they would be easier to slice and dice and > >>>>>> thus use > >>>>>> (relatively) efficiently. 75% of a /24 leaves just 64 addresses > >>>>>> (a > >>>>>> /26) unused, which even if contiguous are hard to redeploy for > >>>>>> some other use. 75% of a /16 would leave 16384 unused addresses, > >>>>>> which > >>> could be utilized much more easily. > >>>>>> > >>>>>> Personally, I don't much care since my company has its /24, and > >>>>>> that's probably all the IPv4 we'll ever need :-) > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> John Santos > >>>>>> Evans Griffiths & Hart, Inc. > >>>>>> 781-861-0670 ext 539 > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> -JH > >>>>> _______________________________________________ > >>>>> 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. > >>>> Jimmy, > >>>> > >>>> I would not support scaling this beyond 80% except at the larger > >>>> allocation levels (eg. perhaps /17 and shorter, aggregate). > >>>> > >>>> As a practical matter I believe these measures should be handled as > >>>> separate policy proposals. The current proposal should be limited > >>>> to the calculation method and perhaps you could write a new > >>>> proposal if you wanted to change the utilization threshold? > >>>> > >>>> Thanks, > >>>> -- > >>>> Jeffrey A. Lyon, CISSP-ISSMP > >>>> Fellow, Black Lotus Communications > >>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: > >>>> blacklotus.net _______________________________________________ > >>>> 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. > > > > > > -- > > Jeffrey A. Lyon, CISSP-ISSMP > > Fellow, Black Lotus Communications > > mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: > blacklotus.net _______________________________________________ > > 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 lar at mwtcorp.net Mon Jun 16 14:58:00 2014 From: lar at mwtcorp.net (lar at mwtcorp.net) Date: Mon, 16 Jun 2014 12:58:00 -0600 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <5AE88771-F659-4502-9458-A56A25A02107@delong.com> References: Message-ID: On Sat, 14 Jun 2014 06:59:39 -0700 Owen DeLong wrote: > Nobody is denying resources to organizations that can document need. I don?t know what your persistent failure is in this regard >or why you are finding it difficult. However, I have yet to see a case where any reasonable need was turned away by ARIN unless >one or more of the following circumstances existed: > > 1. The requestor refused to submit sufficient documentation. > 2. The requestor refused to sign the RSA > 3. The requestor refused to comply with community developed policy. > 4. The requestor?s need was so small that they could not qualify under policy. > Note: This last one has been so completely reduced in recent policy cycles that it is hard to imagine a scenario where it >would apply to any > but the most deliberate and stubborn of corner cases. > > As such, I?m sorry, but absent your willingness to disclose specific examples in detail, I find your argument suspect at best. > Owen, I'm sorry but this isn't quite true. I've had an issue myself. My allocation is a /20. 80% used leaves 819 usable addresses. But as you know they get scattered around. In the case that occurred I had a customer that needed a /22 and another that needed a /23. At the time I had a single open /24 and one /26, the rest was non-contingous /27's, 28's and 29's along with individual addresses that were part of static pools. Since 1996 I have totally renumbered my network 5 times. I'm not allergic to moving things but it takes months to coordinate with customers and irritates the h**l out of them. You can't do it every time to have a larger customer need some IP. They were both deployed and working networks. Not pie in the sky. At the time I was only swiping /29 and larger networks. The request was denied because I was not at the 80% usage for the /20 I had. Actually the swipe didn't show any of my pools or infrastructure while I had other documentation the swipe needed to be close before resources were going to be used going through the rest. The staff suggested that I swipe all assignments down to /32's to help and then assign multiple /27's and /28's to the customers get over the 80% hurdle. The customers were unwilling (probably unable) to configure multiple small networks and then loose them when the larger assignment came through and I was unwilling to "dry lab" it just for show. It is ironic that I could show how over 80% of what I was requesting was to be immediately used I couldn't do it on the previous allocation. One customer moved on and the other has been able to take over an allocation to another customer of a single /24. It still has caused problems but it allowed them to get by. It's unfair to blame "ARIN" for this. The staff are applying policy as best they can and when we leave them wiggle room to do what makes sense they seem willing to do it. I feel that the policy has been broken for a long time. I am not in favor of eliminating a needs test but I do feel showing how addresses are needed and how current assignments are not sufficient to meet those needs should be all that is necessary. Even more so with the transfer market. Obviously the challenge is how to write that up as a policy. I would argue that giving the staff more latitude to use some sense is part of the answer. Larry Ash > Owen > > On Jun 12, 2014, at 11:46 AM, Steven Ryerse wrote: > >> Owen, I would turn your argument around where you said " The fact that IP number policy does not have the force of government >>regulation doesn?t change the fact that circumventing community adopted policy for your own greed is tantamount to stealing >>someone?s furniture." >> >> I wouldn't use the word greed but I would say that denying real resources to real organizations now is stealing their future >>too! >> >> 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? >> >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong >> Sent: Thursday, June 12, 2014 9:31 AM >> To: Brandon Ross >> Cc: arin-ppml at arin.net List (arin-ppml at arin.net) >> Subject: Re: [arin-ppml] About needs basis in 8.3 transfers >> >> >> On Jun 11, 2014, at 1:36 PM, Brandon Ross wrote: >> >>> On Wed, 11 Jun 2014, Matthew Petach wrote: >>> >>>> I cannot absolutely prevent you from stealing my furniture if you so >>>> desire. However, that doesn't mean I'm not going to put a lock on my >>>> front door to at least make it harder for you, and make it patently >>>> clear that you're doing so against my express desires. >>> >>> As has been mentioned here before, stealing furnature is a criminal offence, writing a contract giving exclusive rights to >>>address space is not. That's a pretty crucial difference. If breaking and entering and stealing furnature were legal, the small >>>help of a lock on my porch screen door would make little difference to a "bad actor". Locks keep honest people honest, but if an >>>activity is not widely agreed to be immoral, locks won't help. >> >> This is a distinction without a difference. The fact that IP number policy does not have the force of government regulation >>doesn?t change the fact that circumventing community adopted policy for your own greed is tantamount to stealing someone?s >>furniture. >> >> Arguing that because policy doesn?t carry the force of law, we shouldn?t have policy is not, IMHO, what you want to do here. >>That basically serves as a request for real regulators to come in and develop number resource regulation in place of our lack of >>policy. >> >> At its core, the internet is built on cooperation among the various entities connecting to the network. That cooperation is >>governed by rules built through a community consensus process. While I agree the process isn?t perfect, I would argue that it has >>worked far better than any legislative processes I have observed and that we probably prefer to keep it. >> >>>> I'll ask plainly; for everyone voting for needs-free transfers; would >>>> you still vote that way, *if in doing so, you were guaranteed to not >>>> be able to obtain any number resources under the new policy*? >>> >>> I don't have any address resources now, and I don't ever plan on having any in the future, so sure, why not? >>> >>>> If not, I would claim your votes are not guided by the good of the >>>> community; they're guided by self-interest, and a hope and desire >>>> that you can get something for less effort than you can by following >>>> the current guidelines. >>> >>> Oh really? >> >> I think he was more talking about Mike B. and Steven R., than you, Brandon. >> >>> Much like Owen, I have a nice little business of helping small organizations navigate the ARIN process to get address space. >>> It's not a majority of my income, but it's pretty nice and easy work for me. If needs basis goes away, guess what else goes >>>away? >>> >>> Even though Owen and I are on opposite sides of this coversation, I can guarantee you right now that both of us, without fail, >>>are arguing solely for what we think is best for the community. >>> >>> It's quite ironic that I would make more money by arguing on your side of the issue, isn't it? >>> >>> Or maybe my conspiracy is to get v4 to run out faster so I can make more money on v6 deployment? >> >> It could be. I?m OK with that. ;-) >> >> Owen >> >> >> _______________________________________________ >> 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. Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From andrew.dul at quark.net Mon Jun 16 15:03:27 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 16 Jun 2014 12:03:27 -0700 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: References: Message-ID: <539F3F7F.9090802@quark.net> On 6/16/2014 11:58 AM, lar at mwtcorp.net wrote: > On Sat, 14 Jun 2014 06:59:39 -0700 > Owen DeLong wrote: >> Nobody is denying resources to organizations that can document need. >> I don?t know what your persistent failure is in this regard or why >> you are finding it difficult. However, I have yet to see a case where >> any reasonable need was turned away by ARIN unless one or more of the >> following circumstances existed: >> >> 1. The requestor refused to submit sufficient documentation. >> 2. The requestor refused to sign the RSA >> 3. The requestor refused to comply with community developed >> policy. >> 4. The requestor?s need was so small that they could not >> qualify under policy. >> Note: This last one has been so completely reduced in recent >> policy cycles that it is hard to imagine a scenario where it would >> apply to any >> but the most deliberate and stubborn of corner cases. >> >> As such, I?m sorry, but absent your willingness to disclose specific >> examples in detail, I find your argument suspect at best. >> > Owen, > I'm sorry but this isn't quite true. I've had an issue myself. My > allocation is a /20. > 80% used leaves 819 usable addresses. But as you know they get > scattered around. > In the case that occurred I had a customer that needed a /22 and > another that needed a /23. > At the time I had a single open /24 and one /26, the rest was > non-contingous /27's, 28's > and 29's along with individual addresses that were part of static > pools. Since 1996 I have > totally renumbered my network 5 times. I'm not allergic to moving > things but it takes months > to coordinate with customers and irritates the h**l out of them. You > can't do it every time > to have a larger customer need some IP. > > They were both deployed and working networks. Not pie in the sky. At > the time I was only > swiping /29 and larger networks. The request was denied because I was > not at the 80% > usage for the /20 I had. Actually the swipe didn't show any of my > pools or infrastructure > while I had other documentation the swipe needed to be close before > resources were going > to be used going through the rest. > > The staff suggested that I swipe all assignments down to /32's to help > and then assign > multiple /27's and /28's to the customers get over the 80% hurdle. The > customers were > unwilling (probably unable) to configure multiple small networks and > then loose them > when the larger assignment came through and I was unwilling to "dry > lab" it just for > show. It is ironic that I could show how over 80% of what I was > requesting was to > be immediately used I couldn't do it on the previous allocation. > One customer moved on and the other has been able to take over an > allocation to another > customer of a single /24. It still has caused problems but it allowed > them to get by. > > It's unfair to blame "ARIN" for this. The staff are applying policy as > best they > can and when we leave them wiggle room to do what makes sense they > seem willing to do it. > > I feel that the policy has been broken for a long time. I am not in > favor of > eliminating a needs test but I do feel showing how addresses > are needed and how current assignments are not sufficient to meet > those needs should be all that is necessary. Even more so with the > transfer market. Obviously the challenge is how to write that up as > a policy. I would argue that giving the staff more latitude to use > some sense is part of the answer. > Perhaps, we should just lower the utilization threshold to at least 50% in every allocation. Andrew From jeffrey.lyon at blacklotus.net Mon Jun 16 15:25:28 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 16 Jun 2014 15:25:28 -0400 Subject: [arin-ppml] About needs basis in 8.3 transfers In-Reply-To: <539F3F7F.9090802@quark.net> References: <539F3F7F.9090802@quark.net> Message-ID: That would be easier but my 2014-17 also addresses this issue. Thanks, Jeff On Jun 16, 2014 3:04 PM, "Andrew Dul" wrote: > On 6/16/2014 11:58 AM, lar at mwtcorp.net wrote: > > On Sat, 14 Jun 2014 06:59:39 -0700 > > Owen DeLong wrote: > >> Nobody is denying resources to organizations that can document need. > >> I don?t know what your persistent failure is in this regard or why > >> you are finding it difficult. However, I have yet to see a case where > >> any reasonable need was turned away by ARIN unless one or more of the > >> following circumstances existed: > >> > >> 1. The requestor refused to submit sufficient documentation. > >> 2. The requestor refused to sign the RSA > >> 3. The requestor refused to comply with community developed > >> policy. > >> 4. The requestor?s need was so small that they could not > >> qualify under policy. > >> Note: This last one has been so completely reduced in recent > >> policy cycles that it is hard to imagine a scenario where it would > >> apply to any > >> but the most deliberate and stubborn of corner cases. > >> > >> As such, I?m sorry, but absent your willingness to disclose specific > >> examples in detail, I find your argument suspect at best. > >> > > Owen, > > I'm sorry but this isn't quite true. I've had an issue myself. My > > allocation is a /20. > > 80% used leaves 819 usable addresses. But as you know they get > > scattered around. > > In the case that occurred I had a customer that needed a /22 and > > another that needed a /23. > > At the time I had a single open /24 and one /26, the rest was > > non-contingous /27's, 28's > > and 29's along with individual addresses that were part of static > > pools. Since 1996 I have > > totally renumbered my network 5 times. I'm not allergic to moving > > things but it takes months > > to coordinate with customers and irritates the h**l out of them. You > > can't do it every time > > to have a larger customer need some IP. > > > > They were both deployed and working networks. Not pie in the sky. At > > the time I was only > > swiping /29 and larger networks. The request was denied because I was > > not at the 80% > > usage for the /20 I had. Actually the swipe didn't show any of my > > pools or infrastructure > > while I had other documentation the swipe needed to be close before > > resources were going > > to be used going through the rest. > > > > The staff suggested that I swipe all assignments down to /32's to help > > and then assign > > multiple /27's and /28's to the customers get over the 80% hurdle. The > > customers were > > unwilling (probably unable) to configure multiple small networks and > > then loose them > > when the larger assignment came through and I was unwilling to "dry > > lab" it just for > > show. It is ironic that I could show how over 80% of what I was > > requesting was to > > be immediately used I couldn't do it on the previous allocation. > > One customer moved on and the other has been able to take over an > > allocation to another > > customer of a single /24. It still has caused problems but it allowed > > them to get by. > > > > It's unfair to blame "ARIN" for this. The staff are applying policy as > > best they > > can and when we leave them wiggle room to do what makes sense they > > seem willing to do it. > > > > I feel that the policy has been broken for a long time. I am not in > > favor of > > eliminating a needs test but I do feel showing how addresses > > are needed and how current assignments are not sufficient to meet > > those needs should be all that is necessary. Even more so with the > > transfer market. Obviously the challenge is how to write that up as > > a policy. I would argue that giving the staff more latitude to use > > some sense is part of the answer. > > > > Perhaps, we should just lower the utilization threshold to at least 50% > in every allocation. > > Andrew > _______________________________________________ > 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 Mon Jun 16 19:55:36 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 16 Jun 2014 16:55:36 -0700 Subject: [arin-ppml] Policy discussion - Method of calculating utilization ARIN-2014-17 In-Reply-To: References: <428fdbbbb3c5446995d03b091893dc66@EXCHMB-03.ad.qservco.com> <18B2C6E38A3A324986B392B2D18ABC5102C9C45855@fnb1mbx01.gci.com> <539F2F0B.5040402@quark.net> <92382919dbc54ce2b4a67ba387fac15a@DM2PR03MB398.namprd03.prod.outlook.com> Message-ID: <539F83F8.4070301@quark.net> As the current AC shepherd of this draft, I'm all for bringing this to Baltimore if there is something substantial to discuss. However, there is a lot of time between now and the next PPM time which we could use on the mailing-list to get to a better understanding of the issues surrounding the problem statement and crafting updated policy language to solve the problem. IMO, we shouldn't just "punt" to the next PPM. Everyone should also realize that time to discuss this in person will be greatly limited at the PPM by the current large docket of draft policies now before the community. Andrew On 6/16/2014 11:19 AM, Jeffrey Lyon wrote: > > Agreed re Baltimore > > Thanks, Jeff > > On Jun 16, 2014 2:13 PM, "David Huberman" > > > wrote: > > > > I believe we should discuss in Baltimore in front of a more > substantial audience. There are by enough people participating > here, in my opinion, for any "sense of the room" to make sense. > > David R Huberman > Microsoft Corporation > Senior IT/OPS Program Manager (GFS) > > ________________________________________ > From: arin-ppml-bounces at arin.net > > on behalf of Andrew Dul > > > Sent: Monday, June 16, 2014 10:53:15 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy discussion - Method of calculating > utilization ARIN-2014-17 > > Hello, > > I sent a longer summary of where this policy discussion is last week, > I've pasted a link below to that message in the archive. > > http://lists.arin.net/pipermail/arin-ppml/2014-June/028654.html > > In general, I would say that this draft policy is stalled at this > point. The 80% utilization policy underpins a large majority of the > current policies and thus is a substantial change. There have been a > few people who have voiced their support, but not enough that I > believe > would allow this policy to move forward as a recommended draft at this > point. > > I would also point out that they current policy also constrains larger > providers but in a different way as ARIN is now more closely enforcing > the current policy of "efficiently utilized all previous allocations" > (4.2.4.1) as noted during the NANOG PPC. > > Leif, I don't think there is an easy scaling algorithm to apply to > utilization. The problem with a scaling algorithm is it likely > will be > perceived as "unfair" by organizations on one side of the size > continuum. (We tried HD ratio for v6 and that was not easily > understood, and lead to lots of confusion.) > > Thanks, > Andrew > > > > On 6/13/2014 4:33 PM, Leif Sawyer wrote: > > I was really hoping somebody would suggest, perhaps, some sort > > of easy-to-apply scaling algorithm so that it makes it easier for > > the smaller guys to get the space they need, but harder for the > bigger > > guys to game the system. > > > > I'm sure there's some sort of curve that fits, but my advanced maths > > are limited to Pythagoras. > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net > ] On Behalf Of Jeffrey Lyon > > Sent: Friday, June 13, 2014 2:41 PM > > To: Tim Gimmel > > Cc: arin-ppml at arin.net List > > Subject: Re: [arin-ppml] Policy discussion - Method of > calculating utilization > > > > Tim, > > > > I am also uncertain of the current status but would like to see > some progress. > > > > Thanks, Jeff > > > > On Sat, Jun 14, 2014 at 5:50 AM, Tim Gimmel > > > wrote: > >> I not really sure where this policy discussion is at the > moment, but I want to assert the current method places a strain on > small carriers just trying to do business. We are in the process > of implementing IPv6, but is will be a long journey. > >> Overall I am way past 80% utilization, but because my last > allocation (and this is based on actual usage, not just what has > been 'swiped') has not yet reached 80% we are practically stymied. > >> > >> Tim's 2 cents! > >> > >> Tim > >> > >> Tim Gimmel > >> Metronet | Senior Network Engineer > >> 3701 Communications Way | Evansville, IN 47715 > >> Office: 812.456.4750 > >> www.MetronetInc.com > >> > >> > >>> -----Original Message----- > >>> From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net > ] > >>> On Behalf Of Owen DeLong > >>> Sent: Friday, May 02, 2014 8:14 PM > >>> To: Jeffrey Lyon > >>> Cc: arin-ppml at arin.net List > >>> Subject: Re: [arin-ppml] Policy discussion - Method of calculating > >>> utilization > >>> > >>> While I support Jeffry's proposal for changing the calculation > >>> method, in terms of changing the threshold, I'd like to say that I > >>> really think it is time to stop trying to re-arrange the IPv4 deck > >>> chairs and get on board the IPv6 luxury liners that have come to > >>> rescue us from the sinking IPv4 ship. > >>> > >>> Owen > >>> > >>> On May 2, 2014, at 6:04 PM, Jeffrey Lyon > >>> > > >>> wrote: > >>> > >>>> On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess > wrote: > >>>>> On Fri, May 2, 2014 at 7:33 PM, John Santos > wrote: > >>>>>> On Fri, 2 May 2014, Jimmy Hess wrote: > >>>>>> I think 95% is too high, if the previous example of 3 /24's at > >>>>>> 100% and > >>>>>> 1 /24 at 75% is realistic. That works out to 93.75% aggregate > >>>>>> utilization, not quite reaching the bar, so 90% might be a > better > >>> threshold. > >>>>> For 3 /24s yes. The difficulty here, is trying to > pick a single > >>>>> utilization proportion that works regardless of the aggregate > >>>>> allocation size, to allow for the loss of the oddball /26 or > /27 that > >>>>> can neither be returned nor reused, perhaps another > method is in > >>>>> order than presuming a single aggregate utilization > criterion is > >>>>> the most proper. > >>>>> > >>>>> > >>>>> The more resources you are allocated, the more opportunity > to make > >>>>> your resource allocation efficient. By the time you get > down to a > >>>>> /26, an entire /24 is less than 0.4%. > >>>>> > >>>>> Aggregate Resources Allocated Required > Aggregate > >>>>> Utilization criterion > >>>>> more than a /25 > 75% > >>>>> more than a /22, > 80% > >>>>> more than a /20 > 85% > >>>>> more than a /19 > 90% > >>>>> more than a /18 > 95% > >>>>> more than a /17 > 97% > >>>>> more than a /16 > 98% > >>>>> more than a /15 > 99% > >>>>> > >>>>> > >>>>> > >>>>>> OTOH, /24's are pretty small and maybe that example was > just for > >>>>>> illustration. If people really in this situation have much > >>>>>> larger allocations, they would be easier to slice and dice and > >>>>>> thus use > >>>>>> (relatively) efficiently. 75% of a /24 leaves just 64 > addresses > >>>>>> (a > >>>>>> /26) unused, which even if contiguous are hard to redeploy for > >>>>>> some other use. 75% of a /16 would leave 16384 unused > addresses, > >>>>>> which > >>> could be utilized much more easily. > >>>>>> > >>>>>> Personally, I don't much care since my company has its /24, and > >>>>>> that's probably all the IPv4 we'll ever need :-) > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> John Santos > >>>>>> Evans Griffiths & Hart, Inc. > >>>>>> 781-861-0670 ext 539 > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> -JH > >>>>> _______________________________________________ > >>>>> 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. > >>>> Jimmy, > >>>> > >>>> I would not support scaling this beyond 80% except at the larger > >>>> allocation levels (eg. perhaps /17 and shorter, aggregate). > >>>> > >>>> As a practical matter I believe these measures should be > handled as > >>>> separate policy proposals. The current proposal should be limited > >>>> to the calculation method and perhaps you could write a new > >>>> proposal if you wanted to change the utilization threshold? > >>>> > >>>> Thanks, > >>>> -- > >>>> Jeffrey A. Lyon, CISSP-ISSMP > >>>> Fellow, Black Lotus Communications > >>>> mobile: (757) 304-0668 | gtalk: > jeffrey.lyon at gmail.com | skype: > >>>> blacklotus.net > _______________________________________________ > >>>> 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. > > > > > > -- > > Jeffrey A. Lyon, CISSP-ISSMP > > Fellow, Black Lotus Communications > > mobile: (757) 304-0668 | gtalk: > jeffrey.lyon at gmail.com | skype: > blacklotus.net > _______________________________________________ > > 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 gdendy at equinix.com Tue Jun 17 00:31:58 2014 From: gdendy at equinix.com (Greg Dendy) Date: Mon, 16 Jun 2014 21:31:58 -0700 Subject: [arin-ppml] NANOG 62 - Baltimore - Call For Presentations is Open! Message-ID: <180F02C2-7158-4843-A43D-4CF7AA941A20@equinix.com> NANOG Community- Thanks for helping to make NANOG 61 in Bellevue such a smashing success as the most attended meeting ever, on the 20th anniversary of the first meeting! NANOG will hold its 62nd meeting in Baltimore, MD on October 6-8, 2014, hosted by EdgeConneX. The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG 62 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet, . Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability. Key dates to track if you wish to submit a presentation: * Presentation Abstracts and Draft Slides Due: August 4, 2014 * Topic List Posted: August 18, 2014 * Slides Due: September 1, 2014 * Agenda Published: September 15, 2014 NANOG 62 submissions are welcome on the Program Committee Site or email me if you have questions. Looking forward to seeing everyone in Baltimore! Thanks, Greg Dendy Chair, Program Committee North American Network Operator Group (NANOG) -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Jun 17 19:20:53 2014 From: farmer at umn.edu (David Farmer) Date: Tue, 17 Jun 2014 18:20:53 -0500 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers In-Reply-To: <537672F4.2060804@arin.net> References: <537672F4.2060804@arin.net> Message-ID: <53A0CD55.3020101@umn.edu> First, While this policy has a clearly formed problem statement, I don't support fixing the perceived problem and do not agree it is even a real problem. Then, the proposed solution to this none problem is "removing needs testing" for small IPv4 transfers. I can not support the concept of removing needs testing, that is a line I'm not willing to cross. However, some of the ideas for this policy come from comments I've made. But, for some reason those ideas are spun around to eliminate need, instead of redefining need, which I think can gain community consensus. I support a fundamental reexamination and redefinition of what justified need means in a post (or nearly post) free pool world. But, fundamentally there has to be need involved, the definition for that need may look radically different than what we have used for the last 20 years or so. I support redefining justified need for the transfer of a /24 and up to a /20 as justified by an officer attestation that the resources are needed for use on a operational network within 6 months and a willingness to expend financial resources necessary to acquire the IPv4 resources on the transfer market. However, this is only one small part of the reexamination and redefinition of justified need that is necessary, but is seems like a reasonable bit size chunk to start with. Some may argue that is the same thing that this policy does, and I must disagree; This policy wants to eliminate needs justification, granted only for small transfers. But it eliminates need none the less. Where as what I'm suggesting fundamental redefines and simplifies what justified need means in a post (or nearly post) free pool world for small transfers, but does not eliminate need. Granted, I'm talking about a fairly low bar being set. But there is a bar and it's not as low as some may think. The fact that IPv4 resources have to be acquired on the transfer market is accounted for as part of the demonstration of need, this is a real constraint for most organizations. Furthermore, the officer attestation requirement provides organizational commitment that resources are going to be used and not just stockpiled. I think the real problem this solves is failure of slow start when there is no free pool to prime the pump. So, unfortunately while this policy is at least partially based on my suggestion, I can not support the problem statement given, nor can I support the policy as written. Therefore, I suggest abandoning this problem statement and policy, and starting over with a problem statement focused on a different issue and not focusing on the elimination of need at a solution. On 5/16/14, 15:20 , ARIN wrote: > On 15 May 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-204 > Removing Needs Test from Small IPv4 Transfers" as a Draft Policy. > > Draft Policy ARIN-2014-14 is below and can be found at: > https://www.arin.net/policy/proposals/2014_14.html > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2014-14 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-2014-14 > Removing Needs Test from Small IPv4 Transfers > > Date: 16 May 2014 > > Problem Statement: > > ARIN staff, faced with a surge in near-exhaust allocations and > subsequent transfer requests and a requirement for team review of these, > is spending scarce staff time on needs testing of small transfers. This > proposal seeks to decrease overall ARIN processing time through > elimination of that needs test. > > Policy statement: > > Change the language in NRPM 8.3 after Conditions on the recipient of the > transfer: from "The recipient must demonstrate the need for up to a > 24-month supply of IP address resources under current ARIN policies and > sign an RSA." to "For transfers larger than a /16 equivalent or for > recipients who have completed a needs-free transfer in the prior year, > the recipient must demonstrate the need for up to a 24-month supply of > IP address resources under current ARIN policies and sign an RSA." > > Change the language in the third bullet point in NRPM 8.4 after > Conditions on the recipient of the transfer: from "Recipients within the > ARIN region must demonstrate the need for up to a 24-month supply of > IPv4 address space." to "For transfers larger than a /16 equivalent or > for recipients who have completed a needs-free transfer in the prior > year, recipients in the ARIN region must demonstrate the need for up to > a 24-month supply of IP address resources under current ARIN policies > and sign an RSA." > > Comments: > > Needs testing has been maintained for transfers largely because the > community wishes to ensure protection against hoarding and speculation > in the IPv4 market. This proposal seeks a middle ground between the > elimination of needs tests for transfers altogether, and the continuance > of needs tests for every transfer. This should help ARIN staff to reduce > transfer processing time, since most transfers have been smaller than /16. > > Timetable for implementation: Immediate -- ================================================ 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 springer at inlandnet.com Tue Jun 17 20:20:56 2014 From: springer at inlandnet.com (John Springer) Date: Tue, 17 Jun 2014 17:20:56 -0700 (PDT) Subject: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers In-Reply-To: <53A0CD55.3020101@umn.edu> References: <537672F4.2060804@arin.net> <53A0CD55.3020101@umn.edu> Message-ID: Hi David, On Tue, 17 Jun 2014, David Farmer wrote: > First, While this policy has a clearly formed problem statement, I don't > support fixing the perceived problem and do not agree it is even a real > problem. You mean the problem of delays in resource request processing time as suggested by Leslie and seemingly confirmed by others? Please share the information that you have that contradicts this. > Then, the proposed solution to this none problem is "removing needs testing" > for small IPv4 transfers. I can not support the concept of removing needs > testing, that is a line I'm not willing to cross. Why not? Because it is a line? Why? > However, some of the ideas for this policy come from comments I've made. > But, for some reason those ideas are spun around to eliminate need, instead > of redefining need, which I think can gain community consensus. Happens all the time. People have the right to spin. That some other proposal might gain consensus is not a valid argument against the current proposal. Cum hoc ergo propter hoc, probably > I support a fundamental reexamination and redefinition of what justified need > means in a post (or nearly post) free pool world. But, fundamentally there > has to be need involved, the definition for that need may look radically > different than what we have used for the last 20 years or so. First sentence, thank you for that good idea. Second sentence, Why? What gives you the right to say? To just declare and make it be so. State the reason. > I support redefining justified need for the transfer of a /24 and up to a /20 > as justified by an officer attestation that the resources are needed for use > on a operational network within 6 months and a willingness to expend > financial resources necessary to acquire the IPv4 resources on the transfer > market. However, this is only one small part of the reexamination and > redefinition of justified need that is necessary, but is seems like a > reasonable bit size chunk to start with. About .03%. Accurate numbers coming. A useless gesture. Symbolism. > Some may argue that is the same thing that this policy does, and I must > disagree; This policy wants to eliminate needs justification, granted only > for small transfers. But it eliminates need none the less. Argument through tautology. No one is disputing that this policy seeks to eliminate needs basis for small transfers. Please show your work. State the reason for your disagreement. Don't go in circles. Please. > Where as what I'm suggesting fundamental redefines and simplifies what > justified need means in a post (or nearly post) free pool world for small > transfers, but does not eliminate need. Possibly a good idea, but not a _REASON_ for not doing this. > Granted, I'm talking about a fairly > low bar being set. No danger of tripping. A piece of tape on the floor. > But there is a bar and it's not as low as some may think. This will require evidence, I think. I'll have some coming as soon as I stop being interrupted. > The fact that IPv4 resources have to be acquired on the transfer market is > accounted for as part of the demonstration of need, this is a real constraint > for most organizations. Furthermore, the officer attestation requirement > provides organizational commitment that resources are going to be used and > not just stockpiled. Not even a policy proposal, just the suggestion of one and it is an argument against 2014-14? No. > I think the real problem this solves is failure of slow start when there is > no free pool to prime the pump. Starting to see a pattern? Something that happened before is not evidence of causation. post hoc ergo propter hoc. > So, unfortunately while this policy is at least partially based on my > suggestion, I can not support the problem statement given, nor can I support > the policy as written. Therefore, I suggest abandoning this problem > statement and policy, and starting over with a problem statement focused on a > different issue and not focusing on the elimination of need at a solution. Everybody gets to change their mind. However unless you provide logical _REASONS_, your stance may be acknowledged and then not taken into account, by fair minded people who wish to have a logic based discussion. Clearly you _FEEL_ strongly. As Lee Howard would say, that does not make you more persuasive. Reasons will do that. John Springer > On 5/16/14, 15:20 , ARIN wrote: >> On 15 May 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-204 >> Removing Needs Test from Small IPv4 Transfers" as a Draft Policy. >> >> Draft Policy ARIN-2014-14 is below and can be found at: >> https://www.arin.net/policy/proposals/2014_14.html >> >> You are encouraged to discuss the merits and your concerns of Draft >> Policy 2014-14 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-2014-14 >> Removing Needs Test from Small IPv4 Transfers >> >> Date: 16 May 2014 >> >> Problem Statement: >> >> ARIN staff, faced with a surge in near-exhaust allocations and >> subsequent transfer requests and a requirement for team review of these, >> is spending scarce staff time on needs testing of small transfers. This >> proposal seeks to decrease overall ARIN processing time through >> elimination of that needs test. >> >> Policy statement: >> >> Change the language in NRPM 8.3 after Conditions on the recipient of the >> transfer: from "The recipient must demonstrate the need for up to a >> 24-month supply of IP address resources under current ARIN policies and >> sign an RSA." to "For transfers larger than a /16 equivalent or for >> recipients who have completed a needs-free transfer in the prior year, >> the recipient must demonstrate the need for up to a 24-month supply of >> IP address resources under current ARIN policies and sign an RSA." >> >> Change the language in the third bullet point in NRPM 8.4 after >> Conditions on the recipient of the transfer: from "Recipients within the >> ARIN region must demonstrate the need for up to a 24-month supply of >> IPv4 address space." to "For transfers larger than a /16 equivalent or >> for recipients who have completed a needs-free transfer in the prior >> year, recipients in the ARIN region must demonstrate the need for up to >> a 24-month supply of IP address resources under current ARIN policies >> and sign an RSA." >> >> Comments: >> >> Needs testing has been maintained for transfers largely because the >> community wishes to ensure protection against hoarding and speculation >> in the IPv4 market. This proposal seeks a middle ground between the >> elimination of needs tests for transfers altogether, and the continuance >> of needs tests for every transfer. This should help ARIN staff to reduce >> transfer processing time, since most transfers have been smaller than /16. >> >> Timetable for implementation: Immediate > > -- > ================================================ > 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 narten at us.ibm.com Fri Jun 20 00:53:02 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 20 Jun 2014 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201406200453.s5K4r3KX008944@rotala.raleigh.ibm.com> Total of 18 messages in the last 7 days. script run at: Fri Jun 20 00:53:02 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 16.67% | 3 | 25.18% | 68554 | andrew.dul at quark.net 16.67% | 3 | 22.85% | 62206 | jeffrey.lyon at blacklotus.net 5.56% | 1 | 6.69% | 18198 | hannigan at gmail.com 5.56% | 1 | 5.98% | 16290 | david.huberman at microsoft.com 5.56% | 1 | 4.91% | 13360 | springer at inlandnet.com 5.56% | 1 | 4.75% | 12920 | lar at mwtcorp.net 5.56% | 1 | 4.63% | 12610 | lsawyer at gci.com 5.56% | 1 | 4.44% | 12084 | farmer at umn.edu 5.56% | 1 | 4.21% | 11465 | owen at delong.com 5.56% | 1 | 4.00% | 10875 | tim.gimmel at metronetinc.com 5.56% | 1 | 3.92% | 10665 | gdendy at equinix.com 5.56% | 1 | 3.07% | 8349 | narten at us.ibm.com 5.56% | 1 | 3.02% | 8234 | mysidia at gmail.com 5.56% | 1 | 2.35% | 6400 | gary.buhrmaster at gmail.com --------+------+--------+----------+------------------------ 100.00% | 18 |100.00% | 272210 | Total From mueller at syr.edu Sun Jun 22 07:21:42 2014 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 22 Jun 2014 11:21:42 +0000 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers In-Reply-To: <53A0CD55.3020101@umn.edu> References: <537672F4.2060804@arin.net> <53A0CD55.3020101@umn.edu> Message-ID: <55ef28964e2947cb983ebe5e73778db3@EX13-MBX-13.ad.syr.edu> David I don't think an intransigent attitude toward retaining needs testing is justified by anything you have cited here or elsewhere. RIPE has basically eliminated needs assessment, see this article for an assessment of the results: http://www.internetgovernance.org/2014/06/20/baby-steps-and-big-differences-in-address-transfer-market/ In economics there is the concept of transaction costs. Needs testing is a transaction cost in both free pool allocations and market transfers. If the transactions costs are too high, it is a barrier to transactions happening at all. Basically, it means that you don't spend $5,000 worth of staff time and transacting parties' time to effectuate a transfer that may be worth $4,000 or even $6,000. I think the case that's being made here is that for small transfers, the cost of a full-fledged needs assessment is simply not worth the trouble, as it is disproportionately large relative to the value of the overall transaction. For the smaller transactions, which cannot really pose threats of hoarding and speculation, the value the community gains from imposing traditional needs assessment criteria is pretty minimal compared to the natural form of rationing you are going to get from the market price for the number block. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of David Farmer > Sent: Tuesday, June 17, 2014 7:21 PM > To: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test > from Small IPv4 Transfers > > First, While this policy has a clearly formed problem statement, I don't > support fixing the perceived problem and do not agree it is even a real > problem. > > Then, the proposed solution to this none problem is "removing needs > testing" for small IPv4 transfers. I can not support the concept of removing > needs testing, that is a line I'm not willing to cross. > > However, some of the ideas for this policy come from comments I've made. > But, for some reason those ideas are spun around to eliminate need, > instead of redefining need, which I think can gain community consensus. > > I support a fundamental reexamination and redefinition of what justified > need means in a post (or nearly post) free pool world. But, fundamentally > there has to be need involved, the definition for that need may look radically > different than what we have used for the last 20 years or so. > > I support redefining justified need for the transfer of a /24 and up to a /20 as > justified by an officer attestation that the resources are needed for use on a > operational network within 6 months and a willingness to expend financial > resources necessary to acquire the IPv4 resources on the transfer market. > However, this is only one small part of the reexamination and redefinition of > justified need that is necessary, but is seems like a reasonable bit size chunk > to start with. > > Some may argue that is the same thing that this policy does, and I must > disagree; This policy wants to eliminate needs justification, granted only for > small transfers. But it eliminates need none the less. > > Where as what I'm suggesting fundamental redefines and simplifies what > justified need means in a post (or nearly post) free pool world for small > transfers, but does not eliminate need. Granted, I'm talking about a fairly > low bar being set. But there is a bar and it's not as low as some may think. > The fact that IPv4 resources have to be acquired on the transfer market is > accounted for as part of the demonstration of need, this is a real constraint > for most organizations. Furthermore, the officer attestation requirement > provides organizational commitment that resources are going to be used and > not just stockpiled. > > I think the real problem this solves is failure of slow start when there is no > free pool to prime the pump. > > So, unfortunately while this policy is at least partially based on my > suggestion, I can not support the problem statement given, nor can I support > the policy as written. Therefore, I suggest abandoning this problem > statement and policy, and starting over with a problem statement focused on > a different issue and not focusing on the elimination of need at a solution. > > On 5/16/14, 15:20 , ARIN wrote: > > On 15 May 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-204 > > Removing Needs Test from Small IPv4 Transfers" as a Draft Policy. > > > > Draft Policy ARIN-2014-14 is below and can be found at: > > https://www.arin.net/policy/proposals/2014_14.html > > > > You are encouraged to discuss the merits and your concerns of Draft > > Policy 2014-14 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-2014-14 > > Removing Needs Test from Small IPv4 Transfers > > > > Date: 16 May 2014 > > > > Problem Statement: > > > > ARIN staff, faced with a surge in near-exhaust allocations and > > subsequent transfer requests and a requirement for team review of > > these, is spending scarce staff time on needs testing of small > > transfers. This proposal seeks to decrease overall ARIN processing > > time through elimination of that needs test. > > > > Policy statement: > > > > Change the language in NRPM 8.3 after Conditions on the recipient of > > the > > transfer: from "The recipient must demonstrate the need for up to a > > 24-month supply of IP address resources under current ARIN policies > > and sign an RSA." to "For transfers larger than a /16 equivalent or > > for recipients who have completed a needs-free transfer in the prior > > year, the recipient must demonstrate the need for up to a 24-month > > supply of IP address resources under current ARIN policies and sign an > RSA." > > > > Change the language in the third bullet point in NRPM 8.4 after > > Conditions on the recipient of the transfer: from "Recipients within > > the ARIN region must demonstrate the need for up to a 24-month supply > > of > > IPv4 address space." to "For transfers larger than a /16 equivalent or > > for recipients who have completed a needs-free transfer in the prior > > year, recipients in the ARIN region must demonstrate the need for up > > to a 24-month supply of IP address resources under current ARIN > > policies and sign an RSA." > > > > Comments: > > > > Needs testing has been maintained for transfers largely because the > > community wishes to ensure protection against hoarding and speculation > > in the IPv4 market. This proposal seeks a middle ground between the > > elimination of needs tests for transfers altogether, and the > > continuance of needs tests for every transfer. This should help ARIN > > staff to reduce transfer processing time, since most transfers have been > smaller than /16. > > > > Timetable for implementation: Immediate > > -- > ================================================ > 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 dogwallah at gmail.com Sun Jun 22 09:56:10 2014 From: dogwallah at gmail.com (McTim) Date: Sun, 22 Jun 2014 08:56:10 -0500 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers In-Reply-To: <55ef28964e2947cb983ebe5e73778db3@EX13-MBX-13.ad.syr.edu> References: <537672F4.2060804@arin.net> <53A0CD55.3020101@umn.edu> <55ef28964e2947cb983ebe5e73778db3@EX13-MBX-13.ad.syr.edu> Message-ID: Milton, On Sun, Jun 22, 2014 at 6:21 AM, Milton L Mueller wrote: > David > I don't think an intransigent attitude toward retaining needs testing is justified by anything you have cited here or elsewhere. None of the folks who support needs-testing are being intransigent. Most have signaled a willingness to compromise. RIPE has basically eliminated needs assessment, see this article for an assessment of the results: > http://www.internetgovernance.org/2014/06/20/baby-steps-and-big-differences-in-address-transfer-market/ > > In economics there is the concept of transaction costs. Needs testing is a transaction cost in both free pool allocations and market transfers. If the transactions costs are too high, it is a barrier to transactions happening at all. Basically, it means that you don't spend $5,000 worth of staff time and transacting parties' time to effectuate a transfer that may be worth $4,000 or even $6,000. > > I think the case that's being made here is that for small transfers, the cost of a full-fledged needs assessment is simply not worth the trouble, as it is disproportionately large relative to the value of the overall transaction. For the smaller transactions, which cannot really pose threats of hoarding and speculation, the value the community gains from imposing traditional needs assessment criteria is pretty minimal compared to the natural form of rationing you are going to get from the market price for the number block. As David said: "I don't support fixing the perceived problem and do not agree it is even a real problem." "Problem Statement: ARIN staff, faced with a surge in near-exhaust allocations and subsequent transfer requests and a requirement for team review of these, is spending scarce staff time on needs testing of small transfers..." Do you have evidence from Registration Services that it is a "real problem"? The data you provide on the link above doesn't show this at all. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel p.s. the Metropole lobby does a smashing High Tea > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >> On Behalf Of David Farmer >> Sent: Tuesday, June 17, 2014 7:21 PM >> To: ARIN PPML >> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test >> from Small IPv4 Transfers >> >> First, While this policy has a clearly formed problem statement, I don't >> support fixing the perceived problem and do not agree it is even a real >> problem. >> >> Then, the proposed solution to this none problem is "removing needs >> testing" for small IPv4 transfers. I can not support the concept of removing >> needs testing, that is a line I'm not willing to cross. >> >> However, some of the ideas for this policy come from comments I've made. >> But, for some reason those ideas are spun around to eliminate need, >> instead of redefining need, which I think can gain community consensus. >> >> I support a fundamental reexamination and redefinition of what justified >> need means in a post (or nearly post) free pool world. But, fundamentally >> there has to be need involved, the definition for that need may look radically >> different than what we have used for the last 20 years or so. >> >> I support redefining justified need for the transfer of a /24 and up to a /20 as >> justified by an officer attestation that the resources are needed for use on a >> operational network within 6 months and a willingness to expend financial >> resources necessary to acquire the IPv4 resources on the transfer market. >> However, this is only one small part of the reexamination and redefinition of >> justified need that is necessary, but is seems like a reasonable bit size chunk >> to start with. >> >> Some may argue that is the same thing that this policy does, and I must >> disagree; This policy wants to eliminate needs justification, granted only for >> small transfers. But it eliminates need none the less. >> >> Where as what I'm suggesting fundamental redefines and simplifies what >> justified need means in a post (or nearly post) free pool world for small >> transfers, but does not eliminate need. Granted, I'm talking about a fairly >> low bar being set. But there is a bar and it's not as low as some may think. >> The fact that IPv4 resources have to be acquired on the transfer market is >> accounted for as part of the demonstration of need, this is a real constraint >> for most organizations. Furthermore, the officer attestation requirement >> provides organizational commitment that resources are going to be used and >> not just stockpiled. >> >> I think the real problem this solves is failure of slow start when there is no >> free pool to prime the pump. >> >> So, unfortunately while this policy is at least partially based on my >> suggestion, I can not support the problem statement given, nor can I support >> the policy as written. Therefore, I suggest abandoning this problem >> statement and policy, and starting over with a problem statement focused on >> a different issue and not focusing on the elimination of need at a solution. >> >> On 5/16/14, 15:20 , ARIN wrote: >> > On 15 May 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-204 >> > Removing Needs Test from Small IPv4 Transfers" as a Draft Policy. >> > >> > Draft Policy ARIN-2014-14 is below and can be found at: >> > https://www.arin.net/policy/proposals/2014_14.html >> > >> > You are encouraged to discuss the merits and your concerns of Draft >> > Policy 2014-14 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-2014-14 >> > Removing Needs Test from Small IPv4 Transfers >> > >> > Date: 16 May 2014 >> > >> > Problem Statement: >> > >> > ARIN staff, faced with a surge in near-exhaust allocations and >> > subsequent transfer requests and a requirement for team review of >> > these, is spending scarce staff time on needs testing of small >> > transfers. This proposal seeks to decrease overall ARIN processing >> > time through elimination of that needs test. >> > >> > Policy statement: >> > >> > Change the language in NRPM 8.3 after Conditions on the recipient of >> > the >> > transfer: from "The recipient must demonstrate the need for up to a >> > 24-month supply of IP address resources under current ARIN policies >> > and sign an RSA." to "For transfers larger than a /16 equivalent or >> > for recipients who have completed a needs-free transfer in the prior >> > year, the recipient must demonstrate the need for up to a 24-month >> > supply of IP address resources under current ARIN policies and sign an >> RSA." >> > >> > Change the language in the third bullet point in NRPM 8.4 after >> > Conditions on the recipient of the transfer: from "Recipients within >> > the ARIN region must demonstrate the need for up to a 24-month supply >> > of >> > IPv4 address space." to "For transfers larger than a /16 equivalent or >> > for recipients who have completed a needs-free transfer in the prior >> > year, recipients in the ARIN region must demonstrate the need for up >> > to a 24-month supply of IP address resources under current ARIN >> > policies and sign an RSA." >> > >> > Comments: >> > >> > Needs testing has been maintained for transfers largely because the >> > community wishes to ensure protection against hoarding and speculation >> > in the IPv4 market. This proposal seeks a middle ground between the >> > elimination of needs tests for transfers altogether, and the >> > continuance of needs tests for every transfer. This should help ARIN >> > staff to reduce transfer processing time, since most transfers have been >> smaller than /16. >> > >> > Timetable for implementation: Immediate >> >> -- >> ================================================ >> 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 SRyerse at eclipse-networks.com Sun Jun 22 14:15:43 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Sun, 22 Jun 2014 18:15:43 +0000 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test fromSmall IPv4 Transfers In-Reply-To: References: <537672F4.2060804@arin.net> <53A0CD55.3020101@umn.edu><55ef28964e2947cb983ebe5e73778db3@EX13-MBX-13.ad.syr.edu> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AF9A6E1@ENI-MAIL.eclipse-networks.com> Milton's conclusion in the research for his article: http://www.internetgovernance.org/2014/06/20/baby-steps-and-big-differences-in-address-transfer-market/ indicates that the significant majority of the transfers as a result of the removal of needs testing in Policy of other RIRs is in the smallest block sizes in the /19-/22 range. It seems obvious that smaller Organizations with smaller requirements are the ones who have been prevented via the Needs Policies of the RIRs of getting the resources they require. Thus the large increase in transfers in the /19-/22 range. I'm guessing that the pent-up need will at some point be alleviated and the allocation rate will then level off. Milton's research is empirical evidence that the Draft Policy ARIN-2014-14 is right on target to alleviate this inequity. McTim noted below "None of the folks who support needs-testing are being intransigent. Most have signaled a willingness to compromise." I would agree that in a recent post by McTim, he did indeed adjust his position on needs requirements by supporting the removal of needs on a /24 - but only on a /24 which is very small. I've seen Milton defending needs removal like was done in the RIPE region. I also recall Owen mentioning that he was willing to support a trial of the needs removal only on small blocks. I have also seen a number of folks who don't post here very often mentioning that they support 2014-14. Maybe I've missed it but I haven't seen many longtime highly involved members of this community come out for removal of needs testing. I don't want to put words in his mouth, but I think that is what Milton was getting at in his post to David this morning. I fully support 2014-14 and hope enough of the members of this community will support it so that it is adopted. Then the backlog here in the ARIN region for small organizations can also be remedied. I also have submitted a proposal to the AC to remove needs testing entirely on all minimum IPv4 allocation requests and you will see that in the near future. Cheers! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of McTim Sent: Sunday, June 22, 2014 9:56 AM To: Milton L Mueller Cc: ARIN PPML Subject: Re: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test fromSmall IPv4 Transfers Milton, On Sun, Jun 22, 2014 at 6:21 AM, Milton L Mueller wrote: > David > I don't think an intransigent attitude toward retaining needs testing is justified by anything you have cited here or elsewhere. None of the folks who support needs-testing are being intransigent. Most have signaled a willingness to compromise. RIPE has basically eliminated needs assessment, see this article for an assessment of the results: > http://www.internetgovernance.org/2014/06/20/baby-steps-and-big-differ > ences-in-address-transfer-market/ > > In economics there is the concept of transaction costs. Needs testing is a transaction cost in both free pool allocations and market transfers. If the transactions costs are too high, it is a barrier to transactions happening at all. Basically, it means that you don't spend $5,000 worth of staff time and transacting parties' time to effectuate a transfer that may be worth $4,000 or even $6,000. > > I think the case that's being made here is that for small transfers, the cost of a full-fledged needs assessment is simply not worth the trouble, as it is disproportionately large relative to the value of the overall transaction. For the smaller transactions, which cannot really pose threats of hoarding and speculation, the value the community gains from imposing traditional needs assessment criteria is pretty minimal compared to the natural form of rationing you are going to get from the market price for the number block. As David said: "I don't support fixing the perceived problem and do not agree it is even a real problem." "Problem Statement: ARIN staff, faced with a surge in near-exhaust allocations and subsequent transfer requests and a requirement for team review of these, is spending scarce staff time on needs testing of small transfers..." Do you have evidence from Registration Services that it is a "real problem"? The data you provide on the link above doesn't show this at all. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel p.s. the Metropole lobby does a smashing High Tea > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >> On Behalf Of David Farmer >> Sent: Tuesday, June 17, 2014 7:21 PM >> To: ARIN PPML >> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs >> Test from Small IPv4 Transfers >> >> First, While this policy has a clearly formed problem statement, I >> don't support fixing the perceived problem and do not agree it is >> even a real problem. >> >> Then, the proposed solution to this none problem is "removing needs >> testing" for small IPv4 transfers. I can not support the concept of >> removing needs testing, that is a line I'm not willing to cross. >> >> However, some of the ideas for this policy come from comments I've made. >> But, for some reason those ideas are spun around to eliminate need, >> instead of redefining need, which I think can gain community consensus. >> >> I support a fundamental reexamination and redefinition of what >> justified need means in a post (or nearly post) free pool world. >> But, fundamentally there has to be need involved, the definition for >> that need may look radically different than what we have used for the last 20 years or so. >> >> I support redefining justified need for the transfer of a /24 and up >> to a /20 as justified by an officer attestation that the resources >> are needed for use on a operational network within 6 months and a >> willingness to expend financial resources necessary to acquire the IPv4 resources on the transfer market. >> However, this is only one small part of the reexamination and >> redefinition of justified need that is necessary, but is seems like a >> reasonable bit size chunk to start with. >> >> Some may argue that is the same thing that this policy does, and I >> must disagree; This policy wants to eliminate needs justification, >> granted only for small transfers. But it eliminates need none the less. >> >> Where as what I'm suggesting fundamental redefines and simplifies >> what justified need means in a post (or nearly post) free pool world >> for small transfers, but does not eliminate need. Granted, I'm >> talking about a fairly low bar being set. But there is a bar and it's not as low as some may think. >> The fact that IPv4 resources have to be acquired on the transfer >> market is accounted for as part of the demonstration of need, this is >> a real constraint for most organizations. Furthermore, the officer >> attestation requirement provides organizational commitment that >> resources are going to be used and not just stockpiled. >> >> I think the real problem this solves is failure of slow start when >> there is no free pool to prime the pump. >> >> So, unfortunately while this policy is at least partially based on my >> suggestion, I can not support the problem statement given, nor can I >> support the policy as written. Therefore, I suggest abandoning this >> problem statement and policy, and starting over with a problem >> statement focused on a different issue and not focusing on the elimination of need at a solution. >> >> On 5/16/14, 15:20 , ARIN wrote: >> > On 15 May 2014 the ARIN Advisory Council (AC) accepted >> > "ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers" as a Draft Policy. >> > >> > Draft Policy ARIN-2014-14 is below and can be found at: >> > https://www.arin.net/policy/proposals/2014_14.html >> > >> > You are encouraged to discuss the merits and your concerns of Draft >> > Policy 2014-14 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-2014-14 >> > Removing Needs Test from Small IPv4 Transfers >> > >> > Date: 16 May 2014 >> > >> > Problem Statement: >> > >> > ARIN staff, faced with a surge in near-exhaust allocations and >> > subsequent transfer requests and a requirement for team review of >> > these, is spending scarce staff time on needs testing of small >> > transfers. This proposal seeks to decrease overall ARIN processing >> > time through elimination of that needs test. >> > >> > Policy statement: >> > >> > Change the language in NRPM 8.3 after Conditions on the recipient >> > of the >> > transfer: from "The recipient must demonstrate the need for up to a >> > 24-month supply of IP address resources under current ARIN policies >> > and sign an RSA." to "For transfers larger than a /16 equivalent or >> > for recipients who have completed a needs-free transfer in the >> > prior year, the recipient must demonstrate the need for up to a >> > 24-month supply of IP address resources under current ARIN policies >> > and sign an >> RSA." >> > >> > Change the language in the third bullet point in NRPM 8.4 after >> > Conditions on the recipient of the transfer: from "Recipients >> > within the ARIN region must demonstrate the need for up to a >> > 24-month supply of >> > IPv4 address space." to "For transfers larger than a /16 equivalent >> > or for recipients who have completed a needs-free transfer in the >> > prior year, recipients in the ARIN region must demonstrate the need >> > for up to a 24-month supply of IP address resources under current >> > ARIN policies and sign an RSA." >> > >> > Comments: >> > >> > Needs testing has been maintained for transfers largely because the >> > community wishes to ensure protection against hoarding and >> > speculation in the IPv4 market. This proposal seeks a middle ground >> > between the elimination of needs tests for transfers altogether, >> > and the continuance of needs tests for every transfer. This should >> > help ARIN staff to reduce transfer processing time, since most >> > transfers have been >> smaller than /16. >> > >> > Timetable for implementation: Immediate >> >> -- >> ================================================ >> 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. _______________________________________________ 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 Sun Jun 22 21:27:08 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 22 Jun 2014 18:27:08 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test fromSmall IPv4 Transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AF9A6E1@ENI-MAIL.eclipse-networks.com> References: <537672F4.2060804@arin.net> <53A0CD55.3020101@umn.edu><55ef28964e2947cb983ebe5e73778db3@EX13-MBX-13.ad.syr.edu> <5B9E90747FA2974D91A54FCFA1B8AD12015AF9A6E1@ENI-MAIL.eclipse-networks.com> Message-ID: On Jun 22, 2014, at 11:15 AM, Steven Ryerse wrote: > Milton's conclusion in the research for his article: > > http://www.internetgovernance.org/2014/06/20/baby-steps-and-big-differences-in-address-transfer-market/ > > indicates that the significant majority of the transfers as a result of the removal of needs testing in Policy of other RIRs is in the smallest block sizes in the /19-/22 range. It seems obvious that smaller Organizations with smaller requirements are the ones who have been prevented via the Needs Policies of the RIRs of getting the resources they require. Thus the large increase in transfers in the /19-/22 range. I'm guessing that the pent-up need will at some point be alleviated and the allocation rate will then level off. > Post hoc ergo propter hoc In fact, the vast majority of address blocks issued from the free pools are in the /19-/22 range and so the vast majority of needs, requests, etc. also fall into that range. The fact that the distribution both with and without needs basis seems to fall along roughly the same lines in terms of block size distribution seems to me to say that elimination of needs basis testing has not shown to have any meaningful effect, in fact. > Milton's research is empirical evidence that the Draft Policy ARIN-2014-14 is right on target to alleviate this inequity. I really don?t see it as such. Owen From jeffrey.lyon at blacklotus.net Sun Jun 22 22:13:20 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 23 Jun 2014 11:13:20 +0900 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test fromSmall IPv4 Transfers In-Reply-To: References: <537672F4.2060804@arin.net> <53A0CD55.3020101@umn.edu> <55ef28964e2947cb983ebe5e73778db3@EX13-MBX-13.ad.syr.edu> <5B9E90747FA2974D91A54FCFA1B8AD12015AF9A6E1@ENI-MAIL.eclipse-networks.com> Message-ID: All, I just wanted to jump in and signal my support for removing needs testing completely, ala RIPE. You may now return to your regularly scheduled argument :) Thanks, Jeff On Jun 22, 2014 9:24 PM, "Owen DeLong" wrote: > > On Jun 22, 2014, at 11:15 AM, Steven Ryerse > wrote: > > > Milton's conclusion in the research for his article: > > > > > http://www.internetgovernance.org/2014/06/20/baby-steps-and-big-differences-in-address-transfer-market/ > > > > indicates that the significant majority of the transfers as a result of > the removal of needs testing in Policy of other RIRs is in the smallest > block sizes in the /19-/22 range. It seems obvious that smaller > Organizations with smaller requirements are the ones who have been > prevented via the Needs Policies of the RIRs of getting the resources they > require. Thus the large increase in transfers in the /19-/22 range. I'm > guessing that the pent-up need will at some point be alleviated and the > allocation rate will then level off. > > > > Post hoc ergo propter hoc > > In fact, the vast majority of address blocks issued from the free pools > are in the /19-/22 range and so the vast majority of needs, requests, etc. > also fall into that range. The fact that the distribution both with and > without needs basis seems to fall along roughly the same lines in terms of > block size distribution seems to me to say that elimination of needs basis > testing has not shown to have any meaningful effect, in fact. > > > Milton's research is empirical evidence that the Draft Policy > ARIN-2014-14 is right on target to alleviate this inequity. > > I really don?t see it as such. > > Owen > > _______________________________________________ > 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 mike at iptrading.com Mon Jun 23 10:40:38 2014 From: mike at iptrading.com (Mike Burns) Date: Mon, 23 Jun 2014 10:40:38 -0400 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs TestfromSmall IPv4 Transfers In-Reply-To: References: <537672F4.2060804@arin.net><53A0CD55.3020101@umn.edu><55ef28964e2947cb983ebe5e73778db3@EX13-MBX-13.ad.syr.edu><5B9E90747FA2974D91A54FCFA1B8AD12015AF9A6E1@ENI-MAIL.eclipse-networks.com> Message-ID: <807042DE61CB468DA177DD1107BB77B7@MPC> The fact that the distribution both with and without needs basis seems to fall along roughly the same lines in terms of block size distribution seems to me to say that elimination of needs basis testing has not shown to have any meaningful effect, in fact. Owen Hi Owen, This also means no evidence of speculation, unless for some reason you think speculators wish to engage in many small transactions for some reason. Clearly there were no speculators waiting with bated breath for the elimination of needs-testing so they could begin buying addresses, and also there is no evidence of overbuying by recipients who were otherwise limited by the amount they could justify. I have seen fears that both of these activities would be the result of eliminating the needs-test, and we can say from this early data that such activity has not manifested to a large and obvious extent, at least. In other words, there are limits to speculation baked-in, including fragmented supply, public recording of transactions, and looming IPv6. And the limits to overbuying or hoarding are provided by the co$t of the addresses and the realization that there is likely to be a vibrant and more open future market in IPv4 addresses for any future address needs. Regards, Mike From dogwallah at gmail.com Mon Jun 23 14:44:22 2014 From: dogwallah at gmail.com (McTim) Date: Mon, 23 Jun 2014 13:44:22 -0500 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test fromSmall IPv4 Transfers In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AF9A6E1@ENI-MAIL.eclipse-networks.com> References: <537672F4.2060804@arin.net> <53A0CD55.3020101@umn.edu> <55ef28964e2947cb983ebe5e73778db3@EX13-MBX-13.ad.syr.edu> <5B9E90747FA2974D91A54FCFA1B8AD12015AF9A6E1@ENI-MAIL.eclipse-networks.com> Message-ID: On Sun, Jun 22, 2014 at 1:15 PM, Steven Ryerse wrote: > Milton's conclusion in the research for his article: > > http://www.internetgovernance.org/2014/06/20/baby-steps-and-big-differences-in-address-transfer-market/ > > indicates that the significant majority of the transfers as a result of the removal of needs testing in Policy of other RIRs is in the smallest block sizes in the /19-/22 range. I'd rather look at data than conclusions: "Just eleven (11) transfers have occurred within the ARIN region. Fifteen additional transfers, including a /13 (524,288 addresses), have been inter-regional from ARIN to APNIC." So where is the flood of transfer requests mentioned in the Problem Statement? I don't see it. If RS says it is a problem, I'd be happy to believe them, but I've never known them to complain about workload before. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From kkargel at polartel.com Mon Jun 23 15:22:20 2014 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 23 Jun 2014 14:22:20 -0500 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test fromSmall IPv4 Transfers In-Reply-To: References: <537672F4.2060804@arin.net> <53A0CD55.3020101@umn.edu> <55ef28964e2947cb983ebe5e73778db3@EX13-MBX-13.ad.syr.edu> <5B9E90747FA2974D91A54FCFA1B8AD12015AF9A6E1@ENI-MAIL.eclipse-networks.com> Message-ID: <8695009A81378E48879980039EEDAD28013A962EBC@MAIL1.polartel.local> Out of curiosity, how many transfers have there been from APNIC to ARIN in the same time frame? Does anyone besides me want to bet on zero? Kevin > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of McTim > Sent: Monday, June 23, 2014 1:44 PM > To: Steven Ryerse > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test > fromSmall IPv4 Transfers > > On Sun, Jun 22, 2014 at 1:15 PM, Steven Ryerse networks.com> wrote: > > Milton's conclusion in the research for his article: > > > > http://www.internetgovernance.org/2014/06/20/baby-steps-and-big- > differ > > ences-in-address-transfer-market/ > > > > indicates that the significant majority of the transfers as a result of the > removal of needs testing in Policy of other RIRs is in the smallest block sizes in > the /19-/22 range. > > > I'd rather look at data than conclusions: > > > "Just eleven (11) transfers have occurred within the ARIN region. > Fifteen additional transfers, including a /13 (524,288 addresses), have been > inter-regional from ARIN to APNIC." > > > > So where is the flood of transfer requests mentioned in the Problem > Statement? > > I don't see it. > > If RS says it is a problem, I'd be happy to believe them, but I've never known > them to complain about workload before. > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A route > indicates how we get there." Jon Postel > _______________________________________________ > 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 jeffrey.lyon at blacklotus.net Mon Jun 23 16:49:18 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 24 Jun 2014 05:49:18 +0900 Subject: [arin-ppml] Policy discussion - Method of calculating utilization ARIN-2014-17 In-Reply-To: <539F83F8.4070301@quark.net> References: <428fdbbbb3c5446995d03b091893dc66@EXCHMB-03.ad.qservco.com> <18B2C6E38A3A324986B392B2D18ABC5102C9C45855@fnb1mbx01.gci.com> <539F2F0B.5040402@quark.net> <92382919dbc54ce2b4a67ba387fac15a@DM2PR03MB398.namprd03.prod.outlook.com> <539F83F8.4070301@quark.net> Message-ID: Andrew, The destiny of this policy proposal is somewhat influenced by ARIN-2014-14. If needs testing were eliminated on "Small" transfers (as defined by ARIN policy), then ARIN-2014-17 may be obsolete. I continue to support ARIN-2014-17 on the premise that it is much less controversial than -14 and I feel we can get it passed much easier as I have not seen any violent opposition. The problem is that the current process has disenfranchised smaller companies who are somewhat frequently requesting space under the 3 month need projection and are ending up with many /22's, /21's etc instead of the /20 or /19 that would have been possible prior to austerity measures. To make matters worse, it does not seem that such companies are substantially represented on PPML so it is creating an illusion that the policy is not necessary or would not be supported by the community at large (outside of PPML). Thanks, Jeff On Tue, Jun 17, 2014 at 8:55 AM, Andrew Dul wrote: > As the current AC shepherd of this draft, I'm all for bringing this to > Baltimore if there is something substantial to discuss. However, there is a > lot of time between now and the next PPM time which we could use on the > mailing-list to get to a better understanding of the issues surrounding the > problem statement and crafting updated policy language to solve the problem. > IMO, we shouldn't just "punt" to the next PPM. Everyone should also realize > that time to discuss this in person will be greatly limited at the PPM by > the current large docket of draft policies now before the community. > > Andrew > > > On 6/16/2014 11:19 AM, Jeffrey Lyon wrote: > > Agreed re Baltimore > > Thanks, Jeff > > On Jun 16, 2014 2:13 PM, "David Huberman" > wrote: >> >> >> >> I believe we should discuss in Baltimore in front of a more substantial >> audience. There are by enough people participating here, in my opinion, for >> any "sense of the room" to make sense. >> >> David R Huberman >> Microsoft Corporation >> Senior IT/OPS Program Manager (GFS) >> >> ________________________________________ >> From: arin-ppml-bounces at arin.net on behalf of >> Andrew Dul >> Sent: Monday, June 16, 2014 10:53:15 AM >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Policy discussion - Method of calculating >> utilization ARIN-2014-17 >> >> Hello, >> >> I sent a longer summary of where this policy discussion is last week, >> I've pasted a link below to that message in the archive. >> >> http://lists.arin.net/pipermail/arin-ppml/2014-June/028654.html >> >> In general, I would say that this draft policy is stalled at this >> point. The 80% utilization policy underpins a large majority of the >> current policies and thus is a substantial change. There have been a >> few people who have voiced their support, but not enough that I believe >> would allow this policy to move forward as a recommended draft at this >> point. >> >> I would also point out that they current policy also constrains larger >> providers but in a different way as ARIN is now more closely enforcing >> the current policy of "efficiently utilized all previous allocations" >> (4.2.4.1) as noted during the NANOG PPC. >> >> Leif, I don't think there is an easy scaling algorithm to apply to >> utilization. The problem with a scaling algorithm is it likely will be >> perceived as "unfair" by organizations on one side of the size >> continuum. (We tried HD ratio for v6 and that was not easily >> understood, and lead to lots of confusion.) >> >> Thanks, >> Andrew >> >> >> >> On 6/13/2014 4:33 PM, Leif Sawyer wrote: >> > I was really hoping somebody would suggest, perhaps, some sort >> > of easy-to-apply scaling algorithm so that it makes it easier for >> > the smaller guys to get the space they need, but harder for the bigger >> > guys to game the system. >> > >> > I'm sure there's some sort of curve that fits, but my advanced maths >> > are limited to Pythagoras. >> > >> > >> > -----Original Message----- >> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> > Behalf Of Jeffrey Lyon >> > Sent: Friday, June 13, 2014 2:41 PM >> > To: Tim Gimmel >> > Cc: arin-ppml at arin.net List >> > Subject: Re: [arin-ppml] Policy discussion - Method of calculating >> > utilization >> > >> > Tim, >> > >> > I am also uncertain of the current status but would like to see some >> > progress. >> > >> > Thanks, Jeff >> > >> > On Sat, Jun 14, 2014 at 5:50 AM, Tim Gimmel >> > wrote: >> >> I not really sure where this policy discussion is at the moment, but I >> >> want to assert the current method places a strain on small carriers just >> >> trying to do business. We are in the process of implementing IPv6, but is >> >> will be a long journey. >> >> Overall I am way past 80% utilization, but because my last allocation >> >> (and this is based on actual usage, not just what has been 'swiped') has not >> >> yet reached 80% we are practically stymied. >> >> >> >> Tim's 2 cents! >> >> >> >> Tim >> >> >> >> Tim Gimmel >> >> Metronet | Senior Network Engineer >> >> 3701 Communications Way | Evansville, IN 47715 >> >> Office: 812.456.4750 >> >> www.MetronetInc.com >> >> >> >> >> >>> -----Original Message----- >> >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >> >>> On Behalf Of Owen DeLong >> >>> Sent: Friday, May 02, 2014 8:14 PM >> >>> To: Jeffrey Lyon >> >>> Cc: arin-ppml at arin.net List >> >>> Subject: Re: [arin-ppml] Policy discussion - Method of calculating >> >>> utilization >> >>> >> >>> While I support Jeffry's proposal for changing the calculation >> >>> method, in terms of changing the threshold, I'd like to say that I >> >>> really think it is time to stop trying to re-arrange the IPv4 deck >> >>> chairs and get on board the IPv6 luxury liners that have come to >> >>> rescue us from the sinking IPv4 ship. >> >>> >> >>> Owen >> >>> >> >>> On May 2, 2014, at 6:04 PM, Jeffrey Lyon >> >>> >> >>> wrote: >> >>> >> >>>> On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess wrote: >> >>>>> On Fri, May 2, 2014 at 7:33 PM, John Santos wrote: >> >>>>>> On Fri, 2 May 2014, Jimmy Hess wrote: >> >>>>>> I think 95% is too high, if the previous example of 3 /24's at >> >>>>>> 100% and >> >>>>>> 1 /24 at 75% is realistic. That works out to 93.75% aggregate >> >>>>>> utilization, not quite reaching the bar, so 90% might be a better >> >>> threshold. >> >>>>> For 3 /24s yes. The difficulty here, is trying to pick a >> >>>>> single >> >>>>> utilization proportion that works regardless of the aggregate >> >>>>> allocation size, to allow for the loss of the oddball /26 or /27 >> >>>>> that >> >>>>> can neither be returned nor reused, perhaps another method is in >> >>>>> order than presuming a single aggregate utilization criterion is >> >>>>> the most proper. >> >>>>> >> >>>>> >> >>>>> The more resources you are allocated, the more opportunity to make >> >>>>> your resource allocation efficient. By the time you get down to a >> >>>>> /26, an entire /24 is less than 0.4%. >> >>>>> >> >>>>> Aggregate Resources Allocated Required Aggregate >> >>>>> Utilization criterion >> >>>>> more than a /25 75% >> >>>>> more than a /22, 80% >> >>>>> more than a /20 85% >> >>>>> more than a /19 90% >> >>>>> more than a /18 95% >> >>>>> more than a /17 97% >> >>>>> more than a /16 98% >> >>>>> more than a /15 99% >> >>>>> >> >>>>> >> >>>>> >> >>>>>> OTOH, /24's are pretty small and maybe that example was just for >> >>>>>> illustration. If people really in this situation have much >> >>>>>> larger allocations, they would be easier to slice and dice and >> >>>>>> thus use >> >>>>>> (relatively) efficiently. 75% of a /24 leaves just 64 addresses >> >>>>>> (a >> >>>>>> /26) unused, which even if contiguous are hard to redeploy for >> >>>>>> some other use. 75% of a /16 would leave 16384 unused addresses, >> >>>>>> which >> >>> could be utilized much more easily. >> >>>>>> >> >>>>>> Personally, I don't much care since my company has its /24, and >> >>>>>> that's probably all the IPv4 we'll ever need :-) >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> John Santos >> >>>>>> Evans Griffiths & Hart, Inc. >> >>>>>> 781-861-0670 ext 539 >> >>>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> -JH >> >>>>> _______________________________________________ >> >>>>> 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. >> >>>> Jimmy, >> >>>> >> >>>> I would not support scaling this beyond 80% except at the larger >> >>>> allocation levels (eg. perhaps /17 and shorter, aggregate). >> >>>> >> >>>> As a practical matter I believe these measures should be handled as >> >>>> separate policy proposals. The current proposal should be limited >> >>>> to the calculation method and perhaps you could write a new >> >>>> proposal if you wanted to change the utilization threshold? >> >>>> >> >>>> Thanks, >> >>>> -- >> >>>> Jeffrey A. Lyon, CISSP-ISSMP >> >>>> Fellow, Black Lotus Communications >> >>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: >> >>>> blacklotus.net _______________________________________________ >> >>>> 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. >> > >> > >> > -- >> > Jeffrey A. Lyon, CISSP-ISSMP >> > Fellow, Black Lotus Communications >> > mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: >> > blacklotus.net _______________________________________________ >> > 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. > > -- Jeffrey A. Lyon, CISSP-ISSMP Fellow, Black Lotus Communications mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net From owen at delong.com Mon Jun 23 20:49:35 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Jun 2014 17:49:35 -0700 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs TestfromSmall IPv4 Transfers In-Reply-To: <807042DE61CB468DA177DD1107BB77B7@MPC> References: <537672F4.2060804@arin.net><53A0CD55.3020101@umn.edu><55ef28964e2947cb983ebe5e73778db3@EX13-MBX-13.ad.syr.edu><5B9E90747FA2974D91A54FCFA1B8AD12015AF9A6E1@ENI-MAIL.eclipse-networks.com> <807042DE61CB468DA177DD1107BB77B7@MPC> Message-ID: On Jun 23, 2014, at 07:40 , Mike Burns wrote: > The fact that the distribution both with and without needs basis seems to fall along roughly the same lines in terms of block size distribution seems to me to say that elimination of needs basis testing has not shown to have any meaningful effect, in fact. > > Owen > > > Hi Owen, > > This also means no evidence of speculation, unless for some reason you think speculators wish to engage in many small transactions for some reason. Clearly there were no speculators waiting with bated breath for the elimination of needs-testing so they could begin buying addresses, and also there is no evidence of overbuying by recipients who were otherwise limited by the amount they could justify. Perhaps. Or perhaps there are other reasons that the speculators haven't started yet. > I have seen fears that both of these activities would be the result of eliminating the needs-test, and we can say from this early data that such activity has not manifested to a large and obvious extent, at least. I think it's too early to draw any such conclusion from the data. Indeed, I don't think that the parallel distributions in the early data proves anything, but it certainly can't be used to prove Milton's point, since it actually seems to contradict it, if anything. Personally, I think it is way too small of a sample size to consider meaningful. > In other words, there are limits to speculation baked-in, including fragmented supply, public recording of transactions, and looming IPv6. > And the limits to overbuying or hoarding are provided by the co$t of the addresses and the realization that there is likely to be a vibrant and more open future market in IPv4 addresses for any future address needs. This presumes that speculators would have their transactions recorded publicly (no evidence to support that and you yourself have claimed that there are, in fact, significant numbers of off-books transfers). You can't have your cake and eat it too. I don't think that with significant capital to put into speculation, a vibrant and more open future market in IPv4 addresses is assured in any way, shape, or form. Owen From Tim.Gimmel at metronetinc.com Tue Jun 24 16:04:17 2014 From: Tim.Gimmel at metronetinc.com (Tim Gimmel) Date: Tue, 24 Jun 2014 20:04:17 +0000 Subject: [arin-ppml] Policy discussion - Method of calculating utilization ARIN-2014-17 Message-ID: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> > The problem is that the current process has disenfranchised smaller > companies who are somewhat frequently requesting space under the 3 month > need projection and are ending up with many /22's, /21's etc instead of > the /20 or /19 that would have been possible prior to austerity measures. > To make matters worse, it does not seem that such companies are > substantially represented on PPML so it is creating an illusion that the > policy is not necessary or would not be supported by the community at > large (outside of PPML). > This is exactly what is happening, for example I have 4 /20's and a /19 from earlier days, but now I have 7 /21's and that is the most I will ever be able to request. We are using every possible way to keep IPv4 usage down. --Tim > Thanks, Jeff > > > On Tue, Jun 17, 2014 at 8:55 AM, Andrew Dul wrote: > > As the current AC shepherd of this draft, I'm all for bringing this to > > Baltimore if there is something substantial to discuss. However, > > there is a lot of time between now and the next PPM time which we > > could use on the mailing-list to get to a better understanding of the > > issues surrounding the problem statement and crafting updated policy > language to solve the problem. > > IMO, we shouldn't just "punt" to the next PPM. Everyone should also > > realize that time to discuss this in person will be greatly limited at > > the PPM by the current large docket of draft policies now before the > community. > > > > Andrew > > > > > > On 6/16/2014 11:19 AM, Jeffrey Lyon wrote: > > > > Agreed re Baltimore > > > > Thanks, Jeff > > > > On Jun 16, 2014 2:13 PM, "David Huberman" > > > > wrote: > >> > >> > >> > >> I believe we should discuss in Baltimore in front of a more > >> substantial audience. There are by enough people participating here, > >> in my opinion, for any "sense of the room" to make sense. > >> > >> David R Huberman > >> Microsoft Corporation > >> Senior IT/OPS Program Manager (GFS) > >> > >> ________________________________________ > >> From: arin-ppml-bounces at arin.net on > >> behalf of Andrew Dul > >> Sent: Monday, June 16, 2014 10:53:15 AM > >> To: arin-ppml at arin.net > >> Subject: Re: [arin-ppml] Policy discussion - Method of calculating > >> utilization ARIN-2014-17 > >> > >> Hello, > >> > >> I sent a longer summary of where this policy discussion is last week, > >> I've pasted a link below to that message in the archive. > >> > >> http://lists.arin.net/pipermail/arin-ppml/2014-June/028654.html > >> > >> In general, I would say that this draft policy is stalled at this > >> point. The 80% utilization policy underpins a large majority of the > >> current policies and thus is a substantial change. There have been a > >> few people who have voiced their support, but not enough that I > >> believe would allow this policy to move forward as a recommended > >> draft at this point. > >> > >> I would also point out that they current policy also constrains > >> larger providers but in a different way as ARIN is now more closely > >> enforcing the current policy of "efficiently utilized all previous > allocations" > >> (4.2.4.1) as noted during the NANOG PPC. > >> > >> Leif, I don't think there is an easy scaling algorithm to apply to > >> utilization. The problem with a scaling algorithm is it likely will > >> be perceived as "unfair" by organizations on one side of the size > >> continuum. (We tried HD ratio for v6 and that was not easily > >> understood, and lead to lots of confusion.) > >> > >> Thanks, > >> Andrew > >> > >> > >> > >> On 6/13/2014 4:33 PM, Leif Sawyer wrote: > >> > I was really hoping somebody would suggest, perhaps, some sort of > >> > easy-to-apply scaling algorithm so that it makes it easier for the > >> > smaller guys to get the space they need, but harder for the bigger > >> > guys to game the system. > >> > > >> > I'm sure there's some sort of curve that fits, but my advanced > >> > maths are limited to Pythagoras. > >> > > >> > > >> > -----Original Message----- > >> > From: arin-ppml-bounces at arin.net > >> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon > >> > Sent: Friday, June 13, 2014 2:41 PM > >> > To: Tim Gimmel > >> > Cc: arin-ppml at arin.net List > >> > Subject: Re: [arin-ppml] Policy discussion - Method of calculating > >> > utilization > >> > > >> > Tim, > >> > > >> > I am also uncertain of the current status but would like to see > >> > some progress. > >> > > >> > Thanks, Jeff > >> > > >> > On Sat, Jun 14, 2014 at 5:50 AM, Tim Gimmel > >> > > >> > wrote: > >> >> I not really sure where this policy discussion is at the moment, > >> >> but I want to assert the current method places a strain on small > >> >> carriers just trying to do business. We are in the process of > >> >> implementing IPv6, but is will be a long journey. > >> >> Overall I am way past 80% utilization, but because my last > >> >> allocation (and this is based on actual usage, not just what has > >> >> been 'swiped') has not yet reached 80% we are practically stymied. > >> >> > >> >> Tim's 2 cents! > >> >> > >> >> Tim > >> >> > >> >> Tim Gimmel > >> >> Metronet | Senior Network Engineer > >> >> 3701 Communications Way | Evansville, IN 47715 > >> >> Office: 812.456.4750 > >> >> www.MetronetInc.com > >> >> > >> >> > >> >>> -----Original Message----- > >> >>> From: arin-ppml-bounces at arin.net > >> >>> [mailto:arin-ppml-bounces at arin.net] > >> >>> On Behalf Of Owen DeLong > >> >>> Sent: Friday, May 02, 2014 8:14 PM > >> >>> To: Jeffrey Lyon > >> >>> Cc: arin-ppml at arin.net List > >> >>> Subject: Re: [arin-ppml] Policy discussion - Method of > >> >>> calculating utilization > >> >>> > >> >>> While I support Jeffry's proposal for changing the calculation > >> >>> method, in terms of changing the threshold, I'd like to say that > >> >>> I really think it is time to stop trying to re-arrange the IPv4 > >> >>> deck chairs and get on board the IPv6 luxury liners that have > >> >>> come to rescue us from the sinking IPv4 ship. > >> >>> > >> >>> Owen > >> >>> > >> >>> On May 2, 2014, at 6:04 PM, Jeffrey Lyon > >> >>> > >> >>> wrote: > >> >>> > >> >>>> On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess > wrote: > >> >>>>> On Fri, May 2, 2014 at 7:33 PM, John Santos wrote: > >> >>>>>> On Fri, 2 May 2014, Jimmy Hess wrote: > >> >>>>>> I think 95% is too high, if the previous example of 3 /24's at > >> >>>>>> 100% and > >> >>>>>> 1 /24 at 75% is realistic. That works out to 93.75% aggregate > >> >>>>>> utilization, not quite reaching the bar, so 90% might be a > >> >>>>>> better > >> >>> threshold. > >> >>>>> For 3 /24s yes. The difficulty here, is trying to pick a > >> >>>>> single > >> >>>>> utilization proportion that works regardless of the aggregate > >> >>>>> allocation size, to allow for the loss of the oddball /26 or > >> >>>>> /27 that > >> >>>>> can neither be returned nor reused, perhaps another method is > in > >> >>>>> order than presuming a single aggregate utilization criterion > is > >> >>>>> the most proper. > >> >>>>> > >> >>>>> > >> >>>>> The more resources you are allocated, the more opportunity to > make > >> >>>>> your resource allocation efficient. By the time you get down > to a > >> >>>>> /26, an entire /24 is less than 0.4%. > >> >>>>> > >> >>>>> Aggregate Resources Allocated Required > Aggregate > >> >>>>> Utilization criterion > >> >>>>> more than a /25 > 75% > >> >>>>> more than a /22, > 80% > >> >>>>> more than a /20 > 85% > >> >>>>> more than a /19 > 90% > >> >>>>> more than a /18 > 95% > >> >>>>> more than a /17 > 97% > >> >>>>> more than a /16 > 98% > >> >>>>> more than a /15 > 99% > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>>> OTOH, /24's are pretty small and maybe that example was just > >> >>>>>> for illustration. If people really in this situation have > >> >>>>>> much larger allocations, they would be easier to slice and > >> >>>>>> dice and thus use > >> >>>>>> (relatively) efficiently. 75% of a /24 leaves just 64 > >> >>>>>> addresses (a > >> >>>>>> /26) unused, which even if contiguous are hard to redeploy for > >> >>>>>> some other use. 75% of a /16 would leave 16384 unused > >> >>>>>> addresses, which > >> >>> could be utilized much more easily. > >> >>>>>> > >> >>>>>> Personally, I don't much care since my company has its /24, > >> >>>>>> and that's probably all the IPv4 we'll ever need :-) > >> >>>>>> > >> >>>>>> > >> >>>>>> -- > >> >>>>>> John Santos > >> >>>>>> Evans Griffiths & Hart, Inc. > >> >>>>>> 781-861-0670 ext 539 > >> >>>>>> > >> >>>>> > >> >>>>> > >> >>>>> -- > >> >>>>> -JH > >> >>>>> _______________________________________________ > >> >>>>> 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. > >> >>>> Jimmy, > >> >>>> > >> >>>> I would not support scaling this beyond 80% except at the larger > >> >>>> allocation levels (eg. perhaps /17 and shorter, aggregate). > >> >>>> > >> >>>> As a practical matter I believe these measures should be handled > >> >>>> as separate policy proposals. The current proposal should be > >> >>>> limited to the calculation method and perhaps you could write a > >> >>>> new proposal if you wanted to change the utilization threshold? > >> >>>> > >> >>>> Thanks, > >> >>>> -- > >> >>>> Jeffrey A. Lyon, CISSP-ISSMP > >> >>>> Fellow, Black Lotus Communications > >> >>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: > >> >>>> blacklotus.net _______________________________________________ > >> >>>> 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. > >> > > >> > > >> > -- > >> > Jeffrey A. Lyon, CISSP-ISSMP > >> > Fellow, Black Lotus Communications > >> > mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: > >> > blacklotus.net _______________________________________________ > >> > 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. > > > > > > > > -- > Jeffrey A. Lyon, CISSP-ISSMP > Fellow, Black Lotus Communications > mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: > blacklotus.net _______________________________________________ > 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 SRyerse at eclipse-networks.com Tue Jun 24 16:08:24 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 24 Jun 2014 20:08:24 +0000 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> This is the problem I'm trying to solve and why I've been so vocal about it. 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? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Tim Gimmel Sent: Tuesday, June 24, 2014 4:04 PM To: arin-ppml at arin.net List Subject: Re: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 > The problem is that the current process has disenfranchised smaller > companies who are somewhat frequently requesting space under the 3 > month need projection and are ending up with many /22's, /21's etc > instead of the /20 or /19 that would have been possible prior to austerity measures. > To make matters worse, it does not seem that such companies are > substantially represented on PPML so it is creating an illusion that > the policy is not necessary or would not be supported by the community > at large (outside of PPML). > This is exactly what is happening, for example I have 4 /20's and a /19 from earlier days, but now I have 7 /21's and that is the most I will ever be able to request. We are using every possible way to keep IPv4 usage down. --Tim > Thanks, Jeff > > > On Tue, Jun 17, 2014 at 8:55 AM, Andrew Dul wrote: > > As the current AC shepherd of this draft, I'm all for bringing this > > to Baltimore if there is something substantial to discuss. However, > > there is a lot of time between now and the next PPM time which we > > could use on the mailing-list to get to a better understanding of > > the issues surrounding the problem statement and crafting updated > > policy > language to solve the problem. > > IMO, we shouldn't just "punt" to the next PPM. Everyone should also > > realize that time to discuss this in person will be greatly limited > > at the PPM by the current large docket of draft policies now before > > the > community. > > > > Andrew > > > > > > On 6/16/2014 11:19 AM, Jeffrey Lyon wrote: > > > > Agreed re Baltimore > > > > Thanks, Jeff > > > > On Jun 16, 2014 2:13 PM, "David Huberman" > > > > wrote: > >> > >> > >> > >> I believe we should discuss in Baltimore in front of a more > >> substantial audience. There are by enough people participating > >> here, in my opinion, for any "sense of the room" to make sense. > >> > >> David R Huberman > >> Microsoft Corporation > >> Senior IT/OPS Program Manager (GFS) > >> > >> ________________________________________ > >> From: arin-ppml-bounces at arin.net on > >> behalf of Andrew Dul > >> Sent: Monday, June 16, 2014 10:53:15 AM > >> To: arin-ppml at arin.net > >> Subject: Re: [arin-ppml] Policy discussion - Method of calculating > >> utilization ARIN-2014-17 > >> > >> Hello, > >> > >> I sent a longer summary of where this policy discussion is last > >> week, I've pasted a link below to that message in the archive. > >> > >> http://lists.arin.net/pipermail/arin-ppml/2014-June/028654.html > >> > >> In general, I would say that this draft policy is stalled at this > >> point. The 80% utilization policy underpins a large majority of > >> the current policies and thus is a substantial change. There have > >> been a few people who have voiced their support, but not enough > >> that I believe would allow this policy to move forward as a > >> recommended draft at this point. > >> > >> I would also point out that they current policy also constrains > >> larger providers but in a different way as ARIN is now more closely > >> enforcing the current policy of "efficiently utilized all previous > allocations" > >> (4.2.4.1) as noted during the NANOG PPC. > >> > >> Leif, I don't think there is an easy scaling algorithm to apply to > >> utilization. The problem with a scaling algorithm is it likely > >> will be perceived as "unfair" by organizations on one side of the size > >> continuum. (We tried HD ratio for v6 and that was not easily > >> understood, and lead to lots of confusion.) > >> > >> Thanks, > >> Andrew > >> > >> > >> > >> On 6/13/2014 4:33 PM, Leif Sawyer wrote: > >> > I was really hoping somebody would suggest, perhaps, some sort of > >> > easy-to-apply scaling algorithm so that it makes it easier for > >> > the smaller guys to get the space they need, but harder for the > >> > bigger guys to game the system. > >> > > >> > I'm sure there's some sort of curve that fits, but my advanced > >> > maths are limited to Pythagoras. > >> > > >> > > >> > -----Original Message----- > >> > From: arin-ppml-bounces at arin.net > >> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon > >> > Sent: Friday, June 13, 2014 2:41 PM > >> > To: Tim Gimmel > >> > Cc: arin-ppml at arin.net List > >> > Subject: Re: [arin-ppml] Policy discussion - Method of > >> > calculating utilization > >> > > >> > Tim, > >> > > >> > I am also uncertain of the current status but would like to see > >> > some progress. > >> > > >> > Thanks, Jeff > >> > > >> > On Sat, Jun 14, 2014 at 5:50 AM, Tim Gimmel > >> > > >> > wrote: > >> >> I not really sure where this policy discussion is at the moment, > >> >> but I want to assert the current method places a strain on small > >> >> carriers just trying to do business. We are in the process of > >> >> implementing IPv6, but is will be a long journey. > >> >> Overall I am way past 80% utilization, but because my last > >> >> allocation (and this is based on actual usage, not just what has > >> >> been 'swiped') has not yet reached 80% we are practically stymied. > >> >> > >> >> Tim's 2 cents! > >> >> > >> >> Tim > >> >> > >> >> Tim Gimmel > >> >> Metronet | Senior Network Engineer > >> >> 3701 Communications Way | Evansville, IN 47715 > >> >> Office: 812.456.4750 > >> >> www.MetronetInc.com > >> >> > >> >> > >> >>> -----Original Message----- > >> >>> From: arin-ppml-bounces at arin.net > >> >>> [mailto:arin-ppml-bounces at arin.net] > >> >>> On Behalf Of Owen DeLong > >> >>> Sent: Friday, May 02, 2014 8:14 PM > >> >>> To: Jeffrey Lyon > >> >>> Cc: arin-ppml at arin.net List > >> >>> Subject: Re: [arin-ppml] Policy discussion - Method of > >> >>> calculating utilization > >> >>> > >> >>> While I support Jeffry's proposal for changing the calculation > >> >>> method, in terms of changing the threshold, I'd like to say > >> >>> that I really think it is time to stop trying to re-arrange the > >> >>> IPv4 deck chairs and get on board the IPv6 luxury liners that > >> >>> have come to rescue us from the sinking IPv4 ship. > >> >>> > >> >>> Owen > >> >>> > >> >>> On May 2, 2014, at 6:04 PM, Jeffrey Lyon > >> >>> > >> >>> wrote: > >> >>> > >> >>>> On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess > wrote: > >> >>>>> On Fri, May 2, 2014 at 7:33 PM, John Santos wrote: > >> >>>>>> On Fri, 2 May 2014, Jimmy Hess wrote: > >> >>>>>> I think 95% is too high, if the previous example of 3 /24's > >> >>>>>> at 100% and > >> >>>>>> 1 /24 at 75% is realistic. That works out to 93.75% > >> >>>>>> aggregate utilization, not quite reaching the bar, so 90% > >> >>>>>> might be a better > >> >>> threshold. > >> >>>>> For 3 /24s yes. The difficulty here, is trying to pick a > >> >>>>> single > >> >>>>> utilization proportion that works regardless of the aggregate > >> >>>>> allocation size, to allow for the loss of the oddball /26 or > >> >>>>> /27 that > >> >>>>> can neither be returned nor reused, perhaps another method is > in > >> >>>>> order than presuming a single aggregate utilization criterion > is > >> >>>>> the most proper. > >> >>>>> > >> >>>>> > >> >>>>> The more resources you are allocated, the more opportunity > >> >>>>> to > make > >> >>>>> your resource allocation efficient. By the time you get down > to a > >> >>>>> /26, an entire /24 is less than 0.4%. > >> >>>>> > >> >>>>> Aggregate Resources Allocated Required > Aggregate > >> >>>>> Utilization criterion > >> >>>>> more than a /25 > 75% > >> >>>>> more than a /22, > 80% > >> >>>>> more than a /20 > 85% > >> >>>>> more than a /19 > 90% > >> >>>>> more than a /18 > 95% > >> >>>>> more than a /17 > 97% > >> >>>>> more than a /16 > 98% > >> >>>>> more than a /15 > 99% > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>>> OTOH, /24's are pretty small and maybe that example was just > >> >>>>>> for illustration. If people really in this situation have > >> >>>>>> much larger allocations, they would be easier to slice and > >> >>>>>> dice and thus use > >> >>>>>> (relatively) efficiently. 75% of a /24 leaves just 64 > >> >>>>>> addresses (a > >> >>>>>> /26) unused, which even if contiguous are hard to redeploy > >> >>>>>> for some other use. 75% of a /16 would leave 16384 unused > >> >>>>>> addresses, which > >> >>> could be utilized much more easily. > >> >>>>>> > >> >>>>>> Personally, I don't much care since my company has its /24, > >> >>>>>> and that's probably all the IPv4 we'll ever need :-) > >> >>>>>> > >> >>>>>> > >> >>>>>> -- > >> >>>>>> John Santos > >> >>>>>> Evans Griffiths & Hart, Inc. > >> >>>>>> 781-861-0670 ext 539 > >> >>>>>> > >> >>>>> > >> >>>>> > >> >>>>> -- > >> >>>>> -JH > >> >>>>> _______________________________________________ > >> >>>>> 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. > >> >>>> Jimmy, > >> >>>> > >> >>>> I would not support scaling this beyond 80% except at the > >> >>>> larger allocation levels (eg. perhaps /17 and shorter, aggregate). > >> >>>> > >> >>>> As a practical matter I believe these measures should be > >> >>>> handled as separate policy proposals. The current proposal > >> >>>> should be limited to the calculation method and perhaps you > >> >>>> could write a new proposal if you wanted to change the utilization threshold? > >> >>>> > >> >>>> Thanks, > >> >>>> -- > >> >>>> Jeffrey A. Lyon, CISSP-ISSMP > >> >>>> Fellow, Black Lotus Communications > >> >>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: > >> >>>> blacklotus.net _______________________________________________ > >> >>>> 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. > >> > > >> > > >> > -- > >> > Jeffrey A. Lyon, CISSP-ISSMP > >> > Fellow, Black Lotus Communications > >> > mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: > >> > blacklotus.net _______________________________________________ > >> > 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. > > > > > > > > -- > Jeffrey A. Lyon, CISSP-ISSMP > Fellow, Black Lotus Communications > mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: > blacklotus.net _______________________________________________ > 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 info at arin.net Tue Jun 24 16:15:32 2014 From: info at arin.net (ARIN) Date: Tue, 24 Jun 2014 16:15:32 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - June 2014 Message-ID: <53A9DC64.7010205@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) met on 19 June 2014. The AC recommended the following to the ARIN Board for adoption: Recommended Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup The AC moved the following to last call: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations Recommended Draft Policy ARIN-2414-12: Anti-hijack Policy Recommended Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24 The AC abandoned the following: Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and 8.4 Minimum IPv4 Block Size Requirements Draft Policy ARIN-2014-8: Alignment of 8.3 Needs Requirements to Reality of Business Draft Policy ARIN-2014-11: Improved Registry Accuracy Proposal The AC provided the following statements: "The ARIN council voted to abandon 2014-3 Remove 8.2 and 8.3 and 8.4 Minimum IPv4 Block Size Requirements for the following reasons: - Minimal support from the community - Substantial opposition expressed on list and at the PPM and PPC The AC recognizes that there was some level of support expressed for a reduction in the minimum block size requirements, but did not find enough support to modify this proposal." "The ARIN council voted to abandon 2014-8 Alignment of 8.3 Needs Requirements to Reality of Business: - The author has confirmed that he was amenable to the abandonment of the proposal. - There has been general consensus that this proposal is premature and makes changes to section 8.3 that could have significant unintentional policy changes. - Since the initial proposal a number of other proposals have addressed many of the concerns." "The ARIN council voted to abandon 2014-11 Improved Registry Accuracy for the following reasons: - At the PPC staff noted they were working on changes to the RSA/LSRA that would address many of the issues brought up in the original proposal. - The community has not supported this proposal on list and at the PPC. - The proposal would require a significant overhaul to remove out of scope items that would effectively diminish the proposal." The AC abandoned ARIN-2014-3, 2014-8 and 2014-11. Anyone dissatisfied with these decisions 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 The AC is continuing to work on the following: Draft Policy ARIN-2014-1: Out of Region Use Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs] Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers Draft Policy ARIN-2014-16: Section 4.10 Austerity Policy Update Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate 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 Tue Jun 24 16:15:49 2014 From: info at arin.net (ARIN) Date: Tue, 24 Jun 2014 16:15:49 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations Message-ID: <53A9DC75.5060605@arin.net> The ARIN Advisory Council (AC) met on 19 June 2014 and decided to send the following to last call: Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations 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 8 July 2014. 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-2014-5 Remove 7.2 Lame Delegations 21 April 2014 AC's assessment of conformance with the Principles of Internet Number Resource Policy: "ARIN-2014-5: Remove 7.2 Lame Delegations enables fair and impartial number resource administration by removing a no-longer-relevant section of the NRPM. All of the changes in this draft policy have proven uncontroversial thus far, with substantially more hands for the policy than against." Problem Statement: Section 7.2, asking ARIN to resolve Lame Delegations in in-addr.arpa, was established almost 10 years ago. While there may be real lameness problems in the in-addr.arpa tree, this should no longer be part of ARIN policy for two reasons: 1) NRPM should primarily be used to determine when requestors do, and do not, qualify for number resources because that's what ARIN's purpose is relevant to. ARIN is not an operational technical body, and its policy should only regulate activities ARIN is designed to participate in. 1a) We don't put text about how to operate Whois or RWhois or IRR in NRPM, so we should not put in text about how to operate DNS. 2) ARIN has never effectively implemented this. If there's still a need, it should be addressed directly with ARIN management and staff for prioritization. Policy statement: Remove section 7.2 Comments: a.Timetable for implementation: Immediate b.Anything else: From info at arin.net Tue Jun 24 16:16:05 2014 From: info at arin.net (ARIN) Date: Tue, 24 Jun 2014 16:16:05 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks Message-ID: <53A9DC85.1020908@arin.net> The ARIN Advisory Council (AC) met on 19 June 2014 and decided to send the following to last call: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks 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 8 July 2014. 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-2013-8 Subsequent Allocations for New Multiple Discrete Networks Date: 16 May 2014 AC's assessment of conformance with the Principles of Internet Number Resource Policy: This proposal enables fair and impartial number resource administration by documenting how to get a new block for a new discrete network. Previous versions of the policy did have this information and over time it has been removed. This proposal is technically sound. There is a need for discrete networks and an organization should have a policy that would allow it to create a new discrete network. This proposal is supported by the community. There has been some concern about the criterial that will be used and this version has been updated with the current thinking on the criteria. Policy Statement: IPv4: Add the following statement to section 4.5.4. Upon verification that the organization has shown evidence of deployment of the new discrete network site, the new network(s) shall be allocated the minimum allocation size under section 4.2.1.5 unless the organization can demonstrate additional need using the immediate need criteria (4.2.1.6). IPv6: Add an additional reference to section 6.11.5.b such that it references both the initial allocation and subsequent allocation sections of the IPv6 LIR policy. "Each network will be judged against the existing utilization criteria specified in 6.5.2 and 6.5.3 as if it were a separate organization..." Comments: a. Timetable for implementation: immediate b. This policy is being proposed based upon the Policy Implementation & Experience Report from ARIN 32. https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf c: Older versions of the MDN policy did contain new network criteria. This criteria appears to have been dropped during subsequent rewrites of the MDN policy. "The organization must not allocate a CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to a new network." (https://www.arin.net/policy/archive/nrpm_20041015.pdf) From info at arin.net Tue Jun 24 16:16:19 2014 From: info at arin.net (ARIN) Date: Tue, 24 Jun 2014 16:16:19 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy Message-ID: <53A9DC93.20903@arin.net> The ARIN Advisory Council (AC) met on 19 June 2014 and decided to send the following to an extended last call: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy The text has been revised. The AC provided the following: "ARIN-2014-12 has been modified since the ARIN Advisory Council (AC) recommended this policy on 15 May 2014, in the following ways; 1. The second and third sentences of the policy text were modified to clarify the original policy intent regarding deviation from the minimum allocation size, either smaller or larger as discussed on PPML. These changes are considered editorial in nature and do not change the intent of the policy. 2. A sentence was added to the policy statement reflecting the changes to the policy text as discussed above." 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 15 July 2014. 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-2014-12 Anti-hijack Policy Date: 17 June 2014 AC's assessment of conformance with the Principles of Internet Number Resource Policy: ARIN-2014-12: Anti-hijack Policy enables fair, impartial, and technically sound number resource administration by updating the guidelines for the allocation of experimental resources to ensure all such allocation are documented in Whois, noting their experimental status, and provides these allocations may not overlap any other allocations. Additionally, part of the original policy text has been clarified through editorial changes. Problem Statement: ARIN should not give research organizations permission to hijack prefixes that have already been allocated. Research organizations announcing lit aggregates may receive sensitive production traffic belonging to live networks during periods of instability. Section 11.7 describes more than allocation size therefore updating the section heading to something more accurate is appropriate. Policy statement: Modify the section 11.7 heading to be more accurate. Modify the first sentence to prohibit overlapping assignments. Add text at the end to define how research allocations should be designated. Modify the second and third sentences to clarify the original policy intent regarding deviation from the minimum allocation size, smaller or larger as discussed on PPML. 11.7 Resource Allocation Guidelines The Numbering Resources requested come from the global Internet Resource space, do not overlap currently assigned space, and are not from private or other non-routable Internet Resource space. The allocation size shall be consistent with the existing ARIN minimum allocation sizes, unless smaller allocations are intended to be explicitly part of the experiment. If an organization requires more resources than stipulated by the minimum allocation size in force at the time of its request, the request must clearly describe and justify why a larger allocation is required. All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. Comments: a. Timetable for implementation: Immediate b. Anything else: From info at arin.net Tue Jun 24 16:16:34 2014 From: info at arin.net (ARIN) Date: Tue, 24 Jun 2014 16:16:34 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24 Message-ID: <53A9DCA2.2060907@arin.net> The ARIN Advisory Council (AC) met on 19 June 2014 and decided to send the following to an extended last call: Recommended Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24 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 15 July 2014. 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-2014-13 Reduce All Minimum Allocation/Assignment Units to /24 Date: 20 May 2014 AC's assessment of conformance with the Principles of Internet Number Resource Policy: Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24 - This proposal will lower all allocation(s) and assignment(s) of IPv4 address in section 4.2 and 4.3 to a /24 minimum. The policy would also remove section 4.9 as the allocation and assignment sizes were now larger than 4.2 and 4.3. As noted in the staff report it will also remove the maximum initial allocation that was used with the examples in 4.2.2.2. The changes to the NRPM are fair in that they would treat all resource applicants equally. They are technically sound and have received support from the community. Problem Statement: As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units for IPv4 to /24 across the board. Policy statement: Remove all references to minimum allocations /20 and /22 replacing them with the term allocation or with /24 when referencing minimum size blocks. Change the title of 4.2.2.1 to "ISP Requirements" with revised text stating: All ISP organizations must satisfy the following requirements...thus eliminating the entire Multi-homed section and subsections along with other superfluous example text. Delete the special case allocations/assignments for the Caribbean as the new /24 minimums are an improvement. Comments: a. Timetable for implementation: Immediate b. A red line version has been included Full text version of changes for easy reference: 4.2.1.5. Minimum allocation In general, ARIN allocates /24 and larger IP address prefixes to ISPs. If allocations smaller than /24 are needed, ISPs should request address space from their upstream provider. 4.2.2.1 ISP Requirements All ISP organizations must satisfy the following requirements: 4.2.2.1.1 Use of /24 The efficient utilization of an entire previously allocated /24 from their upstream ISP. This allocation may have been provided by an ISP??s upstream provider(s), and does not have to be contiguous address space. 4.2.2.1.3. Three months Provide detailed information showing specifically how the requested allocation will be utilized within three months. 4.2.2.1.4. Renumber and return ISPs receiving a new allocation may wish to renumber out of their previously allocated space. In this case, an ISP must use the new allocation to renumber out of that previously allocated block of address space and must return the space to its upstream provider. 4.2.2.2. [section number retired] 4.3.2 Minimum assignment 4.3.2.1. [section moved to 4.3.2] The minimum block of IP address space assigned by ARIN to end-users is a /24. If assignments smaller than /24 are needed, end-users should contact their upstream provider. 4.3.2.2 [section number retired] 4.9 [section number retired] From farmer at umn.edu Tue Jun 24 17:42:58 2014 From: farmer at umn.edu (David Farmer) Date: Tue, 24 Jun 2014 16:42:58 -0500 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <53A9DC93.20903@arin.net> References: <53A9DC93.20903@arin.net> Message-ID: <53A9F0E2.7070103@umn.edu> To help additionally highlight the changes to the Policy Text since the 15 May 2014 version that the AC recommended; I'm including this HTMLized red-lined version of the Last Call Policy Text below. Only the changes since the 15 May 2014 version that the AC recommended are being highlighted. As stated these changes are considered editorial in nature and are not intended to change the intent or meaning of the policy, only clarify the original intent. The red text has been added and red text with a strike-through has been deleted. --- 11.7 Resource Allocation Guidelines The Numbering Resources requested come from the global Internet Resource space, do not overlap currently assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should shall be consistent with the existing ARIN minimum allocation sizes, unless smaller allocations are intended to be explicitly part of the experiment. If an organization requires more resources than stipulated by the minimum allocation sizes in force at the time of their its request, their experimental documentation shouldhave the request must clearly described and justified justify why this a larger allocation is required. All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. --- If you are not using a HTML compatible email client then please refer to the clean text included in the original Last Call email, it will be difficult to interpret the above text without a HTML compatible email client. Thanks. -- ================================================ 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 ================================================ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Tue Jun 24 18:04:17 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 24 Jun 2014 15:04:17 -0700 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> Message-ID: <53A9F5E1.1010104@quark.net> The problem described below appears to be more related to the current 3-month window for additional allocations, not necessarily the utilization metric. The 3-month window has had a number of side-effects, some of which were not anticipated when that policy was put in place. With run-out in the region approaching rapidly we need to turn our attention to the longer term policies which will support the desires of the community (as best possible) through the transfer market or other mechanisms. Changing the utilization formula (for those requests which do require a formal needs assessment) may be part of the policy changes which are needed. Andrew On 6/24/2014 1:08 PM, Steven Ryerse wrote: > This is the problem I'm trying to solve and why I've been so vocal about it. > > 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? > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Tim Gimmel > Sent: Tuesday, June 24, 2014 4:04 PM > To: arin-ppml at arin.net List > Subject: Re: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 > > >> The problem is that the current process has disenfranchised smaller >> companies who are somewhat frequently requesting space under the 3 >> month need projection and are ending up with many /22's, /21's etc >> instead of the /20 or /19 that would have been possible prior to austerity measures. >> To make matters worse, it does not seem that such companies are >> substantially represented on PPML so it is creating an illusion that >> the policy is not necessary or would not be supported by the community >> at large (outside of PPML). >> > This is exactly what is happening, for example I have 4 /20's and a /19 from earlier days, but now I have 7 /21's and that is the most I will ever be able to request. We are using every possible way to keep IPv4 usage down. > > --Tim > From mpetach at netflight.com Tue Jun 24 21:26:07 2014 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 24 Jun 2014 18:26:07 -0700 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <53A9F0E2.7070103@umn.edu> References: <53A9DC93.20903@arin.net> <53A9F0E2.7070103@umn.edu> Message-ID: I support the newly-redlined version of the draft. Matt On Tue, Jun 24, 2014 at 2:42 PM, David Farmer wrote: > To help additionally highlight the changes to the Policy Text since the > 15 May 2014 version that the AC recommended; I'm including this HTMLized > red-lined version of the Last Call Policy Text below. Only the changes > since the 15 May 2014 version that the AC recommended are being > highlighted. As stated these changes are considered editorial in nature > and are not intended to change the intent or meaning of the policy, only > clarify the original intent. The red text has been added and red text with > a strike-through has been deleted. > > --- > 11.7 Resource Allocation Guidelines > > The Numbering Resources requested come from the global Internet Resource > space, do not overlap currently assigned space, and are not from private or > other non-routable Internet Resource space. The allocation size should > shall be consistent with the existing ARIN minimum allocation sizes, > unless smaller allocations are intended to be explicitly part of the > experiment. If an organization requires more resources than stipulated by > the minimum allocation sizes in force at the time of their its request, their > experimental documentation should have the request must clearly described > and justified justify why this a larger allocation is required. > > All research allocations must be registered publicly in whois. Each > research allocation will be designated as a research allocation with a > comment indicating when the allocation will end. > --- > > If you are not using a HTML compatible email client then please refer to > the clean text included in the original Last Call email, it will be > difficult to interpret the above text without a HTML compatible email > client. > > Thanks. > > -- > ================================================ > 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 lar at mwtcorp.net Wed Jun 25 11:42:39 2014 From: lar at mwtcorp.net (lar at mwtcorp.net) Date: Wed, 25 Jun 2014 09:42:39 -0600 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: <53A9F5E1.1010104@quark.net> References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> <53A9F5E1.1010104@quark.net> Message-ID: On Tue, 24 Jun 2014 15:04:17 -0700 Andrew Dul wrote: > The problem described below appears to be more related to the current > 3-month window for additional allocations, not necessarily the > utilization metric. The 3-month window has had a number of > side-effects, some of which were not anticipated when that policy was > put in place. With run-out in the region approaching rapidly we need to > turn our attention to the longer term policies which will support the > desires of the community (as best possible) through the transfer market > or other mechanisms. Changing the utilization formula (for those > requests which do require a formal needs assessment) may be part of the > policy changes which are needed. > Some of the problem of the formula are long standing. If your last allocation was a /22 and you have a larger customer come to you with a legitimate and clear need for a /22 or /21 you have no way of getting it no matter what % utilization is in the policy. It has always seemed to me, that "need" should have a lot more to do with what you are going to do with the requested allocation, and what is available in your current allocations, than some arbitrary utilization percentage. The problem is that ARIN would then have to get into network design arguments. The argument that just removing the needs test for smaller allocations entirely has some merit. The problem seems to be in defining what is small. A compromise of /20 has been suggested and I think it's reasonable. Even though I support needs testing I can support removing it at a /20 and smaller. Larry Ash > Andrew > > On 6/24/2014 1:08 PM, Steven Ryerse wrote: >> This is the problem I'm trying to solve and why I've been so vocal about it. >> >> 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? >> >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Tim Gimmel >> Sent: Tuesday, June 24, 2014 4:04 PM >> To: arin-ppml at arin.net List >> Subject: Re: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 >> >> >>> The problem is that the current process has disenfranchised smaller >>> companies who are somewhat frequently requesting space under the 3 >>> month need projection and are ending up with many /22's, /21's etc >>> instead of the /20 or /19 that would have been possible prior to austerity measures. >>> To make matters worse, it does not seem that such companies are >>> substantially represented on PPML so it is creating an illusion that >>> the policy is not necessary or would not be supported by the community >>> at large (outside of PPML). >>> >> This is exactly what is happening, for example I have 4 /20's and a /19 from earlier days, but now I have 7 /21's and that is >>the most I will ever be able to request. We are using every possible way to keep IPv4 usage down. >> >> --Tim >> > > _______________________________________________ > 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. Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From jeffrey.lyon at blacklotus.net Wed Jun 25 11:49:27 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 26 Jun 2014 00:49:27 +0900 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> <53A9F5E1.1010104@quark.net> Message-ID: Larry, I think you intended this for ARIN-2014-14? On that proposal I would agree to /20 as a compromise. Thanks, Jeff On Jun 25, 2014 11:43 AM, wrote: > On Tue, 24 Jun 2014 15:04:17 -0700 > Andrew Dul wrote: > >> The problem described below appears to be more related to the current >> 3-month window for additional allocations, not necessarily the >> utilization metric. The 3-month window has had a number of >> side-effects, some of which were not anticipated when that policy was >> put in place. With run-out in the region approaching rapidly we need to >> turn our attention to the longer term policies which will support the >> desires of the community (as best possible) through the transfer market >> or other mechanisms. Changing the utilization formula (for those >> requests which do require a formal needs assessment) may be part of the >> policy changes which are needed. >> >> Some of the problem of the formula are long standing. If your last > allocation > was a /22 and you have a larger customer come to you with a legitimate and > clear need for a /22 or /21 you have no way of getting it no matter what % > utilization > is in the policy. It has always seemed to me, that "need" should have a > lot more to > do with what you are going to do with the requested allocation, and what > is available > in your current allocations, than some arbitrary utilization percentage. > The > problem is that ARIN would then have to get into network design arguments. > > The argument that just removing the needs test for smaller allocations > entirely > has some merit. The problem seems to be in defining what is small. A > compromise of /20 has > been suggested and I think it's reasonable. Even though I support needs > testing I can support removing it at a /20 and smaller. > > Larry Ash > > Andrew >> >> On 6/24/2014 1:08 PM, Steven Ryerse wrote: >> >>> This is the problem I'm trying to solve and why I've been so vocal about >>> it. >>> 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? >>> >>> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >>> Behalf Of Tim Gimmel >>> Sent: Tuesday, June 24, 2014 4:04 PM >>> To: arin-ppml at arin.net List >>> Subject: Re: [arin-ppml] Policy discussion - Method of >>> calculatingutilization ARIN-2014-17 >>> >>> >>> The problem is that the current process has disenfranchised smaller >>>> companies who are somewhat frequently requesting space under the 3 month >>>> need projection and are ending up with many /22's, /21's etc instead of the >>>> /20 or /19 that would have been possible prior to austerity measures. >>>> To make matters worse, it does not seem that such companies are >>>> substantially represented on PPML so it is creating an illusion that the >>>> policy is not necessary or would not be supported by the community at large >>>> (outside of PPML). >>>> >>>> This is exactly what is happening, for example I have 4 /20's and a >>> /19 from earlier days, but now I have 7 /21's and that is the most I will >>> ever be able to request. We are using every possible way to keep IPv4 >>> usage down. >>> >>> --Tim >>> >>> >> _______________________________________________ >> 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. >> > > Larry Ash > Network Administrator > Mountain West Telephone > 123 W 1st St. > Casper, WY 82601 > Office 307 233-8387 > _______________________________________________ > 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 lar at mwtcorp.net Wed Jun 25 12:26:32 2014 From: lar at mwtcorp.net (lar at mwtcorp.net) Date: Wed, 25 Jun 2014 10:26:32 -0600 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> <53A9F5E1.1010104@quark.net> Message-ID: On Thu, 26 Jun 2014 00:49:27 +0900 Jeffrey Lyon wrote: > Larry, > > I think you intended this for ARIN-2014-14? On that proposal I would agree > to /20 as a compromise. Opps, sorry you are right, but in general the problem occurs here also. My instinct has been to support 2014-17 but I can see that if your large enough and with smaller allocations, aggregating all previous allocations might have you at 80% before you assign the first address from the last allocation. Instead of aggregating all previous allocations, could we set some aggregate package size. Maybe aggregating your newest previous allocations up to a /18 (pick a number), or your newest allocation whichever is larger. Feels a little clunky but it might ease the problem. Larry > > Thanks, Jeff > On Jun 25, 2014 11:43 AM, wrote: > >> On Tue, 24 Jun 2014 15:04:17 -0700 >> Andrew Dul wrote: >> >>> The problem described below appears to be more related to the current >>> 3-month window for additional allocations, not necessarily the >>> utilization metric. The 3-month window has had a number of >>> side-effects, some of which were not anticipated when that policy was >>> put in place. With run-out in the region approaching rapidly we need to >>> turn our attention to the longer term policies which will support the >>> desires of the community (as best possible) through the transfer market >>> or other mechanisms. Changing the utilization formula (for those >>> requests which do require a formal needs assessment) may be part of the >>> policy changes which are needed. >>> >>> Some of the problem of the formula are long standing. If your last >> allocation >> was a /22 and you have a larger customer come to you with a legitimate and >> clear need for a /22 or /21 you have no way of getting it no matter what % >> utilization >> is in the policy. It has always seemed to me, that "need" should have a >> lot more to >> do with what you are going to do with the requested allocation, and what >> is available >> in your current allocations, than some arbitrary utilization percentage. >> The >> problem is that ARIN would then have to get into network design arguments. >> >> The argument that just removing the needs test for smaller allocations >> entirely >> has some merit. The problem seems to be in defining what is small. A >> compromise of /20 has >> been suggested and I think it's reasonable. Even though I support needs >> testing I can support removing it at a /20 and smaller. >> >> Larry Ash >> >> Andrew >>> >>> On 6/24/2014 1:08 PM, Steven Ryerse wrote: >>> >>>> This is the problem I'm trying to solve and why I've been so vocal about >>>> it. >>>> 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? >>>> >>>> >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >>>> Behalf Of Tim Gimmel >>>> Sent: Tuesday, June 24, 2014 4:04 PM >>>> To: arin-ppml at arin.net List >>>> Subject: Re: [arin-ppml] Policy discussion - Method of >>>> calculatingutilization ARIN-2014-17 >>>> >>>> >>>> The problem is that the current process has disenfranchised smaller >>>>> companies who are somewhat frequently requesting space under the 3 month >>>>> need projection and are ending up with many /22's, /21's etc instead of the >>>>> /20 or /19 that would have been possible prior to austerity measures. >>>>> To make matters worse, it does not seem that such companies are >>>>> substantially represented on PPML so it is creating an illusion that the >>>>> policy is not necessary or would not be supported by the community at large >>>>> (outside of PPML). >>>>> >>>>> This is exactly what is happening, for example I have 4 /20's and a >>>> /19 from earlier days, but now I have 7 /21's and that is the most I will >>>> ever be able to request. We are using every possible way to keep IPv4 >>>> usage down. >>>> >>>> --Tim >>>> >>>> >>> _______________________________________________ >>> 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. >>> >> >> Larry Ash >> Network Administrator >> Mountain West Telephone >> 123 W 1st St. >> Casper, WY 82601 >> Office 307 233-8387 >> _______________________________________________ >> 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. Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From SRyerse at eclipse-networks.com Wed Jun 25 12:45:34 2014 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 25 Jun 2014 16:45:34 +0000 Subject: [arin-ppml] Policy discussion - Method ofcalculatingutilization ARIN-2014-17 In-Reply-To: References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com><5B9E 90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com><53A9F5E1.1010104@quark.net> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015AFB5F8A@ENI-MAIL.eclipse-networks.com> Well stated. A /24 as the minimum isn't really enough unless you are a very small organization. A /20 is not perfect but is closer to the mark of what is required. Thais is why ARIN-2014-14 is needed for small to smaller organizations. 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? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of lar at mwtcorp.net Sent: Wednesday, June 25, 2014 11:43 AM To: andrew.dul at quark.net; arin-ppml at arin.net Subject: Re: [arin-ppml] Policy discussion - Method ofcalculatingutilization ARIN-2014-17 On Tue, 24 Jun 2014 15:04:17 -0700 Andrew Dul wrote: > The problem described below appears to be more related to the current > 3-month window for additional allocations, not necessarily the > utilization metric. The 3-month window has had a number of > side-effects, some of which were not anticipated when that policy was > put in place. With run-out in the region approaching rapidly we need > to turn our attention to the longer term policies which will support > the desires of the community (as best possible) through the transfer > market or other mechanisms. Changing the utilization formula (for > those requests which do require a formal needs assessment) may be part > of the policy changes which are needed. > Some of the problem of the formula are long standing. If your last allocation was a /22 and you have a larger customer come to you with a legitimate and clear need for a /22 or /21 you have no way of getting it no matter what % utilization is in the policy. It has always seemed to me, that "need" should have a lot more to do with what you are going to do with the requested allocation, and what is available in your current allocations, than some arbitrary utilization percentage. The problem is that ARIN would then have to get into network design arguments. The argument that just removing the needs test for smaller allocations entirely has some merit. The problem seems to be in defining what is small. A compromise of /20 has been suggested and I think it's reasonable. Even though I support needs testing I can support removing it at a /20 and smaller. Larry Ash > Andrew > > On 6/24/2014 1:08 PM, Steven Ryerse wrote: >> This is the problem I'm trying to solve and why I've been so vocal about it. >> >> 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? >> >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >> On Behalf Of Tim Gimmel >> Sent: Tuesday, June 24, 2014 4:04 PM >> To: arin-ppml at arin.net List >> Subject: Re: [arin-ppml] Policy discussion - Method of >> calculatingutilization ARIN-2014-17 >> >> >>> The problem is that the current process has disenfranchised smaller >>> companies who are somewhat frequently requesting space under the 3 >>> month need projection and are ending up with many /22's, /21's etc >>> instead of the /20 or /19 that would have been possible prior to austerity measures. >>> To make matters worse, it does not seem that such companies are >>> substantially represented on PPML so it is creating an illusion that >>> the policy is not necessary or would not be supported by the >>> community at large (outside of PPML). >>> >> This is exactly what is happening, for example I have 4 /20's and a >>/19 from earlier days, but now I have 7 /21's and that is the most I will ever be able to request. We are using every possible way to keep IPv4 usage down. >> >> --Tim >> > > _______________________________________________ > 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. Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 _______________________________________________ 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 bill at tknow.com Wed Jun 25 14:38:25 2014 From: bill at tknow.com (Bill Buhler) Date: Wed, 25 Jun 2014 14:38:25 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: References: <53A9DC93.20903@arin.net> <53A9F0E2.7070103@umn.edu> Message-ID: <66E414654AD098469738606C8E7B03B048A6262053@P1MBX03.HMC1.COMCAST.NET> I support it as well. Bill From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Petach Sent: Tuesday, June 24, 2014 7:26 PM To: David Farmer Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy I support the newly-redlined version of the draft. Matt On Tue, Jun 24, 2014 at 2:42 PM, David Farmer > wrote: To help additionally highlight the changes to the Policy Text since the 15 May 2014 version that the AC recommended; I'm including this HTMLized red-lined version of the Last Call Policy Text below. Only the changes since the 15 May 2014 version that the AC recommended are being highlighted. As stated these changes are considered editorial in nature and are not intended to change the intent or meaning of the policy, only clarify the original intent. The red text has been added and red text with a strike-through has been deleted. --- 11.7 Resource Allocation Guidelines The Numbering Resources requested come from the global Internet Resource space, do not overlap currently assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should shall be consistent with the existing ARIN minimum allocation sizes, unless smaller allocations are intended to be explicitly part of the experiment. If an organization requires more resources than stipulated by the minimum allocation sizes in force at the time of their its request, their experimental documentation should have the request must clearly described and justified justify why this a larger allocation is required. All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. --- If you are not using a HTML compatible email client then please refer to the clean text included in the original Last Call email, it will be difficult to interpret the above text without a HTML compatible email client. Thanks. -- ================================================ 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 gary.buhrmaster at gmail.com Wed Jun 25 15:10:28 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 25 Jun 2014 19:10:28 +0000 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <53A9DC93.20903@arin.net> References: <53A9DC93.20903@arin.net> Message-ID: On Tue, Jun 24, 2014 at 8:16 PM, ARIN wrote: > The ARIN Advisory Council (AC) met on 19 June 2014 and decided to > send the following to an extended last call: > > Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy I support this policy as currently written. While I believe that ARIN will never again issue routing authorizations that caused this particular issue to bubble to the surface, explicit policy and clarification is goodness going forward, setting reasonable expectations for the experimental research community. Gary From JOHN at egh.com Wed Jun 25 16:00:11 2014 From: JOHN at egh.com (John Santos) Date: Wed, 25 Jun 2014 16:00:11 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy In-Reply-To: <66E414654AD098469738606C8E7B03B048A6262053@P1MBX03.HMC1.COMCAST.NET> Message-ID: <1140625155941.32315N-100000@joonya.egh.com> Support -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From owen at delong.com Wed Jun 25 16:04:07 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 25 Jun 2014 13:04:07 -0700 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> <53A9F5E1.1010104@quark.net> Message-ID: <3DE58922-17C4-4C0C-AD16-A821F676E391@delong.com> On Jun 25, 2014, at 08:42 , wrote: > On Tue, 24 Jun 2014 15:04:17 -0700 > Andrew Dul wrote: >> The problem described below appears to be more related to the current >> 3-month window for additional allocations, not necessarily the >> utilization metric. The 3-month window has had a number of >> side-effects, some of which were not anticipated when that policy was >> put in place. With run-out in the region approaching rapidly we need to >> turn our attention to the longer term policies which will support the >> desires of the community (as best possible) through the transfer market >> or other mechanisms. Changing the utilization formula (for those >> requests which do require a formal needs assessment) may be part of the >> policy changes which are needed. > Some of the problem of the formula are long standing. If your last allocation > was a /22 and you have a larger customer come to you with a legitimate and > clear need for a /22 or /21 you have no way of getting it no matter what % utilization > is in the policy. It has always seemed to me, that "need" should have a lot more to > do with what you are going to do with the requested allocation, and what is available > in your current allocations, than some arbitrary utilization percentage. The > problem is that ARIN would then have to get into network design arguments. Actually, I believe that this circumstance is the reason that the immediate needs clause exists. 4.2.1.6. Immediate need If an ISP has an immediate need for address space, and can provide justification to show that the address space will be utilized within 30 days of the request, ARIN may issue a block of address space, not larger than a /16 nor smaller than ARIN's customary minimum allocation, to that organization. These cases are exceptional. Perhaps, in practice, since it is located in principles (not sure how or why that occurred), and there isn't anything concrete stating that it should be treated as an exception to 4.2.4.1, it does not get implemented as I believe was intended. Staff would have to clarify that. If that is the case, it would be a relatively simple proposal to fix: Amend section 4.2.4 by adding: 4.2.4.5 Exceptional Cases of Immediate Need If a subscriber member has a customer who needs a larger block than remains in the subscriber member's free pool, then a request under section 4.2.1.6 shall apply as an exception to the requirements in 4.2.4.1. > The argument that just removing the needs test for smaller allocations entirely > has some merit. The problem seems to be in defining what is small. A compromise of /20 has > been suggested and I think it's reasonable. Even though I support needs > testing I can support removing it at a /20 and smaller. I really think that removing the needs test is unlikely to gain consensus, even at the smaller point. There is clear resistance in the community to this idea and I expect that opposition will remain strong. If people support the idea above, I'm happy to put it into a policy template and get it started in the process. If there is strong support, it can probably be moved through the process fairly quickly. Owen > > Larry Ash > >> Andrew >> On 6/24/2014 1:08 PM, Steven Ryerse wrote: >>> This is the problem I'm trying to solve and why I've been so vocal about it. >>> 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? >>> >>> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Tim Gimmel >>> Sent: Tuesday, June 24, 2014 4:04 PM >>> To: arin-ppml at arin.net List >>> Subject: Re: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 >>> >>> >>>> The problem is that the current process has disenfranchised smaller companies who are somewhat frequently requesting space under the 3 month need projection and are ending up with many /22's, /21's etc instead of the /20 or /19 that would have been possible prior to austerity measures. >>>> To make matters worse, it does not seem that such companies are substantially represented on PPML so it is creating an illusion that the policy is not necessary or would not be supported by the community at large (outside of PPML). >>>> >>> This is exactly what is happening, for example I have 4 /20's and a /19 from earlier days, but now I have 7 /21's and that is the most I will ever be able to request. We are using every possible way to keep IPv4 usage down. >>> >>> --Tim >>> >> _______________________________________________ >> 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. > > Larry Ash > Network Administrator > Mountain West Telephone > 123 W 1st St. > Casper, WY 82601 > Office 307 233-8387 > _______________________________________________ > 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 jeffrey.lyon at blacklotus.net Wed Jun 25 16:24:52 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 25 Jun 2014 16:24:52 -0400 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: <3DE58922-17C4-4C0C-AD16-A821F676E391@delong.com> References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> <53A9F5E1.1010104@quark.net> <3DE58922-17C4-4C0C-AD16-A821F676E391@delong.com> Message-ID: All, Given the ongoing debate and somewhat strong sentiment at different points of the "needs testing" spectrum, ARIN-2014-17 should be considered as a solution to some of the problems which are partially driving the movement to remove needs testing. I would also like to caution against convoluting -17 too much. Some of the dissenters are recommending various changes which I feel would make the policy unnecessarily complicated and in the effort to compromise, may actually make it more difficult to find consensus. Thanks, Jeff On Wed, Jun 25, 2014 at 4:04 PM, Owen DeLong wrote: > > On Jun 25, 2014, at 08:42 , wrote: > > On Tue, 24 Jun 2014 15:04:17 -0700 > Andrew Dul wrote: > > The problem described below appears to be more related to the current > 3-month window for additional allocations, not necessarily the > utilization metric. The 3-month window has had a number of > side-effects, some of which were not anticipated when that policy was > put in place. With run-out in the region approaching rapidly we need to > turn our attention to the longer term policies which will support the > desires of the community (as best possible) through the transfer market > or other mechanisms. Changing the utilization formula (for those > requests which do require a formal needs assessment) may be part of the > policy changes which are needed. > > Some of the problem of the formula are long standing. If your last > allocation > was a /22 and you have a larger customer come to you with a legitimate and > clear need for a /22 or /21 you have no way of getting it no matter what % > utilization > is in the policy. It has always seemed to me, that "need" should have a lot > more to > do with what you are going to do with the requested allocation, and what is > available > in your current allocations, than some arbitrary utilization percentage. The > problem is that ARIN would then have to get into network design arguments. > > > Actually, I believe that this circumstance is the reason that the immediate > needs clause > exists. > > 4.2.1.6. Immediate need > > If an ISP has an immediate need for address space, and can provide > justification to show that the address space will be utilized within 30 days > of the request, ARIN may issue a block of address space, not larger than a > /16 nor smaller than ARIN's customary minimum allocation, to that > organization. These cases are exceptional. > > Perhaps, in practice, since it is located in principles (not sure how or why > that occurred), and there isn't anything concrete stating that it should be > treated as an exception to 4.2.4.1, it does not get implemented as I believe > was intended. Staff would have to clarify that. If that is the case, it > would be a relatively simple proposal to fix: > > Amend section 4.2.4 by adding: > 4.2.4.5 Exceptional Cases of Immediate Need > If a subscriber member has a customer who needs a larger block than remains > in the subscriber member's > free pool, then a request under section 4.2.1.6 shall apply as an exception > to the requirements in 4.2.4.1. > > The argument that just removing the needs test for smaller allocations > entirely > has some merit. The problem seems to be in defining what is small. A > compromise of /20 has > been suggested and I think it's reasonable. Even though I support needs > testing I can support removing it at a /20 and smaller. > > > I really think that removing the needs test is unlikely to gain consensus, > even at the smaller point. There is clear resistance in the community to > this idea and I expect that opposition will remain strong. > > If people support the idea above, I'm happy to put it into a policy template > and get it started in the process. If there is strong support, it can > probably be moved through the process fairly quickly. > > Owen > > > Larry Ash > > Andrew > On 6/24/2014 1:08 PM, Steven Ryerse wrote: > > This is the problem I'm trying to solve and why I've been so vocal about it. > 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? > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Tim Gimmel > Sent: Tuesday, June 24, 2014 4:04 PM > To: arin-ppml at arin.net List > Subject: Re: [arin-ppml] Policy discussion - Method of > calculatingutilization ARIN-2014-17 > > > The problem is that the current process has disenfranchised smaller > companies who are somewhat frequently requesting space under the 3 month > need projection and are ending up with many /22's, /21's etc instead of the > /20 or /19 that would have been possible prior to austerity measures. > To make matters worse, it does not seem that such companies are > substantially represented on PPML so it is creating an illusion that the > policy is not necessary or would not be supported by the community at large > (outside of PPML). > > This is exactly what is happening, for example I have 4 /20's and a /19 from > earlier days, but now I have 7 /21's and that is the most I will ever be > able to request. We are using every possible way to keep IPv4 usage down. > > --Tim > > _______________________________________________ > 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. > > > Larry Ash > Network Administrator > Mountain West Telephone > 123 W 1st St. > Casper, WY 82601 > Office 307 233-8387 > _______________________________________________ > 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. -- Jeffrey A. Lyon, CISSP-ISSMP Fellow, Black Lotus Communications mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net From gary.buhrmaster at gmail.com Wed Jun 25 16:33:42 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 25 Jun 2014 20:33:42 +0000 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: <3DE58922-17C4-4C0C-AD16-A821F676E391@delong.com> References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> <53A9F5E1.1010104@quark.net> <3DE58922-17C4-4C0C-AD16-A821F676E391@delong.com> Message-ID: On Wed, Jun 25, 2014 at 8:04 PM, Owen DeLong wrote: ..... > Actually, I believe that this circumstance is the reason that the immediate > needs clause > exists. "Immediate need" occurred to me, too, but as the NRPM can be a bit "dense" to parse, I had not had time to review if it properly applies. I am glad someone has more time (and experience) to parse the NRPM. ..... > If people support the idea above, I'm happy to put it into a policy template > and get it started in the process. If there is strong support, it can > probably be moved through the process fairly quickly. The devil is in the details, but this does, indeed, sound like the correct change to resolve what appears to one of those practical issues in real work networks that I support. Gary From jeffrey.lyon at blacklotus.net Wed Jun 25 16:37:18 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 26 Jun 2014 05:37:18 +0900 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> <53A9F5E1.1010104@quark.net> <3DE58922-17C4-4C0C-AD16-A821F676E391@delong.com> Message-ID: Owen, I would be extremely grateful if you would be kind enough to take charge of introducing the removal of needs testing for /20 and longer as a policy proposal. Please keep in mind we're still talking about this on the ARIN-2014-17 thread which is a different proposal :) Thanks, Jeff On Thu, Jun 26, 2014 at 5:33 AM, Gary Buhrmaster wrote: > On Wed, Jun 25, 2014 at 8:04 PM, Owen DeLong wrote: > ..... >> Actually, I believe that this circumstance is the reason that the immediate >> needs clause >> exists. > > "Immediate need" occurred to me, too, but as the > NRPM can be a bit "dense" to parse, I had not had > time to review if it properly applies. I am glad someone > has more time (and experience) to parse the NRPM. > > ..... > >> If people support the idea above, I'm happy to put it into a policy template >> and get it started in the process. If there is strong support, it can >> probably be moved through the process fairly quickly. > > The devil is in the details, but this does, indeed, > sound like the correct change to resolve what > appears to one of those practical issues in real > work networks that I support. > > Gary > _______________________________________________ > 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. -- Jeffrey A. Lyon, CISSP-ISSMP Fellow, Black Lotus Communications mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net From gary.buhrmaster at gmail.com Wed Jun 25 16:54:27 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 25 Jun 2014 20:54:27 +0000 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> <53A9F5E1.1010104@quark.net> <3DE58922-17C4-4C0C-AD16-A821F676E391@delong.com> Message-ID: On Wed, Jun 25, 2014 at 8:37 PM, Jeffrey Lyon wrote: > Owen, > > I would be extremely grateful if you would be kind enough to take > charge of introducing the removal of needs testing for /20 and longer > as a policy proposal. Perhaps I was unclear in my reply. I apologize. My support was for Owen's suggestion of an immediate need policy clarification, not for any removal of needs testing. I do not support removal of needs testing. Do not use my reply to support your position. Thank you. From info at arin.net Thu Jun 26 11:28:05 2014 From: info at arin.net (ARIN) Date: Thu, 26 Jun 2014 11:28:05 -0400 Subject: [arin-ppml] =?windows-1252?q?NRPM_2014=2E3_=96_New_Policies_Imple?= =?windows-1252?q?mented?= Message-ID: <53AC3C05.1080801@arin.net> On 16 May 2014 the ARIN Board of Trustees adopted the following policies: ARIN-2014-4: Remove 4.2.5 Web Hosting Policy https://www.arin.net/policy/proposals/2014_4.html ARIN-2014-7: Section 4.4 Micro Allocation Conservation Update https://www.arin.net/policy/proposals/2014_7.html ARIN-2014-10: Remove Sections 4.6 and 4.7 https://www.arin.net/policy/proposals/2014_10.html A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2014.3 is effective 26 June 2014 and supersedes the previous version. NRPM 2014.3 contains the implementation of the policies listed above. The NRPM is available at: https://www.arin.net/policy/nrpm.html Board minutes are available at: https://www.arin.net/about_us/bot/index.html Draft policies and proposals are 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) From jeffrey.lyon at blacklotus.net Thu Jun 26 11:39:22 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 26 Jun 2014 11:39:22 -0400 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> <53A9F5E1.1010104@quark.net> <3DE58922-17C4-4C0C-AD16-A821F676E391@delong.com> Message-ID: The recent adoption of ARIN-2014-7 makes 2014-17 even more crucial. Thanks, Jeff On Jun 25, 2014 4:54 PM, "Gary Buhrmaster" wrote: > On Wed, Jun 25, 2014 at 8:37 PM, Jeffrey Lyon > wrote: > > Owen, > > > > I would be extremely grateful if you would be kind enough to take > > charge of introducing the removal of needs testing for /20 and longer > > as a policy proposal. > > Perhaps I was unclear in my reply. I apologize. > My support was for Owen's suggestion of an > immediate need policy clarification, not for any > removal of needs testing. I do not support removal > of needs testing. Do not use my reply to support > your position. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Thu Jun 26 11:50:17 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Thu, 26 Jun 2014 08:50:17 -0700 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> <53A9F5E1.1010104@quark.net> <3DE58922-17C4-4C0C-AD16-A821F676E391@delong.com> Message-ID: <53AC4139.1020404@quark.net> Jeff, Can you please explain why you believe 2014-7 effects the discussion of 2014-17? They appear unrelated to me. Thanks, Andrew On 6/26/2014 8:39 AM, Jeffrey Lyon wrote: > > The recent adoption of ARIN-2014-7 makes 2014-17 even more crucial. > > Thanks, Jeff > > On Jun 25, 2014 4:54 PM, "Gary Buhrmaster" > wrote: > > On Wed, Jun 25, 2014 at 8:37 PM, Jeffrey Lyon > > > wrote: > > Owen, > > > > I would be extremely grateful if you would be kind enough to take > > charge of introducing the removal of needs testing for /20 and > longer > > as a policy proposal. > > Perhaps I was unclear in my reply. I apologize. > My support was for Owen's suggestion of an > immediate need policy clarification, not for any > removal of needs testing. I do not support removal > of needs testing. Do not use my reply to support > your position. Thank you. > > > > _______________________________________________ > 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 jeffrey.lyon at blacklotus.net Thu Jun 26 12:33:31 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 26 Jun 2014 12:33:31 -0400 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: <53AC4139.1020404@quark.net> References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> <53A9F5E1.1010104@quark.net> <3DE58922-17C4-4C0C-AD16-A821F676E391@delong.com> <53AC4139.1020404@quark.net> Message-ID: Andrew, To escape the issue of having to justify numerous smaller assignments individually one could have requested transition space in am attempt to aggregate. Thanks, Jeff On Jun 26, 2014 11:50 AM, "Andrew Dul" wrote: > Jeff, > > Can you please explain why you believe 2014-7 effects the discussion of > 2014-17? They appear unrelated to me. > > Thanks, > Andrew > > On 6/26/2014 8:39 AM, Jeffrey Lyon wrote: > > The recent adoption of ARIN-2014-7 makes 2014-17 even more crucial. > > Thanks, Jeff > On Jun 25, 2014 4:54 PM, "Gary Buhrmaster" > wrote: > >> On Wed, Jun 25, 2014 at 8:37 PM, Jeffrey Lyon >> wrote: >> > Owen, >> > >> > I would be extremely grateful if you would be kind enough to take >> > charge of introducing the removal of needs testing for /20 and longer >> > as a policy proposal. >> >> Perhaps I was unclear in my reply. I apologize. >> My support was for Owen's suggestion of an >> immediate need policy clarification, not for any >> removal of needs testing. I do not support removal >> of needs testing. Do not use my reply to support >> your position. Thank you. >> > > > _______________________________________________ > 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 Thu Jun 26 12:49:43 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Thu, 26 Jun 2014 09:49:43 -0700 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> <53A9F5E1.1010104@quark.net> <3DE58922-17C4-4C0C-AD16-A821F676E391@delong.com> <53AC4139.1020404@quark.net> Message-ID: <53AC4F27.7030606@quark.net> I'm still not understanding the connection, 2014-7 deals with the number of organizations in an internet exchange point to qualify for a direct allocation from ARIN. Are you thinking of a different policy? Andrew On 6/26/2014 9:33 AM, Jeffrey Lyon wrote: > > Andrew, > > To escape the issue of having to justify numerous smaller assignments > individually one could have requested transition space in am attempt > to aggregate. > > Thanks, Jeff > > On Jun 26, 2014 11:50 AM, "Andrew Dul" > wrote: > > Jeff, > > Can you please explain why you believe 2014-7 effects the > discussion of 2014-17? They appear unrelated to me. > > Thanks, > Andrew > > On 6/26/2014 8:39 AM, Jeffrey Lyon wrote: >> >> The recent adoption of ARIN-2014-7 makes 2014-17 even more crucial. >> >> Thanks, Jeff >> >> On Jun 25, 2014 4:54 PM, "Gary Buhrmaster" >> > wrote: >> >> On Wed, Jun 25, 2014 at 8:37 PM, Jeffrey Lyon >> > > wrote: >> > Owen, >> > >> > I would be extremely grateful if you would be kind enough >> to take >> > charge of introducing the removal of needs testing for /20 >> and longer >> > as a policy proposal. >> >> Perhaps I was unclear in my reply. I apologize. >> My support was for Owen's suggestion of an >> immediate need policy clarification, not for any >> removal of needs testing. I do not support removal >> of needs testing. Do not use my reply to support >> your position. Thank you. >> >> >> >> _______________________________________________ >> 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 jeffrey.lyon at blacklotus.net Thu Jun 26 12:51:30 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 26 Jun 2014 12:51:30 -0400 Subject: [arin-ppml] Policy discussion - Method of calculatingutilization ARIN-2014-17 In-Reply-To: <53AC4F27.7030606@quark.net> References: <5757446e3c394241a1179ece7780e38c@EXCHMB-03.ad.qservco.com> <5B9E90747FA2974D91A54FCFA1B8AD12015AFAFC6C@ENI-MAIL.eclipse-networks.com> <53A9F5E1.1010104@quark.net> <3DE58922-17C4-4C0C-AD16-A821F676E391@delong.com> <53AC4139.1020404@quark.net> <53AC4F27.7030606@quark.net> Message-ID: Yes, -10 actually. Thanks, Jeff On Jun 26, 2014 12:50 PM, "Andrew Dul" wrote: > I'm still not understanding the connection, 2014-7 deals with the number > of organizations in an internet exchange point to qualify for a direct > allocation from ARIN. Are you thinking of a different policy? > > Andrew > > On 6/26/2014 9:33 AM, Jeffrey Lyon wrote: > > Andrew, > > To escape the issue of having to justify numerous smaller assignments > individually one could have requested transition space in am attempt to > aggregate. > > Thanks, Jeff > On Jun 26, 2014 11:50 AM, "Andrew Dul" wrote: > >> Jeff, >> >> Can you please explain why you believe 2014-7 effects the discussion of >> 2014-17? They appear unrelated to me. >> >> Thanks, >> Andrew >> >> On 6/26/2014 8:39 AM, Jeffrey Lyon wrote: >> >> The recent adoption of ARIN-2014-7 makes 2014-17 even more crucial. >> >> Thanks, Jeff >> On Jun 25, 2014 4:54 PM, "Gary Buhrmaster" >> wrote: >> >>> On Wed, Jun 25, 2014 at 8:37 PM, Jeffrey Lyon >>> wrote: >>> > Owen, >>> > >>> > I would be extremely grateful if you would be kind enough to take >>> > charge of introducing the removal of needs testing for /20 and longer >>> > as a policy proposal. >>> >>> Perhaps I was unclear in my reply. I apologize. >>> My support was for Owen's suggestion of an >>> immediate need policy clarification, not for any >>> removal of needs testing. I do not support removal >>> of needs testing. Do not use my reply to support >>> your position. Thank you. >>> >> >> >> _______________________________________________ >> 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 Thu Jun 26 14:52:18 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Thu, 26 Jun 2014 11:52:18 -0700 Subject: [arin-ppml] [Revised] DRAFT POLICY ARIN-2014-9: RESOLVE CONFLICT BETWEEN RSA AND 8.2 UTILIZATION REQUIREMENTS In-Reply-To: References: Message-ID: <53AC6BE2.6090205@quark.net> On 6/2/2014 10:34 AM, Heather Schiller wrote: > At the PPM in April, there was support for leaving this paragraph in > the NRPM, but removing the words 'aggregate' and 'return', resulting > in the text below. The AC encourages feedback on this proposed change. > > Thanks, > --Heather > > > Draft Policy ARIN-2014-9 > Resolve Conflict Between RSA and 8.2 Utilization Requirements > > Remove the words "aggregate" and "reclaim" from 8.2, so it reads: > > "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." > This new text removes the threat of reclamation from the policy manual as the current RSA (section 6) prohibits ARIN from reclaiming addresses for lack of use, but this rewrite does not make it clear that an organization can retain their addresses for future use. This change makes it clear that resources or parts of resources will not become orphaned blocks due to a merger or acquisition. I believe this change would promote registry accuracy as it should allow organizations to update all their records to show the new holder and user of the resources regardless of utilization. May I suggest the following rewrite to clarify that an organization can retain their addresses through a transfer. ...ARIN will notify the resource holder(s) that they may return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy or retain their resources for future use or later transfer/return. Thanks, Andrew From scottleibrand at gmail.com Thu Jun 26 15:31:41 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 26 Jun 2014 12:31:41 -0700 Subject: [arin-ppml] [Revised] DRAFT POLICY ARIN-2014-9: RESOLVE CONFLICT BETWEEN RSA AND 8.2 UTILIZATION REQUIREMENTS In-Reply-To: <53AC6BE2.6090205@quark.net> References: <53AC6BE2.6090205@quark.net> Message-ID: On Thu, Jun 26, 2014 at 11:52 AM, Andrew Dul wrote: > On 6/2/2014 10:34 AM, Heather Schiller wrote: > > At the PPM in April, there was support for leaving this paragraph in > > the NRPM, but removing the words 'aggregate' and 'return', resulting > > in the text below. The AC encourages feedback on this proposed change. > > > > Thanks, > > --Heather > > > > > > Draft Policy ARIN-2014-9 > > Resolve Conflict Between RSA and 8.2 Utilization Requirements > > > > Remove the words "aggregate" and "reclaim" from 8.2, so it reads: > > > > "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." > > > > This new text removes the threat of reclamation from the policy manual > as the current RSA (section 6) prohibits ARIN from reclaiming addresses > for lack of use, but this rewrite does not make it clear that an > organization can retain their addresses for future use. This change > makes it clear that resources or parts of resources will not become > orphaned blocks due to a merger or acquisition. I believe this change > would promote registry accuracy as it should allow organizations to > update all their records to show the new holder and user of the > resources regardless of utilization. > > May I suggest the following rewrite to clarify that an organization can > retain their addresses through a transfer. > While that was a goal of the original proposal (which would've eliminated this section entirely) I did not get the sense that the community supported going that far. Rather, the consensus seemed to be that if an organization acquires addresses they don't currently need via M&A transfer, they should work in good faith to find a buyer for them and transfer them under 8.3 or 8.4. If they are unwilling to do so, they will remain in violation of this policy language and be unable to acquire any additional addresses, but ARIN will not attempt to reclaim the addresses. > ...ARIN will notify the resource holder(s) that they may return or > transfer resources as needed to restore compliance via the processes > outlined in current ARIN policy or retain their resources for future use > or later transfer/return. > If there is community support for allowing organizations to retain unneeded resources obtained through M&A for future use, please speak up. I didn't hear much support for that position expressed at the meeting. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From lar at mwtcorp.net Thu Jun 26 15:44:11 2014 From: lar at mwtcorp.net (lar at mwtcorp.net) Date: Thu, 26 Jun 2014 13:44:11 -0600 Subject: [arin-ppml] Unintended Consequence of 2014-17 Message-ID: I must strongly oppose 2014-17 It effectively removes meaningful needs testing for large and very large organizations. (I know that utilization isn't the only test but it's a major part of need testing.) According to my admittedly hasty and crude calculations: If you have in aggregate a /8 of IPv4 and you have 90% of it utilized. -You could- request a /16 and before you used a single one of those addresses meet the need requirement for another /16 and still be over 80% utilization. Other sizes scale accordingly but the effect is the same greatly favoring the large and very large. Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From scottleibrand at gmail.com Thu Jun 26 15:51:10 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 26 Jun 2014 12:51:10 -0700 Subject: [arin-ppml] Unintended Consequence of 2014-17 In-Reply-To: References: Message-ID: Once the free pool is exhausted, this text from 4.1.8, Unmet requests, also applies: Repeated requests, in a manner that would circumvent 4.1.6, are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. If 2014-17 does not take effect until after runout, does that address your concern going forward? Also, remember that if an organization qualifies for more than a /16, they will likely want to ask for more than a /16 up front. I'm not sure that asking for lots of small blocks back to back would do anything for them (unless they were trying to hoover up lots of smaller blocks because the size they qualify is gone, which is exactly what the above language was intended to prevent). -Scott On Thu, Jun 26, 2014 at 12:44 PM, wrote: > I must strongly oppose 2014-17 > > It effectively removes meaningful needs testing for large and very large > organizations. > (I know that utilization isn't the only test but it's a major part of need > testing.) > > According to my admittedly hasty and crude calculations: > If you have in aggregate a /8 of IPv4 and you have 90% of it utilized. > > -You could- > > request a /16 > > and before you used a single one of those addresses meet the need > requirement for another /16 and still > be over 80% utilization. > > Other sizes scale accordingly but the effect is the same greatly favoring > the large and very large. > > > Larry Ash > Network Administrator > Mountain West Telephone > 123 W 1st St. > Casper, WY 82601 > Office 307 233-8387 > _______________________________________________ > 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 jeffrey.lyon at blacklotus.net Thu Jun 26 16:25:38 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 26 Jun 2014 16:25:38 -0400 Subject: [arin-ppml] [Revised] DRAFT POLICY ARIN-2014-9: RESOLVE CONFLICT BETWEEN RSA AND 8.2 UTILIZATION REQUIREMENTS In-Reply-To: References: <53AC6BE2.6090205@quark.net> Message-ID: Scott, Notwithstanding my support for at least partially removing needs testing, addresses obtained via M&A should certainly be sold/transferred or returned. Thanks, Jeff On Thu, Jun 26, 2014 at 3:31 PM, Scott Leibrand wrote: > On Thu, Jun 26, 2014 at 11:52 AM, Andrew Dul wrote: >> >> On 6/2/2014 10:34 AM, Heather Schiller wrote: >> > At the PPM in April, there was support for leaving this paragraph in >> > the NRPM, but removing the words 'aggregate' and 'return', resulting >> > in the text below. The AC encourages feedback on this proposed change. >> > >> > Thanks, >> > --Heather >> > >> > >> > Draft Policy ARIN-2014-9 >> > Resolve Conflict Between RSA and 8.2 Utilization Requirements >> > >> > Remove the words "aggregate" and "reclaim" from 8.2, so it reads: >> > >> > "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." >> > >> >> This new text removes the threat of reclamation from the policy manual >> as the current RSA (section 6) prohibits ARIN from reclaiming addresses >> for lack of use, but this rewrite does not make it clear that an >> organization can retain their addresses for future use. This change >> makes it clear that resources or parts of resources will not become >> orphaned blocks due to a merger or acquisition. I believe this change >> would promote registry accuracy as it should allow organizations to >> update all their records to show the new holder and user of the >> resources regardless of utilization. >> >> May I suggest the following rewrite to clarify that an organization can >> retain their addresses through a transfer. > > > While that was a goal of the original proposal (which would've eliminated > this section entirely) I did not get the sense that the community supported > going that far. Rather, the consensus seemed to be that if an organization > acquires addresses they don't currently need via M&A transfer, they should > work in good faith to find a buyer for them and transfer them under 8.3 or > 8.4. If they are unwilling to do so, they will remain in violation of this > policy language and be unable to acquire any additional addresses, but ARIN > will not attempt to reclaim the addresses. > >> >> ...ARIN will notify the resource holder(s) that they may return or >> transfer resources as needed to restore compliance via the processes >> outlined in current ARIN policy or retain their resources for future use >> or later transfer/return. > > > If there is community support for allowing organizations to retain unneeded > resources obtained through M&A for future use, please speak up. I didn't > hear much support for that position expressed at the meeting. > > -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. -- Jeffrey A. Lyon, CISSP-ISSMP Fellow, Black Lotus Communications mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net From jeffrey.lyon at blacklotus.net Thu Jun 26 16:32:06 2014 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 26 Jun 2014 16:32:06 -0400 Subject: [arin-ppml] Unintended Consequence of 2014-17 In-Reply-To: References: Message-ID: Larry, -17 makes needs testing more fair for smaller organizations. In terms of larger organizations, it isn't at all practical to have a /8 and spend even a minute of your day to request something much, much smaller. That would be like me requesting a /24 right now. I would never do that :) I get the sense that some of the community feels I have an ulterior motive for supporting this proposal given my concurrent support of something similar to -14. Thanks, Jeff On Thu, Jun 26, 2014 at 3:44 PM, wrote: > I must strongly oppose 2014-17 > > It effectively removes meaningful needs testing for large and very large > organizations. > (I know that utilization isn't the only test but it's a major part of need > testing.) > > According to my admittedly hasty and crude calculations: > If you have in aggregate a /8 of IPv4 and you have 90% of it utilized. > > -You could- > > request a /16 > > and before you used a single one of those addresses meet the need > requirement for another /16 and still > be over 80% utilization. > > Other sizes scale accordingly but the effect is the same greatly favoring > the large and very large. > > > Larry Ash > Network Administrator > Mountain West Telephone > 123 W 1st St. > Casper, WY 82601 > Office 307 233-8387 > _______________________________________________ > 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. -- Jeffrey A. Lyon, CISSP-ISSMP Fellow, Black Lotus Communications mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net From gary.buhrmaster at gmail.com Thu Jun 26 16:58:16 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 26 Jun 2014 20:58:16 +0000 Subject: [arin-ppml] [Revised] DRAFT POLICY ARIN-2014-9: RESOLVE CONFLICT BETWEEN RSA AND 8.2 UTILIZATION REQUIREMENTS In-Reply-To: References: <53AC6BE2.6090205@quark.net> Message-ID: On Thu, Jun 26, 2014 at 7:31 PM, Scott Leibrand wrote: > On Thu, Jun 26, 2014 at 11:52 AM, Andrew Dul wrote: ..... >> May I suggest the following rewrite to clarify that an organization can >> retain their addresses through a transfer. ..... > If there is community support for allowing organizations to retain unneeded > resources obtained through M&A for future use, please speak up. I didn't > hear much support for that position expressed at the meeting. I would not support the change suggested by Andrew, and would consider it somewhat of a poison pill, as it attempts to codify elimination of needs testing for which there is not (to this point) a clear community consensus (although there continues to be a lively discussion). Let this proposal stand on its own merits. From owen at delong.com Thu Jun 26 19:20:44 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 26 Jun 2014 16:20:44 -0700 Subject: [arin-ppml] [Revised] DRAFT POLICY ARIN-2014-9: RESOLVE CONFLICT BETWEEN RSA AND 8.2 UTILIZATION REQUIREMENTS In-Reply-To: <53AC6BE2.6090205@quark.net> References: <53AC6BE2.6090205@quark.net> Message-ID: <51440F13-B71B-474A-B5F0-28A359648494@delong.com> On Jun 26, 2014, at 11:52 , Andrew Dul wrote: > On 6/2/2014 10:34 AM, Heather Schiller wrote: >> At the PPM in April, there was support for leaving this paragraph in >> the NRPM, but removing the words 'aggregate' and 'return', resulting >> in the text below. The AC encourages feedback on this proposed change. >> >> Thanks, >> --Heather >> >> >> Draft Policy ARIN-2014-9 >> Resolve Conflict Between RSA and 8.2 Utilization Requirements >> >> Remove the words "aggregate" and "reclaim" from 8.2, so it reads: >> >> "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." >> > > This new text removes the threat of reclamation from the policy manual > as the current RSA (section 6) prohibits ARIN from reclaiming addresses > for lack of use, but this rewrite does not make it clear that an > organization can retain their addresses for future use. This change > makes it clear that resources or parts of resources will not become > orphaned blocks due to a merger or acquisition. I believe this change > would promote registry accuracy as it should allow organizations to > update all their records to show the new holder and user of the > resources regardless of utilization. > > May I suggest the following rewrite to clarify that an organization can > retain their addresses through a transfer. > > ...ARIN will notify the resource holder(s) that they may return or > transfer resources as needed to restore compliance via the processes > outlined in current ARIN policy or retain their resources for future use > or later transfer/return. I would not support this change. It is not the intent of the policy to facilitate hoarding addresses for future use which is what this would enable. While ARIN is prohibited by (errors in) the RSA from reclaiming resources under this circumstance, I believe it is still appropriate for policy to require holders to take action to restore their networks to compliance with the intent of policy. Owen From khatfield at socllc.net Fri Jun 27 00:35:03 2014 From: khatfield at socllc.net (khatfield at socllc.net) Date: Thu, 26 Jun 2014 23:35:03 -0500 Subject: [arin-ppml] [Revised] DRAFT POLICY ARIN-2014-9: RESOLVE CONFLICT BETWEEN RSA AND 8.2 UTILIZATION REQUIREMENTS In-Reply-To: <51440F13-B71B-474A-B5F0-28A359648494@delong.com> References: <53AC6BE2.6090205@quark.net> <51440F13-B71B-474A-B5F0-28A359648494@delong.com> Message-ID: <1923962648.18361.1403843705546@a54c07c625104beab14eb508c863e787.nuevasync.com> I am in complete agreement with Owen. Additionally, I disagree on a change based on a business sale. The policies enforced for M&A have worked thus far. No one should be able to sell addresses as part of a business sale. There should be enough cooperation as part of the sale to allow a request and validation through ARIN after/during the a business transfer. This ensures the purchasing company isn't hoarding. Despite Jeffrey Lyon's previous request asking the community to not assume he has an "ulterior motive", I can respectfully ensure everyone that he does. Since Jeff has brought this up. I would also like to state that upon sale of some of my companies specific business assets, IP's not included. A sale with loan, which The IRC Company/Black Lotus chose to default on, with confirmation by the circuit court of Delaware. We have since been unable to get our previous host - Black Lotus to stop announcing our owned subnets and AS. Despite requests to their upstream providers we continue to be unable to use IP's we currently pay for. We additionally continue to receive spam notices, notices of racist (white power websites) being hosted on our IP's (by Black Lotus) as well as pretty much anything else they wouldn't normally host on their own IP's. Thereby, leaving my company with the legal implications of their continued abuse. Since Jeff was unable to default on us and take the IP's - you can see where this request is coming from. Therefore, I wish to ask the community to watch carefully for his "ulterior motives". Kevin Hatfield Carrier Communications, Inc. > On Jun 26, 2014, at 6:24 PM, "Owen DeLong" wrote: > > >> On Jun 26, 2014, at 11:52 , Andrew Dul wrote: >> >>> On 6/2/2014 10:34 AM, Heather Schiller wrote: >>> At the PPM in April, there was support for leaving this paragraph in >>> the NRPM, but removing the words 'aggregate' and 'return', resulting >>> in the text below. The AC encourages feedback on this proposed change. >>> >>> Thanks, >>> --Heather >>> >>> >>> Draft Policy ARIN-2014-9 >>> Resolve Conflict Between RSA and 8.2 Utilization Requirements >>> >>> Remove the words "aggregate" and "reclaim" from 8.2, so it reads: >>> >>> "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." >> >> This new text removes the threat of reclamation from the policy manual >> as the current RSA (section 6) prohibits ARIN from reclaiming addresses >> for lack of use, but this rewrite does not make it clear that an >> organization can retain their addresses for future use. This change >> makes it clear that resources or parts of resources will not become >> orphaned blocks due to a merger or acquisition. I believe this change >> would promote registry accuracy as it should allow organizations to >> update all their records to show the new holder and user of the >> resources regardless of utilization. >> >> May I suggest the following rewrite to clarify that an organization can >> retain their addresses through a transfer. >> >> ...ARIN will notify the resource holder(s) that they may return or >> transfer resources as needed to restore compliance via the processes >> outlined in current ARIN policy or retain their resources for future use >> or later transfer/return. > > I would not support this change. It is not the intent of the policy to facilitate > hoarding addresses for future use which is what this would enable. > > While ARIN is prohibited by (errors in) the RSA from reclaiming resources > under this circumstance, I believe it is still appropriate for policy to require > holders to take action to restore their networks to compliance with the intent > of policy. > > Owen > > _______________________________________________ > 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 narten at us.ibm.com Fri Jun 27 00:53:03 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 27 Jun 2014 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201406270453.s5R4r3bL023622@rotala.raleigh.ibm.com> Total of 47 messages in the last 7 days. script run at: Fri Jun 27 00:53:03 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 21.28% | 10 | 23.83% | 115415 | jeffrey.lyon at blacklotus.net 12.77% | 6 | 8.92% | 43173 | info at arin.net 8.51% | 4 | 8.74% | 42320 | owen at delong.com 8.51% | 4 | 8.49% | 41126 | andrew.dul at quark.net 6.38% | 3 | 9.65% | 46751 | sryerse at eclipse-networks.com 8.51% | 4 | 5.19% | 25131 | gary.buhrmaster at gmail.com 6.38% | 3 | 4.76% | 23035 | lar at mwtcorp.net 4.26% | 2 | 4.82% | 23345 | scottleibrand at gmail.com 4.26% | 2 | 4.46% | 21609 | dogwallah at gmail.com 2.13% | 1 | 4.05% | 19590 | bill at tknow.com 2.13% | 1 | 3.91% | 18953 | tim.gimmel at metronetinc.com 2.13% | 1 | 2.80% | 13535 | mueller at syr.edu 2.13% | 1 | 2.70% | 13069 | mpetach at netflight.com 2.13% | 1 | 2.48% | 12018 | farmer at umn.edu 2.13% | 1 | 1.47% | 7100 | kkargel at polartel.com 2.13% | 1 | 1.44% | 6965 | narten at us.ibm.com 2.13% | 1 | 1.31% | 6334 | mike at iptrading.com 2.13% | 1 | 0.98% | 4769 | john at egh.com --------+------+--------+----------+------------------------ 100.00% | 47 |100.00% | 484238 | Total From cja at daydream.com Mon Jun 30 17:34:12 2014 From: cja at daydream.com (CJ Aronson) Date: Mon, 30 Jun 2014 15:34:12 -0600 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: <53A9DC85.1020908@arin.net> References: <53A9DC85.1020908@arin.net> Message-ID: Hi everyone Does anyone have comments on this recommended draft policy? Thanks! ----Cathy On Tue, Jun 24, 2014 at 2:16 PM, ARIN wrote: > The ARIN Advisory Council (AC) met on 19 June 2014 and decided to > send the following to last call: > > Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New > Multiple Discrete Networks > > 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 8 July 2014. 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-2013-8 > Subsequent Allocations for New Multiple Discrete Networks > > Date: 16 May 2014 > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > This proposal enables fair and impartial number resource administration by > documenting how to get a new block for a new discrete network. Previous > versions of the policy did have this information and over time it has been > removed. > > This proposal is technically sound. There is a need for discrete networks > and an organization should have a policy that would allow it to create a > new discrete network. > > This proposal is supported by the community. There has been some concern > about the criterial that will be used and this version has been updated > with the current thinking on the criteria. > > Policy Statement: > > IPv4: > Add the following statement to section 4.5.4. > Upon verification that the organization has shown evidence of deployment > of the new discrete network site, the new network(s) shall be allocated the > minimum allocation size under section 4.2.1.5 unless the organization can > demonstrate additional need using the immediate need criteria (4.2.1.6). > > IPv6: > Add an additional reference to section 6.11.5.b such that it references > both the initial allocation and subsequent allocation sections of the IPv6 > LIR policy. > "Each network will be judged against the existing utilization criteria > specified in 6.5.2 and 6.5.3 as if it were a separate organization..." > > Comments: > a. Timetable for implementation: immediate > b. This policy is being proposed based upon the Policy Implementation & > Experience Report from ARIN 32. > https://www.arin.net/participate/meetings/reports/ > ARIN_32/PDF/thursday/nobile-policy.pdf > c: Older versions of the MDN policy did contain new network criteria. This > criteria appears to have been dropped during subsequent rewrites of the MDN > policy. "The organization must not allocate a CIDR block larger than the > current minimum assignment size of the RIR (currently /20 for ARIN) to a > new network." (https://www.arin.net/policy/archive/nrpm_20041015.pdf) > _______________________________________________ > 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 celestea at usc.edu Mon Jun 30 18:01:08 2014 From: celestea at usc.edu (Celeste Anderson) Date: Mon, 30 Jun 2014 22:01:08 +0000 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: References: <53A9DC85.1020908@arin.net>, Message-ID: <1404165667297.60035@usc.edu> ?Looks okay. No further comments. --celeste. ________________________________ From: arin-ppml-bounces at arin.net on behalf of CJ Aronson Sent: Monday, June 30, 2014 2:34 PM To: ARIN Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks Hi everyone Does anyone have comments on this recommended draft policy? Thanks! ----Cathy On Tue, Jun 24, 2014 at 2:16 PM, ARIN > wrote: The ARIN Advisory Council (AC) met on 19 June 2014 and decided to send the following to last call: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks 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 8 July 2014. 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-2013-8 Subsequent Allocations for New Multiple Discrete Networks Date: 16 May 2014 AC's assessment of conformance with the Principles of Internet Number Resource Policy: This proposal enables fair and impartial number resource administration by documenting how to get a new block for a new discrete network. Previous versions of the policy did have this information and over time it has been removed. This proposal is technically sound. There is a need for discrete networks and an organization should have a policy that would allow it to create a new discrete network. This proposal is supported by the community. There has been some concern about the criterial that will be used and this version has been updated with the current thinking on the criteria. Policy Statement: IPv4: Add the following statement to section 4.5.4. Upon verification that the organization has shown evidence of deployment of the new discrete network site, the new network(s) shall be allocated the minimum allocation size under section 4.2.1.5 unless the organization can demonstrate additional need using the immediate need criteria (4.2.1.6). IPv6: Add an additional reference to section 6.11.5.b such that it references both the initial allocation and subsequent allocation sections of the IPv6 LIR policy. "Each network will be judged against the existing utilization criteria specified in 6.5.2 and 6.5.3 as if it were a separate organization..." Comments: a. Timetable for implementation: immediate b. This policy is being proposed based upon the Policy Implementation & Experience Report from ARIN 32. https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf c: Older versions of the MDN policy did contain new network criteria. This criteria appears to have been dropped during subsequent rewrites of the MDN policy. "The organization must not allocate a CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to a new network." (https://www.arin.net/policy/archive/nrpm_20041015.pdf) _______________________________________________ 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 Jun 30 18:58:31 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 30 Jun 2014 18:58:31 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: References: <53A9DC85.1020908@arin.net> Message-ID: <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> Objection, with the majority of the community from the previous ARIN meeting, recent NANOG PPC and other comments and fora discussion. But don't let that stop the ARIN AC from moving it forward in its obsession with controlling v4 markets. Best, -M< > On Jun 30, 2014, at 17:34, CJ Aronson wrote: > > Hi everyone > > Does anyone have comments on this recommended draft policy? > > Thanks! > ----Cathy > > >> On Tue, Jun 24, 2014 at 2:16 PM, ARIN wrote: >> The ARIN Advisory Council (AC) met on 19 June 2014 and decided to >> send the following to last call: >> >> Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks >> >> 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 8 July 2014. 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-2013-8 >> Subsequent Allocations for New Multiple Discrete Networks >> >> Date: 16 May 2014 >> >> AC's assessment of conformance with the Principles of Internet Number Resource Policy: >> >> This proposal enables fair and impartial number resource administration by documenting how to get a new block for a new discrete network. Previous versions of the policy did have this information and over time it has been removed. >> >> This proposal is technically sound. There is a need for discrete networks and an organization should have a policy that would allow it to create a new discrete network. >> >> This proposal is supported by the community. There has been some concern about the criterial that will be used and this version has been updated with the current thinking on the criteria. >> >> Policy Statement: >> >> IPv4: >> Add the following statement to section 4.5.4. >> Upon verification that the organization has shown evidence of deployment of the new discrete network site, the new network(s) shall be allocated the minimum allocation size under section 4.2.1.5 unless the organization can demonstrate additional need using the immediate need criteria (4.2.1.6). >> >> IPv6: >> Add an additional reference to section 6.11.5.b such that it references both the initial allocation and subsequent allocation sections of the IPv6 LIR policy. >> "Each network will be judged against the existing utilization criteria specified in 6.5.2 and 6.5.3 as if it were a separate organization..." >> >> Comments: >> a. Timetable for implementation: immediate >> b. This policy is being proposed based upon the Policy Implementation & Experience Report from ARIN 32. >> https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf >> c: Older versions of the MDN policy did contain new network criteria. This criteria appears to have been dropped during subsequent rewrites of the MDN policy. "The organization must not allocate a CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to a new network." (https://www.arin.net/policy/archive/nrpm_20041015.pdf) >> _______________________________________________ >> 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 JOHN at egh.com Mon Jun 30 19:04:01 2014 From: JOHN at egh.com (John Santos) Date: Mon, 30 Jun 2014 19:04:01 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> Message-ID: <1140630190321.35075G-100000@joonya.egh.com> Support. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From jcurran at arin.net Mon Jun 30 19:12:21 2014 From: jcurran at arin.net (John Curran) Date: Mon, 30 Jun 2014 23:12:21 +0000 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> Message-ID: On Jun 30, 2014, at 6:58 PM, Martin Hannigan wrote: > Objection, with the majority of the community from the previous ARIN meeting, recent NANOG PPC and other comments and fora discussion. > > But don't let that stop the ARIN AC from moving it forward in its obsession with controlling v4 markets. Martin - The policy in question would be applied both with respect to allocations from the regional free pool as well as during specified transfers for those seeking to use the MDN policy for their basis of need. It would be helpful to the discussion if you could elaborate on your views on how the addition of the proposed policy language would result in unfair and/or technically unsound administration of number resources. Thanks! /John John Curran President and CEO ARIN From hannigan at gmail.com Mon Jun 30 19:16:30 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 30 Jun 2014 19:16:30 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> Message-ID: On Monday, June 30, 2014, John Curran wrote: > On Jun 30, 2014, at 6:58 PM, Martin Hannigan > wrote: > > > Objection, with the majority of the community from the previous ARIN > meeting, recent NANOG PPC and other comments and fora discussion. > > > > But don't let that stop the ARIN AC from moving it forward in its > obsession with controlling v4 markets. > > Martin - > > The policy in question would be applied both with respect to allocations > from the > regional free pool as well as during specified transfers for those > seeking to use the > MDN policy for their basis of need. > > It would be helpful to the discussion if you could elaborate on your > views on how the > addition of the proposed policy language would result in unfair and/or > technically > unsound administration of number resources. > > Thanks! > /John John, See the multiple event transcripts. We'covered this ground. No need to waste bits. If you, or the AC, disagrees feel free to tear my opinion apart with the myriad of facts you undoubtedly possess. :) Let's simply agree that the ARIN AC doesn't represent all of our view points effectively and see what happens? Best, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Jun 30 19:31:07 2014 From: jcurran at arin.net (John Curran) Date: Mon, 30 Jun 2014 23:31:07 +0000 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> Message-ID: On Jun 30, 2014, at 7:16 PM, Martin Hannigan wrote: > See the multiple event transcripts. > > We'covered this ground. No need to waste bits. If you, or the AC, disagrees feel free to tear my opinion apart with the myriad of facts you undoubtedly possess. :) Martin - I have no view on the draft policy, but for others considering whether they are in support or in opposition, it would be use to have a short summary of your concerns. > Let's simply agree that the ARIN AC doesn't represent all of our view points effectively and see what happens? If you take a moment to express your views on the list, then the entire community will see them and can support (or not) in their responses. There is no question of representation if you take the opportunity to post your reasoning to the list. It is, however, entirely your choice. Thanks! /John John Curran President and CEO ARIN From scottleibrand at gmail.com Mon Jun 30 19:38:46 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 30 Jun 2014 16:38:46 -0700 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> Message-ID: Martin, I felt the objections raised at previous meetings were addressed, not ignored. Can you clarify how you feel that this policy would make it harder for a recipient to qualify to receive space via transfer? The intent here is to allow organizations to create new discrete networks and qualify for space from them. If you think it will do the opposite, it's worth detailing how and why. It's also worth noting that, by documenting the basic requirements for such networks, it also reduces ARIN staff's discretion and provides additional policy certainty. Scott > On Jun 30, 2014, at 3:58 PM, Martin Hannigan wrote: > > Objection, with the majority of the community from the previous ARIN meeting, recent NANOG PPC and other comments and fora discussion. > > But don't let that stop the ARIN AC from moving it forward in its obsession with controlling v4 markets. > > Best, > > -M< > > >> On Jun 30, 2014, at 17:34, CJ Aronson wrote: >> >> Hi everyone >> >> Does anyone have comments on this recommended draft policy? >> >> Thanks! >> ----Cathy >> >> >>> On Tue, Jun 24, 2014 at 2:16 PM, ARIN wrote: >>> The ARIN Advisory Council (AC) met on 19 June 2014 and decided to >>> send the following to last call: >>> >>> Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks >>> >>> 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 8 July 2014. 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-2013-8 >>> Subsequent Allocations for New Multiple Discrete Networks >>> >>> Date: 16 May 2014 >>> >>> AC's assessment of conformance with the Principles of Internet Number Resource Policy: >>> >>> This proposal enables fair and impartial number resource administration by documenting how to get a new block for a new discrete network. Previous versions of the policy did have this information and over time it has been removed. >>> >>> This proposal is technically sound. There is a need for discrete networks and an organization should have a policy that would allow it to create a new discrete network. >>> >>> This proposal is supported by the community. There has been some concern about the criterial that will be used and this version has been updated with the current thinking on the criteria. >>> >>> Policy Statement: >>> >>> IPv4: >>> Add the following statement to section 4.5.4. >>> Upon verification that the organization has shown evidence of deployment of the new discrete network site, the new network(s) shall be allocated the minimum allocation size under section 4.2.1.5 unless the organization can demonstrate additional need using the immediate need criteria (4.2.1.6). >>> >>> IPv6: >>> Add an additional reference to section 6.11.5.b such that it references both the initial allocation and subsequent allocation sections of the IPv6 LIR policy. >>> "Each network will be judged against the existing utilization criteria specified in 6.5.2 and 6.5.3 as if it were a separate organization..." >>> >>> Comments: >>> a. Timetable for implementation: immediate >>> b. This policy is being proposed based upon the Policy Implementation & Experience Report from ARIN 32. >>> https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf >>> c: Older versions of the MDN policy did contain new network criteria. This criteria appears to have been dropped during subsequent rewrites of the MDN policy. "The organization must not allocate a CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to a new network." (https://www.arin.net/policy/archive/nrpm_20041015.pdf) >>> _______________________________________________ >>> 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 Mon Jun 30 19:59:34 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 30 Jun 2014 19:59:34 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> Message-ID: <3FD6B958-E21D-41C7-AA84-D656A0EB67F0@gmail.com> Scott, Asking me to do the work the AC is supposed to do is like asking a nun to certify their virginity. I made my point and I feel zero need to defend what is completely obvious and on the record. As I explained to our "CEO and President", feel free to demonstrate otherwise. Best, Martin > On Jun 30, 2014, at 19:38, Scott Leibrand wrote: > > Martin, > > I felt the objections raised at previous meetings were addressed, not ignored. Can you clarify how you feel that this policy would make it harder for a recipient to qualify to receive space via transfer? The intent here is to allow organizations to create new discrete networks and qualify for space from them. If you think it will do the opposite, it's worth detailing how and why. > > It's also worth noting that, by documenting the basic requirements for such networks, it also reduces ARIN staff's discretion and provides additional policy certainty. > > Scott > >> On Jun 30, 2014, at 3:58 PM, Martin Hannigan wrote: >> >> Objection, with the majority of the community from the previous ARIN meeting, recent NANOG PPC and other comments and fora discussion. >> >> But don't let that stop the ARIN AC from moving it forward in its obsession with controlling v4 markets. >> >> Best, >> >> -M< >> >> >>> On Jun 30, 2014, at 17:34, CJ Aronson wrote: >>> >>> Hi everyone >>> >>> Does anyone have comments on this recommended draft policy? >>> >>> Thanks! >>> ----Cathy >>> >>> >>>> On Tue, Jun 24, 2014 at 2:16 PM, ARIN wrote: >>>> The ARIN Advisory Council (AC) met on 19 June 2014 and decided to >>>> send the following to last call: >>>> >>>> Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks >>>> >>>> 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 8 July 2014. 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-2013-8 >>>> Subsequent Allocations for New Multiple Discrete Networks >>>> >>>> Date: 16 May 2014 >>>> >>>> AC's assessment of conformance with the Principles of Internet Number Resource Policy: >>>> >>>> This proposal enables fair and impartial number resource administration by documenting how to get a new block for a new discrete network. Previous versions of the policy did have this information and over time it has been removed. >>>> >>>> This proposal is technically sound. There is a need for discrete networks and an organization should have a policy that would allow it to create a new discrete network. >>>> >>>> This proposal is supported by the community. There has been some concern about the criterial that will be used and this version has been updated with the current thinking on the criteria. >>>> >>>> Policy Statement: >>>> >>>> IPv4: >>>> Add the following statement to section 4.5.4. >>>> Upon verification that the organization has shown evidence of deployment of the new discrete network site, the new network(s) shall be allocated the minimum allocation size under section 4.2.1.5 unless the organization can demonstrate additional need using the immediate need criteria (4.2.1.6). >>>> >>>> IPv6: >>>> Add an additional reference to section 6.11.5.b such that it references both the initial allocation and subsequent allocation sections of the IPv6 LIR policy. >>>> "Each network will be judged against the existing utilization criteria specified in 6.5.2 and 6.5.3 as if it were a separate organization..." >>>> >>>> Comments: >>>> a. Timetable for implementation: immediate >>>> b. This policy is being proposed based upon the Policy Implementation & Experience Report from ARIN 32. >>>> https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf >>>> c: Older versions of the MDN policy did contain new network criteria. This criteria appears to have been dropped during subsequent rewrites of the MDN policy. "The organization must not allocate a CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to a new network." (https://www.arin.net/policy/archive/nrpm_20041015.pdf) >>>> _______________________________________________ >>>> 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 Mon Jun 30 20:12:33 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 30 Jun 2014 17:12:33 -0700 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: <3FD6B958-E21D-41C7-AA84-D656A0EB67F0@gmail.com> References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> <3FD6B958-E21D-41C7-AA84-D656A0EB67F0@gmail.com> Message-ID: You obviously have a unique perspective on this issue that would be worth sharing, as I'm not aware of anyone else who has expressed the concern that the current version of this policy would make it harder to qualify for space. (Previous versions had some language that might've, which was changed to avoid doing so.) If you can explain the reason for your objection in enough detail for us to understand what the issue is, I'd be happy to work more with the AC shepherds and the author, to (for example) look at additional language changes to address the concern. I understand that your objection s obvious to you, but it's not obvious to me (as applied to the current revised text). And without being able to understand the objection, I can't in good conscience speak up against moving this policy forward. -Scott On Mon, Jun 30, 2014 at 4:59 PM, Martin Hannigan wrote: > > Scott, > > Asking me to do the work the AC is supposed to do is like asking a nun to > certify their virginity. > > I made my point and I feel zero need to defend what is completely obvious > and on the record. > > As I explained to our "CEO and President", feel free to demonstrate > otherwise. > > Best, > > Martin > > > > On Jun 30, 2014, at 19:38, Scott Leibrand wrote: > > Martin, > > I felt the objections raised at previous meetings were addressed, not > ignored. Can you clarify how you feel that this policy would make it harder > for a recipient to qualify to receive space via transfer? The intent here > is to allow organizations to create new discrete networks and qualify for > space from them. If you think it will do the opposite, it's worth detailing > how and why. > > It's also worth noting that, by documenting the basic requirements for > such networks, it also reduces ARIN staff's discretion and provides > additional policy certainty. > > Scott > > On Jun 30, 2014, at 3:58 PM, Martin Hannigan wrote: > > Objection, with the majority of the community from the previous ARIN > meeting, recent NANOG PPC and other comments and fora discussion. > > But don't let that stop the ARIN AC from moving it forward in its > obsession with controlling v4 markets. > > Best, > > -M< > > > On Jun 30, 2014, at 17:34, CJ Aronson wrote: > > Hi everyone > > Does anyone have comments on this recommended draft policy? > > Thanks! > ----Cathy > > > On Tue, Jun 24, 2014 at 2:16 PM, ARIN wrote: > >> The ARIN Advisory Council (AC) met on 19 June 2014 and decided to >> send the following to last call: >> >> Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New >> Multiple Discrete Networks >> >> 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 8 July 2014. 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-2013-8 >> Subsequent Allocations for New Multiple Discrete Networks >> >> Date: 16 May 2014 >> >> AC's assessment of conformance with the Principles of Internet Number >> Resource Policy: >> >> This proposal enables fair and impartial number resource administration >> by documenting how to get a new block for a new discrete network. Previous >> versions of the policy did have this information and over time it has been >> removed. >> >> This proposal is technically sound. There is a need for discrete networks >> and an organization should have a policy that would allow it to create a >> new discrete network. >> >> This proposal is supported by the community. There has been some concern >> about the criterial that will be used and this version has been updated >> with the current thinking on the criteria. >> >> Policy Statement: >> >> IPv4: >> Add the following statement to section 4.5.4. >> Upon verification that the organization has shown evidence of deployment >> of the new discrete network site, the new network(s) shall be allocated the >> minimum allocation size under section 4.2.1.5 unless the organization can >> demonstrate additional need using the immediate need criteria (4.2.1.6). >> >> IPv6: >> Add an additional reference to section 6.11.5.b such that it references >> both the initial allocation and subsequent allocation sections of the IPv6 >> LIR policy. >> "Each network will be judged against the existing utilization criteria >> specified in 6.5.2 and 6.5.3 as if it were a separate organization..." >> >> Comments: >> a. Timetable for implementation: immediate >> b. This policy is being proposed based upon the Policy Implementation & >> Experience Report from ARIN 32. >> https://www.arin.net/participate/meetings/reports/ >> ARIN_32/PDF/thursday/nobile-policy.pdf >> c: Older versions of the MDN policy did contain new network criteria. >> This criteria appears to have been dropped during subsequent rewrites of >> the MDN policy. "The organization must not allocate a CIDR block larger >> than the current minimum assignment size of the RIR (currently /20 for >> ARIN) to a new network." (https://www.arin.net/policy/ >> archive/nrpm_20041015.pdf) >> _______________________________________________ >> 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 jcurran at arin.net Mon Jun 30 20:17:57 2014 From: jcurran at arin.net (John Curran) Date: Tue, 1 Jul 2014 00:17:57 +0000 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: <3FD6B958-E21D-41C7-AA84-D656A0EB67F0@gmail.com> References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> , <3FD6B958-E21D-41C7-AA84-D656A0EB67F0@gmail.com> Message-ID: On Jun 30, 2014, at 7:59 PM, "Martin Hannigan" wrote: > > Asking me to do the work the AC ... To be clear, the draft policy was revised based on the input received and the AC is doing -_their_ job by asking if there remains any objections. The job of those in the community is to express any concerns that they still have with regards to the recommended draft policy. Thanks! /John John Curran President and CEO ARIN From hannigan at gmail.com Mon Jun 30 20:19:50 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 30 Jun 2014 20:19:50 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> <3FD6B958-E21D-41C7-AA84-D656A0EB67F0@gmail.com> Message-ID: I'm clear. I was in the room. My perspective is that they didn't listen. They (you) can feel free to demonstrate to us that they did. Best, -M< > On Jun 30, 2014, at 20:17, John Curran wrote: > >> On Jun 30, 2014, at 7:59 PM, "Martin Hannigan" wrote: >> >> Asking me to do the work the AC ... > > To be clear, the draft policy was revised based on the > input received and the AC is doing -_their_ job by asking > if there remains any objections. > > The job of those in the community is to express any concerns > that they still have with regards to the recommended draft policy. > > Thanks! > /John > > John Curran > President and CEO > ARIN > From scottleibrand at gmail.com Mon Jun 30 20:54:05 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 30 Jun 2014 17:54:05 -0700 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> <3FD6B958-E21D-41C7-AA84-D656A0EB67F0@gmail.com> Message-ID: I was in the room as well. I heard your objections in Chicago ( https://www.arin.net/participate/meetings/reports/ARIN_33/ppm1_transcript.html#anchor_11) "to the contract issue". Since then, ARIN-2013-8 has been revised to address your concern, and in fact no longer requires any contracts for connectivity, but simply "evidence of deployment of the new discrete network site". Since that revision, ARIN-2013-8 was also discussed at the ARIN PPC and NANOG 61 in Bellevue. I don't recall or see ( https://www.arin.net/participate/meetings/reports/ppc_nanog61/ppc_transcript.html#anchor_3) that you (or anyone else) raised any concerns at that meeting. I believe the main objection you expressed at the ARIN 33 meeting has been addressed. If you have another objection, or you feel it hasn't been addressed, please provide some additional details. Otherwise, this will be my last message on this topic. -Scott On Mon, Jun 30, 2014 at 5:19 PM, Martin Hannigan wrote: > > I'm clear. I was in the room. My perspective is that they didn't listen. > > They (you) can feel free to demonstrate to us that they did. > > Best, > > -M< > > > > > On Jun 30, 2014, at 20:17, John Curran wrote: > > > >> On Jun 30, 2014, at 7:59 PM, "Martin Hannigan" > wrote: > >> > >> Asking me to do the work the AC ... > > > > To be clear, the draft policy was revised based on the > > input received and the AC is doing -_their_ job by asking > > if there remains any objections. > > > > The job of those in the community is to express any concerns > > that they still have with regards to the recommended draft policy. > > > > Thanks! > > /John > > > > John Curran > > President and CEO > > ARIN > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Mon Jun 30 20:57:32 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 30 Jun 2014 20:57:32 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> <3FD6B958-E21D-41C7-AA84-D656A0EB67F0@gmail.com> Message-ID: Scott, There have been more objections than mine all along the route. We pay ARIN millions in fees. We simply ask that ARIN do what we believe is best. Assuming that this is simply about my opinion demonstrates ARINs usual arrogance. Best, -M< On Monday, June 30, 2014, Scott Leibrand wrote: > I was in the room as well. I heard your objections in Chicago ( > https://www.arin.net/participate/meetings/reports/ARIN_33/ppm1_transcript.html#anchor_11) > "to the contract issue". Since then, ARIN-2013-8 has been revised to > address your concern, and in fact no longer requires any contracts for > connectivity, but simply "evidence of deployment of the new discrete > network site". > > Since that revision, ARIN-2013-8 was also discussed at the ARIN PPC and > NANOG 61 in Bellevue. I don't recall or see ( > https://www.arin.net/participate/meetings/reports/ppc_nanog61/ppc_transcript.html#anchor_3) > that you (or anyone else) raised any concerns at that meeting. > > I believe the main objection you expressed at the ARIN 33 meeting has been > addressed. If you have another objection, or you feel it hasn't been > addressed, please provide some additional details. Otherwise, this will be > my last message on this topic. > > -Scott > > > On Mon, Jun 30, 2014 at 5:19 PM, Martin Hannigan > wrote: > >> >> I'm clear. I was in the room. My perspective is that they didn't listen. >> >> They (you) can feel free to demonstrate to us that they did. >> >> Best, >> >> -M< >> >> >> >> > On Jun 30, 2014, at 20:17, John Curran > > wrote: >> > >> >> On Jun 30, 2014, at 7:59 PM, "Martin Hannigan" > > wrote: >> >> >> >> Asking me to do the work the AC ... >> > >> > To be clear, the draft policy was revised based on the >> > input received and the AC is doing -_their_ job by asking >> > if there remains any objections. >> > >> > The job of those in the community is to express any concerns >> > that they still have with regards to the recommended draft policy. >> > >> > Thanks! >> > /John >> > >> > John Curran >> > President and CEO >> > ARIN >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cja at daydream.com Mon Jun 30 22:05:58 2014 From: cja at daydream.com (CJ Aronson) Date: Mon, 30 Jun 2014 20:05:58 -0600 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> <3FD6B958-E21D-41C7-AA84-D656A0EB67F0@gmail.com> Message-ID: Everyone out there. If there are more objections to this policy please speak up. Thanks! ----Cathy On Mon, Jun 30, 2014 at 6:57 PM, Martin Hannigan wrote: > > Scott, > > There have been more objections than mine all along the route. We pay > ARIN millions in fees. We simply ask that ARIN do what we believe is best. > > Assuming that this is simply about my opinion demonstrates ARINs > usual arrogance. > > Best, > > -M< > > On Monday, June 30, 2014, Scott Leibrand wrote: > >> I was in the room as well. I heard your objections in Chicago ( >> https://www.arin.net/participate/meetings/reports/ARIN_33/ppm1_transcript.html#anchor_11) >> "to the contract issue". Since then, ARIN-2013-8 has been revised to >> address your concern, and in fact no longer requires any contracts for >> connectivity, but simply "evidence of deployment of the new discrete >> network site". >> >> Since that revision, ARIN-2013-8 was also discussed at the ARIN PPC and >> NANOG 61 in Bellevue. I don't recall or see ( >> https://www.arin.net/participate/meetings/reports/ppc_nanog61/ppc_transcript.html#anchor_3) >> that you (or anyone else) raised any concerns at that meeting. >> >> I believe the main objection you expressed at the ARIN 33 meeting has >> been addressed. If you have another objection, or you feel it hasn't been >> addressed, please provide some additional details. Otherwise, this will be >> my last message on this topic. >> >> -Scott >> >> >> On Mon, Jun 30, 2014 at 5:19 PM, Martin Hannigan >> wrote: >> >>> >>> I'm clear. I was in the room. My perspective is that they didn't listen. >>> >>> They (you) can feel free to demonstrate to us that they did. >>> >>> Best, >>> >>> -M< >>> >>> >>> >>> > On Jun 30, 2014, at 20:17, John Curran wrote: >>> > >>> >> On Jun 30, 2014, at 7:59 PM, "Martin Hannigan" >>> wrote: >>> >> >>> >> Asking me to do the work the AC ... >>> > >>> > To be clear, the draft policy was revised based on the >>> > input received and the AC is doing -_their_ job by asking >>> > if there remains any objections. >>> > >>> > The job of those in the community is to express any concerns >>> > that they still have with regards to the recommended draft policy. >>> > >>> > 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 cja at daydream.com Mon Jun 30 22:31:59 2014 From: cja at daydream.com (CJ Aronson) Date: Mon, 30 Jun 2014 20:31:59 -0600 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks In-Reply-To: References: <53A9DC85.1020908@arin.net> <1A7654A5-1A4D-4656-A166-2B867198916F@gmail.com> <3FD6B958-E21D-41C7-AA84-D656A0EB67F0@gmail.com> Message-ID: Martin, Here is the link to the transcript from NANOG 60 PPC (the one before last) https://www.arin.net/participate/meetings/reports/ppc_nanog60/ppc_transcript.html#anchor_3 Here you said your main objection was the policy requiring a contract and we took that away. At the PPC in Washington (NANOG 61) there wasn't one single comment positive or negative from the audience. I fail to see from the transcript from NANOG 60 what your objections are at this time since we changed the text and removed what you said concerned you. I went back and reread it to make sure I remembered exactly what you had said. Although I have tried for many years I am unable to read minds. Please tell us what is a problem at this point. If anyone else can tell us that would be great too. Thanks! ----Cathy On Mon, Jun 30, 2014 at 6:57 PM, Martin Hannigan wrote: > > Scott, > > There have been more objections than mine all along the route. We pay > ARIN millions in fees. We simply ask that ARIN do what we believe is best. > > Assuming that this is simply about my opinion demonstrates ARINs > usual arrogance. > > Best, > > -M< > > On Monday, June 30, 2014, Scott Leibrand wrote: > >> I was in the room as well. I heard your objections in Chicago ( >> https://www.arin.net/participate/meetings/reports/ARIN_33/ppm1_transcript.html#anchor_11) >> "to the contract issue". Since then, ARIN-2013-8 has been revised to >> address your concern, and in fact no longer requires any contracts for >> connectivity, but simply "evidence of deployment of the new discrete >> network site". >> >> Since that revision, ARIN-2013-8 was also discussed at the ARIN PPC and >> NANOG 61 in Bellevue. I don't recall or see ( >> https://www.arin.net/participate/meetings/reports/ppc_nanog61/ppc_transcript.html#anchor_3) >> that you (or anyone else) raised any concerns at that meeting. >> >> I believe the main objection you expressed at the ARIN 33 meeting has >> been addressed. If you have another objection, or you feel it hasn't been >> addressed, please provide some additional details. Otherwise, this will be >> my last message on this topic. >> >> -Scott >> >> >> On Mon, Jun 30, 2014 at 5:19 PM, Martin Hannigan >> wrote: >> >>> >>> I'm clear. I was in the room. My perspective is that they didn't listen. >>> >>> They (you) can feel free to demonstrate to us that they did. >>> >>> Best, >>> >>> -M< >>> >>> >>> >>> > On Jun 30, 2014, at 20:17, John Curran wrote: >>> > >>> >> On Jun 30, 2014, at 7:59 PM, "Martin Hannigan" >>> wrote: >>> >> >>> >> Asking me to do the work the AC ... >>> > >>> > To be clear, the draft policy was revised based on the >>> > input received and the AC is doing -_their_ job by asking >>> > if there remains any objections. >>> > >>> > The job of those in the community is to express any concerns >>> > that they still have with regards to the recommended draft policy. >>> > >>> > 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: