From narten at us.ibm.com Fri Feb 5 00:53:03 2016 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 05 Feb 2016 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201602050553.u155r3Do011980@rotala.raleigh.ibm.com> Total of 6 messages in the last 7 days. script run at: Fri Feb 5 00:53:02 EST 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 16.67% | 1 | 35.78% | 59039 | andrew.dul at quark.net 16.67% | 1 | 20.59% | 33972 | jschiller at google.com 16.67% | 1 | 14.91% | 24600 | dogwallah at gmail.com 16.67% | 1 | 12.67% | 20912 | rjletts at uw.edu 16.67% | 1 | 11.80% | 19465 | ctacit at tacitlaw.com 16.67% | 1 | 4.26% | 7022 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 6 |100.00% | 165010 | Total From jschiller at google.com Wed Feb 10 22:31:50 2016 From: jschiller at google.com (Jason Schiller) Date: Wed, 10 Feb 2016 22:31:50 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-5: Out of region use In-Reply-To: <56290749.5040609@arin.net> References: <56290749.5040609@arin.net> Message-ID: Jason Schiller, Google, ASO AC, I Support this policy as written. In response to comments by Bob Evens, Fiber Internet Center at the NANOG 66 PPC mic, proof of carrying on business in the ARIN region in a meaningful manor only apply to organization who desire to use ARIN resources out side of the ARIN service region. A. Applicants who plan to use ARIN resources entirely inside the ARIN service region have no additional burden of proof required than under current policy. B. Applicants whose out of region use is negligible, such that they do not need to count out of region use to show efficient utilization, have no additional burden of proof required than under current policy. C. Under current ARIN policy and current ARIN operating practices, use of ARIN resources in networks that are wholly outside the ARIN service region is not counted, and ARIN will not issue IP space for use in networks that are wholly outside the ARIN service region. In exchange for the added burden of demonstrating a real nexus to the ARIN service region, these applicants will be able to use ARIN resources out side of the ARIN service region. Applicants who fail to demonstrate a real nexus are no worse off then they are under current policy. D. Under current ARIN policy and current ARIN operating practices, ARIN resources may be used outside the ARIN service region if the address space is used, in part in the ARIN service region by in region equipment and or in region customers, and if the address space is part of a contiguous network that resides, in part, in the ARIN service region as demonstrated by announcement of a covering aggregate from within the ARIN service region (as well as elsewhere). This use case will now have the added burden of demonstrating a nexus to the ARIN service region. In exchange for such a burden they are released from the need to ensure that some part of each aggregate is used in region. The covering route announced from within the US is also not needed, but having such a route (even if less preferred) is not a real burden for networks that are truly contiguous. Applicants who fail to demonstrate a real nexus will no longer be able to get IP space. I think the new burden on type "D" applicants is not so heavy. I also think it is desirable to prevent applicants that do not have a strong nexus to the ARIN service region from getting ARIN issued IP space as there is no good mechanism to combat fraud or abuse. However, if there is significant objection from the community about this new added burden on type "D" applicants, and the possibility of creating a situation where an application under current policy would have been permitted, but will now be rejected under this new policy, then I would suggest a carve out. I do not support such a carve out, especially if ARIN council is concerned about it creating a liability, but would not oppose it. (full disclosure most of my requests are of type "D" and a few are of type "A".) __Jason Schiller On Thu, Oct 22, 2015 at 11:56 AM, ARIN wrote: > Recommended Draft Policy ARIN-2015-5 > Out of region use > > On 9 October 2015 the ARIN Advisory Council (AC) recommended > ARIN-2015-5 for adoption, making it a Recommended Draft Policy. > > ARIN-2015-5 is below and can be found at: > https://www.arin.net/policy/proposals/2015_5.html > > You are encouraged to discuss Draft Policy 2015-5 on the PPML prior to > its presentation at the next ARIN Public Policy Consultation. Both the > discussion on the list and at the meeting will be used by the ARIN Advisory > Council to determine the community consensus for adopting this as policy. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Recommended Draft Policy ARIN-2015-5 > Out of region use > > Date: 22 October 2015 > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > ARIN-2015-5 enables fair and impartial number resource administration by > allowing any ARIN Organization with a real and substantial connection to > the ARIN region to use number resources out of region without prejudice. > This proposal is technically sound, as it addresses the key concerns > related to the unlimited openness of out of region use and enables ARIN > staff to implement the policy efficiently. The policy received a unanimous > show of support at the ARIN PPM in Montreal. However, the AC encourages > further discussion of ARIN-2015-5 on PPML to ensure we also have support > from the the ARIN community at large. > > Problem statement: > > Current policy neither clearly forbids nor clearly permits out of region > use of ARIN registered resources. This has created confusion and > controversy within the ARIN community for some time. Earlier work on this > issue has explored several options to restrict or otherwise limit out of > region use or loosen controls and totally authorize such use. None of these > options have gained consensus within the community. The next logical option > is a proposal that clearly permits out of region use while addressing the > key concerns expressed about unlimited openness to out of region use and > enables ARIN staff to implement the policy efficiently. > > Policy statement: > > Create new Section X: > > ARIN registered resources may be used outside the ARIN service region. Out > of region use of ARIN registered resources are valid justification for > additional number resources, provided that the applicant has a real and > substantial connection with the ARIN region which applicant must prove (as > described below) and is using the same type of resources (with a delegation > lineage back to an ARIN allocation or assignment) within the ARIN service > region as follows: > > * IPv4: At least a /22 used in region > * IPv6: At least a /44 used in region > * ASN: At least one ASN present on one or more peering sessions and/or > routers within the region. > > A real and substantial connection shall be defined as carrying on business > in the ARIN region in a meaningful manner. The determination as to whether > an entity is carrying on business in the ARIN region in a meaningful manner > shall be made by ARIN. Simply being incorporated in the ARIN region shall > not be sufficient, on its own, to prove that an entity is carrying on > business in the ARIN region in a meaningful manner. Methods that entities > may consider using, including cumulatively, to prove that they are carrying > on business in the ARIN region in a meaningful manner include: > * Demonstrating a physical presence in the ARIN region through a bricks > and mortar location that is actually used for the purposes of conducting > business in the ARIN region in a meaningful manner. That is to say, the > location is not merely a registered office that serves no other business > purpose. > * Demonstrating that the entity has staff in the ARIN region. The greater > the number of staff, the stronger this connecting factor is. > * Demonstrating that the entity holds assets in the ARIN region. The > greater the asset value, the stronger this connecting factor is. > * Demonstrating that the entity provides services to and solicits sales > from residents of the ARIN region. > * Demonstrating that the entity holds periodic meetings in the ARIN region. > * Demonstrating that the entity raises investment capital from investors > in the ARIN region. > * Demonstrating that the entity has a registered corporation in the ARIN > region, although this factor on its own shall not be sufficient. > * Other fact based criterion that the entity considers appropriate and > submits for ARIN's review. > The weight accorded to any of the above-noted factors, if any, shall be > determined solely by ARIN. > > The services and facilities used to justify the need for ARIN resources > that will be used out of region cannot also be used to justify resource > requests from another RIR. When a request for resources from ARIN is > justified by need located within another RIR's service region, an officer > of the application must attest that the same services and facilities have > not been used as the basis for a resource request in the other region(s). > ARIN reserves the right to obtain from the applicant a listing of all the > applicant's number holdings in the region(s) of proposed use, when there > are factual reasons to support the request. > > Comments: > > a) Timetable for implementation: Various iterations of this policy have > been presented and debated by ARIN for well over a year now. Given the > amount of time that has already been spent on developing a policy, ideally, > this policy would be implemented as soon as possible. > b) Explanation of draft policy: The draft policy addresses both the > problem statement as well as the concerns raised at ARIN 35 by participants > as well as ARIN counsel. > Firstly, the draft policy addresses the concerns of ARIN counsel as well > as some of the participants at ARIN 35 by ensuring that anyone requesting > numbered resources from ARIN has a real and substantial connection with the > ARIN region. This should go a long way to addressing concerns about fraud, > legal liability, and interference with the jurisdiction of other RIRs. > In addition, by placing the burden of proof for demonstrating a real and > substantial connection with the ARIN region on the applicant, the amount of > work required of ARIN staff to apply the policy will be reduced. > The factors noted above are suggestions that an entity may use to > demonstrate to ARIN that it is carrying on business in the ARIN region in a > meaningful manner. These factors are all indicative, some more than others, > that an entity has a real and substantial connection to the ARIN region > through the carrying on of business in the ARIN region in a meaningful > manner. Not all of the factors will apply in a given case and proving a > single factor may not be enough to satisfy ARIN that an entity is carrying > on business in the region in a meaningful manner. The list of factors is > meant to be quite broad, including an open-ended factor, in order to > capture the diversity of businesses that operate in the ARIN region and > that may justifiably require numbered resources from ARIN. This approach is > very similar to the practical method that courts typically apply to assess > whether parties have a sufficient connection to a jurisdiction so as to > require them to submit themselves to the courts of that jurisdiction. > > This draft policy is a substantial improvement over the previous version > of ARIN-2014-1 in terms of reducing the overall risk to the community by > requiring a real and substantial connection between an entity requesting > resources and the ARIN region. > > ##### > > ARIN STAFF & LEGAL ASSESSMENT > Draft Policy ARIN-2015-5 > OUT OF REGION USE > > Date of Assessment: 17 September 2015 > > ___ > 1. Summary (Staff Understanding) > > This proposal would allow an organization to receive Internet number > resources from ARIN for use out of region as long as the applicant is > currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 > ASN within the ARIN service region, respectively. In addition, the > applicant must have a real and substantial connection with the ARIN region, > which the applicant shall be responsible for proving. > > ___ > 2. Comments > > A. ARIN Staff Comments > > This policy would increase the complexity of ARIN staff review work in > request cases that fit the profile of this policy. There would in an > increase in the vetting and utilization verification work currently > conducted by ARIN staff. > > This policy would be placed in the NRPM as section 9, "Out of Region Use". > > B. ARIN General Counsel ? Legal Assessment > > If the policy is enacted it will require ARIN staff to work with counsel > with some attendant increase in costs in the first year to manage > implementation. The policy is consistent with standard legal principles > routinely utilized in the ARIN region. The policy creates no material legal > risks. > > ___ > 3. Resource Impact > > From a request review standpoint, implementation of this policy would > require additional review steps for Internet number resource requests. It > could have future staffing implications based on the amount of additional > work the policy could present. It is estimated that implementation could > occur within 3 months after ratification by the ARIN Board of Trustees. The > following would be needed in order to implement: > > * Updated guidelines and internal procedures > * Staff training > > Implementation of this policy may allow for registrations in the ARIN > database that require unicode character sets. From an engineering > standpoint, implementation of this policy could have a major resource > impact. It is estimated that implementation would occur within 12 months, > instead of the 3 months cited above, after ratification by the ARIN Board > of Trustees if ARIN is required to support unicode character sets. The > following would be needed in order to implement: > > * Engineering: Engineering efforts to handle out of region business rules > may be substantial as our system only supports ascii now. If there is a > need for unicode character sets, then there is a substantial amount of work > required to upgrade the DB and applications to support unicode. > Additionally, we would need to discuss how to display unicode characters in > port 43 whois. > > ___ > 4. Proposal / Draft Policy Text Assessed > > Draft Policy ARIN-2015-5 (September 9, 2015, version) > > Problem statement: > > Current policy neither clearly forbids nor clearly permits out of region > use of ARIN registered resources. This has created confusion and > controversy within the ARIN community for some time. Earlier work on this > issue has explored several options to restrict or otherwise limit out of > region use. None of these options have gained consensus within the > community. The next logical option is a proposal that clearly permits out > of region use while addressing the key concerns expressed about unlimited > openness to out of region use and enables ARIN staff to implement the > policy efficiently. > > Policy statement: > > Create new Section X: > > ARIN registered resources may be used outside the ARIN service region. Out > of region use of ARIN registered resources are valid justification for > additional number resources, provided that the applicant has a real and > substantial connection with the ARIN region which applicant must prove (as > described below) and is using the same type of resources (with a delegation > lineage back to an ARIN allocation or assignment) within the ARIN service > region as follows: > > * IPv4: At least a /22 used in region > * IPv6: At least a /44 used in region > * ASN: At least one ASN present on one or more peering sessions and/or > routers within the region. > > A real and substantial connection shall be defined as carrying on business > in the ARIN region in a meaningful manner, whether for or not for profit. > The determination as to whether an entity is carrying on business in the > ARIN region in a meaningful manner shall be made by ARIN. Simply being > incorporated in the ARIN region shall not be sufficient, on its own, to > prove that an entity is carrying on business in the ARIN region in a > meaningful manner. Methods that entities may consider using, including > cumulatively, to prove that they are carrying on business in the ARIN > region in a meaningful manner include: > * Demonstrating a physical presence in the ARIN region through a bricks > and mortar location that is actually used for the purposes of conducting > business in the ARIN region in a meaningful manner. That is to say, the > location is not merely a registered office that serves no other business > purpose. > * Demonstrating that the entity has staff in the ARIN region. The greater > the number of staff, the stronger this connecting factor is. > * Demonstrating that the entity holds assets in the ARIN region. The > greater the asset value, the stronger this connecting factor is. > * Demonstrating that the entity provides services to or solicits sales > from residents of the ARIN region. > * Demonstrating that the entity holds annual meetings in the ARIN region. > * Demonstrating that the entity raises investment capital from investors > in the ARIN region. > * Demonstrating that the entity has a registered office in the ARIN > region, although this factor on its own shall not be sufficient. > * Any other method that the entity considers appropriate. > The weight accorded to any of the above-noted factors, if any, shall be > determined solely by ARIN. > > The services and facilities used to justify the need for ARIN resources > that will be used out of region cannot also be used to justify resource > requests from another RIR. When a request for resources from ARIN is > justified by need located within another RIR's service region, an officer > of the application must attest that the same services and facilities have > not been used as the basis for a resource request in the other region(s). > ARIN reserves the right to request a listing of all the applicant's number > holdings in the region(s) of proposed use, but this should happen only when > there are significant reasons to suspect duplicate requests. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Wed Feb 10 23:31:34 2016 From: jschiller at google.com (Jason Schiller) Date: Wed, 10 Feb 2016 23:31:34 -0500 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> Message-ID: I oppose as written. I opposed ARIN-2015-3 and I oppose this draft policy on the same grounds. I support simplifying some transfers and keeping the more complicated old rules for others in general... However, the policy as written requires no real, tangible, and verifiable claim. Without such a check justified need for transfers simply becomes a 2 year future looking projection, and with sufficient arm waving an easy end run around justified need. I could certainly get on board if there were some other tangible and verifiable claim to show there was a real commitment to use half the address space within two years. I choose Scott's email to reply to because I like his approach in general. 1. Make an agreement to acquire addresses in the quantity you believe you need. 2. If that agreement brings your total address holdings to less than 2x your current or 24-month projected usage, get easy approval for the transfer from ARIN under the Simplified requirements for demonstrated need for IPv4 transfers defined in this draft policy. 3. Skip the LOA and ongoing legal stuff. 4. Use the addresses. I would suggest a slight modification and a slight clarification. 1. Make an agreement to acquire addresses in the quantity you believe you need. 2. If that agreement brings your total address holdings to less than 2x your current holdings And your current holdings are > 80% utilized in aggregate and no less that 50% per resource, then you qualify for a simplified transfer. 3. You can still qualify for a two year supply under the current unsimplified policy You can get twice your last year's run rate if your current holding are > 80% utilization in aggregate and no less that 50% per resource, 4. Sign an RSA 5. Use the addresses Note: sources of a transfer still: - must be the current (dispute free) registered holder of the IPv4 address space - must not have received a transfer, allocation or assignment from ARIN in the last year (not including M&A) - minimum /24 Neither Scott's nor my approach here deal with organizations that have no resources. I (and MJ) tried a more complicated version of this as ARIN-2014-20. Scott, do you want to consider my (friendly) amendment and draft some text? Do you want to consider what to do for organizations with no resources? ___Jason On Mon, Oct 5, 2015 at 4:30 PM, Scott Leibrand wrote: > I believe we should make it easy to: > > 1. Make an agreement to acquire addresses in the quantity you believe you > need. > 2. If that agreement brings your total address holdings to less than 2x > your current or 24-month projected usage, get easy approval for the > transfer from ARIN under the Simplified requirements for demonstrated > need for IPv4 transfers defined in this draft policy. > 3. Skip the LOA and ongoing legal stuff. > 4. Use the addresses. > > -Scott > > On Mon, Oct 5, 2015 at 1:07 PM, Martin Hannigan > wrote: > >> >> >> On Mon, Oct 5, 2015 at 3:29 PM, Scott Leibrand >> wrote: >> >>> Reducing the burden on ARIN staff is not part of the problem statement >>> for this proposal (though it might be a side effect, depending on how they >>> implement it). The main goal here is to reduce the administrative burden >>> on organizations who need to acquire IPv4 space via transfer. That burden >>> may actually be higher for smaller entities who don't have experience with >>> and processes in place for jumping through ARIN's hoops. >>> >>> I don't think this policy would have much impact on the ability of large >>> well-funded entities to purchase as much address space as they like. >>> Currently, those organizations simply write a contract that gives them full >>> rights to the address space they're buying, and allows them to transfer the >>> space with ARIN whenever they are ready to put it into use on their network >>> (or can otherwise pass ARIN's needs justification tests). >>> >>> >>> >> >> Let me give you a real world example. >> >> 1. Buy rights to use addresses in any quantity you believe you need >> 2. Use those addresses as you need them, assuming the agreement you made >> with the party works properly >> 3. Get an LOA from the documented owner >> 4. Bypass ARIN entirely >> 5. Use the addresses. >> >> How do you think we should solve that problem? >> >> >> Best, >> >> -M< >> >> >> >> > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Thu Feb 11 01:09:32 2016 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 10 Feb 2016 23:09:32 -0700 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> Message-ID: Thanks for the constructive suggestions. Let me see (inline below) if I understand exactly what you're saying. On Wed, Feb 10, 2016 at 9:31 PM, Jason Schiller wrote: > I oppose as written. > > I opposed ARIN-2015-3 and I oppose this draft policy on the same grounds. > I support simplifying some transfers and keeping the more complicated old > rules for others in general... > > However, the policy as written requires no real, tangible, and verifiable > claim. Without such a check justified need for transfers simply becomes a > 2 year future looking projection, and with sufficient arm waving an easy > end run around justified need. > > I could certainly get on board if there were some other tangible and > verifiable claim to show there was a real commitment to use half the > address space within two years. > > I choose Scott's email to reply to because I like his approach in general. > > 1. Make an agreement to acquire addresses in the quantity you believe you > need. > 2. If that agreement brings your total address holdings to less than 2x > your current or 24-month projected usage, get easy approval for the > transfer from ARIN under the Simplified requirements for demonstrated > need for IPv4 transfers defined in this draft policy. > 3. Skip the LOA and ongoing legal stuff. > 4. Use the addresses. > > I would suggest a slight modification and a slight clarification. > > 1. Make an agreement to acquire addresses in the quantity you believe you > need. > 2. If that agreement brings your total address holdings to less than 2x > your current holdings > And your current holdings are > 80% utilized in aggregate and no less > that 50% per resource, > then you qualify for a simplified transfer. > So if I understand correctly, you're suggesting that we reinstate the >80% overall and 50% per-resource utilization requirements for simplified transfers, but once an organization has met that threshold, they can qualify for a simplified transfer that will get them up to 2x their current holdings? (You removed "or 24-month projected usage".) The proposed text as written ("IPv4 transfer recipients must demonstrate (and an officer of the requesting organization must attest) that they will use at least 50% of their aggregate IPv4 addresses (including the requested resources) on an operational network within 24 months.") is more liberal than that on two counts: 1) it does not include any requirement for utilization level of current resources, and 2) it allows the transfer of resources up to 2x the 24-month projection (as attested by an officer). I understand your objection to 2), but can you clarify why you think 1) is problematic? I would like to get more feedback from others here on PPML as to how comfortable we are trusting officer attestations of forward-looking projections, plus the need to shell out real hard cash for any space obtained, as a limit on any fraudulent or anticompetitive behavior. *If* a lot of people are uncomfortable with trusting officer-attested forward-looking projections, then another middle ground would be to simply limit simplified transfers to 2x current holdings. I think that would be sufficient for most organizations, and any for whom RSA section 4 is a better option can of course elect to use that, as you mentioned in your #3 below. It would also address your desire for a "tangible and verifiable claim to show there was a real commitment to use half the address space within two years", because they would actually be required to demonstrate use of half the resulting address space holdings before they qualify for the simplified transfer at all. Thoughts? -Scott > 3. You can still qualify for a two year supply under the current > unsimplified policy > You can get twice your last year's run rate > if your current holding are > 80% utilization in aggregate and no > less that 50% per resource, > 4. Sign an RSA > 5. Use the addresses > > Note: sources of a transfer still: > - must be the current (dispute free) registered holder of the IPv4 address > space > - must not have received a transfer, allocation or assignment from ARIN in > the last year > (not including M&A) > - minimum /24 > > > Neither Scott's nor my approach here deal with organizations that have no > resources. > > I (and MJ) tried a more complicated version of this as ARIN-2014-20. > > Scott, do you want to consider my (friendly) amendment and draft some > text? > Do you want to consider what to do for organizations with no resources? > > > ___Jason > > > On Mon, Oct 5, 2015 at 4:30 PM, Scott Leibrand > wrote: > >> I believe we should make it easy to: >> >> 1. Make an agreement to acquire addresses in the quantity you believe you >> need. >> 2. If that agreement brings your total address holdings to less than 2x >> your current or 24-month projected usage, get easy approval for the >> transfer from ARIN under the Simplified requirements for demonstrated >> need for IPv4 transfers defined in this draft policy. >> 3. Skip the LOA and ongoing legal stuff. >> 4. Use the addresses. >> >> -Scott >> >> On Mon, Oct 5, 2015 at 1:07 PM, Martin Hannigan >> wrote: >> >>> >>> >>> On Mon, Oct 5, 2015 at 3:29 PM, Scott Leibrand >>> wrote: >>> >>>> Reducing the burden on ARIN staff is not part of the problem statement >>>> for this proposal (though it might be a side effect, depending on how they >>>> implement it). The main goal here is to reduce the administrative burden >>>> on organizations who need to acquire IPv4 space via transfer. That burden >>>> may actually be higher for smaller entities who don't have experience with >>>> and processes in place for jumping through ARIN's hoops. >>>> >>>> I don't think this policy would have much impact on the ability of >>>> large well-funded entities to purchase as much address space as they like. >>>> Currently, those organizations simply write a contract that gives them full >>>> rights to the address space they're buying, and allows them to transfer the >>>> space with ARIN whenever they are ready to put it into use on their network >>>> (or can otherwise pass ARIN's needs justification tests). >>>> >>>> >>>> >>> >>> Let me give you a real world example. >>> >>> 1. Buy rights to use addresses in any quantity you believe you need >>> 2. Use those addresses as you need them, assuming the agreement you made >>> with the party works properly >>> 3. Get an LOA from the documented owner >>> 4. Bypass ARIN entirely >>> 5. Use the addresses. >>> >>> How do you think we should solve that problem? >>> >>> >>> Best, >>> >>> -M< >>> >>> >>> >>> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Feb 12 00:53:02 2016 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 12 Feb 2016 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201602120553.u1C5r2mh020670@rotala.raleigh.ibm.com> Total of 4 messages in the last 7 days. script run at: Fri Feb 12 00:53:01 EST 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 2 | 65.94% | 67231 | jschiller at google.com 25.00% | 1 | 27.24% | 27776 | scottleibrand at gmail.com 25.00% | 1 | 6.81% | 6945 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 4 |100.00% | 101952 | Total From bill at herrin.us Sun Feb 14 07:33:37 2016 From: bill at herrin.us (William Herrin) Date: Sun, 14 Feb 2016 07:33:37 -0500 Subject: [arin-ppml] ARIN invoice reminders Message-ID: Howdy, Today I received a sternly worded email reminding me to pay my ARIN invoice. Know what the email did not include? An invoice. Know what I need to pay the invoice? An invoice. For your consideration, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From lee at dilkie.com Sun Feb 14 09:57:07 2016 From: lee at dilkie.com (Lee Dilkie) Date: Sun, 14 Feb 2016 09:57:07 -0500 Subject: [arin-ppml] ARIN invoice reminders In-Reply-To: References: Message-ID: <56C095C3.7060809@dilkie.com> gave me a good sunday morning laugh... thanks Bill. On 2/14/2016 7:33 AM, William Herrin wrote: > Howdy, > > Today I received a sternly worded email reminding me to pay my ARIN > invoice. Know what the email did not include? An invoice. Know what I > need to pay the invoice? An invoice. > > For your consideration, > Bill Herrin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Sun Feb 14 10:15:09 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sun, 14 Feb 2016 10:15:09 -0500 Subject: [arin-ppml] ARIN invoice reminders In-Reply-To: <56C095C3.7060809@dilkie.com> References: <56C095C3.7060809@dilkie.com> Message-ID: They were sent out in January, I think. The reminder should probably include the invoice, I do agree there. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sun, Feb 14, 2016 at 9:57 AM, Lee Dilkie wrote: > gave me a good sunday morning laugh... thanks Bill. > > On 2/14/2016 7:33 AM, William Herrin wrote: > > Howdy, > > Today I received a sternly worded email reminding me to pay my ARIN > invoice. Know what the email did not include? An invoice. Know what I > need to pay the invoice? An invoice. > > For your consideration, > Bill Herrin > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 jim at reptiles.org Sun Feb 14 22:51:30 2016 From: jim at reptiles.org (Jim Mercer) Date: Sun, 14 Feb 2016 22:51:30 -0500 Subject: [arin-ppml] ARIN invoice reminders In-Reply-To: References: <56C095C3.7060809@dilkie.com> Message-ID: <20160215035130.GA73500@reptiles.org> On Sun, Feb 14, 2016 at 10:15:09AM -0500, Josh Luthman wrote: > > On 2/14/2016 7:33 AM, William Herrin wrote: > > Today I received a sternly worded email reminding me to pay my ARIN > > invoice. Know what the email did not include? An invoice. Know what I > > need to pay the invoice? An invoice. > > > > For your consideration, > > Bill Herrin > > > > They were sent out in January, I think. The reminder should probably > include the invoice, I do agree there. i'm pretty sure there is a relationship between the email address that recieved the sternly worded message, and the ARIN website account billing contacts. that relationship likely includes the ability to login and check your current billing, and billing history. including invoices. just sayin'. --jim -- Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" -- Hunter S. Thompson From snoble at sonn.com Sun Feb 14 23:04:24 2016 From: snoble at sonn.com (Steve Noble) Date: Sun, 14 Feb 2016 20:04:24 -0800 Subject: [arin-ppml] ARIN invoice reminders In-Reply-To: <20160215035130.GA73500@reptiles.org> References: <56C095C3.7060809@dilkie.com> <20160215035130.GA73500@reptiles.org> Message-ID: Unless like me, ARIN refuses to allow you access, but still bills you for the object that they claim you are not in charge of. On Feb 14, 2016 7:51 PM, "Jim Mercer" wrote: > On Sun, Feb 14, 2016 at 10:15:09AM -0500, Josh Luthman wrote: > > > On 2/14/2016 7:33 AM, William Herrin wrote: > > > Today I received a sternly worded email reminding me to pay my ARIN > > > invoice. Know what the email did not include? An invoice. Know what I > > > need to pay the invoice? An invoice. > > > > > > For your consideration, > > > Bill Herrin > > > > > > > They were sent out in January, I think. The reminder should probably > > include the invoice, I do agree there. > > i'm pretty sure there is a relationship between the email address that > recieved the sternly worded message, and the ARIN website account billing > contacts. > > that relationship likely includes the ability to login and check your > current > billing, and billing history. > > including invoices. > > just sayin'. > > --jim > > > -- > Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 > > Life should not be a journey to the grave with the intention of > arriving safely in a pretty and well preserved body, but rather > to skid in broadside in a cloud of smoke, thoroughly used up, > totally worn out, and loudly proclaiming "Wow! What a Ride!" > -- Hunter S. Thompson > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 mysidia at gmail.com Sun Feb 14 23:39:42 2016 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 14 Feb 2016 22:39:42 -0600 Subject: [arin-ppml] ARIN invoice reminders In-Reply-To: References: <56C095C3.7060809@dilkie.com> <20160215035130.GA73500@reptiles.org> Message-ID: On Sun, Feb 14, 2016 at 10:04 PM, Steve Noble wrote: > Unless like me, ARIN refuses to allow you access, but still bills you for > the object that they claim you are not in charge of. I doubt it is unusual for organizations' contact responsible for seeing that expected bills are paid to be different from the persons authorized to make administrative changes to the object or agreement. For example, the typical accounting clerk within an organization has no legitimate reason to be relinquishing resources, changing, DNS servers or WHOIS entries, etc. I am sure if you check ARIN's website: https://www.arin.net/contact_us.html You will find that there is some registration services contact, you can reach out to request assistance with your troubles, and/or request what you want or work out what the required process is. Nothing the general public on ARIN-PPML can do to ease your troubles, regards. -- -JH From snoble at sonn.com Sun Feb 14 23:53:59 2016 From: snoble at sonn.com (Steve Noble) Date: Sun, 14 Feb 2016 20:53:59 -0800 Subject: [arin-ppml] ARIN invoice reminders In-Reply-To: References: <56C095C3.7060809@dilkie.com> <20160215035130.GA73500@reptiles.org> Message-ID: Actually, that is exactly how the issue finally got fixed. Using the arin-ppml list, I posted the issue and after 7 or so years of being ignored, John looked into it and found that I was one of many disenfranchised ASN owners. My main point is that ARIN separates service from money. They billed me for and repeatedly sent nasty grams about an ASN that they refused to let me administer. A good story for valentine's day :) On Feb 14, 2016 8:40 PM, "Jimmy Hess" wrote: > On Sun, Feb 14, 2016 at 10:04 PM, Steve Noble wrote: > > Unless like me, ARIN refuses to allow you access, but still bills you for > > the object that they claim you are not in charge of. > > I doubt it is unusual for organizations' contact responsible for > seeing that expected bills are paid to be different from > the persons authorized to make administrative changes to the > object or agreement. > > For example, the typical accounting clerk within an organization has > no legitimate reason to be relinquishing resources, changing, DNS > servers or WHOIS entries, etc. > > I am sure if you check ARIN's website: > https://www.arin.net/contact_us.html > > You will find that there is some registration services contact, you > can reach out to request assistance with your troubles, and/or > request what you want or work out what the required process is. > > Nothing the general public on ARIN-PPML can do to ease your troubles, > regards. > > -- > -JH > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Feb 15 08:05:10 2016 From: jcurran at arin.net (John Curran) Date: Mon, 15 Feb 2016 13:05:10 +0000 Subject: [arin-ppml] ARIN invoice reminders In-Reply-To: References: <56C095C3.7060809@dilkie.com> <20160215035130.GA73500@reptiles.org> Message-ID: <4D1EF6E8-87C2-4328-8618-A47FE1656B95@corp.arin.net> On Feb 14, 2016, at 11:53 PM, Steve Noble > wrote: Actually, that is exactly how the issue finally got fixed. Using the arin-ppml list, I posted the issue and after 7 or so years of being ignored, John looked into it and found that I was one of many disenfranchised ASN owners. My main point is that ARIN separates service from money. They billed me for and repeatedly sent nasty grams about an ASN that they refused to let me administer. That is correct; you were not associated with the organization assigned the ASN, so you were unable to administer the resource. (Rather than repeating the entire set of messages, folks can find the the thread starting about here in the archives: ) Best wishes, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Feb 15 08:17:21 2016 From: jcurran at arin.net (John Curran) Date: Mon, 15 Feb 2016 13:17:21 +0000 Subject: [arin-ppml] ARIN invoice reminders In-Reply-To: References: Message-ID: <372968FB-174B-41AF-B071-AE7BDD0D9C5D@corp.arin.net> On Feb 14, 2016, at 7:33 AM, William Herrin > wrote: Howdy, Today I received a sternly worded email reminding me to pay my ARIN invoice. Know what the email did not include? An invoice. Know what I need to pay the invoice? An invoice. Bill - We actually send the invoice to the billing contact, and then in the past would send the reminders to only the billing contact, but folks indicated that they wanted to know if there was a payment issue with their organization, so we revised the processes to send notices to all contacts for open invoices: This process is documented online under the ?Fees & Invoices? section of the ARIN website - "Invoice reminder messages are sent via email 30 days prior to, and again on, the due date. These messages are sent to Admin, Tech and Billing Contacts for organizations with open invoices.? I have two suggestions - 1) If you believe we should also include the open invoice(s) on these reminder emails, please submit a suggestion that effect asap 2) This is perfect example of a service-related issue that ARIN staff (i.e. me) lack useful insight on the relative merits of the various approaches, and hence I?ll be referring it to the new ARIN Services Working Group for recommendation. We just sent out a call for participation - please consider volunteering for it! (Note specifically that one simply has to be a member of the ARIN community; it is not necessary to be an ARIN Member to serve on the Services WG) Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Feb 16 00:23:18 2016 From: farmer at umn.edu (David Farmer) Date: Mon, 15 Feb 2016 23:23:18 -0600 Subject: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy In-Reply-To: References: <56A94A93.2000806@umn.edu> Message-ID: <56C2B246.4090807@umn.edu> As shepherd, I need additional feedback on this, I need a better sense of what the community wants here. Should we move forward more or less as-is, with a minor editorial change, substituting "criterion" for "criteria"? Or, does the community want to work on a way to address the concerns raised but Jason? Your input please. Thanks On 1/29/16 10:00 , Jason Schiller wrote: > McTim, > > WRT some other tangible and verifiable claim to show there was a real > commitment to use half the address space within one year... > > I think there are 3 choices: > > 1. Very vague > > Something like "there must be some tangible and verifiable claim to > show there was a real commitment to use half the address space within > one year and not just a future projection or business case" > > > 2. Open ended with some guidance for ARIN staff: > > Something like "there must be some tangible and verifiable claim to > show there was a real commitment to use half the address space within > one year and not just a future projection or business case. Some > examples include: > - list of equipment in hand to be numbered counting at least 25% of > requested IP size > - invoices showing equipment purchases demonstrating a commitment to buy > equipment to be numbered counting at least 25% of requested IP size > - invoices showing equipment purchases demonstrating a commitment to buy > equipment to be numbered counting at least 50% of requested IP size > within one year > - lease agreements for real estate supporting equipment that is > appropratly sized to support equipment to be numbered counting at least > 50% of requested IP size > > 3. specific criterion > > ---- > > I don't know what it the right answer here, and suspect it has more to > do with what the community is comfortable with. > > On one end of the spectrum is choice 1. This allows ARIN to do the > right thing. But this also is not clear about what the community > expects, and ARIN may act in a way that is counter to what is > anticipated, and may seem like ARIN is being arbitrary or has too much > leeway to screw with requestors. > > The opposite end of the spectrum is choice 3. This sets a very clear > list of what qualifies. Hammering out that list may be very difficult, > and it is unlikely to be complete. This will leave little or no room > for ARIN to do the right thing and approve a request that is justified, > but not one of the criterion listed. > > Choice 2 is the middle ground. Where we have a not necessarily complete > list of criterion (so somewhat less difficulty in drawing up the list) > that creates a very clear expectation of what ARIN should accept (and > reduces the possibility that ARIN may act in a way that is counter to > what is anticipated, and may seem like ARIN is being arbitrary or has > too much leeway to screw with requestors) with respect to criterion > clearly defined, while also allowing ARIN to do the right thing with > similar types of proof that are not explicitly listed as criterion (this > has somewhat higher risk that ARIN may act in a way that is counter to > what is anticipated, and may seem like ARIN is being arbitrary or has > too much leeway to screw with requestors, but less risk than option 1 as > the criterion should serve as good guidance) > > > So two open questions to the community? > > 1. Is the community most comfortable with: > A. totally vague and open-ended such as "there must be some > tangible and verifiable claim to show there was a real commitment to > use half the address space within one year and not just a future > projection or business case" > > B. A vague statement with some guidance as to some acceptable forms > of tangible verifiable proof of a real commitment to use half the IP > address within one year. > > C. A very clear list of what proof is considered acceptable > > > 2. If the community prefers B. guidance or C. a very clear list then > what sort of things would the community like to see on that list? > > > On Fri, Jan 29, 2016 at 8:27 AM, McTim > wrote: > > > > On Thu, Jan 28, 2016 at 4:52 PM, Jason Schiller > > wrote: > > I support the removal of the 30 day utilization as it is > unreasonable for any larger end-site, who may have a real need > for say a /16, with 65,000 desktops arriving on a loading doc > next week, but an inability to unbox, configure and deploy > 16,384 to the various office locations in 30 days. > > > agreed. > > However, this is the only provision that has a real, tangible, > and verifiable claim. Without this check justified need for end > users simply becomes a 1 year future looking projection, and > with sufficient arm waving an easy end run around justified need > for any end user with no IP space or if they are efficiently > using what they currently hold. > > > good point! > > I could get on board if the maximum sized block permitted on a > purely future looking projection was a /24 and you had to use it > prior to getting more. > > > +1 > > I could certainly get on board if there were some other tangible > and verifiable claim to show there was a real commitment to use > half the address space within one year. > > > Would this language suffice, or would we need a metric of some sort? > > > Regards, > > McTim > > __Jason > > On Thu, Jan 28, 2016 at 8:55 AM, Brian Jones > wrote: > > Looks good to me Dave. I am okay with using criteria or > criterion, however using the strict definition it looks as > though criterion is the proper singular form. > > -- > Brian > > On Wed, Jan 27, 2016 at 5:54 PM, David Farmer > > wrote: > > The following is the proposed update for ARIN-2015-3: > Remove 30-Day Utilization Requirement in End-User IPv4 > Policy based on strong support in Montreal. > > Beyond deleting the 25% bullet as the policy says, their > are editorial changes as follows to the remaining text; > > - It looks weird to have single item bullet list, so > merge the two remaining sentence fragments into a single > sentence. > - Change "are" to "is", since there is only one > remaining criteria > - Use of "criteria" as a singular is common usage, even > though technically it's plural. > - Resulting in "The basic criteria that must be met is a > 50% utilization rate within one year." > > The remaining and resulting text for 4.3.3 is now > included in the policy text, for editorial clarity. The > original staff and legal suggested removing the RFC2050 > reference and also pointed out that > 4.2.3.6 also has a 25% immediate use clause and a > RFC2050 reference. > > Feedback in Montreal was that deleting the 25% immediate > use was a nice bite-sized change, and we shouldn't try > to do more than that with this change, so those changes > are not included at this time. > > Any additional feedback or comments are appreciated. > > Thanks > > --------- > > Draft Policy ARIN-2015-3: Remove 30 day utilization > requirement in end-user IPv4 policy > > Date: 27 January 2015 > > Problem Statement: > > End-user policy is intended to provide end-users with a > one year supply of IP addresses. Qualification for a > one-year supply requires the network operator to utilize > at least 25% of the requested addresses within 30 days. > This text is unrealistic and should be removed. > > First, it often takes longer than 30 days to stage > equipment and start actually using the addresses. > > Second, growth is often not that regimented; the > forecast is to use X addresses over the course of a > year, not to use 25% of X within 30 days. > > Third, this policy text applies to additional address > space requests. It is incompatible with the requirements > of other additional address space request justification > which indicates that 80% utilization of existing space > is sufficient to justify new space. If a block is at > 80%, then often (almost always?) the remaining 80% will > be used over the next 30 days and longer. Therefore the > operator cannot honestly state they will use 25% of the > ADDITIONAL space within 30 days of receiving it; they're > still trying to use their older block efficiently. > > Fourth, in the face of ARIN exhaustion, some ISPs are > starting to not give out /24 (or larger) blocks. So the > justification for the 25% rule that previously existed > (and in fact, applied for many years) is no longer germane. > > Policy statement: > > Remove the 25% utilization criteria bullet point from > NRPM 4.3.3. > > Resulting text: > > 4.3.3. Utilization rate > > Utilization rate of address space is a key factor in > justifying a new > assignment of IP address space. Requesters must show > exactly how > previous address assignments have been utilized and must > provide > appropriate details to verify their one-year growth > projection. > > The basic criteria that must be met is a 50% utilization > rate within one year. > > A greater utilization rate may be required based on > individual network > requirements. Please refer to RFC 2050 for more > information on > utilization guidelines. > > 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 > > ================================================ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage 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. > > > > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there." Jon Postel > > > > > -- > _______________________________________________________ > 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. > -- ================================================ 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 rjacobs at pslightwave.com Tue Feb 16 10:38:14 2016 From: rjacobs at pslightwave.com (Robert Jacobs) Date: Tue, 16 Feb 2016 15:38:14 +0000 Subject: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy In-Reply-To: <56C2B246.4090807@umn.edu> References: <56A94A93.2000806@umn.edu> <56C2B246.4090807@umn.edu> Message-ID: We are very interested in this discussion as we are a Tier 2 ISP that will be struggling to continue to keep a steady supply of IPV4 space to service our customers and growth. For us it seems defining and then publicizing what parameters ARIN will be using to determine what is required to get a 2 years plan of usage and how we document that back to ARIN. Whither this is a very open ended vague requirement or a very detailed and thought out requirement if you all don't give us some solid information and guidelines then our job of growing our ip space is left with a hole that maybe be wide open one day and multi-sided and tight the next week where only a specific plug will fit it. I am leaning toward something like number 2 where there is some latitude for different needs but there is some specifics things that must be documented and in place for you to move forward on getting an allocation approved... Robert Jacobs?|?Network Architect Director Direct:??832-615-7742 Main:?? 832-615-8000 Fax:????713-510-1650 5959 Corporate Dr. Suite 3300; Houston, TX 77036 A Certified Woman-Owned Business? 24x7x365?Customer? Support: 832-615-8000 |?support at pslightwave.com This electronic message contains information from Phonoscope Lightwave which may be privileged and confidential. The information is intended to be for the use of individual(s) or entity named above. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify me by telephone or e-mail immediately. ? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer Sent: Monday, February 15, 2016 11:23 PM To: ARIN PPML Subject: Re: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy As shepherd, I need additional feedback on this, I need a better sense of what the community wants here. Should we move forward more or less as-is, with a minor editorial change, substituting "criterion" for "criteria"? Or, does the community want to work on a way to address the concerns raised but Jason? Your input please. Thanks On 1/29/16 10:00 , Jason Schiller wrote: > McTim, > > WRT some other tangible and verifiable claim to show there was a real > commitment to use half the address space within one year... > > I think there are 3 choices: > > 1. Very vague > > Something like "there must be some tangible and verifiable claim to > show there was a real commitment to use half the address space within > one year and not just a future projection or business case" > > > 2. Open ended with some guidance for ARIN staff: > > Something like "there must be some tangible and verifiable claim to > show there was a real commitment to use half the address space within > one year and not just a future projection or business case. Some > examples include: > - list of equipment in hand to be numbered counting at least 25% of > requested IP size > - invoices showing equipment purchases demonstrating a commitment to > buy equipment to be numbered counting at least 25% of requested IP > size > - invoices showing equipment purchases demonstrating a commitment to > buy equipment to be numbered counting at least 50% of requested IP > size within one year > - lease agreements for real estate supporting equipment that is > appropratly sized to support equipment to be numbered counting at > least 50% of requested IP size > > 3. specific criterion > > ---- > > I don't know what it the right answer here, and suspect it has more to > do with what the community is comfortable with. > > On one end of the spectrum is choice 1. This allows ARIN to do the > right thing. But this also is not clear about what the community > expects, and ARIN may act in a way that is counter to what is > anticipated, and may seem like ARIN is being arbitrary or has too much > leeway to screw with requestors. > > The opposite end of the spectrum is choice 3. This sets a very clear > list of what qualifies. Hammering out that list may be very > difficult, and it is unlikely to be complete. This will leave little > or no room for ARIN to do the right thing and approve a request that > is justified, but not one of the criterion listed. > > Choice 2 is the middle ground. Where we have a not necessarily > complete list of criterion (so somewhat less difficulty in drawing up > the list) that creates a very clear expectation of what ARIN should > accept (and reduces the possibility that ARIN may act in a way that is > counter to what is anticipated, and may seem like ARIN is being > arbitrary or has too much leeway to screw with requestors) with > respect to criterion clearly defined, while also allowing ARIN to do > the right thing with similar types of proof that are not explicitly > listed as criterion (this has somewhat higher risk that ARIN may act > in a way that is counter to what is anticipated, and may seem like > ARIN is being arbitrary or has too much leeway to screw with > requestors, but less risk than option 1 as the criterion should serve > as good guidance) > > > So two open questions to the community? > > 1. Is the community most comfortable with: > A. totally vague and open-ended such as "there must be some > tangible and verifiable claim to show there was a real commitment to > use half the address space within one year and not just a future > projection or business case" > > B. A vague statement with some guidance as to some acceptable > forms of tangible verifiable proof of a real commitment to use half > the IP address within one year. > > C. A very clear list of what proof is considered acceptable > > > 2. If the community prefers B. guidance or C. a very clear list then > what sort of things would the community like to see on that list? > > > On Fri, Jan 29, 2016 at 8:27 AM, McTim > wrote: > > > > On Thu, Jan 28, 2016 at 4:52 PM, Jason Schiller > > wrote: > > I support the removal of the 30 day utilization as it is > unreasonable for any larger end-site, who may have a real need > for say a /16, with 65,000 desktops arriving on a loading doc > next week, but an inability to unbox, configure and deploy > 16,384 to the various office locations in 30 days. > > > agreed. > > However, this is the only provision that has a real, tangible, > and verifiable claim. Without this check justified need for end > users simply becomes a 1 year future looking projection, and > with sufficient arm waving an easy end run around justified need > for any end user with no IP space or if they are efficiently > using what they currently hold. > > > good point! > > I could get on board if the maximum sized block permitted on a > purely future looking projection was a /24 and you had to use it > prior to getting more. > > > +1 > > I could certainly get on board if there were some other tangible > and verifiable claim to show there was a real commitment to use > half the address space within one year. > > > Would this language suffice, or would we need a metric of some sort? > > > Regards, > > McTim > > __Jason > > On Thu, Jan 28, 2016 at 8:55 AM, Brian Jones > wrote: > > Looks good to me Dave. I am okay with using criteria or > criterion, however using the strict definition it looks as > though criterion is the proper singular form. > > -- > Brian > > On Wed, Jan 27, 2016 at 5:54 PM, David Farmer > > wrote: > > The following is the proposed update for ARIN-2015-3: > Remove 30-Day Utilization Requirement in End-User IPv4 > Policy based on strong support in Montreal. > > Beyond deleting the 25% bullet as the policy says, their > are editorial changes as follows to the remaining > text; > > - It looks weird to have single item bullet list, so > merge the two remaining sentence fragments into a single > sentence. > - Change "are" to "is", since there is only one > remaining criteria > - Use of "criteria" as a singular is common usage, even > though technically it's plural. > - Resulting in "The basic criteria that must be met is a > 50% utilization rate within one year." > > The remaining and resulting text for 4.3.3 is now > included in the policy text, for editorial clarity. The > original staff and legal suggested removing the RFC2050 > reference and also pointed out that > 4.2.3.6 also has a 25% immediate use clause and a > RFC2050 reference. > > Feedback in Montreal was that deleting the 25% immediate > use was a nice bite-sized change, and we shouldn't try > to do more than that with this change, so those changes > are not included at this time. > > Any additional feedback or comments are appreciated. > > Thanks > > --------- > > Draft Policy ARIN-2015-3: Remove 30 day utilization > requirement in end-user IPv4 policy > > Date: 27 January 2015 > > Problem Statement: > > End-user policy is intended to provide end-users with a > one year supply of IP addresses. Qualification for a > one-year supply requires the network operator to utilize > at least 25% of the requested addresses within 30 days. > This text is unrealistic and should be removed. > > First, it often takes longer than 30 days to stage > equipment and start actually using the addresses. > > Second, growth is often not that regimented; the > forecast is to use X addresses over the course of a > year, not to use 25% of X within 30 days. > > Third, this policy text applies to additional address > space requests. It is incompatible with the requirements > of other additional address space request justification > which indicates that 80% utilization of existing space > is sufficient to justify new space. If a block is at > 80%, then often (almost always?) the remaining 80% will > be used over the next 30 days and longer. Therefore the > operator cannot honestly state they will use 25% of the > ADDITIONAL space within 30 days of receiving it; they're > still trying to use their older block efficiently. > > Fourth, in the face of ARIN exhaustion, some ISPs are > starting to not give out /24 (or larger) blocks. So the > justification for the 25% rule that previously existed > (and in fact, applied for many years) is no longer germane. > > Policy statement: > > Remove the 25% utilization criteria bullet point from > NRPM 4.3.3. > > Resulting text: > > 4.3.3. Utilization rate > > Utilization rate of address space is a key factor in > justifying a new > assignment of IP address space. Requesters must show > exactly how > previous address assignments have been utilized and must > provide > appropriate details to verify their one-year growth > projection. > > The basic criteria that must be met is a 50% utilization > rate within one year. > > A greater utilization rate may be required based on > individual network > requirements. Please refer to RFC 2050 for more > information on > utilization guidelines. > > 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 > > ================================================ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage 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. > > > > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there." Jon Postel > > > > > -- > _______________________________________________________ > 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. > -- ================================================ 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 rjletts at uw.edu Tue Feb 16 15:51:22 2016 From: rjletts at uw.edu (Richard J. Letts) Date: Tue, 16 Feb 2016 20:51:22 +0000 Subject: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy In-Reply-To: <56C2B246.4090807@umn.edu> References: <56A94A93.2000806@umn.edu> <56C2B246.4090807@umn.edu> Message-ID: My preference is to apply the policy change as written (with the minor editorial change substituting "criterion" for "criteria".) Thank you Richard Letts > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of David Farmer > Sent: Monday, February 15, 2016 9:23 PM > To: ARIN PPML > Subject: Re: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization > Requirement in End-User IPv4 Policy > > As shepherd, I need additional feedback on this, I need a better sense of > what the community wants here. > > Should we move forward more or less as-is, with a minor editorial change, > substituting "criterion" for "criteria"? > > Or, does the community want to work on a way to address the concerns > raised but Jason? > > Your input please. > > Thanks > > On 1/29/16 10:00 , Jason Schiller wrote: > > McTim, > > > > WRT some other tangible and verifiable claim to show there was a real > > commitment to use half the address space within one year... > > > > I think there are 3 choices: > > > > 1. Very vague > > > > Something like "there must be some tangible and verifiable claim to > > show there was a real commitment to use half the address space within > > one year and not just a future projection or business case" > > > > > > 2. Open ended with some guidance for ARIN staff: > > > > Something like "there must be some tangible and verifiable claim to > > show there was a real commitment to use half the address space within > > one year and not just a future projection or business case. Some > > examples include: > > - list of equipment in hand to be numbered counting at least 25% of > > requested IP size > > - invoices showing equipment purchases demonstrating a commitment to > > buy equipment to be numbered counting at least 25% of requested IP > > size > > - invoices showing equipment purchases demonstrating a commitment to > > buy equipment to be numbered counting at least 50% of requested IP > > size within one year > > - lease agreements for real estate supporting equipment that is > > appropratly sized to support equipment to be numbered counting at > > least 50% of requested IP size > > > > 3. specific criterion > > > > ---- > > > > I don't know what it the right answer here, and suspect it has more to > > do with what the community is comfortable with. > > > > On one end of the spectrum is choice 1. This allows ARIN to do the > > right thing. But this also is not clear about what the community > > expects, and ARIN may act in a way that is counter to what is > > anticipated, and may seem like ARIN is being arbitrary or has too much > > leeway to screw with requestors. > > > > The opposite end of the spectrum is choice 3. This sets a very clear > > list of what qualifies. Hammering out that list may be very > > difficult, and it is unlikely to be complete. This will leave little > > or no room for ARIN to do the right thing and approve a request that > > is justified, but not one of the criterion listed. > > > > Choice 2 is the middle ground. Where we have a not necessarily > > complete list of criterion (so somewhat less difficulty in drawing up > > the list) that creates a very clear expectation of what ARIN should > > accept (and reduces the possibility that ARIN may act in a way that is > > counter to what is anticipated, and may seem like ARIN is being > > arbitrary or has too much leeway to screw with requestors) with > > respect to criterion clearly defined, while also allowing ARIN to do > > the right thing with similar types of proof that are not explicitly > > listed as criterion (this has somewhat higher risk that ARIN may act > > in a way that is counter to what is anticipated, and may seem like > > ARIN is being arbitrary or has too much leeway to screw with > > requestors, but less risk than option 1 as the criterion should serve > > as good guidance) > > > > > > So two open questions to the community? > > > > 1. Is the community most comfortable with: > > A. totally vague and open-ended such as "there must be some > > tangible and verifiable claim to show there was a real commitment to > > use half the address space within one year and not just a future > > projection or business case" > > > > B. A vague statement with some guidance as to some acceptable > > forms of tangible verifiable proof of a real commitment to use half > > the IP address within one year. > > > > C. A very clear list of what proof is considered acceptable > > > > > > 2. If the community prefers B. guidance or C. a very clear list then > > what sort of things would the community like to see on that list? > > > > > > On Fri, Jan 29, 2016 at 8:27 AM, McTim > > wrote: > > > > > > > > On Thu, Jan 28, 2016 at 4:52 PM, Jason Schiller > > > wrote: > > > > I support the removal of the 30 day utilization as it is > > unreasonable for any larger end-site, who may have a real need > > for say a /16, with 65,000 desktops arriving on a loading doc > > next week, but an inability to unbox, configure and deploy > > 16,384 to the various office locations in 30 days. > > > > > > agreed. > > > > However, this is the only provision that has a real, tangible, > > and verifiable claim. Without this check justified need for end > > users simply becomes a 1 year future looking projection, and > > with sufficient arm waving an easy end run around justified need > > for any end user with no IP space or if they are efficiently > > using what they currently hold. > > > > > > good point! > > > > I could get on board if the maximum sized block permitted on a > > purely future looking projection was a /24 and you had to use it > > prior to getting more. > > > > > > +1 > > > > I could certainly get on board if there were some other tangible > > and verifiable claim to show there was a real commitment to use > > half the address space within one year. > > > > > > Would this language suffice, or would we need a metric of some sort? > > > > > > Regards, > > > > McTim > > > > __Jason > > > > On Thu, Jan 28, 2016 at 8:55 AM, Brian Jones > > wrote: > > > > Looks good to me Dave. I am okay with using criteria or > > criterion, however using the strict definition it looks as > > though criterion is the proper singular form. > > > > -- > > Brian > > > > On Wed, Jan 27, 2016 at 5:54 PM, David Farmer > > > wrote: > > > > The following is the proposed update for ARIN-2015-3: > > Remove 30-Day Utilization Requirement in End-User IPv4 > > Policy based on strong support in Montreal. > > > > Beyond deleting the 25% bullet as the policy says, their > > are editorial changes as follows to the remaining > > text; > > > > - It looks weird to have single item bullet list, so > > merge the two remaining sentence fragments into a single > > sentence. > > - Change "are" to "is", since there is only one > > remaining criteria > > - Use of "criteria" as a singular is common usage, even > > though technically it's plural. > > - Resulting in "The basic criteria that must be met is a > > 50% utilization rate within one year." > > > > The remaining and resulting text for 4.3.3 is now > > included in the policy text, for editorial clarity. The > > original staff and legal suggested removing the RFC2050 > > reference and also pointed out that > > 4.2.3.6 also has a 25% immediate use clause and a > > RFC2050 reference. > > > > Feedback in Montreal was that deleting the 25% immediate > > use was a nice bite-sized change, and we shouldn't try > > to do more than that with this change, so those changes > > are not included at this time. > > > > Any additional feedback or comments are appreciated. > > > > Thanks > > > > --------- > > > > Draft Policy ARIN-2015-3: Remove 30 day utilization > > requirement in end-user IPv4 policy > > > > Date: 27 January 2015 > > > > Problem Statement: > > > > End-user policy is intended to provide end-users with a > > one year supply of IP addresses. Qualification for a > > one-year supply requires the network operator to utilize > > at least 25% of the requested addresses within 30 days. > > This text is unrealistic and should be removed. > > > > First, it often takes longer than 30 days to stage > > equipment and start actually using the addresses. > > > > Second, growth is often not that regimented; the > > forecast is to use X addresses over the course of a > > year, not to use 25% of X within 30 days. > > > > Third, this policy text applies to additional address > > space requests. It is incompatible with the requirements > > of other additional address space request justification > > which indicates that 80% utilization of existing space > > is sufficient to justify new space. If a block is at > > 80%, then often (almost always?) the remaining 80% will > > be used over the next 30 days and longer. Therefore the > > operator cannot honestly state they will use 25% of the > > ADDITIONAL space within 30 days of receiving it; they're > > still trying to use their older block efficiently. > > > > Fourth, in the face of ARIN exhaustion, some ISPs are > > starting to not give out /24 (or larger) blocks. So the > > justification for the 25% rule that previously existed > > (and in fact, applied for many years) is no longer germane. > > > > Policy statement: > > > > Remove the 25% utilization criteria bullet point from > > NRPM 4.3.3. > > > > Resulting text: > > > > 4.3.3. Utilization rate > > > > Utilization rate of address space is a key factor in > > justifying a new > > assignment of IP address space. Requesters must show > > exactly how > > previous address assignments have been utilized and must > > provide > > appropriate details to verify their one-year growth > > projection. > > > > The basic criteria that must be met is a 50% utilization > > rate within one year. > > > > A greater utilization rate may be required based on > > individual network > > requirements. Please refer to RFC 2050 for more > > information on > > utilization guidelines. > > > > 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 > > > > ================================================ > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > > ). > > Unsubscribe or manage 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. > > > > > > > > > > -- > > Cheers, > > > > McTim > > "A name indicates what we seek. An address indicates where it is. A > > route indicates how we get there." Jon Postel > > > > > > > > > > -- > > _______________________________________________________ > > 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. > > > > > -- > ================================================ > 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 hvgeekwtrvl at gmail.com Tue Feb 16 16:33:11 2016 From: hvgeekwtrvl at gmail.com (james machado) Date: Tue, 16 Feb 2016 13:33:11 -0800 Subject: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy In-Reply-To: References: <56A94A93.2000806@umn.edu> <56C2B246.4090807@umn.edu> Message-ID: I support this as written with our without the the "criterion" for "criteria". James Machado From bjones at vt.edu Tue Feb 16 16:52:25 2016 From: bjones at vt.edu (Brian Jones) Date: Tue, 16 Feb 2016 16:52:25 -0500 Subject: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy In-Reply-To: References: <56A94A93.2000806@umn.edu> <56C2B246.4090807@umn.edu> Message-ID: On Tue, Feb 16, 2016 at 3:51 PM, Richard J. Letts wrote: > My preference is to apply the policy change as written (with the minor > editorial change substituting "criterion" for "criteria".) > ?+1? -- Brian > > Thank you > Richard Letts > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > > Behalf Of David Farmer > > Sent: Monday, February 15, 2016 9:23 PM > > To: ARIN PPML > > Subject: Re: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization > > Requirement in End-User IPv4 Policy > > > > As shepherd, I need additional feedback on this, I need a better sense of > > what the community wants here. > > > > Should we move forward more or less as-is, with a minor editorial change, > > substituting "criterion" for "criteria"? > > > > Or, does the community want to work on a way to address the concerns > > raised but Jason? > > > > Your input please. > > > > Thanks > > > > On 1/29/16 10:00 , Jason Schiller wrote: > > > McTim, > > > > > > WRT some other tangible and verifiable claim to show there was a real > > > commitment to use half the address space within one year... > > > > > > I think there are 3 choices: > > > > > > 1. Very vague > > > > > > Something like "there must be some tangible and verifiable claim to > > > show there was a real commitment to use half the address space within > > > one year and not just a future projection or business case" > > > > > > > > > 2. Open ended with some guidance for ARIN staff: > > > > > > Something like "there must be some tangible and verifiable claim to > > > show there was a real commitment to use half the address space within > > > one year and not just a future projection or business case. Some > > > examples include: > > > - list of equipment in hand to be numbered counting at least 25% of > > > requested IP size > > > - invoices showing equipment purchases demonstrating a commitment to > > > buy equipment to be numbered counting at least 25% of requested IP > > > size > > > - invoices showing equipment purchases demonstrating a commitment to > > > buy equipment to be numbered counting at least 50% of requested IP > > > size within one year > > > - lease agreements for real estate supporting equipment that is > > > appropratly sized to support equipment to be numbered counting at > > > least 50% of requested IP size > > > > > > 3. specific criterion > > > > > > ---- > > > > > > I don't know what it the right answer here, and suspect it has more to > > > do with what the community is comfortable with. > > > > > > On one end of the spectrum is choice 1. This allows ARIN to do the > > > right thing. But this also is not clear about what the community > > > expects, and ARIN may act in a way that is counter to what is > > > anticipated, and may seem like ARIN is being arbitrary or has too much > > > leeway to screw with requestors. > > > > > > The opposite end of the spectrum is choice 3. This sets a very clear > > > list of what qualifies. Hammering out that list may be very > > > difficult, and it is unlikely to be complete. This will leave little > > > or no room for ARIN to do the right thing and approve a request that > > > is justified, but not one of the criterion listed. > > > > > > Choice 2 is the middle ground. Where we have a not necessarily > > > complete list of criterion (so somewhat less difficulty in drawing up > > > the list) that creates a very clear expectation of what ARIN should > > > accept (and reduces the possibility that ARIN may act in a way that is > > > counter to what is anticipated, and may seem like ARIN is being > > > arbitrary or has too much leeway to screw with requestors) with > > > respect to criterion clearly defined, while also allowing ARIN to do > > > the right thing with similar types of proof that are not explicitly > > > listed as criterion (this has somewhat higher risk that ARIN may act > > > in a way that is counter to what is anticipated, and may seem like > > > ARIN is being arbitrary or has too much leeway to screw with > > > requestors, but less risk than option 1 as the criterion should serve > > > as good guidance) > > > > > > > > > So two open questions to the community? > > > > > > 1. Is the community most comfortable with: > > > A. totally vague and open-ended such as "there must be some > > > tangible and verifiable claim to show there was a real commitment to > > > use half the address space within one year and not just a future > > > projection or business case" > > > > > > B. A vague statement with some guidance as to some acceptable > > > forms of tangible verifiable proof of a real commitment to use half > > > the IP address within one year. > > > > > > C. A very clear list of what proof is considered acceptable > > > > > > > > > 2. If the community prefers B. guidance or C. a very clear list then > > > what sort of things would the community like to see on that list? > > > > > > > > > On Fri, Jan 29, 2016 at 8:27 AM, McTim > > > wrote: > > > > > > > > > > > > On Thu, Jan 28, 2016 at 4:52 PM, Jason Schiller > > > > wrote: > > > > > > I support the removal of the 30 day utilization as it is > > > unreasonable for any larger end-site, who may have a real need > > > for say a /16, with 65,000 desktops arriving on a loading doc > > > next week, but an inability to unbox, configure and deploy > > > 16,384 to the various office locations in 30 days. > > > > > > > > > agreed. > > > > > > However, this is the only provision that has a real, tangible, > > > and verifiable claim. Without this check justified need for > end > > > users simply becomes a 1 year future looking projection, and > > > with sufficient arm waving an easy end run around justified > need > > > for any end user with no IP space or if they are efficiently > > > using what they currently hold. > > > > > > > > > good point! > > > > > > I could get on board if the maximum sized block permitted on a > > > purely future looking projection was a /24 and you had to use > it > > > prior to getting more. > > > > > > > > > +1 > > > > > > I could certainly get on board if there were some other > tangible > > > and verifiable claim to show there was a real commitment to use > > > half the address space within one year. > > > > > > > > > Would this language suffice, or would we need a metric of some > sort? > > > > > > > > > Regards, > > > > > > McTim > > > > > > __Jason > > > > > > On Thu, Jan 28, 2016 at 8:55 AM, Brian Jones > > > wrote: > > > > > > Looks good to me Dave. I am okay with using criteria or > > > criterion, however using the strict definition it looks as > > > though criterion is the proper singular form. > > > > > > -- > > > Brian > > > > > > On Wed, Jan 27, 2016 at 5:54 PM, David Farmer > > > > wrote: > > > > > > The following is the proposed update for ARIN-2015-3: > > > Remove 30-Day Utilization Requirement in End-User IPv4 > > > Policy based on strong support in Montreal. > > > > > > Beyond deleting the 25% bullet as the policy says, > their > > > are editorial changes as follows to the remaining > > > text; > > > > > > - It looks weird to have single item bullet list, so > > > merge the two remaining sentence fragments into a > single > > > sentence. > > > - Change "are" to "is", since there is only one > > > remaining criteria > > > - Use of "criteria" as a singular is common usage, even > > > though technically it's plural. > > > - Resulting in "The basic criteria that must be met is > a > > > 50% utilization rate within one year." > > > > > > The remaining and resulting text for 4.3.3 is now > > > included in the policy text, for editorial clarity. > The > > > original staff and legal suggested removing the RFC2050 > > > reference and also pointed out that > > > 4.2.3.6 also has a 25% immediate use clause and a > > > RFC2050 reference. > > > > > > Feedback in Montreal was that deleting the 25% > immediate > > > use was a nice bite-sized change, and we shouldn't try > > > to do more than that with this change, so those changes > > > are not included at this time. > > > > > > Any additional feedback or comments are appreciated. > > > > > > Thanks > > > > > > --------- > > > > > > Draft Policy ARIN-2015-3: Remove 30 day utilization > > > requirement in end-user IPv4 policy > > > > > > Date: 27 January 2015 > > > > > > Problem Statement: > > > > > > End-user policy is intended to provide end-users with a > > > one year supply of IP addresses. Qualification for a > > > one-year supply requires the network operator to > utilize > > > at least 25% of the requested addresses within 30 days. > > > This text is unrealistic and should be removed. > > > > > > First, it often takes longer than 30 days to stage > > > equipment and start actually using the addresses. > > > > > > Second, growth is often not that regimented; the > > > forecast is to use X addresses over the course of a > > > year, not to use 25% of X within 30 days. > > > > > > Third, this policy text applies to additional address > > > space requests. It is incompatible with the > requirements > > > of other additional address space request justification > > > which indicates that 80% utilization of existing space > > > is sufficient to justify new space. If a block is at > > > 80%, then often (almost always?) the remaining 80% will > > > be used over the next 30 days and longer. Therefore the > > > operator cannot honestly state they will use 25% of the > > > ADDITIONAL space within 30 days of receiving it; > they're > > > still trying to use their older block efficiently. > > > > > > Fourth, in the face of ARIN exhaustion, some ISPs are > > > starting to not give out /24 (or larger) blocks. So the > > > justification for the 25% rule that previously existed > > > (and in fact, applied for many years) is no longer > germane. > > > > > > Policy statement: > > > > > > Remove the 25% utilization criteria bullet point from > > > NRPM 4.3.3. > > > > > > Resulting text: > > > > > > 4.3.3. Utilization rate > > > > > > Utilization rate of address space is a key factor in > > > justifying a new > > > assignment of IP address space. Requesters must show > > > exactly how > > > previous address assignments have been utilized and > must > > > provide > > > appropriate details to verify their one-year growth > > > projection. > > > > > > The basic criteria that must be met is a 50% > utilization > > > rate within one year. > > > > > > A greater utilization rate may be required based on > > > individual network > > > requirements. Please refer to RFC 2050 for more > > > information on > > > utilization guidelines. > > > > > > 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 > > > > > > ================================================ > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are > subscribed to > > > the ARIN Public Policy Mailing List ( > ARIN-PPML at arin.net > > > ). > > > Unsubscribe or manage 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. > > > > > > > > > > > > > > > -- > > > Cheers, > > > > > > McTim > > > "A name indicates what we seek. An address indicates where it is. A > > > route indicates how we get there." Jon Postel > > > > > > > > > > > > > > > -- > > > _______________________________________________________ > > > 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. > > > > > > > > > -- > > ================================================ > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsawyer at gci.com Tue Feb 16 19:12:54 2016 From: lsawyer at gci.com (Leif Sawyer) Date: Wed, 17 Feb 2016 00:12:54 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks Message-ID: Good afternoon - Based on feedback from Montreal as well as internal discussions, I've reworked this policy. AC members and ARIN staff are looking for additional feedback, as well as your position in terms of supporting or opposing this draft policy. We'll be discussing this policy, as well as any feedback provided on this week's AC teleconference, so I'm very appreciative of your input. Thanks, Leif Sawyer Shepherd - ARIN-2015-9 NRPM section 8: https://www.arin.net/policy/nrpm.html#eight Most current draft policy text follows: -- Draft Policy ARIN-2015-9 Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks Original Date: 23 September 2015 Updated: 16 February, 2016 Problem statement: The current needs-based evaluation language in NRPM sections 8.2 and 8.3, regarding transfer of IPv4 netblocks from one organization to another, may cause a recipient organization to bypass the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. The result is that the data visible in ARIN registry may become more inaccurate over time. Policy statement: This proposal eliminates all needs-based evaluation language for sections 8.2 and 8.3, allowing transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. Section 8.1 Principles: - Strike the fragment from the 3rd paragraph which reads ", based on justified need, " so the resulting text reads "Number resources are issued to organizations, not to individuals representing those organizations." Section 8.2 Mergers and Acquisitions: - Change the 4th bullet from: "The resources to be transferred will be subject to ARIN policies." to: "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification." - Strike the final paragraph which begins "In the event that number resources of the combined organizations are no longer justified under ARIN policy ..." Section 8.3 Transfers between Specified Recipients within the ARIN Region: - Change the first bullet under "Conditions on 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: "The recipient must sign an RSA." - Change the 2nd bullet under "Conditions on recipient of the transfer" from: "The resources to be transferred will be subject to ARIN policies." to: "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification." Comments: a. Timetable for implementation: Immediate b. Anything else As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and ARIN) have now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfill that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to ensuring an accurate registry database. The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. From jschiller at google.com Wed Feb 17 13:19:52 2016 From: jschiller at google.com (Jason Schiller) Date: Wed, 17 Feb 2016 13:19:52 -0500 Subject: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy In-Reply-To: References: <56A94A93.2000806@umn.edu> <56C2B246.4090807@umn.edu> Message-ID: Just in case it wasn't clear, I oppose as written as it has no teeth and can easily be an end user end-run around justified need. I support the change with some teeth so it is not likely to be an end-run around justified need. __Jason On Tue, Feb 16, 2016 at 4:52 PM, Brian Jones wrote: > > > > > On Tue, Feb 16, 2016 at 3:51 PM, Richard J. Letts wrote: > >> My preference is to apply the policy change as written (with the minor >> editorial change substituting "criterion" for "criteria".) >> > > ?+1? > -- > Brian > > >> >> Thank you >> Richard Letts >> >> > -----Original Message----- >> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> > Behalf Of David Farmer >> > Sent: Monday, February 15, 2016 9:23 PM >> > To: ARIN PPML >> > Subject: Re: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization >> > Requirement in End-User IPv4 Policy >> > >> > As shepherd, I need additional feedback on this, I need a better sense >> of >> > what the community wants here. >> > >> > Should we move forward more or less as-is, with a minor editorial >> change, >> > substituting "criterion" for "criteria"? >> > >> > Or, does the community want to work on a way to address the concerns >> > raised but Jason? >> > >> > Your input please. >> > >> > Thanks >> > >> > On 1/29/16 10:00 , Jason Schiller wrote: >> > > McTim, >> > > >> > > WRT some other tangible and verifiable claim to show there was a real >> > > commitment to use half the address space within one year... >> > > >> > > I think there are 3 choices: >> > > >> > > 1. Very vague >> > > >> > > Something like "there must be some tangible and verifiable claim to >> > > show there was a real commitment to use half the address space within >> > > one year and not just a future projection or business case" >> > > >> > > >> > > 2. Open ended with some guidance for ARIN staff: >> > > >> > > Something like "there must be some tangible and verifiable claim to >> > > show there was a real commitment to use half the address space within >> > > one year and not just a future projection or business case. Some >> > > examples include: >> > > - list of equipment in hand to be numbered counting at least 25% of >> > > requested IP size >> > > - invoices showing equipment purchases demonstrating a commitment to >> > > buy equipment to be numbered counting at least 25% of requested IP >> > > size >> > > - invoices showing equipment purchases demonstrating a commitment to >> > > buy equipment to be numbered counting at least 50% of requested IP >> > > size within one year >> > > - lease agreements for real estate supporting equipment that is >> > > appropratly sized to support equipment to be numbered counting at >> > > least 50% of requested IP size >> > > >> > > 3. specific criterion >> > > >> > > ---- >> > > >> > > I don't know what it the right answer here, and suspect it has more to >> > > do with what the community is comfortable with. >> > > >> > > On one end of the spectrum is choice 1. This allows ARIN to do the >> > > right thing. But this also is not clear about what the community >> > > expects, and ARIN may act in a way that is counter to what is >> > > anticipated, and may seem like ARIN is being arbitrary or has too much >> > > leeway to screw with requestors. >> > > >> > > The opposite end of the spectrum is choice 3. This sets a very clear >> > > list of what qualifies. Hammering out that list may be very >> > > difficult, and it is unlikely to be complete. This will leave little >> > > or no room for ARIN to do the right thing and approve a request that >> > > is justified, but not one of the criterion listed. >> > > >> > > Choice 2 is the middle ground. Where we have a not necessarily >> > > complete list of criterion (so somewhat less difficulty in drawing up >> > > the list) that creates a very clear expectation of what ARIN should >> > > accept (and reduces the possibility that ARIN may act in a way that is >> > > counter to what is anticipated, and may seem like ARIN is being >> > > arbitrary or has too much leeway to screw with requestors) with >> > > respect to criterion clearly defined, while also allowing ARIN to do >> > > the right thing with similar types of proof that are not explicitly >> > > listed as criterion (this has somewhat higher risk that ARIN may act >> > > in a way that is counter to what is anticipated, and may seem like >> > > ARIN is being arbitrary or has too much leeway to screw with >> > > requestors, but less risk than option 1 as the criterion should serve >> > > as good guidance) >> > > >> > > >> > > So two open questions to the community? >> > > >> > > 1. Is the community most comfortable with: >> > > A. totally vague and open-ended such as "there must be some >> > > tangible and verifiable claim to show there was a real commitment to >> > > use half the address space within one year and not just a future >> > > projection or business case" >> > > >> > > B. A vague statement with some guidance as to some acceptable >> > > forms of tangible verifiable proof of a real commitment to use half >> > > the IP address within one year. >> > > >> > > C. A very clear list of what proof is considered acceptable >> > > >> > > >> > > 2. If the community prefers B. guidance or C. a very clear list then >> > > what sort of things would the community like to see on that list? >> > > >> > > >> > > On Fri, Jan 29, 2016 at 8:27 AM, McTim > > > > wrote: >> > > >> > > >> > > >> > > On Thu, Jan 28, 2016 at 4:52 PM, Jason Schiller >> > > > wrote: >> > > >> > > I support the removal of the 30 day utilization as it is >> > > unreasonable for any larger end-site, who may have a real need >> > > for say a /16, with 65,000 desktops arriving on a loading doc >> > > next week, but an inability to unbox, configure and deploy >> > > 16,384 to the various office locations in 30 days. >> > > >> > > >> > > agreed. >> > > >> > > However, this is the only provision that has a real, tangible, >> > > and verifiable claim. Without this check justified need for >> end >> > > users simply becomes a 1 year future looking projection, and >> > > with sufficient arm waving an easy end run around justified >> need >> > > for any end user with no IP space or if they are efficiently >> > > using what they currently hold. >> > > >> > > >> > > good point! >> > > >> > > I could get on board if the maximum sized block permitted on a >> > > purely future looking projection was a /24 and you had to use >> it >> > > prior to getting more. >> > > >> > > >> > > +1 >> > > >> > > I could certainly get on board if there were some other >> tangible >> > > and verifiable claim to show there was a real commitment to >> use >> > > half the address space within one year. >> > > >> > > >> > > Would this language suffice, or would we need a metric of some >> sort? >> > > >> > > >> > > Regards, >> > > >> > > McTim >> > > >> > > __Jason >> > > >> > > On Thu, Jan 28, 2016 at 8:55 AM, Brian Jones > > > > wrote: >> > > >> > > Looks good to me Dave. I am okay with using criteria or >> > > criterion, however using the strict definition it looks as >> > > though criterion is the proper singular form. >> > > >> > > -- >> > > Brian >> > > >> > > On Wed, Jan 27, 2016 at 5:54 PM, David Farmer >> > > > wrote: >> > > >> > > The following is the proposed update for ARIN-2015-3: >> > > Remove 30-Day Utilization Requirement in End-User IPv4 >> > > Policy based on strong support in Montreal. >> > > >> > > Beyond deleting the 25% bullet as the policy says, >> their >> > > are editorial changes as follows to the remaining >> > > text; >> > > >> > > - It looks weird to have single item bullet list, so >> > > merge the two remaining sentence fragments into a >> single >> > > sentence. >> > > - Change "are" to "is", since there is only one >> > > remaining criteria >> > > - Use of "criteria" as a singular is common usage, >> even >> > > though technically it's plural. >> > > - Resulting in "The basic criteria that must be met >> is a >> > > 50% utilization rate within one year." >> > > >> > > The remaining and resulting text for 4.3.3 is now >> > > included in the policy text, for editorial clarity. >> The >> > > original staff and legal suggested removing the >> RFC2050 >> > > reference and also pointed out that >> > > 4.2.3.6 also has a 25% immediate use clause and a >> > > RFC2050 reference. >> > > >> > > Feedback in Montreal was that deleting the 25% >> immediate >> > > use was a nice bite-sized change, and we shouldn't try >> > > to do more than that with this change, so those >> changes >> > > are not included at this time. >> > > >> > > Any additional feedback or comments are appreciated. >> > > >> > > Thanks >> > > >> > > --------- >> > > >> > > Draft Policy ARIN-2015-3: Remove 30 day utilization >> > > requirement in end-user IPv4 policy >> > > >> > > Date: 27 January 2015 >> > > >> > > Problem Statement: >> > > >> > > End-user policy is intended to provide end-users with >> a >> > > one year supply of IP addresses. Qualification for a >> > > one-year supply requires the network operator to >> utilize >> > > at least 25% of the requested addresses within 30 >> days. >> > > This text is unrealistic and should be removed. >> > > >> > > First, it often takes longer than 30 days to stage >> > > equipment and start actually using the addresses. >> > > >> > > Second, growth is often not that regimented; the >> > > forecast is to use X addresses over the course of a >> > > year, not to use 25% of X within 30 days. >> > > >> > > Third, this policy text applies to additional address >> > > space requests. It is incompatible with the >> requirements >> > > of other additional address space request >> justification >> > > which indicates that 80% utilization of existing space >> > > is sufficient to justify new space. If a block is at >> > > 80%, then often (almost always?) the remaining 80% >> will >> > > be used over the next 30 days and longer. Therefore >> the >> > > operator cannot honestly state they will use 25% of >> the >> > > ADDITIONAL space within 30 days of receiving it; >> they're >> > > still trying to use their older block efficiently. >> > > >> > > Fourth, in the face of ARIN exhaustion, some ISPs are >> > > starting to not give out /24 (or larger) blocks. So >> the >> > > justification for the 25% rule that previously existed >> > > (and in fact, applied for many years) is no longer >> germane. >> > > >> > > Policy statement: >> > > >> > > Remove the 25% utilization criteria bullet point from >> > > NRPM 4.3.3. >> > > >> > > Resulting text: >> > > >> > > 4.3.3. Utilization rate >> > > >> > > Utilization rate of address space is a key factor in >> > > justifying a new >> > > assignment of IP address space. Requesters must show >> > > exactly how >> > > previous address assignments have been utilized and >> must >> > > provide >> > > appropriate details to verify their one-year growth >> > > projection. >> > > >> > > The basic criteria that must be met is a 50% >> utilization >> > > rate within one year. >> > > >> > > A greater utilization rate may be required based on >> > > individual network >> > > requirements. Please refer to RFC 2050 for more >> > > information on >> > > utilization guidelines. >> > > >> > > 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 >> > > >> > > ================================================ >> > > _______________________________________________ >> > > PPML >> > > You are receiving this message because you are >> subscribed to >> > > the ARIN Public Policy Mailing List ( >> ARIN-PPML at arin.net >> > > ). >> > > Unsubscribe or manage 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. >> > > >> > > >> > > >> > > >> > > -- >> > > Cheers, >> > > >> > > McTim >> > > "A name indicates what we seek. An address indicates where it is. >> A >> > > route indicates how we get there." Jon Postel >> > > >> > > >> > > >> > > >> > > -- >> > > _______________________________________________________ >> > > 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. >> > > >> > >> > >> > -- >> > ================================================ >> > 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. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Wed Feb 17 14:07:42 2016 From: info at arin.net (ARIN) Date: Wed, 17 Feb 2016 14:07:42 -0500 Subject: [arin-ppml] =?utf-8?q?NRPM_2016=2E1_=E2=80=93_New_Policies_Implem?= =?utf-8?q?ented_=28ARIN-2015-1_and_2015-4=29?= Message-ID: <56C4C4FE.7040705@arin.net> On 10 December 2015 the ARIN Board of Trustees adopted the following number policies: ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments https://www.arin.net/policy/proposals/2015_1.html ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations https://www.arin.net/policy/proposals/2015_4.html These new policies are now in effect. A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2016.1 is effective 17 February 2016 and supersedes the previous version. 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 ron.baione at yahoo.com Wed Feb 17 22:22:58 2016 From: ron.baione at yahoo.com (Ron Baione) Date: Wed, 17 Feb 2016 19:22:58 -0800 Subject: [arin-ppml] U.S. Nationalization of Apple's Employees In-Reply-To: <56C4C4FE.7040705@arin.net> Message-ID: <1455765778.81586.YahooMailMobile@web121906.mail.ne1.yahoo.com> This email is written in support of the rights of employees of the american tech industry: After forcing all American citizens to purchase a product, health insurance, the U.S. government is looking to force employees of a private company, Apple, to perform a specific task in the creation of a new product, in this instance, to create new code which would then allow the government to bypass Iphone security protections, according to the article at the following website: http://www.thedailybeast.com/articles/2016/02/17/apple-unlocked-iphones-for-the-feds-70-times-before.html The U.S. government can legally ask companies to comply with existing regulations, but a government agent forcing individual employees of a private company to perform a specific task, effectively forcing the employee to choose between retaining their job and creating the new product for the government, is simply the next step down the slippery slope. Americans are in the "forced actions phase" of this oligarchy. Internet policy groups and all internet governance groups should at least consider that when the heath insurance mandate was accepted, people wondered what would be the next mandate, would a future president take advantage of the trend towards mandating citizens to act? If apple's employees are forced to comply with a forced action, that in my opinion is no different than Apple having been nationalized by the U.S. government, in my opinion. What's next? The argument is much bigger than phones. U.S. government agents could order any private company employee in the entire country to perform any task the government deemed necessary. If a future government agent deemed that it was immediately necessary for a future apple employee to shine the shoes of the government agent, then they could refer back to the forced creation of code and ask, what's the difference? Oligarchy is about gaining the obedience of its citizens to the state via brutality (see broken windows police theory argument on gaining obedience) and via the provision of lose-lose choices that pit a citizen against his or her own ability to economically support himself or herself. Any male government agent forcing or pressuring a female private employee at apple to perform a specific action would also be violating women's Civil Rights law, same can be said for race etc., civil rights law exist for a reason in the american workplace. Oligarchy is government by hypocritical political criminals and their stooges, and internet governance groups should call it out for what it is and speak out against the american oligarchy on behalf of the U.S. tech industry which employs citizens from all countries. Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Thu Feb 18 13:34:55 2016 From: dogwallah at gmail.com (McTim) Date: Thu, 18 Feb 2016 13:34:55 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: I am opposed. If there are "networks in need of additional IPv4 addresses", surely they should be able to show this, in accord with long standing practice. I'd rather us not move to a situation which enables/encourages speculation and profit taking (or rent-seeking if you will) in re: IP resource distribution. Regards, McTim On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer wrote: > Good afternoon - > > Based on feedback from Montreal as well as internal discussions, I've > reworked this policy. > AC members and ARIN staff are looking for additional feedback, as well as > your position in terms > of supporting or opposing this draft policy. > > We'll be discussing this policy, as well as any feedback provided on > this week's AC teleconference, > so I'm very appreciative of your input. > > Thanks, > > Leif Sawyer > Shepherd - ARIN-2015-9 > > NRPM section 8: https://www.arin.net/policy/nrpm.html#eight > > Most current draft policy text follows: > -- > > Draft Policy ARIN-2015-9 > Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers > of IPv4 netblocks > Original Date: 23 September 2015 > Updated: 16 February, 2016 > > Problem statement: > The current needs-based evaluation language in NRPM sections 8.2 and 8.3, > regarding transfer of IPv4 > netblocks from one organization to another, may cause a recipient > organization to bypass the ARIN > registry entirely in order to secure the needed IPv4 netblocks in a more > timely fashion directly from the > current holder. The result is that the data visible in ARIN registry may > become more inaccurate over > time. > > Policy statement: > This proposal eliminates all needs-based evaluation language for sections > 8.2 and 8.3, allowing > transfers to be reflected in the database as they occur following an > agreement of transfer from the > resource provider to the recipient. > > Section 8.1 Principles: > - Strike the fragment from the 3rd paragraph which reads > ", based on justified need, " > so the resulting text reads > "Number resources are issued to organizations, not to individuals > representing those organizations." > Section 8.2 Mergers and Acquisitions: > - Change the 4th bullet from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, > excluding any policies related to needs-based justification." > > - Strike the final paragraph which begins "In the event that number > resources of the combined organizations are no longer justified under ARIN > policy ..." > > Section 8.3 Transfers between Specified Recipients within the ARIN Region: > - Change the first bullet under "Conditions on 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: > "The recipient must sign an RSA." > > - Change the 2nd bullet under "Conditions on recipient of the transfer" > from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, > excluding any policies related to needs-based justification." > > Comments: > a. Timetable for implementation: Immediate > b. Anything else > As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and > ARIN) have now been > exhausted, networks in need of additional IPv4 addresses have shifted away > from the practice of > receiving them from the RIR's resource pool. Instead, networks in need are > seeking out current holders > of IPv4 resources who are willing to transfer them in order to fulfill > that need. Accordingly, the RIR's > primary responsibility vis-?-vis IPv4 netblock governance has shifted from > "allocation" to ensuring an > accurate registry database. > > The RIPE registry can be used as a reference of one which has evolved over > the past couple years to > shift their focus away from conservation/allocation and towards database > accuracy. IPv4 netblock > transfers within that RIR consist merely of validating authenticity of the > parties requesting a transfer. > Provided the organizations meet the basic requirement of RIR membership, > and that the transferring > organization has the valid authority to request the transfer, the > transaction completes without any > "needs-based" review. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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: From owen at delong.com Thu Feb 18 14:16:43 2016 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Feb 2016 11:16:43 -0800 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: +1 ? McTim said it very well. Owen > On Feb 18, 2016, at 10:34 , McTim wrote: > > I am opposed. > > If there are "networks in need of additional IPv4 addresses", surely they should be able to show this, in accord with long standing practice. > > I'd rather us not move to a situation which enables/encourages speculation and profit taking (or rent-seeking if you will) in re: IP resource distribution. > > Regards, > > McTim > > > On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer > wrote: > Good afternoon - > > Based on feedback from Montreal as well as internal discussions, I've reworked this policy. > AC members and ARIN staff are looking for additional feedback, as well as your position in terms > of supporting or opposing this draft policy. > > We'll be discussing this policy, as well as any feedback provided on this week's AC teleconference, > so I'm very appreciative of your input. > > Thanks, > > Leif Sawyer > Shepherd - ARIN-2015-9 > > NRPM section 8: https://www.arin.net/policy/nrpm.html#eight > > Most current draft policy text follows: > -- > > Draft Policy ARIN-2015-9 > Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks > Original Date: 23 September 2015 > Updated: 16 February, 2016 > > Problem statement: > The current needs-based evaluation language in NRPM sections 8.2 and 8.3, regarding transfer of IPv4 > netblocks from one organization to another, may cause a recipient organization to bypass the ARIN > registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the > current holder. The result is that the data visible in ARIN registry may become more inaccurate over > time. > > Policy statement: > This proposal eliminates all needs-based evaluation language for sections 8.2 and 8.3, allowing > transfers to be reflected in the database as they occur following an agreement of transfer from the > resource provider to the recipient. > > Section 8.1 Principles: > - Strike the fragment from the 3rd paragraph which reads > ", based on justified need, " > so the resulting text reads > "Number resources are issued to organizations, not to individuals representing those organizations." > Section 8.2 Mergers and Acquisitions: > - Change the 4th bullet from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification." > > - Strike the final paragraph which begins "In the event that number resources of the combined organizations are no longer justified under ARIN policy ..." > > Section 8.3 Transfers between Specified Recipients within the ARIN Region: > - Change the first bullet under "Conditions on 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: > "The recipient must sign an RSA." > > - Change the 2nd bullet under "Conditions on recipient of the transfer" from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification." > > Comments: > a. Timetable for implementation: Immediate > b. Anything else > As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and ARIN) have now been > exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of > receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders > of IPv4 resources who are willing to transfer them in order to fulfill that need. Accordingly, the RIR's > primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to ensuring an > accurate registry database. > > The RIPE registry can be used as a reference of one which has evolved over the past couple years to > shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock > transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. > Provided the organizations meet the basic requirement of RIR membership, and that the transferring > organization has the valid authority to request the transfer, the transaction completes without any > "needs-based" review. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage 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 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 vaughn at swiftsystems.com Thu Feb 18 14:32:29 2016 From: vaughn at swiftsystems.com (Vaughn Thurman - Swift Systems) Date: Thu, 18 Feb 2016 14:32:29 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> +1 Sent from my mobile device, please forgive brevity and typos. > On Feb 18, 2016, at 2:16 PM, Owen DeLong wrote: > > +1 ? McTim said it very well. > > Owen > >> On Feb 18, 2016, at 10:34 , McTim wrote: >> >> I am opposed. >> >> If there are "networks in need of additional IPv4 addresses", surely they should be able to show this, in accord with long standing practice. >> >> I'd rather us not move to a situation which enables/encourages speculation and profit taking (or rent-seeking if you will) in re: IP resource distribution. >> >> Regards, >> >> McTim >> >> >>> On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer wrote: >>> Good afternoon - >>> >>> Based on feedback from Montreal as well as internal discussions, I've reworked this policy. >>> AC members and ARIN staff are looking for additional feedback, as well as your position in terms >>> of supporting or opposing this draft policy. >>> >>> We'll be discussing this policy, as well as any feedback provided on this week's AC teleconference, >>> so I'm very appreciative of your input. >>> >>> Thanks, >>> >>> Leif Sawyer >>> Shepherd - ARIN-2015-9 >>> >>> NRPM section 8: https://www.arin.net/policy/nrpm.html#eight >>> >>> Most current draft policy text follows: >>> -- >>> >>> Draft Policy ARIN-2015-9 >>> Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks >>> Original Date: 23 September 2015 >>> Updated: 16 February, 2016 >>> >>> Problem statement: >>> The current needs-based evaluation language in NRPM sections 8.2 and 8.3, regarding transfer of IPv4 >>> netblocks from one organization to another, may cause a recipient organization to bypass the ARIN >>> registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the >>> current holder. The result is that the data visible in ARIN registry may become more inaccurate over >>> time. >>> >>> Policy statement: >>> This proposal eliminates all needs-based evaluation language for sections 8.2 and 8.3, allowing >>> transfers to be reflected in the database as they occur following an agreement of transfer from the >>> resource provider to the recipient. >>> >>> Section 8.1 Principles: >>> - Strike the fragment from the 3rd paragraph which reads >>> ", based on justified need, " >>> so the resulting text reads >>> "Number resources are issued to organizations, not to individuals representing those organizations." >>> Section 8.2 Mergers and Acquisitions: >>> - Change the 4th bullet from: >>> "The resources to be transferred will be subject to ARIN policies." >>> to: >>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification." >>> >>> - Strike the final paragraph which begins "In the event that number resources of the combined organizations are no longer justified under ARIN policy ..." >>> >>> Section 8.3 Transfers between Specified Recipients within the ARIN Region: >>> - Change the first bullet under "Conditions on 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: >>> "The recipient must sign an RSA." >>> >>> - Change the 2nd bullet under "Conditions on recipient of the transfer" from: >>> "The resources to be transferred will be subject to ARIN policies." >>> to: >>> "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification." >>> >>> Comments: >>> a. Timetable for implementation: Immediate >>> b. Anything else >>> As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and ARIN) have now been >>> exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of >>> receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders >>> of IPv4 resources who are willing to transfer them in order to fulfill that need. Accordingly, the RIR's >>> primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to ensuring an >>> accurate registry database. >>> >>> The RIPE registry can be used as a reference of one which has evolved over the past couple years to >>> shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock >>> transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. >>> Provided the organizations meet the basic requirement of RIR membership, and that the transferring >>> organization has the valid authority to request the transfer, the transaction completes without any >>> "needs-based" review. >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage 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 >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage 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 droisman at softlayer.com Thu Feb 18 15:03:05 2016 From: droisman at softlayer.com (Dani Roisman) Date: Thu, 18 Feb 2016 20:03:05 +0000 Subject: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 In-Reply-To: References: Message-ID: I support this re-write of the previous draft, and agree with the removal of the 8.4 language at this stage (8.4 transfers should get separate attention due to the tie-in with other RIRs). When I defended this proposal in Montreal, I had may people come up to me after the session had ended who expressed their support. I would ask that those of you who *do* think the time has come to shift ARIN focus away from an inhibiting role, and instead prioritize accurate documentation of IPv4 market-induced transfers, please speak up now. The ARIN AC and membership needs to hear views of not only those opposed to this proposal. ---- Dani Roisman | -----Original Message----- | Date: Wed, 17 Feb 2016 00:12:54 +0000 | From: Leif Sawyer | To: ARIN PPML | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks | Message-ID: | | Content-Type: text/plain; charset=WINDOWS-1252 | | Good afternoon - | | Based on feedback from Montreal as well as internal discussions, I've | reworked this policy. | AC members and ARIN staff are looking for additional feedback, as well as | your position in terms | of supporting or opposing this draft policy. | | We'll be discussing this policy, as well as any feedback provided on this | week's AC teleconference, | so I'm very appreciative of your input. | | Thanks, | | Leif Sawyer | Shepherd - ARIN-2015-9 | | NRPM section 8: https://www.arin.net/policy/nrpm.html#eight | | Most current draft policy text follows: | -- | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 | netblocks | Original Date: 23 September 2015 | Updated: 16 February, 2016 | | Problem statement: | The current needs-based evaluation language in NRPM sections 8.2 and 8.3, | regarding transfer of IPv4 | netblocks from one organization to another, may cause a recipient | organization to bypass the ARIN | registry entirely in order to secure the needed IPv4 netblocks in a more | timely fashion directly from the | current holder. The result is that the data visible in ARIN registry may become | more inaccurate over | time. | | Policy statement: | This proposal eliminates all needs-based evaluation language for sections 8.2 | and 8.3, allowing | transfers to be reflected in the database as they occur following an | agreement of transfer from the | resource provider to the recipient. | | Section 8.1 Principles: | - Strike the fragment from the 3rd paragraph which reads | ", based on justified need, " | so the resulting text reads | "Number resources are issued to organizations, not to individuals | representing those organizations." | Section 8.2 Mergers and Acquisitions: | - Change the 4th bullet from: | "The resources to be transferred will be subject to ARIN policies." | to: | "The resources to be transferred will be subject to ARIN policies, excluding | any policies related to needs-based justification." | | - Strike the final paragraph which begins "In the event that number resources | of the combined organizations are no longer justified under ARIN policy ..." | | Section 8.3 Transfers between Specified Recipients within the ARIN Region: | - Change the first bullet under "Conditions on 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: | "The recipient must sign an RSA." | | - Change the 2nd bullet under "Conditions on recipient of the transfer" from: | "The resources to be transferred will be subject to ARIN policies." | to: | "The resources to be transferred will be subject to ARIN policies, excluding | any policies related to needs-based justification." | | Comments: | a. Timetable for implementation: Immediate | b. Anything else | As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and | ARIN) have now been | exhausted, networks in need of additional IPv4 addresses have shifted away | from the practice of | receiving them from the RIR's resource pool. Instead, networks in need are | seeking out current holders | of IPv4 resources who are willing to transfer them in order to fulfill that need. | Accordingly, the RIR's | primary responsibility vis-?-vis IPv4 netblock governance has shifted from | "allocation" to ensuring an | accurate registry database. | | The RIPE registry can be used as a reference of one which has evolved over | the past couple years to | shift their focus away from conservation/allocation and towards database | accuracy. IPv4 netblock | transfers within that RIR consist merely of validating authenticity of the | parties requesting a transfer. | Provided the organizations meet the basic requirement of RIR membership, | and that the transferring | organization has the valid authority to request the transfer, the transaction | completes without any | "needs-based" review. | | | From droisman at softlayer.com Thu Feb 18 15:07:50 2016 From: droisman at softlayer.com (Dani Roisman) Date: Thu, 18 Feb 2016 20:07:50 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks Message-ID: (resending to fix threading, sorry about that folks) I support this re-write of the previous draft, and agree with the removal of the 8.4 language at this stage (8.4 transfers should get separate attention due to the tie-in with other RIRs). When I defended this proposal in Montreal, I had may people come up to me after the session had ended who expressed their support. I would ask that those of you who *do* think the time has come to shift ARIN focus away from an inhibiting role, and instead prioritize accurate documentation of IPv4 market-induced transfers, please speak up now. The ARIN AC and membership needs to hear views of not only those opposed to this proposal. ---- Dani Roisman | -----Original Message----- | Date: Wed, 17 Feb 2016 00:12:54 +0000 | From: Leif Sawyer | To: ARIN PPML | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks | Message-ID: | | Content-Type: text/plain; charset=WINDOWS-1252 | | Good afternoon - | | Based on feedback from Montreal as well as internal discussions, I've | reworked this policy. | AC members and ARIN staff are looking for additional feedback, as well as | your position in terms | of supporting or opposing this draft policy. | | We'll be discussing this policy, as well as any feedback provided on this | week's AC teleconference, | so I'm very appreciative of your input. | | Thanks, | | Leif Sawyer | Shepherd - ARIN-2015-9 | | NRPM section 8: https://www.arin.net/policy/nrpm.html#eight | | Most current draft policy text follows: | -- | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 | netblocks | Original Date: 23 September 2015 | Updated: 16 February, 2016 | | Problem statement: | The current needs-based evaluation language in NRPM sections 8.2 and 8.3, | regarding transfer of IPv4 | netblocks from one organization to another, may cause a recipient | organization to bypass the ARIN | registry entirely in order to secure the needed IPv4 netblocks in a more | timely fashion directly from the | current holder. The result is that the data visible in ARIN registry may become | more inaccurate over | time. | | Policy statement: | This proposal eliminates all needs-based evaluation language for sections 8.2 | and 8.3, allowing | transfers to be reflected in the database as they occur following an | agreement of transfer from the | resource provider to the recipient. | | Section 8.1 Principles: | - Strike the fragment from the 3rd paragraph which reads | ", based on justified need, " | so the resulting text reads | "Number resources are issued to organizations, not to individuals | representing those organizations." | Section 8.2 Mergers and Acquisitions: | - Change the 4th bullet from: | "The resources to be transferred will be subject to ARIN policies." | to: | "The resources to be transferred will be subject to ARIN policies, excluding | any policies related to needs-based justification." | | - Strike the final paragraph which begins "In the event that number resources | of the combined organizations are no longer justified under ARIN policy ..." | | Section 8.3 Transfers between Specified Recipients within the ARIN Region: | - Change the first bullet under "Conditions on 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: | "The recipient must sign an RSA." | | - Change the 2nd bullet under "Conditions on recipient of the transfer" from: | "The resources to be transferred will be subject to ARIN policies." | to: | "The resources to be transferred will be subject to ARIN policies, excluding | any policies related to needs-based justification." | | Comments: | a. Timetable for implementation: Immediate | b. Anything else | As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and | ARIN) have now been | exhausted, networks in need of additional IPv4 addresses have shifted away | from the practice of | receiving them from the RIR's resource pool. Instead, networks in need are | seeking out current holders | of IPv4 resources who are willing to transfer them in order to fulfill that need. | Accordingly, the RIR's | primary responsibility vis-?-vis IPv4 netblock governance has shifted from | "allocation" to ensuring an | accurate registry database. | | The RIPE registry can be used as a reference of one which has evolved over | the past couple years to | shift their focus away from conservation/allocation and towards database | accuracy. IPv4 netblock | transfers within that RIR consist merely of validating authenticity of the | parties requesting a transfer. | Provided the organizations meet the basic requirement of RIR membership, | and that the transferring | organization has the valid authority to request the transfer, the transaction | completes without any | "needs-based" review. | | | From jschiller at google.com Thu Feb 18 15:11:41 2016 From: jschiller at google.com (Jason Schiller) Date: Thu, 18 Feb 2016 15:11:41 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> Message-ID: +1 to what MCTim, Owen, and Vaughn said. In general I oppose transfers with no need. If there are "networks in need of additional IPv4 addresses", surely they should be able to show this, in accord with long standing practice. I'd rather us not move to a situation which enables/encourages speculation and profit taking (or rent-seeking if you will) in re: IP resource distribution. I'd also rather not encourage one competitor in a business segment to be able to better stockpile addresses and for that to become a competitive advantage against other providers in the space. Additionally if this is done in a wide enough scale it can sufficiently lengthen wide spread IPv6 adoption. This policy would also allow for companies with the deepest pockets and the most profitable services to concentrate IPv4 space. I'm not sure that is more "fair" than the pre-existing framework for "fair". __Jason On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems < vaughn at swiftsystems.com> wrote: > +1 > > Sent from my mobile device, please forgive brevity and typos. > > On Feb 18, 2016, at 2:16 PM, Owen DeLong wrote: > > +1 ? McTim said it very well. > > Owen > > On Feb 18, 2016, at 10:34 , McTim wrote: > > I am opposed. > > If there are "networks in need of additional IPv4 addresses", surely they > should be able to show this, in accord with long standing practice. > > I'd rather us not move to a situation which enables/encourages speculation > and profit taking (or rent-seeking if you will) in re: IP resource > distribution. > > Regards, > > McTim > > > On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer wrote: > >> Good afternoon - >> >> Based on feedback from Montreal as well as internal discussions, I've >> reworked this policy. >> AC members and ARIN staff are looking for additional feedback, as well as >> your position in terms >> of supporting or opposing this draft policy. >> >> We'll be discussing this policy, as well as any feedback provided on >> this week's AC teleconference, >> so I'm very appreciative of your input. >> >> Thanks, >> >> Leif Sawyer >> Shepherd - ARIN-2015-9 >> >> NRPM section 8: https://www.arin.net/policy/nrpm.html#eight >> >> Most current draft policy text follows: >> -- >> >> Draft Policy ARIN-2015-9 >> Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers >> of IPv4 netblocks >> Original Date: 23 September 2015 >> Updated: 16 February, 2016 >> >> Problem statement: >> The current needs-based evaluation language in NRPM sections 8.2 and 8.3, >> regarding transfer of IPv4 >> netblocks from one organization to another, may cause a recipient >> organization to bypass the ARIN >> registry entirely in order to secure the needed IPv4 netblocks in a more >> timely fashion directly from the >> current holder. The result is that the data visible in ARIN registry may >> become more inaccurate over >> time. >> >> Policy statement: >> This proposal eliminates all needs-based evaluation language for sections >> 8.2 and 8.3, allowing >> transfers to be reflected in the database as they occur following an >> agreement of transfer from the >> resource provider to the recipient. >> >> Section 8.1 Principles: >> - Strike the fragment from the 3rd paragraph which reads >> ", based on justified need, " >> so the resulting text reads >> "Number resources are issued to organizations, not to individuals >> representing those organizations." >> Section 8.2 Mergers and Acquisitions: >> - Change the 4th bullet from: >> "The resources to be transferred will be subject to ARIN policies." >> to: >> "The resources to be transferred will be subject to ARIN policies, >> excluding any policies related to needs-based justification." >> >> - Strike the final paragraph which begins "In the event that number >> resources of the combined organizations are no longer justified under ARIN >> policy ..." >> >> Section 8.3 Transfers between Specified Recipients within the ARIN Region: >> - Change the first bullet under "Conditions on 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: >> "The recipient must sign an RSA." >> >> - Change the 2nd bullet under "Conditions on recipient of the transfer" >> from: >> "The resources to be transferred will be subject to ARIN policies." >> to: >> "The resources to be transferred will be subject to ARIN policies, >> excluding any policies related to needs-based justification." >> >> Comments: >> a. Timetable for implementation: Immediate >> b. Anything else >> As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and >> ARIN) have now been >> exhausted, networks in need of additional IPv4 addresses have shifted >> away from the practice of >> receiving them from the RIR's resource pool. Instead, networks in need >> are seeking out current holders >> of IPv4 resources who are willing to transfer them in order to fulfill >> that need. Accordingly, the RIR's >> primary responsibility vis-?-vis IPv4 netblock governance has shifted >> from "allocation" to ensuring an >> accurate registry database. >> >> The RIPE registry can be used as a reference of one which has evolved >> over the past couple years to >> shift their focus away from conservation/allocation and towards database >> accuracy. IPv4 netblock >> transfers within that RIR consist merely of validating authenticity of >> the parties requesting a transfer. >> Provided the organizations meet the basic requirement of RIR membership, >> and that the transferring >> organization has the valid authority to request the transfer, the >> transaction completes without any >> "needs-based" review. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage 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 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From JOHN at egh.com Thu Feb 18 15:18:12 2016 From: JOHN at egh.com (John Santos) Date: Thu, 18 Feb 2016 15:18:12 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> Message-ID: <1160218151726.64084A-100000@joonya.egh.com> Opposed. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From mwinters at edwardrose.com Thu Feb 18 15:24:16 2016 From: mwinters at edwardrose.com (Mike Winters) Date: Thu, 18 Feb 2016 20:24:16 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: I am opposed to the proposal and think McTim sums it up very well. Also +1 to Owen, Vaughn and Jason. What you are suggesting is akin to saying we should legalize the sale of alcohol to minors because they are going to drink anyway, but at least we would know who is drinking so that makes it ok. Maybe we should consider changing policy so that ARIN can recover the IP address of both organizations if they bypass policy. Mike -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Dani Roisman Sent: Thursday, February 18, 2016 3:08 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks (resending to fix threading, sorry about that folks) I support this re-write of the previous draft, and agree with the removal of the 8.4 language at this stage (8.4 transfers should get separate attention due to the tie-in with other RIRs). When I defended this proposal in Montreal, I had may people come up to me after the session had ended who expressed their support. I would ask that those of you who *do* think the time has come to shift ARIN focus away from an inhibiting role, and instead prioritize accurate documentation of IPv4 market-induced transfers, please speak up now. The ARIN AC and membership needs to hear views of not only those opposed to this proposal. ---- Dani Roisman From mike at iptrading.com Thu Feb 18 15:34:49 2016 From: mike at iptrading.com (Mike Burns) Date: Thu, 18 Feb 2016 15:34:49 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 Message-ID: Rent and profit seeking? That horse has long left the barn. But it's telling that arguments against this policy reveal themselves to be ideological in nature. Speculation? ?Only existing in fevered imaginations. Absent in RIPE despite its "encouragement/enablement". Still waiting for evidence of speculation, care to share any? I support this overdue relaxing of outdated inhibitors to normal business practices and to accurate registration. Mike? Sent from my Sprint phone
-------- Original message --------
From: Dani Roisman
Date:02/18/2016 3:03 PM (GMT-05:00)
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7
I support this re-write of the previous draft, and agree with the removal of the 8.4 language at this stage (8.4 transfers should get separate attention due to the tie-in with other RIRs). When I defended this proposal in Montreal, I had may people come up to me after the session had ended who expressed their support. I would ask that those of you who *do* think the time has come to shift ARIN focus away from an inhibiting role, and instead prioritize accurate documentation of IPv4 market-induced transfers, please speak up now. The ARIN AC and membership needs to hear views of not only those opposed to this proposal. ---- Dani Roisman | -----Original Message----- | Date: Wed, 17 Feb 2016 00:12:54 +0000 | From: Leif Sawyer | To: ARIN PPML | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks | Message-ID: | | Content-Type: text/plain; charset=WINDOWS-1252 | | Good afternoon - | | Based on feedback from Montreal as well as internal discussions, I've | reworked this policy. | AC members and ARIN staff are looking for additional feedback, as well as | your position in terms | of supporting or opposing this draft policy. | | We'll be discussing this policy, as well as any feedback provided on this | week's AC teleconference, | so I'm very appreciative of your input. | | Thanks, | | Leif Sawyer | Shepherd - ARIN-2015-9 | | NRPM section 8: https://www.arin.net/policy/nrpm.html#eight | | Most current draft policy text follows: | -- | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 | netblocks | Original Date: 23 September 2015 | Updated: 16 February, 2016 | | Problem statement: | The current needs-based evaluation language in NRPM sections 8.2 and 8.3, | regarding transfer of IPv4 | netblocks from one organization to another, may cause a recipient | organization to bypass the ARIN | registry entirely in order to secure the needed IPv4 netblocks in a more | timely fashion directly from the | current holder. The result is that the data visible in ARIN registry may become | more inaccurate over | time. | | Policy statement: | This proposal eliminates all needs-based evaluation language for sections 8.2 | and 8.3, allowing | transfers to be reflected in the database as they occur following an | agreement of transfer from the | resource provider to the recipient. | | Section 8.1 Principles: | - Strike the fragment from the 3rd paragraph which reads | ", based on justified need, " | so the resulting text reads | "Number resources are issued to organizations, not to individuals | representing those organizations." | Section 8.2 Mergers and Acquisitions: | - Change the 4th bullet from: | "The resources to be transferred will be subject to ARIN policies." | to: | "The resources to be transferred will be subject to ARIN policies, excluding | any policies related to needs-based justification." | | - Strike the final paragraph which begins "In the event that number resources | of the combined organizations are no longer justified under ARIN policy ..." | | Section 8.3 Transfers between Specified Recipients within the ARIN Region: | - Change the first bullet under "Conditions on 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: | "The recipient must sign an RSA." | | - Change the 2nd bullet under "Conditions on recipient of the transfer" from: | "The resources to be transferred will be subject to ARIN policies." | to: | "The resources to be transferred will be subject to ARIN policies, excluding | any policies related to needs-based justification." | | Comments: | a. Timetable for implementation: Immediate | b. Anything else | As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and | ARIN) have now been | exhausted, networks in need of additional IPv4 addresses have shifted away | from the practice of | receiving them from the RIR's resource pool. Instead, networks in need are | seeking out current holders | of IPv4 resources who are willing to transfer them in order to fulfill that need. | Accordingly, the RIR's | primary responsibility vis-?-vis IPv4 netblock governance has shifted from | "allocation" to ensuring an | accurate registry database. | | The RIPE registry can be used as a reference of one which has evolved over | the past couple years to | shift their focus away from conservation/allocation and towards database | accuracy. IPv4 netblock | transfers within that RIR consist merely of validating authenticity of the | parties requesting a transfer. | Provided the organizations meet the basic requirement of RIR membership, | and that the transferring | organization has the valid authority to request the transfer, the transaction | completes without any | "needs-based" review. | | | _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage 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 Thu Feb 18 16:18:51 2016 From: dogwallah at gmail.com (McTim) Date: Thu, 18 Feb 2016 16:18:51 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 In-Reply-To: References: Message-ID: On Thu, Feb 18, 2016 at 3:34 PM, Mike Burns wrote: > > Rent and profit seeking? > That horse has long left the barn. But it's telling that arguments against this policy reveal themselves to be ideological in nature. > > Speculation? Only existing in fevered imaginations. Absent in RIPE despite its "encouragement/enablement". Still waiting for evidence of speculation, care to share any? The existence of your company and other "brokers" isn't evidence enough that people want to make money solely by buying and selling v4 resources? Methinks you fail to see the forest for the trees! Regards, McTim > > > I support this overdue relaxing of outdated inhibitors to normal business practices and to accurate registration. > > > Mike > > > > Sent from my Sprint phone > > > -------- Original message -------- > From: Dani Roisman > Date:02/18/2016 3:03 PM (GMT-05:00) > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 > > I support this re-write of the previous draft, and agree with the removal of the 8.4 language at this stage (8.4 transfers should get separate attention due to the tie-in with other RIRs). When I defended this proposal in Montreal, I had may people come up to me after the session had ended who expressed their support. > > I would ask that those of you who *do* think the time has come to shift ARIN focus away from an inhibiting role, and instead prioritize accurate documentation of IPv4 market-induced transfers, please speak up now. The ARIN AC and membership needs to hear views of not only those opposed to this proposal. > > ---- > Dani Roisman > > > | -----Original Message----- > | Date: Wed, 17 Feb 2016 00:12:54 +0000 > | From: Leif Sawyer > | To: ARIN PPML > | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > | evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks > | Message-ID: > | | prd02.gci.com> > | Content-Type: text/plain; charset=WINDOWS-1252 > | > | Good afternoon - > | > | Based on feedback from Montreal as well as internal discussions, I've > | reworked this policy. > | AC members and ARIN staff are looking for additional feedback, as well as > | your position in terms > | of supporting or opposing this draft policy. > | > | We'll be discussing this policy, as well as any feedback provided on this > | week's AC teleconference, > | so I'm very appreciative of your input. > | > | Thanks, > | > | Leif Sawyer > | Shepherd - ARIN-2015-9 > | > | NRPM section 8: https://www.arin.net/policy/nrpm.html#eight > | > | Most current draft policy text follows: > | -- > | > | Draft Policy ARIN-2015-9 > | Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 > | netblocks > | Original Date: 23 September 2015 > | Updated: 16 February, 2016 > | > | Problem statement: > | The current needs-based evaluation language in NRPM sections 8.2 and 8.3, > | regarding transfer of IPv4 > | netblocks from one organization to another, may cause a recipient > | organization to bypass the ARIN > | registry entirely in order to secure the needed IPv4 netblocks in a more > | timely fashion directly from the > | current holder. The result is that the data visible in ARIN registry may become > | more inaccurate over > | time. > | > | Policy statement: > | This proposal eliminates all needs-based evaluation language for sections 8.2 > | and 8.3, allowing > | transfers to be reflected in the database as they occur following an > | agreement of transfer from the > | resource provider to the recipient. > | > | Section 8.1 Principles: > | - Strike the fragment from the 3rd paragraph which reads > | ", based on justified need, " > | so the resulting text reads > | "Number resources are issued to organizations, not to individuals > | representing those organizations." > | Section 8.2 Mergers and Acquisitions: > | - Change the 4th bullet from: > | "The resources to be transferred will be subject to ARIN policies." > | to: > | "The resources to be transferred will be subject to ARIN policies, excluding > | any policies related to needs-based justification." > | > | - Strike the final paragraph which begins "In the event that number resources > | of the combined organizations are no longer justified under ARIN policy ..." > | > | Section 8.3 Transfers between Specified Recipients within the ARIN Region: > | - Change the first bullet under "Conditions on 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: > | "The recipient must sign an RSA." > | > | - Change the 2nd bullet under "Conditions on recipient of the transfer" from: > | "The resources to be transferred will be subject to ARIN policies." > | to: > | "The resources to be transferred will be subject to ARIN policies, excluding > | any policies related to needs-based justification." > | > | Comments: > | a. Timetable for implementation: Immediate > | b. Anything else > | As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and > | ARIN) have now been > | exhausted, networks in need of additional IPv4 addresses have shifted away > | from the practice of > | receiving them from the RIR's resource pool. Instead, networks in need are > | seeking out current holders > | of IPv4 resources who are willing to transfer them in order to fulfill that need. > | Accordingly, the RIR's > | primary responsibility vis-?-vis IPv4 netblock governance has shifted from > | "allocation" to ensuring an > | accurate registry database. > | > | The RIPE registry can be used as a reference of one which has evolved over > | the past couple years to > | shift their focus away from conservation/allocation and towards database > | accuracy. IPv4 netblock > | transfers within that RIR consist merely of validating authenticity of the > | parties requesting a transfer. > | Provided the organizations meet the basic requirement of RIR membership, > | and that the transferring > | organization has the valid authority to request the transfer, the transaction > | completes without any > | "needs-based" review. > | > | > | > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 From gdiscovery at sympatico.ca Thu Feb 18 16:47:59 2016 From: gdiscovery at sympatico.ca (Michael Clarke) Date: Thu, 18 Feb 2016 16:47:59 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 11 In-Reply-To: References: Message-ID: <00fd01d16a96$090360b0$1b0a2210$@sympatico.ca> Keep getting this e-mail - don't know what to do with it. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of arin-ppml-request at arin.net Sent: Thursday, February 18, 2016 4:20 PM To: arin-ppml at arin.net Subject: ARIN-PPML Digest, Vol 128, Issue 11 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: Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks (John Santos) 2. Re: Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks (Mike Winters) 3. Re: ARIN-PPML Digest, Vol 128, Issue 7 (Mike Burns) 4. Re: ARIN-PPML Digest, Vol 128, Issue 7 (McTim) ---------------------------------------------------------------------- Message: 1 Date: Thu, 18 Feb 2016 15:18:12 -0500 From: John Santos To: ARIN PPML Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks Message-ID: <1160218151726.64084A-100000 at joonya.egh.com> Content-Type: text/plain; charset="us-ascii" Opposed. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Message: 2 Date: Thu, 18 Feb 2016 20:24:16 +0000 From: Mike Winters To: 'Dani Roisman' , "arin-ppml at arin.net" Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks Message-ID: Content-Type: text/plain; charset="us-ascii" I am opposed to the proposal and think McTim sums it up very well. Also +1 to Owen, Vaughn and Jason. What you are suggesting is akin to saying we should legalize the sale of alcohol to minors because they are going to drink anyway, but at least we would know who is drinking so that makes it ok. Maybe we should consider changing policy so that ARIN can recover the IP address of both organizations if they bypass policy. Mike -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Dani Roisman Sent: Thursday, February 18, 2016 3:08 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks (resending to fix threading, sorry about that folks) I support this re-write of the previous draft, and agree with the removal of the 8.4 language at this stage (8.4 transfers should get separate attention due to the tie-in with other RIRs). When I defended this proposal in Montreal, I had may people come up to me after the session had ended who expressed their support. I would ask that those of you who *do* think the time has come to shift ARIN focus away from an inhibiting role, and instead prioritize accurate documentation of IPv4 market-induced transfers, please speak up now. The ARIN AC and membership needs to hear views of not only those opposed to this proposal. ---- Dani Roisman ------------------------------ Message: 3 Date: Thu, 18 Feb 2016 15:34:49 -0500 From: Mike Burns To: Dani Roisman , "arin-ppml at arin.net" Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 Message-ID: Content-Type: text/plain; charset="utf-8" Rent and profit seeking? That horse has long left the barn. But it's telling that arguments against this policy reveal themselves to be ideological in nature. Speculation? ?Only existing in fevered imaginations. Absent in RIPE despite its "encouragement/enablement". Still waiting for evidence of speculation, care to share any? I support this overdue relaxing of outdated inhibitors to normal business practices and to accurate registration. Mike? Sent from my Sprint phone
-------- Original message --------
From: Dani Roisman
Date:02/18/2016 3:03 PM (GMT-05:00)
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7
I support this re-write of the previous draft, and agree with the removal of the 8.4 language at this stage (8.4 transfers should get separate attention due to the tie-in with other RIRs). When I defended this proposal in Montreal, I had may people come up to me after the session had ended who expressed their support. I would ask that those of you who *do* think the time has come to shift ARIN focus away from an inhibiting role, and instead prioritize accurate documentation of IPv4 market-induced transfers, please speak up now. The ARIN AC and membership needs to hear views of not only those opposed to this proposal. ---- Dani Roisman | -----Original Message----- | Date: Wed, 17 Feb 2016 00:12:54 +0000 | From: Leif Sawyer | To: ARIN PPML | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based | evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks | Message-ID: | | Content-Type: text/plain; charset=WINDOWS-1252 | | Good afternoon - | | Based on feedback from Montreal as well as internal discussions, | I've reworked this policy. | AC members and ARIN staff are looking for additional feedback, as well | as your position in terms of supporting or opposing this draft policy. | | We'll be discussing this policy, as well as any feedback provided on | this week's AC teleconference, so I'm very appreciative of your input. | | Thanks, | | Leif Sawyer | Shepherd - ARIN-2015-9 | | NRPM section 8: https://www.arin.net/policy/nrpm.html#eight | | Most current draft policy text follows: | -- | | Draft Policy ARIN-2015-9 | Eliminating needs-based evaluation for Section 8.2 and 8.3 | transfers of IPv4 netblocks Original Date: 23 September 2015 | Updated: 16 February, 2016 | | Problem statement: | The current needs-based evaluation language in NRPM sections 8.2 and | 8.3, regarding transfer of IPv4 netblocks from one organization to | another, may cause a recipient organization to bypass the ARIN | registry entirely in order to secure the needed IPv4 netblocks in a | more timely fashion directly from the current holder. The result is | that the data visible in ARIN registry may become more inaccurate over | time. | | Policy statement: | This proposal eliminates all needs-based evaluation language for | sections 8.2 and 8.3, allowing transfers to be reflected in the | database as they occur following an agreement of transfer from the | resource provider to the recipient. | | Section 8.1 Principles: | - Strike the fragment from the 3rd paragraph which reads ", based on | justified need, " | so the resulting text reads | "Number resources are issued to organizations, not to individuals | representing those organizations." | Section 8.2 Mergers and Acquisitions: | - Change the 4th bullet from: | "The resources to be transferred will be subject to ARIN policies." | to: | "The resources to be transferred will be subject to ARIN policies, | excluding any policies related to needs-based justification." | | - Strike the final paragraph which begins "In the event that number | resources of the combined organizations are no longer justified under ARIN policy ..." | | Section 8.3 Transfers between Specified Recipients within the ARIN Region: | - Change the first bullet under "Conditions on 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: | "The recipient must sign an RSA." | | - Change the 2nd bullet under "Conditions on recipient of the transfer" from: | "The resources to be transferred will be subject to ARIN policies." | to: | "The resources to be transferred will be subject to ARIN policies, | excluding any policies related to needs-based justification." | | Comments: | a. Timetable for implementation: Immediate b. Anything else As the | "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and | ARIN) have now been | exhausted, networks in need of additional IPv4 addresses have shifted | away from the practice of receiving them from the RIR's resource pool. | Instead, networks in need are seeking out current holders of IPv4 | resources who are willing to transfer them in order to fulfill that need. | Accordingly, the RIR's | primary responsibility vis-?-vis IPv4 netblock governance has shifted | from "allocation" to ensuring an accurate registry database. | | The RIPE registry can be used as a reference of one which has evolved | over the past couple years to shift their focus away from | conservation/allocation and towards database accuracy. IPv4 netblock | transfers within that RIR consist merely of validating authenticity of | the parties requesting a transfer. | Provided the organizations meet the basic requirement of RIR | membership, and that the transferring organization has the valid | authority to request the transfer, the transaction completes without | any "needs-based" review. | | | _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage 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: 4 Date: Thu, 18 Feb 2016 16:18:51 -0500 From: McTim To: "arin-ppml at arin.net" Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 Message-ID: Content-Type: text/plain; charset=UTF-8 On Thu, Feb 18, 2016 at 3:34 PM, Mike Burns wrote: > > Rent and profit seeking? > That horse has long left the barn. But it's telling that arguments against this policy reveal themselves to be ideological in nature. > > Speculation? Only existing in fevered imaginations. Absent in RIPE despite its "encouragement/enablement". Still waiting for evidence of speculation, care to share any? The existence of your company and other "brokers" isn't evidence enough that people want to make money solely by buying and selling v4 resources? Methinks you fail to see the forest for the trees! Regards, McTim > > > I support this overdue relaxing of outdated inhibitors to normal business practices and to accurate registration. > > > Mike > > > > Sent from my Sprint phone > > > -------- Original message -------- > From: Dani Roisman > Date:02/18/2016 3:03 PM (GMT-05:00) > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 > > I support this re-write of the previous draft, and agree with the removal of the 8.4 language at this stage (8.4 transfers should get separate attention due to the tie-in with other RIRs). When I defended this proposal in Montreal, I had may people come up to me after the session had ended who expressed their support. > > I would ask that those of you who *do* think the time has come to shift ARIN focus away from an inhibiting role, and instead prioritize accurate documentation of IPv4 market-induced transfers, please speak up now. The ARIN AC and membership needs to hear views of not only those opposed to this proposal. > > ---- > Dani Roisman > > > | -----Original Message----- > | Date: Wed, 17 Feb 2016 00:12:54 +0000 > | From: Leif Sawyer > | To: ARIN PPML > | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > | needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 > | netblocks > | Message-ID: > | | prd02.gci.com> > | Content-Type: text/plain; charset=WINDOWS-1252 > | > | Good afternoon - > | > | Based on feedback from Montreal as well as internal discussions, > | I've reworked this policy. > | AC members and ARIN staff are looking for additional feedback, as > | well as your position in terms of supporting or opposing this draft > | policy. > | > | We'll be discussing this policy, as well as any feedback provided > | on this week's AC teleconference, so I'm very appreciative of your > | input. > | > | Thanks, > | > | Leif Sawyer > | Shepherd - ARIN-2015-9 > | > | NRPM section 8: https://www.arin.net/policy/nrpm.html#eight > | > | Most current draft policy text follows: > | -- > | > | Draft Policy ARIN-2015-9 > | Eliminating needs-based evaluation for Section 8.2 and 8.3 > | transfers of IPv4 netblocks Original Date: 23 September 2015 > | Updated: 16 February, 2016 > | > | Problem statement: > | The current needs-based evaluation language in NRPM sections 8.2 and > | 8.3, regarding transfer of IPv4 netblocks from one organization to > | another, may cause a recipient organization to bypass the ARIN > | registry entirely in order to secure the needed IPv4 netblocks in a > | more timely fashion directly from the current holder. The result is > | that the data visible in ARIN registry may become more inaccurate > | over time. > | > | Policy statement: > | This proposal eliminates all needs-based evaluation language for > | sections 8.2 and 8.3, allowing transfers to be reflected in the > | database as they occur following an agreement of transfer from the > | resource provider to the recipient. > | > | Section 8.1 Principles: > | - Strike the fragment from the 3rd paragraph which reads ", based on > | justified need, " > | so the resulting text reads > | "Number resources are issued to organizations, not to individuals > | representing those organizations." > | Section 8.2 Mergers and Acquisitions: > | - Change the 4th bullet from: > | "The resources to be transferred will be subject to ARIN policies." > | to: > | "The resources to be transferred will be subject to ARIN policies, > | excluding any policies related to needs-based justification." > | > | - Strike the final paragraph which begins "In the event that number > | resources of the combined organizations are no longer justified under ARIN policy ..." > | > | Section 8.3 Transfers between Specified Recipients within the ARIN Region: > | - Change the first bullet under "Conditions on 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: > | "The recipient must sign an RSA." > | > | - Change the 2nd bullet under "Conditions on recipient of the transfer" from: > | "The resources to be transferred will be subject to ARIN policies." > | to: > | "The resources to be transferred will be subject to ARIN policies, > | excluding any policies related to needs-based justification." > | > | Comments: > | a. Timetable for implementation: Immediate b. Anything else As the > | "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and > | ARIN) have now been > | exhausted, networks in need of additional IPv4 addresses have > | shifted away from the practice of receiving them from the RIR's > | resource pool. Instead, networks in need are seeking out current > | holders of IPv4 resources who are willing to transfer them in order > | to fulfill that need. > | Accordingly, the RIR's > | primary responsibility vis-?-vis IPv4 netblock governance has > | shifted from "allocation" to ensuring an accurate registry database. > | > | The RIPE registry can be used as a reference of one which has > | evolved over the past couple years to shift their focus away from > | conservation/allocation and towards database accuracy. IPv4 netblock > | transfers within that RIR consist merely of validating authenticity > | of the parties requesting a transfer. > | Provided the organizations meet the basic requirement of RIR > | membership, and that the transferring organization has the valid > | authority to request the transfer, the transaction completes without > | any "needs-based" review. > | > | > | > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 ------------------------------ _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml End of ARIN-PPML Digest, Vol 128, Issue 11 ****************************************** From milton at gatech.edu Thu Feb 18 22:47:28 2016 From: milton at gatech.edu (Mueller, Milton L) Date: Fri, 19 Feb 2016 03:47:28 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com>, Message-ID: Really. Am I going to have to be the first to point out the irony of Google employees complaining that companies with "deep pockets" and "the most profitable services" will dominate the address market if we make minor relaxations of need assessments? What's wrong with this picture? Think, folks. Isn't it obvious that companies like Google are in a very good position to get the addresses they want - via less than transparent market mechanisms such as options contracts and acquisitions? And isn't it possible that they might be trying to prevent smaller companies from participating in the market by throwing up artificial barriers? All this talk of "fairness" overlooks the fact that it's more fair to have simple, transparent bidding and less bureaucracy. Smaller bidders can easily afford smaller chunks of numbers, and they benefit from the reduced administrative burden and delays associated with pointless and restrictive needs assessments. When I hear smaller ISPs who need addresses making Jason's arguments, I might take them seriously. Until then, no. --MM From: arin-ppml-bounces at arin.net on behalf of Jason Schiller Sent: Thursday, February 18, 2016 3:11 PM To: Vaughn Thurman - Swift Systems Cc: ARIN PPML Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks +1 to what MCTim, Owen, and Vaughn said. In general I oppose transfers with no need. If there are "networks in need of additional IPv4 addresses", surely they should be able to show this, in accord with long standing practice. I'd rather us not move to a situation which enables/encourages speculation and profit taking (or rent-seeking if you will) in re: IP resource distribution. I'd also rather not encourage one competitor in a business segment to be able to better stockpile addresses and for that to become a competitive advantage against other providers in the space. Additionally if this is done in a wide enough scale it can sufficiently lengthen wide spread IPv6 adoption. This policy would also allow for companies with the deepest pockets and the most profitable services to concentrate IPv4 space. I'm not sure that is more "fair" than the pre-existing framework for "fair". __Jason On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems > wrote: +1 Sent from my mobile device, please forgive brevity and typos. On Feb 18, 2016, at 2:16 PM, Owen DeLong > wrote: +1 ? McTim said it very well. Owen On Feb 18, 2016, at 10:34 , McTim > wrote: I am opposed. If there are "networks in need of additional IPv4 addresses", surely they should be able to show this, in accord with long standing practice. I'd rather us not move to a situation which enables/encourages speculation and profit taking (or rent-seeking if you will) in re: IP resource distribution. Regards, McTim On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer > wrote: Good afternoon - Based on feedback from Montreal as well as internal discussions, I've reworked this policy. AC members and ARIN staff are looking for additional feedback, as well as your position in terms of supporting or opposing this draft policy. We'll be discussing this policy, as well as any feedback provided on this week's AC teleconference, so I'm very appreciative of your input. Thanks, Leif Sawyer Shepherd - ARIN-2015-9 NRPM section 8: https://www.arin.net/policy/nrpm.html#eight Most current draft policy text follows: -- Draft Policy ARIN-2015-9 Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks Original Date: 23 September 2015 Updated: 16 February, 2016 Problem statement: The current needs-based evaluation language in NRPM sections 8.2 and 8.3, regarding transfer of IPv4 netblocks from one organization to another, may cause a recipient organization to bypass the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. The result is that the data visible in ARIN registry may become more inaccurate over time. Policy statement: This proposal eliminates all needs-based evaluation language for sections 8.2 and 8.3, allowing transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. Section 8.1 Principles: - Strike the fragment from the 3rd paragraph which reads ", based on justified need, " so the resulting text reads "Number resources are issued to organizations, not to individuals representing those organizations." Section 8.2 Mergers and Acquisitions: - Change the 4th bullet from: "The resources to be transferred will be subject to ARIN policies." to: "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification." - Strike the final paragraph which begins "In the event that number resources of the combined organizations are no longer justified under ARIN policy ..." Section 8.3 Transfers between Specified Recipients within the ARIN Region: - Change the first bullet under "Conditions on 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: "The recipient must sign an RSA." - Change the 2nd bullet under "Conditions on recipient of the transfer" from: "The resources to be transferred will be subject to ARIN policies." to: "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification." Comments: a. Timetable for implementation: Immediate b. Anything else As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and ARIN) have now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfill that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to ensuring an accurate registry database. The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage 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 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Thu Feb 18 23:07:40 2016 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 19 Feb 2016 04:07:40 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com>, Message-ID: <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> Milton is right! We are one of those small ISPs and the deck is stacked against us on purpose by larger organizations. It is time to move on and stop arranging the deck chairs on the IPv4 Titanic like other regions have. It?s 2016 not 2001. I support this policy! 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: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mueller, Milton L Sent: Thursday, February 18, 2016 10:47 PM To: Jason Schiller Cc: ARIN PPML Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks Really. Am I going to have to be the first to point out the irony of Google employees complaining that companies with "deep pockets" and "the most profitable services" will dominate the address market if we make minor relaxations of need assessments? What's wrong with this picture? Think, folks. Isn't it obvious that companies like Google are in a very good position to get the addresses they want - via less than transparent market mechanisms such as options contracts and acquisitions? And isn't it possible that they might be trying to prevent smaller companies from participating in the market by throwing up artificial barriers? All this talk of "fairness" overlooks the fact that it's more fair to have simple, transparent bidding and less bureaucracy. Smaller bidders can easily afford smaller chunks of numbers, and they benefit from the reduced administrative burden and delays associated with pointless and restrictive needs assessments. When I hear smaller ISPs who need addresses making Jason's arguments, I might take them seriously. Until then, no. --MM From: arin-ppml-bounces at arin.net > on behalf of Jason Schiller > Sent: Thursday, February 18, 2016 3:11 PM To: Vaughn Thurman - Swift Systems Cc: ARIN PPML Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks +1 to what MCTim, Owen, and Vaughn said. In general I oppose transfers with no need. If there are "networks in need of additional IPv4 addresses", surely they should be able to show this, in accord with long standing practice. I'd rather us not move to a situation which enables/encourages speculation and profit taking (or rent-seeking if you will) in re: IP resource distribution. I'd also rather not encourage one competitor in a business segment to be able to better stockpile addresses and for that to become a competitive advantage against other providers in the space. Additionally if this is done in a wide enough scale it can sufficiently lengthen wide spread IPv6 adoption. This policy would also allow for companies with the deepest pockets and the most profitable services to concentrate IPv4 space. I'm not sure that is more "fair" than the pre-existing framework for "fair". __Jason On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems > wrote: +1 Sent from my mobile device, please forgive brevity and typos. On Feb 18, 2016, at 2:16 PM, Owen DeLong > wrote: +1 ? McTim said it very well. Owen On Feb 18, 2016, at 10:34 , McTim > wrote: I am opposed. If there are "networks in need of additional IPv4 addresses", surely they should be able to show this, in accord with long standing practice. I'd rather us not move to a situation which enables/encourages speculation and profit taking (or rent-seeking if you will) in re: IP resource distribution. Regards, McTim On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer > wrote: Good afternoon - Based on feedback from Montreal as well as internal discussions, I've reworked this policy. AC members and ARIN staff are looking for additional feedback, as well as your position in terms of supporting or opposing this draft policy. We'll be discussing this policy, as well as any feedback provided on this week's AC teleconference, so I'm very appreciative of your input. Thanks, Leif Sawyer Shepherd - ARIN-2015-9 NRPM section 8: https://www.arin.net/policy/nrpm.html#eight Most current draft policy text follows: -- Draft Policy ARIN-2015-9 Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks Original Date: 23 September 2015 Updated: 16 February, 2016 Problem statement: The current needs-based evaluation language in NRPM sections 8.2 and 8.3, regarding transfer of IPv4 netblocks from one organization to another, may cause a recipient organization to bypass the ARIN registry entirely in order to secure the needed IPv4 netblocks in a more timely fashion directly from the current holder. The result is that the data visible in ARIN registry may become more inaccurate over time. Policy statement: This proposal eliminates all needs-based evaluation language for sections 8.2 and 8.3, allowing transfers to be reflected in the database as they occur following an agreement of transfer from the resource provider to the recipient. Section 8.1 Principles: - Strike the fragment from the 3rd paragraph which reads ", based on justified need, " so the resulting text reads "Number resources are issued to organizations, not to individuals representing those organizations." Section 8.2 Mergers and Acquisitions: - Change the 4th bullet from: "The resources to be transferred will be subject to ARIN policies." to: "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification." - Strike the final paragraph which begins "In the event that number resources of the combined organizations are no longer justified under ARIN policy ..." Section 8.3 Transfers between Specified Recipients within the ARIN Region: - Change the first bullet under "Conditions on 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: "The recipient must sign an RSA." - Change the 2nd bullet under "Conditions on recipient of the transfer" from: "The resources to be transferred will be subject to ARIN policies." to: "The resources to be transferred will be subject to ARIN policies, excluding any policies related to needs-based justification." Comments: a. Timetable for implementation: Immediate b. Anything else As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and ARIN) have now been exhausted, networks in need of additional IPv4 addresses have shifted away from the practice of receiving them from the RIR's resource pool. Instead, networks in need are seeking out current holders of IPv4 resources who are willing to transfer them in order to fulfill that need. Accordingly, the RIR's primary responsibility vis-?-vis IPv4 netblock governance has shifted from "allocation" to ensuring an accurate registry database. The RIPE registry can be used as a reference of one which has evolved over the past couple years to shift their focus away from conservation/allocation and towards database accuracy. IPv4 netblock transfers within that RIR consist merely of validating authenticity of the parties requesting a transfer. Provided the organizations meet the basic requirement of RIR membership, and that the transferring organization has the valid authority to request the transfer, the transaction completes without any "needs-based" review. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage 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 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage 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: 1468 bytes Desc: image001.jpg URL: From ajs at anvilwalrusden.com Thu Feb 18 23:09:57 2016 From: ajs at anvilwalrusden.com (Andrew Sullivan) Date: Thu, 18 Feb 2016 23:09:57 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> Message-ID: <20160219040957.GU100@mx2.yitter.info> Hi, Let me start by saying that I don't really care about this. But ? On Thu, Feb 18, 2016 at 03:11:41PM -0500, Jason Schiller wrote: > I'd rather us not move to a situation which enables/encourages speculation > and profit taking (or rent-seeking if you will) in re: IP resource > distribution. ?the above sounds precariously close to using regulatory power in the market. If that's the justification, then I think ARIN can't use it. Best regards, A -- Andrew Sullivan ajs at anvilwalrusden.com From rcarpen at network1.net Thu Feb 18 23:29:53 2016 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 18 Feb 2016 23:29:53 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> Message-ID: <64759736.483998.1455856193822.JavaMail.zimbra@network1.net> Are you arguing that by removing the barriers that it would make it more difficult for Google to get more addresses? If not, then the point is moot. thanks, -Randy ----- On Feb 18, 2016, at 10:47 PM, Mueller, Milton L milton at gatech.edu wrote: > Really. Am I going to have to be the first to point out the irony of Google > employees complaining that companies with "deep pockets" and "the most > profitable services" will dominate the address market if we make minor > relaxations of need assessments? > > > > > What's wrong with this picture? Think, folks. > > > > > Isn't it obvious that companies like Google are in a very good position to get > the addresses they want - via less than transparent market mechanisms such as > options contracts and acquisitions? And isn't it possible that they might be > trying to prevent smaller companies from participating in the market by > throwing up artificial barriers? > > > > > All this talk of "fairness" overlooks the fact that it's more fair to have > simple, transparent bidding and less bureaucracy. Smaller bidders can easily > afford smaller chunks of numbers, and they benefit from the reduced > administrative burden and delays associated with pointless and restrictive > needs assessments. When I hear smaller ISPs who need addresses making Jason's > arguments, I might take them seriously. Until then, no. > > > > > > --MM > > > > > From: arin-ppml-bounces at arin.net on behalf of Jason > Schiller > Sent: Thursday, February 18, 2016 3:11 PM > To: Vaughn Thurman - Swift Systems > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks > +1 to what MCTim, Owen, and Vaughn said. > > In general I oppose transfers with no need. > > If there are "networks in need of additional IPv4 addresses", surely they should > be able to show this, in accord with long standing practice. > > I'd rather us not move to a situation which enables/encourages speculation and > profit taking (or rent-seeking if you will) in re: IP resource distribution. > > I'd also rather not encourage one competitor in a business segment to be able to > better stockpile addresses and for that to become a competitive advantage > against other providers in the space. Additionally if this is done in a wide > enough scale it can sufficiently lengthen wide spread IPv6 adoption. > > This policy would also allow for companies with the deepest pockets and the most > profitable services to concentrate IPv4 space. I'm not sure that is more "fair" > than the pre-existing framework for "fair". > > __Jason > > > > On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems < > vaughn at swiftsystems.com > wrote: > > > > +1 > > Sent from my mobile device, please forgive brevity and typos. > > On Feb 18, 2016, at 2:16 PM, Owen DeLong < owen at delong.com > wrote: > > > > > +1 ? McTim said it very well. > > Owen > > > > > On Feb 18, 2016, at 10:34 , McTim < dogwallah at gmail.com > wrote: > > I am opposed. > > If there are " networks in need of additional IPv4 addresses", surely they > should be able to show this, in accord with long standing practice. > > I'd rather us not move to a situation which enables/encourages speculation and > profit taking (or rent-seeking if you will) in re: IP resource distribution. > > Regards, > > McTim > > > On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer < lsawyer at gci.com > wrote: > > > Good afternoon - > > Based on feedback from Montreal as well as internal discussions, I've reworked > this policy. > AC members and ARIN staff are looking for additional feedback, as well as your > position in terms > of supporting or opposing this draft policy. > > We'll be discussing this policy, as well as any feedback provided on this week's > AC teleconference, > so I'm very appreciative of your input. > > Thanks, > > Leif Sawyer > Shepherd - ARIN-2015-9 > > NRPM section 8: https://www.arin.net/policy/nrpm.html#eight > > Most current draft policy text follows: > -- > > Draft Policy ARIN-2015-9 > Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 > netblocks > Original Date: 23 September 2015 > Updated: 16 February, 2016 > > Problem statement: > The current needs-based evaluation language in NRPM sections 8.2 and 8.3, > regarding transfer of IPv4 > netblocks from one organization to another, may cause a recipient organization > to bypass the ARIN > registry entirely in order to secure the needed IPv4 netblocks in a more timely > fashion directly from the > current holder. The result is that the data visible in ARIN registry may become > more inaccurate over > time. > > Policy statement: > This proposal eliminates all needs-based evaluation language for sections 8.2 > and 8.3, allowing > transfers to be reflected in the database as they occur following an agreement > of transfer from the > resource provider to the recipient. > > Section 8.1 Principles: > - Strike the fragment from the 3rd paragraph which reads > ", based on justified need, " > so the resulting text reads > "Number resources are issued to organizations, not to individuals representing > those organizations." > Section 8.2 Mergers and Acquisitions: > - Change the 4th bullet from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, excluding any > policies related to needs-based justification." > > - Strike the final paragraph which begins "In the event that number resources of > the combined organizations are no longer justified under ARIN policy ..." > > Section 8.3 Transfers between Specified Recipients within the ARIN Region: > - Change the first bullet under "Conditions on 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: > "The recipient must sign an RSA." > > - Change the 2nd bullet under "Conditions on recipient of the transfer" from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, excluding any > policies related to needs-based justification." > > Comments: > a. Timetable for implementation: Immediate > b. Anything else > As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and ARIN) > have now been > exhausted, networks in need of additional IPv4 addresses have shifted away from > the practice of > receiving them from the RIR's resource pool. Instead, networks in need are > seeking out current holders > of IPv4 resources who are willing to transfer them in order to fulfill that > need. Accordingly, the RIR's > primary responsibility vis-?-vis IPv4 netblock governance has shifted from > "allocation" to ensuring an > accurate registry database. > > The RIPE registry can be used as a reference of one which has evolved over the > past couple years to > shift their focus away from conservation/allocation and towards database > accuracy. IPv4 netblock > transfers within that RIR consist merely of validating authenticity of the > parties requesting a transfer. > Provided the organizations meet the basic requirement of RIR membership, and > that the transferring > organization has the valid authority to request the transfer, the transaction > completes without any > "needs-based" review. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). > Unsubscribe or manage 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 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). > Unsubscribe or manage 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. From rcarpen at network1.net Thu Feb 18 23:50:16 2016 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 18 Feb 2016 23:50:16 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> Message-ID: <823499847.484118.1455857416654.JavaMail.zimbra@network1.net> So, you are saying that you need addresses, but can't justify it? I keep hearing the argument and it makes no sense. I manage the IP networks of a bunch of small ISPs. I have never had an issue with justifying their needs. There certainly are instances where it would be nice to have some more space to have more flexibility and for future needs. But, we can't justify the actual need, so we shouldn't get the space. Others have a need and can justify it, therefore they should be able to get it. Making it trivial to get space would lead to those who do *not* need it getting it because they can, which will reduce the amount of space available to those who actually need it. I oppose vehemently. thanks, -Randy ----- On Feb 18, 2016, at 11:07 PM, Steven Ryerse SRyerse at eclipse-networks.com wrote: > Milton is right! We are one of those small ISPs and the deck is stacked against > us on purpose by larger organizations. It is time to move on and stop arranging > the deck chairs on the IPv4 Titanic like other regions have. It?s 2016 not > 2001. I support this policy! > > > > > > > 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 ? > > > > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf > Of Mueller, Milton L > Sent: Thursday, February 18, 2016 10:47 PM > To: Jason Schiller > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks > > > > > > > > Really. Am I going to have to be the first to point out the irony of Google > employees complaining that companies with "deep pockets" and "the most > profitable services" will dominate the address market if we make minor > relaxations of need assessments? > > > > What's wrong with this picture? Think, folks. > > > > Isn't it obvious that companies like Google are in a very good position to get > the addresses they want - via less than transparent market mechanisms such as > options contracts and acquisitions? And isn't it possible that they might be > trying to prevent smaller companies from participating in the market by > throwing up artificial barriers? > > > > All this talk of "fairness" overlooks the fact that it's more fair to have > simple, transparent bidding and less bureaucracy. Smaller bidders can easily > afford smaller chunks of numbers, and they benefit from the reduced > administrative burden and delays associated with pointless and restrictive > needs assessments. When I hear smaller ISPs who need addresses making Jason's > arguments, I might take them seriously. Until then, no. > > > > --MM > > > > From: arin-ppml-bounces at arin.net < arin-ppml-bounces at arin.net > on behalf of > Jason Schiller < jschiller at google.com > > > > Sent: Thursday, February 18, 2016 3:11 PM > To: Vaughn Thurman - Swift Systems > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks > > > > > > +1 to what MCTim, Owen, and Vaughn said. > > > > > > In general I oppose transfers with no need. > > > > > > If there are "networks in need of additional IPv4 addresses", surely they should > be able to show this, in accord with long standing practice. > > > > > > I'd rather us not move to a situation which enables/encourages speculation and > profit taking (or rent-seeking if you will) in re: IP resource distribution. > > > > > > I'd also rather not encourage one competitor in a business segment to be able to > better stockpile addresses and for that to become a competitive advantage > > > against other providers in the space. Additionally if this is done in a wide > enough scale it can sufficiently lengthen wide spread IPv6 adoption. > > > > > > This policy would also allow for companies with the deepest pockets and the most > profitable services to concentrate IPv4 space. I'm not sure that is more "fair" > > > than the pre-existing framework for "fair". > > > > > > __Jason > > > > > > > > > > > > On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems < > vaughn at swiftsystems.com > wrote: > > > > > +1 > > Sent from my mobile device, please forgive brevity and typos. > > > > On Feb 18, 2016, at 2:16 PM, Owen DeLong < owen at delong.com > wrote: > > > > > > +1 ? McTim said it very well. > > > > > > Owen > > > > > > > > > On Feb 18, 2016, at 10:34 , McTim < dogwallah at gmail.com > wrote: > > > > > > I am opposed. > > > > > > If there are " networks in need of additional IPv4 addresses", surely they > should be able to show this, in accord with long standing practice. > > > > > > I'd rather us not move to a situation which enables/encourages speculation and > profit taking (or rent-seeking if you will) in re: IP resource distribution. > > > > > > Regards, > > > > > > McTim > > > > > > > > > On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer < lsawyer at gci.com > wrote: > > > > Good afternoon - > > Based on feedback from Montreal as well as internal discussions, I've reworked > this policy. > AC members and ARIN staff are looking for additional feedback, as well as your > position in terms > of supporting or opposing this draft policy. > > We'll be discussing this policy, as well as any feedback provided on this week's > AC teleconference, > so I'm very appreciative of your input. > > Thanks, > > Leif Sawyer > Shepherd - ARIN-2015-9 > > NRPM section 8: https://www.arin.net/policy/nrpm.html#eight > > Most current draft policy text follows: > -- > > Draft Policy ARIN-2015-9 > Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 > netblocks > Original Date: 23 September 2015 > Updated: 16 February, 2016 > > Problem statement: > The current needs-based evaluation language in NRPM sections 8.2 and 8.3, > regarding transfer of IPv4 > netblocks from one organization to another, may cause a recipient organization > to bypass the ARIN > registry entirely in order to secure the needed IPv4 netblocks in a more timely > fashion directly from the > current holder. The result is that the data visible in ARIN registry may become > more inaccurate over > time. > > Policy statement: > This proposal eliminates all needs-based evaluation language for sections 8.2 > and 8.3, allowing > transfers to be reflected in the database as they occur following an agreement > of transfer from the > resource provider to the recipient. > > Section 8.1 Principles: > - Strike the fragment from the 3rd paragraph which reads > ", based on justified need, " > so the resulting text reads > "Number resources are issued to organizations, not to individuals representing > those organizations." > Section 8.2 Mergers and Acquisitions: > - Change the 4th bullet from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, excluding any > policies related to needs-based justification." > > - Strike the final paragraph which begins "In the event that number resources of > the combined organizations are no longer justified under ARIN policy ..." > > Section 8.3 Transfers between Specified Recipients within the ARIN Region: > - Change the first bullet under "Conditions on 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: > "The recipient must sign an RSA." > > - Change the 2nd bullet under "Conditions on recipient of the transfer" from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, excluding any > policies related to needs-based justification." > > Comments: > a. Timetable for implementation: Immediate > b. Anything else > As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and ARIN) > have now been > exhausted, networks in need of additional IPv4 addresses have shifted away from > the practice of > receiving them from the RIR's resource pool. Instead, networks in need are > seeking out current holders > of IPv4 resources who are willing to transfer them in order to fulfill that > need. Accordingly, the RIR's > primary responsibility vis-?-vis IPv4 netblock governance has shifted from > "allocation" to ensuring an > accurate registry database. > > The RIPE registry can be used as a reference of one which has evolved over the > past couple years to > shift their focus away from conservation/allocation and towards database > accuracy. IPv4 netblock > transfers within that RIR consist merely of validating authenticity of the > parties requesting a transfer. > Provided the organizations meet the basic requirement of RIR membership, and > that the transferring > organization has the valid authority to request the transfer, the transaction > completes without any > "needs-based" review. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). > Unsubscribe or manage 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 > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). > Unsubscribe or manage 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. From pmcnary at cameron.net Fri Feb 19 00:20:02 2016 From: pmcnary at cameron.net (Paul) Date: Thu, 18 Feb 2016 23:20:02 -0600 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: <823499847.484118.1455857416654.JavaMail.zimbra@network1.net> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> <823499847.484118.1455857416654.JavaMail.zimbra@network1.net> Message-ID: <56C6A602.8050303@cameron.net> I have a question. Our small ISP company is losing a /22 and a /23 we were reallocated years ago. The company sold and now is requiring us to give these back. This was unexpected. We did not see that coming and by the time we got the news and started the process to directly acquire IPv4 ARIN was out. My question is: if we justify a certain IP Block maybe a /21 or /22. Is it true if we acquire them a /24 at a time we have to wait 12 months before we can get the next transfer approved? and have to pay another $500 for each /24 we get transferred in. So if we are lucky to find a legacy owner, I have been told by ARIN that they need proof of the company from the secretary of state. Back in the 80's and 90's fictitious names did not have to be registered by most states especially in the case of a sole proprietorship or a small corporation using an unregistered DBA. This seems to be the case of acquiring and trying to transfer legacy IP Blocks in to ARIN. We were required to get a new ORG-ID because the dba we were using at the time of the re-allocation wasn't registered with the state. It was perfectly legal at the time the ORG-ID was issued. This is the biggest obstacle I have had. I am scared to acquire Legacy Resources because ARIN threatens to claw them back if I try to transfer and register them. The big companies have lawyers that can fight the ARIN policies and win, we do not. If I am misunderstanding the transfer system please clue me in. This is extremely expensive for a small ISP like us. I see both sides of the proposal as detrimental to small ISP's. We are currently having to re-IP 8 /24's to a /27. Very hard to do! I want what ever it takes to transfer in resources up to the justification amount. It might take 1 year maybe 10 years and not be charged on every /24 up to our justification.. IPv6 direct allocations were supposed to get a $500 direct allocation by now. A $500 direct allocation of IPv6 would help but we have to find enough IPv4 to stay in business. Currently our fiber provider can provide IPv6 to our rural area. Please help me understand the bureaucracy that ARIN is? Thanks Paul McNary McNary Computer Services On 2/18/2016 10:50 PM, Randy Carpenter wrote: > So, you are saying that you need addresses, but can't justify it? I keep hearing the argument and it makes no sense. > > I manage the IP networks of a bunch of small ISPs. I have never had an issue with justifying their needs. There certainly are instances where it would be nice to have some more space to have more flexibility and for future needs. But, we can't justify the actual need, so we shouldn't get the space. Others have a need and can justify it, therefore they should be able to get it. > > Making it trivial to get space would lead to those who do *not* need it getting it because they can, which will reduce the amount of space available to those who actually need it. > > I oppose vehemently. > > thanks, > -Randy > > > ----- On Feb 18, 2016, at 11:07 PM, Steven Ryerse SRyerse at eclipse-networks.com wrote: > >> Milton is right! We are one of those small ISPs and the deck is stacked against >> us on purpose by larger organizations. It is time to move on and stop arranging >> the deck chairs on the IPv4 Titanic like other regions have. It?s 2016 not >> 2001. I support this policy! >> >> >> >> >> >> >> 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 ? >> >> >> >> >> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf >> Of Mueller, Milton L >> Sent: Thursday, February 18, 2016 10:47 PM >> To: Jason Schiller >> Cc: ARIN PPML >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based >> evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks >> >> >> >> >> >> >> >> Really. Am I going to have to be the first to point out the irony of Google >> employees complaining that companies with "deep pockets" and "the most >> profitable services" will dominate the address market if we make minor >> relaxations of need assessments? >> >> >> >> What's wrong with this picture? Think, folks. >> >> >> >> Isn't it obvious that companies like Google are in a very good position to get >> the addresses they want - via less than transparent market mechanisms such as >> options contracts and acquisitions? And isn't it possible that they might be >> trying to prevent smaller companies from participating in the market by >> throwing up artificial barriers? >> >> >> >> All this talk of "fairness" overlooks the fact that it's more fair to have >> simple, transparent bidding and less bureaucracy. Smaller bidders can easily >> afford smaller chunks of numbers, and they benefit from the reduced >> administrative burden and delays associated with pointless and restrictive >> needs assessments. When I hear smaller ISPs who need addresses making Jason's >> arguments, I might take them seriously. Until then, no. >> >> >> >> --MM >> >> >> >> From: arin-ppml-bounces at arin.net < arin-ppml-bounces at arin.net > on behalf of >> Jason Schiller < jschiller at google.com > >> >> >> Sent: Thursday, February 18, 2016 3:11 PM >> To: Vaughn Thurman - Swift Systems >> Cc: ARIN PPML >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based >> evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks >> >> >> >> >> >> +1 to what MCTim, Owen, and Vaughn said. >> >> >> >> >> >> In general I oppose transfers with no need. >> >> >> >> >> >> If there are "networks in need of additional IPv4 addresses", surely they should >> be able to show this, in accord with long standing practice. >> >> >> >> >> >> I'd rather us not move to a situation which enables/encourages speculation and >> profit taking (or rent-seeking if you will) in re: IP resource distribution. >> >> >> >> >> >> I'd also rather not encourage one competitor in a business segment to be able to >> better stockpile addresses and for that to become a competitive advantage >> >> >> against other providers in the space. Additionally if this is done in a wide >> enough scale it can sufficiently lengthen wide spread IPv6 adoption. >> >> >> >> >> >> This policy would also allow for companies with the deepest pockets and the most >> profitable services to concentrate IPv4 space. I'm not sure that is more "fair" >> >> >> than the pre-existing framework for "fair". >> >> >> >> >> >> __Jason >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems < >> vaughn at swiftsystems.com > wrote: >> >> >> >> >> +1 >> >> Sent from my mobile device, please forgive brevity and typos. >> >> >> >> On Feb 18, 2016, at 2:16 PM, Owen DeLong < owen at delong.com > wrote: >> >> >> >> >> >> +1 ? McTim said it very well. >> >> >> >> >> >> Owen >> >> >> >> >> >> >> >> >> On Feb 18, 2016, at 10:34 , McTim < dogwallah at gmail.com > wrote: >> >> >> >> >> >> I am opposed. >> >> >> >> >> >> If there are " networks in need of additional IPv4 addresses", surely they >> should be able to show this, in accord with long standing practice. >> >> >> >> >> >> I'd rather us not move to a situation which enables/encourages speculation and >> profit taking (or rent-seeking if you will) in re: IP resource distribution. >> >> >> >> >> >> Regards, >> >> >> >> >> >> McTim >> >> >> >> >> >> >> >> >> On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer < lsawyer at gci.com > wrote: >> >> >> >> Good afternoon - >> >> Based on feedback from Montreal as well as internal discussions, I've reworked >> this policy. >> AC members and ARIN staff are looking for additional feedback, as well as your >> position in terms >> of supporting or opposing this draft policy. >> >> We'll be discussing this policy, as well as any feedback provided on this week's >> AC teleconference, >> so I'm very appreciative of your input. >> >> Thanks, >> >> Leif Sawyer >> Shepherd - ARIN-2015-9 >> >> NRPM section 8: https://www.arin.net/policy/nrpm.html#eight >> >> Most current draft policy text follows: >> -- >> >> Draft Policy ARIN-2015-9 >> Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 >> netblocks >> Original Date: 23 September 2015 >> Updated: 16 February, 2016 >> >> Problem statement: >> The current needs-based evaluation language in NRPM sections 8.2 and 8.3, >> regarding transfer of IPv4 >> netblocks from one organization to another, may cause a recipient organization >> to bypass the ARIN >> registry entirely in order to secure the needed IPv4 netblocks in a more timely >> fashion directly from the >> current holder. The result is that the data visible in ARIN registry may become >> more inaccurate over >> time. >> >> Policy statement: >> This proposal eliminates all needs-based evaluation language for sections 8.2 >> and 8.3, allowing >> transfers to be reflected in the database as they occur following an agreement >> of transfer from the >> resource provider to the recipient. >> >> Section 8.1 Principles: >> - Strike the fragment from the 3rd paragraph which reads >> ", based on justified need," >> so the resulting text reads >> "Number resources are issued to organizations, not to individuals representing >> those organizations." >> Section 8.2 Mergers and Acquisitions: >> - Change the 4th bullet from: >> "The resources to be transferred will be subject to ARIN policies." >> to: >> "The resources to be transferred will be subject to ARIN policies, excluding any >> policies related to needs-based justification." >> >> - Strike the final paragraph which begins "In the event that number resources of >> the combined organizations are no longer justified under ARIN policy ..." >> >> Section 8.3 Transfers between Specified Recipients within the ARIN Region: >> - Change the first bullet under "Conditions on 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: >> "The recipient must sign an RSA." >> >> - Change the 2nd bullet under "Conditions on recipient of the transfer" from: >> "The resources to be transferred will be subject to ARIN policies." >> to: >> "The resources to be transferred will be subject to ARIN policies, excluding any >> policies related to needs-based justification." >> >> Comments: >> a. Timetable for implementation: Immediate >> b. Anything else >> As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and ARIN) >> have now been >> exhausted, networks in need of additional IPv4 addresses have shifted away from >> the practice of >> receiving them from the RIR's resource pool. Instead, networks in need are >> seeking out current holders >> of IPv4 resources who are willing to transfer them in order to fulfill that >> need. Accordingly, the RIR's >> primary responsibility vis-?-vis IPv4 netblock governance has shifted from >> "allocation" to ensuring an >> accurate registry database. >> >> The RIPE registry can be used as a reference of one which has evolved over the >> past couple years to >> shift their focus away from conservation/allocation and towards database >> accuracy. IPv4 netblock >> transfers within that RIR consist merely of validating authenticity of the >> parties requesting a transfer. >> Provided the organizations meet the basic requirement of RIR membership, and >> that the transferring >> organization has the valid authority to request the transfer, the transaction >> completes without any >> "needs-based" review. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). >> Unsubscribe or manage 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 >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). >> Unsubscribe or manage 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. >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage 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 Fri Feb 19 00:28:44 2016 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 19 Feb 2016 05:28:44 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: <823499847.484118.1455857416654.JavaMail.zimbra@network1.net> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> <823499847.484118.1455857416654.JavaMail.zimbra@network1.net> Message-ID: Loosening up the policies is working fine in other regions. What justification do you really have to not do it here?? In case you don't know, brokers are doing a brisk business in IPv4 blocks outside of ARIN, and every time one sells the database gets less accurate. All of the arguments about cornering the market or whatever are not happening in other regions and there is no reason why our region is somehow different. With runout we now just have policies to prevent IPv4 runout that has already happened. Isn't it time for this Region to join the rest of the world we used to lead? 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: Randy Carpenter [mailto:rcarpen at network1.net] Sent: Thursday, February 18, 2016 11:50 PM To: Steven Ryerse Cc: ARIN PPML Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks So, you are saying that you need addresses, but can't justify it? I keep hearing the argument and it makes no sense. I manage the IP networks of a bunch of small ISPs. I have never had an issue with justifying their needs. There certainly are instances where it would be nice to have some more space to have more flexibility and for future needs. But, we can't justify the actual need, so we shouldn't get the space. Others have a need and can justify it, therefore they should be able to get it. Making it trivial to get space would lead to those who do *not* need it getting it because they can, which will reduce the amount of space available to those who actually need it. I oppose vehemently. thanks, -Randy ----- On Feb 18, 2016, at 11:07 PM, Steven Ryerse SRyerse at eclipse-networks.com wrote: > Milton is right! We are one of those small ISPs and the deck is > stacked against us on purpose by larger organizations. It is time to > move on and stop arranging the deck chairs on the IPv4 Titanic like > other regions have. It?s 2016 not 2001. I support this policy! > > > > > > > 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 ? > > > > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of Mueller, Milton L > Sent: Thursday, February 18, 2016 10:47 PM > To: Jason Schiller > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 > netblocks > > > > > > > > Really. Am I going to have to be the first to point out the irony of > Google employees complaining that companies with "deep pockets" and > "the most profitable services" will dominate the address market if we > make minor relaxations of need assessments? > > > > What's wrong with this picture? Think, folks. > > > > Isn't it obvious that companies like Google are in a very good > position to get the addresses they want - via less than transparent > market mechanisms such as options contracts and acquisitions? And > isn't it possible that they might be trying to prevent smaller > companies from participating in the market by throwing up artificial barriers? > > > > All this talk of "fairness" overlooks the fact that it's more fair to > have simple, transparent bidding and less bureaucracy. Smaller bidders > can easily afford smaller chunks of numbers, and they benefit from the > reduced administrative burden and delays associated with pointless and > restrictive needs assessments. When I hear smaller ISPs who need > addresses making Jason's arguments, I might take them seriously. Until then, no. > > > > --MM > > > > From: arin-ppml-bounces at arin.net < arin-ppml-bounces at arin.net > on > behalf of Jason Schiller < jschiller at google.com > > > > Sent: Thursday, February 18, 2016 3:11 PM > To: Vaughn Thurman - Swift Systems > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 > netblocks > > > > > > +1 to what MCTim, Owen, and Vaughn said. > > > > > > In general I oppose transfers with no need. > > > > > > If there are "networks in need of additional IPv4 addresses", surely > they should be able to show this, in accord with long standing practice. > > > > > > I'd rather us not move to a situation which enables/encourages > speculation and profit taking (or rent-seeking if you will) in re: IP resource distribution. > > > > > > I'd also rather not encourage one competitor in a business segment to > be able to better stockpile addresses and for that to become a > competitive advantage > > > against other providers in the space. Additionally if this is done in > a wide enough scale it can sufficiently lengthen wide spread IPv6 adoption. > > > > > > This policy would also allow for companies with the deepest pockets > and the most profitable services to concentrate IPv4 space. I'm not sure that is more "fair" > > > than the pre-existing framework for "fair". > > > > > > __Jason > > > > > > > > > > > > On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems < > vaughn at swiftsystems.com > wrote: > > > > > +1 > > Sent from my mobile device, please forgive brevity and typos. > > > > On Feb 18, 2016, at 2:16 PM, Owen DeLong < owen at delong.com > wrote: > > > > > > +1 ? McTim said it very well. > > > > > > Owen > > > > > > > > > On Feb 18, 2016, at 10:34 , McTim < dogwallah at gmail.com > wrote: > > > > > > I am opposed. > > > > > > If there are " networks in need of additional IPv4 addresses", surely > they should be able to show this, in accord with long standing practice. > > > > > > I'd rather us not move to a situation which enables/encourages > speculation and profit taking (or rent-seeking if you will) in re: IP resource distribution. > > > > > > Regards, > > > > > > McTim > > > > > > > > > On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer < lsawyer at gci.com > wrote: > > > > Good afternoon - > > Based on feedback from Montreal as well as internal discussions, I've > reworked this policy. > AC members and ARIN staff are looking for additional feedback, as well > as your position in terms of supporting or opposing this draft policy. > > We'll be discussing this policy, as well as any feedback provided on > this week's AC teleconference, so I'm very appreciative of your input. > > Thanks, > > Leif Sawyer > Shepherd - ARIN-2015-9 > > NRPM section 8: https://www.arin.net/policy/nrpm.html#eight > > Most current draft policy text follows: > -- > > Draft Policy ARIN-2015-9 > Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers > of IPv4 netblocks Original Date: 23 September 2015 > Updated: 16 February, 2016 > > Problem statement: > The current needs-based evaluation language in NRPM sections 8.2 and > 8.3, regarding transfer of IPv4 netblocks from one organization to > another, may cause a recipient organization to bypass the ARIN > registry entirely in order to secure the needed IPv4 netblocks in a > more timely fashion directly from the current holder. The result is > that the data visible in ARIN registry may become more inaccurate over > time. > > Policy statement: > This proposal eliminates all needs-based evaluation language for > sections 8.2 and 8.3, allowing transfers to be reflected in the > database as they occur following an agreement of transfer from the > resource provider to the recipient. > > Section 8.1 Principles: > - Strike the fragment from the 3rd paragraph which reads ", based on > justified need, " > so the resulting text reads > "Number resources are issued to organizations, not to individuals > representing those organizations." > Section 8.2 Mergers and Acquisitions: > - Change the 4th bullet from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, > excluding any policies related to needs-based justification." > > - Strike the final paragraph which begins "In the event that number > resources of the combined organizations are no longer justified under ARIN policy ..." > > Section 8.3 Transfers between Specified Recipients within the ARIN Region: > - Change the first bullet under "Conditions on 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: > "The recipient must sign an RSA." > > - Change the 2nd bullet under "Conditions on recipient of the transfer" from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, > excluding any policies related to needs-based justification." > > Comments: > a. Timetable for implementation: Immediate b. Anything else As the > "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and > ARIN) have now been exhausted, networks in need of additional IPv4 > addresses have shifted away from the practice of receiving them from > the RIR's resource pool. Instead, networks in need are seeking out > current holders of IPv4 resources who are willing to transfer them in > order to fulfill that need. Accordingly, the RIR's primary > responsibility vis-?-vis IPv4 netblock governance has shifted from > "allocation" to ensuring an accurate registry database. > > The RIPE registry can be used as a reference of one which has evolved > over the past couple years to shift their focus away from > conservation/allocation and towards database accuracy. IPv4 netblock > transfers within that RIR consist merely of validating authenticity of > the parties requesting a transfer. > Provided the organizations meet the basic requirement of RIR > membership, and that the transferring organization has the valid > authority to request the transfer, the transaction completes without > any "needs-based" review. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List ( ARIN-PPML at arin.net ). > Unsubscribe or manage 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 > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List ( ARIN-PPML at arin.net ). > Unsubscribe or manage 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. From narten at us.ibm.com Fri Feb 19 00:53:03 2016 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 19 Feb 2016 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201602190553.u1J5r3fN031107@rotala.raleigh.ibm.com> Total of 35 messages in the last 7 days. script run at: Fri Feb 19 00:53:03 EST 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 5.71% | 2 | 13.58% | 85199 | jschiller at google.com 2.86% | 1 | 9.76% | 61244 | sryerse at eclipse-networks.com 2.86% | 1 | 8.80% | 55175 | bjones at vt.edu 5.71% | 2 | 5.51% | 34555 | rcarpen at network1.net 5.71% | 2 | 5.08% | 31842 | dogwallah at gmail.com 5.71% | 2 | 3.64% | 22840 | jcurran at arin.net 5.71% | 2 | 3.52% | 22076 | snoble at sonn.com 5.71% | 2 | 3.36% | 21097 | droisman at softlayer.com 2.86% | 1 | 5.03% | 31521 | milton at gatech.edu 2.86% | 1 | 4.07% | 25549 | rjletts at uw.edu 2.86% | 1 | 3.94% | 24744 | rjacobs at pslightwave.com 2.86% | 1 | 3.70% | 23211 | gdiscovery at sympatico.ca 2.86% | 1 | 3.70% | 23209 | mike at iptrading.com 2.86% | 1 | 3.49% | 21898 | vaughn at swiftsystems.com 2.86% | 1 | 3.48% | 21820 | farmer at umn.edu 2.86% | 1 | 3.26% | 20451 | owen at delong.com 2.86% | 1 | 2.77% | 17350 | ron.baione at yahoo.com 2.86% | 1 | 1.56% | 9768 | josh at imaginenetworksllc.com 2.86% | 1 | 1.46% | 9141 | lsawyer at gci.com 2.86% | 1 | 1.22% | 7658 | lee at dilkie.com 2.86% | 1 | 1.19% | 7457 | mysidia at gmail.com 2.86% | 1 | 1.09% | 6833 | narten at us.ibm.com 2.86% | 1 | 1.08% | 6799 | hvgeekwtrvl at gmail.com 2.86% | 1 | 1.07% | 6705 | mwinters at edwardrose.com 2.86% | 1 | 0.98% | 6118 | ajs at anvilwalrusden.com 2.86% | 1 | 0.97% | 6107 | jim at reptiles.org 2.86% | 1 | 0.92% | 5776 | bill at herrin.us 2.86% | 1 | 0.90% | 5645 | info at arin.net 2.86% | 1 | 0.87% | 5479 | john at egh.com --------+------+--------+----------+------------------------ 100.00% | 35 |100.00% | 627267 | Total From mike at iptrading.com Fri Feb 19 10:49:00 2016 From: mike at iptrading.com (Mike Burns) Date: Fri, 19 Feb 2016 10:49:00 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 In-Reply-To: References: Message-ID: <003501d16b2d$0d0a8a70$271f9f50$@iptrading.com> The existence of your company and other "brokers" isn't evidence enough that people want to make money solely by buying and selling v4 resources? Methinks you fail to see the forest for the trees! Regards, McTim Hi McTim, I'm really not sure what you are saying above, but actually the existence of brokers like me is in fact evidence that people want to make money solely by buying and selling IPv4 addresses. Adding quotes around brokers doesn't really change that fact. As a poster who has for years made comments related to speculation, do you care to speculate yourself on the example of the RIPE registry? After all, if there has been a years-long pent-up demand to speculate in IPv4 addresses, surely there would be evidence of what you claim? Regards, Mike From dogwallah at gmail.com Fri Feb 19 12:16:32 2016 From: dogwallah at gmail.com (McTim) Date: Fri, 19 Feb 2016 12:16:32 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 In-Reply-To: <003501d16b2d$0d0a8a70$271f9f50$@iptrading.com> References: <003501d16b2d$0d0a8a70$271f9f50$@iptrading.com> Message-ID: On Fri, Feb 19, 2016 at 10:49 AM, Mike Burns wrote: > The existence of your company and other "brokers" isn't evidence enough that > people want to make money solely by buying and selling v4 resources? > > Methinks you fail to see the forest for the trees! > > Regards, > > McTim > > > Hi McTim, > > I'm really not sure what you are saying above, but actually the existence of > brokers like me is in fact evidence that people want to make money solely by > buying and selling IPv4 addresses. Adding quotes around brokers doesn't > really change that fact. > > As a poster who has for years made comments related to speculation, do you > care to speculate yourself on the example of the RIPE registry? After all, > if there has been a years-long pent-up demand to speculate in IPv4 > addresses, surely there would be evidence of what you claim? Of course, there has been speculation going on for years in the EU. Look at the top ten by country table near the bottom of this page: https://labs.ripe.net/Members/wilhelm/ipv4-transfers-in-the-ripe-ncc-service-region and ask yourself why one small country punches above its weight in exported v4. While these PI blocks were acquired within policy, it is clear that they were obtained for later resale, which is definition #2 below: spec?u?la?tion ?speky??l?SH(?)n/ noun 1. the forming of a theory or conjecture without firm evidence. "there has been widespread speculation that he plans to quit" 2. investment in stocks, property, or other ventures in the hope of gain but with the risk of loss. "the company's move into property speculation" So I am not in favor of removing restrictions on bad behaviour just because some have engaged in said behaviour in other regions. I am not saying this is fraudulent behaviour, but certainly speculative in nature and not in the best interests of the Internet community. That of course is my ideology showing, and I make no bones about it. I am a big fan of accuracy in public network information databases, which is why I authored "no reverse without assignment" in the AFRINIC region, so the whole "you don't care about registry accuracy' argument doesn't fly with me. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From jschiller at google.com Fri Feb 19 13:08:06 2016 From: jschiller at google.com (Jason Schiller) Date: Fri, 19 Feb 2016 13:08:06 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: <64759736.483998.1455856193822.JavaMail.zimbra@network1.net> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <64759736.483998.1455856193822.JavaMail.zimbra@network1.net> Message-ID: Removing barriers would allow companies with enough money to out right buy more than a two year supply of IPv4 addresses if they believed their likelihood of needing a longer time horizon justifies the cost. They could complete the transaction, transfer the address space in whole, and use as they desired over whatever time horizon they saw fit. This is different to a buying a future where money is paid to hold IPv4 addresses, and make them available for sipping from in two year (or less) sized increments under the ARIN transfer policy. This requires demonstrating efficient utilization of currently held resources, and then only permits a maximum transfer of two year supply, after which a new demonstration of efficient utilization of currently held resources, and a new two year window can be established. This second approach has much risk associated. Risk of the transfer source going bankrupt, risk of the transfer source breaching the contract, risk of the transfer source finding more favorable terms and transferring the remaining future to another party, risk of the transfer recipient having underutilization and have an inability to get additional resources, risk of transferring the resources to the wrong OrgID (realizing a new use case under one OrgID evaporates, and a different new use case appears under a different OrgID). As such, the inherent risk of a future will likely limit the spend. Reducing or eliminating this risk will encourage the behavior. This is different than just paying money to get unlimited use of IPv4 resources outside of ARIN policy, with no transfer, and only a letter of authority to route the space, a re-allocate or re-assignment SWIP, or a public comment indicating who has the right of use. This third approach has the risk of the source going bankrupt and the risk that the source could easily revoke the LOA, SWIP or public comment, and ask providers to not route the IP space. It has the added reputation risk that the recipient of the IP space is acting below board. As such risk is even greater than the previous case and will likewise have a greater limitation on the spend. The final case is renting of IPv4 space. This differs from the previous case in that the spend is ongoing (e.g. monthly or yearly). The risk is similar to the previous case except if the IPv4 addresses are revoked payment is stopped. While the recipient has not lost their future spend, they also may find themselves suddenly out of IPv4 space. With the difficulty of renumbering, they may find they are forced to pay predatory pricing from some period of time, and double rent new IP space while they number out of the old (excessively high cost) IPv4 space. Furthermore, if IPv4 space is not available for rent at a reasonable price, they will be locked in to paying an unreasonable price. Due to the uncertainty and possibility of lock in and predatory pricing I would argue this arrangement is even more risky than the previous arrangement if long term (think more than 2 years) use of IPv4 is desired. ___Jason On Thu, Feb 18, 2016 at 11:29 PM, Randy Carpenter wrote: > > Are you arguing that by removing the barriers that it would make it more > difficult for Google to get more addresses? If not, then the point is moot. > > > thanks, > -Randy > > > ----- On Feb 18, 2016, at 10:47 PM, Mueller, Milton L milton at gatech.edu > wrote: > > > Really. Am I going to have to be the first to point out the irony of > Google > > employees complaining that companies with "deep pockets" and "the most > > profitable services" will dominate the address market if we make minor > > relaxations of need assessments? > > > > > > > > > > What's wrong with this picture? Think, folks. > > > > > > > > > > Isn't it obvious that companies like Google are in a very good position > to get > > the addresses they want - via less than transparent market mechanisms > such as > > options contracts and acquisitions? And isn't it possible that they > might be > > trying to prevent smaller companies from participating in the market by > > throwing up artificial barriers? > > > > > > > > > > All this talk of "fairness" overlooks the fact that it's more fair to > have > > simple, transparent bidding and less bureaucracy. Smaller bidders can > easily > > afford smaller chunks of numbers, and they benefit from the reduced > > administrative burden and delays associated with pointless and > restrictive > > needs assessments. When I hear smaller ISPs who need addresses making > Jason's > > arguments, I might take them seriously. Until then, no. > > > > > > > > > > > > --MM > > > > > > > > > > From: arin-ppml-bounces at arin.net on behalf > of Jason > > Schiller > > Sent: Thursday, February 18, 2016 3:11 PM > > To: Vaughn Thurman - Swift Systems > > Cc: ARIN PPML > > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based > > evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks > > +1 to what MCTim, Owen, and Vaughn said. > > > > In general I oppose transfers with no need. > > > > If there are "networks in need of additional IPv4 addresses", surely > they should > > be able to show this, in accord with long standing practice. > > > > I'd rather us not move to a situation which enables/encourages > speculation and > > profit taking (or rent-seeking if you will) in re: IP resource > distribution. > > > > I'd also rather not encourage one competitor in a business segment to be > able to > > better stockpile addresses and for that to become a competitive advantage > > against other providers in the space. Additionally if this is done in a > wide > > enough scale it can sufficiently lengthen wide spread IPv6 adoption. > > > > This policy would also allow for companies with the deepest pockets and > the most > > profitable services to concentrate IPv4 space. I'm not sure that is more > "fair" > > than the pre-existing framework for "fair". > > > > __Jason > > > > > > > > On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems < > > vaughn at swiftsystems.com > wrote: > > > > > > > > +1 > > > > Sent from my mobile device, please forgive brevity and typos. > > > > On Feb 18, 2016, at 2:16 PM, Owen DeLong < owen at delong.com > wrote: > > > > > > > > > > +1 ? McTim said it very well. > > > > Owen > > > > > > > > > > On Feb 18, 2016, at 10:34 , McTim < dogwallah at gmail.com > wrote: > > > > I am opposed. > > > > If there are " networks in need of additional IPv4 addresses", surely > they > > should be able to show this, in accord with long standing practice. > > > > I'd rather us not move to a situation which enables/encourages > speculation and > > profit taking (or rent-seeking if you will) in re: IP resource > distribution. > > > > Regards, > > > > McTim > > > > > > On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer < lsawyer at gci.com > wrote: > > > > > > Good afternoon - > > > > Based on feedback from Montreal as well as internal discussions, I've > reworked > > this policy. > > AC members and ARIN staff are looking for additional feedback, as well > as your > > position in terms > > of supporting or opposing this draft policy. > > > > We'll be discussing this policy, as well as any feedback provided on > this week's > > AC teleconference, > > so I'm very appreciative of your input. > > > > Thanks, > > > > Leif Sawyer > > Shepherd - ARIN-2015-9 > > > > NRPM section 8: https://www.arin.net/policy/nrpm.html#eight > > > > Most current draft policy text follows: > > -- > > > > Draft Policy ARIN-2015-9 > > Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of > IPv4 > > netblocks > > Original Date: 23 September 2015 > > Updated: 16 February, 2016 > > > > Problem statement: > > The current needs-based evaluation language in NRPM sections 8.2 and 8.3, > > regarding transfer of IPv4 > > netblocks from one organization to another, may cause a recipient > organization > > to bypass the ARIN > > registry entirely in order to secure the needed IPv4 netblocks in a more > timely > > fashion directly from the > > current holder. The result is that the data visible in ARIN registry may > become > > more inaccurate over > > time. > > > > Policy statement: > > This proposal eliminates all needs-based evaluation language for > sections 8.2 > > and 8.3, allowing > > transfers to be reflected in the database as they occur following an > agreement > > of transfer from the > > resource provider to the recipient. > > > > Section 8.1 Principles: > > - Strike the fragment from the 3rd paragraph which reads > > ", based on justified need, " > > so the resulting text reads > > "Number resources are issued to organizations, not to individuals > representing > > those organizations." > > Section 8.2 Mergers and Acquisitions: > > - Change the 4th bullet from: > > "The resources to be transferred will be subject to ARIN policies." > > to: > > "The resources to be transferred will be subject to ARIN policies, > excluding any > > policies related to needs-based justification." > > > > - Strike the final paragraph which begins "In the event that number > resources of > > the combined organizations are no longer justified under ARIN policy ..." > > > > Section 8.3 Transfers between Specified Recipients within the ARIN > Region: > > - Change the first bullet under "Conditions on 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: > > "The recipient must sign an RSA." > > > > - Change the 2nd bullet under "Conditions on recipient of the transfer" > from: > > "The resources to be transferred will be subject to ARIN policies." > > to: > > "The resources to be transferred will be subject to ARIN policies, > excluding any > > policies related to needs-based justification." > > > > Comments: > > a. Timetable for implementation: Immediate > > b. Anything else > > As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, > and ARIN) > > have now been > > exhausted, networks in need of additional IPv4 addresses have shifted > away from > > the practice of > > receiving them from the RIR's resource pool. Instead, networks in need > are > > seeking out current holders > > of IPv4 resources who are willing to transfer them in order to fulfill > that > > need. Accordingly, the RIR's > > primary responsibility vis-?-vis IPv4 netblock governance has shifted > from > > "allocation" to ensuring an > > accurate registry database. > > > > The RIPE registry can be used as a reference of one which has evolved > over the > > past couple years to > > shift their focus away from conservation/allocation and towards database > > accuracy. IPv4 netblock > > transfers within that RIR consist merely of validating authenticity of > the > > parties requesting a transfer. > > Provided the organizations meet the basic requirement of RIR membership, > and > > that the transferring > > organization has the valid authority to request the transfer, the > transaction > > completes without any > > "needs-based" review. > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). > > Unsubscribe or manage 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 > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). > > Unsubscribe or manage 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. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcarpen at network1.net Fri Feb 19 13:40:10 2016 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 19 Feb 2016 13:40:10 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> <823499847.484118.1455857416654.JavaMail.zimbra@network1.net> Message-ID: <248377227.487901.1455907210853.JavaMail.zimbra@network1.net> That didn't really answer my question. If you have a philosophical argument, that is fine. What you said, however, is that the "desk is stacked against you on purpose by larger organizations." If that is the case, how is giving the larger organizations even more ability to control the market going to benefit you? thanks, -Randy ----- On Feb 19, 2016, at 12:28 AM, Steven Ryerse SRyerse at eclipse-networks.com wrote: > Loosening up the policies is working fine in other regions. What justification > do you really have to not do it here?? In case you don't know, brokers are > doing a brisk business in IPv4 blocks outside of ARIN, and every time one sells > the database gets less accurate. All of the arguments about cornering the > market or whatever are not happening in other regions and there is no reason > why our region is somehow different. > > With runout we now just have policies to prevent IPv4 runout that has already > happened. Isn't it time for this Region to join the rest of the world we used > to lead? > > > 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: Randy Carpenter [mailto:rcarpen at network1.net] > Sent: Thursday, February 18, 2016 11:50 PM > To: Steven Ryerse > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks > > > So, you are saying that you need addresses, but can't justify it? I keep hearing > the argument and it makes no sense. > > I manage the IP networks of a bunch of small ISPs. I have never had an issue > with justifying their needs. There certainly are instances where it would be > nice to have some more space to have more flexibility and for future needs. > But, we can't justify the actual need, so we shouldn't get the space. Others > have a need and can justify it, therefore they should be able to get it. > > Making it trivial to get space would lead to those who do *not* need it getting > it because they can, which will reduce the amount of space available to those > who actually need it. > > I oppose vehemently. > > thanks, > -Randy > > > ----- On Feb 18, 2016, at 11:07 PM, Steven Ryerse SRyerse at eclipse-networks.com > wrote: > >> Milton is right! We are one of those small ISPs and the deck is >> stacked against us on purpose by larger organizations. It is time to >> move on and stop arranging the deck chairs on the IPv4 Titanic like >> other regions have. It?s 2016 not 2001. I support this policy! >> >> >> >> >> >> >> 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 ? >> >> >> >> >> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >> On Behalf Of Mueller, Milton L >> Sent: Thursday, February 18, 2016 10:47 PM >> To: Jason Schiller >> Cc: ARIN PPML >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating >> needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 >> netblocks >> >> >> >> >> >> >> >> Really. Am I going to have to be the first to point out the irony of >> Google employees complaining that companies with "deep pockets" and >> "the most profitable services" will dominate the address market if we >> make minor relaxations of need assessments? >> >> >> >> What's wrong with this picture? Think, folks. >> >> >> >> Isn't it obvious that companies like Google are in a very good >> position to get the addresses they want - via less than transparent >> market mechanisms such as options contracts and acquisitions? And >> isn't it possible that they might be trying to prevent smaller >> companies from participating in the market by throwing up artificial barriers? >> >> >> >> All this talk of "fairness" overlooks the fact that it's more fair to >> have simple, transparent bidding and less bureaucracy. Smaller bidders >> can easily afford smaller chunks of numbers, and they benefit from the >> reduced administrative burden and delays associated with pointless and >> restrictive needs assessments. When I hear smaller ISPs who need >> addresses making Jason's arguments, I might take them seriously. Until then, no. >> >> >> >> --MM >> >> >> >> From: arin-ppml-bounces at arin.net < arin-ppml-bounces at arin.net > on >> behalf of Jason Schiller < jschiller at google.com > >> >> >> Sent: Thursday, February 18, 2016 3:11 PM >> To: Vaughn Thurman - Swift Systems >> Cc: ARIN PPML >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating >> needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 >> netblocks >> >> >> >> >> >> +1 to what MCTim, Owen, and Vaughn said. >> >> >> >> >> >> In general I oppose transfers with no need. >> >> >> >> >> >> If there are "networks in need of additional IPv4 addresses", surely >> they should be able to show this, in accord with long standing practice. >> >> >> >> >> >> I'd rather us not move to a situation which enables/encourages >> speculation and profit taking (or rent-seeking if you will) in re: IP resource >> distribution. >> >> >> >> >> >> I'd also rather not encourage one competitor in a business segment to >> be able to better stockpile addresses and for that to become a >> competitive advantage >> >> >> against other providers in the space. Additionally if this is done in >> a wide enough scale it can sufficiently lengthen wide spread IPv6 adoption. >> >> >> >> >> >> This policy would also allow for companies with the deepest pockets >> and the most profitable services to concentrate IPv4 space. I'm not sure that is >> more "fair" >> >> >> than the pre-existing framework for "fair". >> >> >> >> >> >> __Jason >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems < >> vaughn at swiftsystems.com > wrote: >> >> >> >> >> +1 >> >> Sent from my mobile device, please forgive brevity and typos. >> >> >> >> On Feb 18, 2016, at 2:16 PM, Owen DeLong < owen at delong.com > wrote: >> >> >> >> >> >> +1 ? McTim said it very well. >> >> >> >> >> >> Owen >> >> >> >> >> >> >> >> >> On Feb 18, 2016, at 10:34 , McTim < dogwallah at gmail.com > wrote: >> >> >> >> >> >> I am opposed. >> >> >> >> >> >> If there are " networks in need of additional IPv4 addresses", surely >> they should be able to show this, in accord with long standing practice. >> >> >> >> >> >> I'd rather us not move to a situation which enables/encourages >> speculation and profit taking (or rent-seeking if you will) in re: IP resource >> distribution. >> >> >> >> >> >> Regards, >> >> >> >> >> >> McTim >> >> >> >> >> >> >> >> >> On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer < lsawyer at gci.com > wrote: >> >> >> >> Good afternoon - >> >> Based on feedback from Montreal as well as internal discussions, I've >> reworked this policy. >> AC members and ARIN staff are looking for additional feedback, as well >> as your position in terms of supporting or opposing this draft policy. >> >> We'll be discussing this policy, as well as any feedback provided on >> this week's AC teleconference, so I'm very appreciative of your input. >> >> Thanks, >> >> Leif Sawyer >> Shepherd - ARIN-2015-9 >> >> NRPM section 8: https://www.arin.net/policy/nrpm.html#eight >> >> Most current draft policy text follows: >> -- >> >> Draft Policy ARIN-2015-9 >> Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers >> of IPv4 netblocks Original Date: 23 September 2015 >> Updated: 16 February, 2016 >> >> Problem statement: >> The current needs-based evaluation language in NRPM sections 8.2 and >> 8.3, regarding transfer of IPv4 netblocks from one organization to >> another, may cause a recipient organization to bypass the ARIN >> registry entirely in order to secure the needed IPv4 netblocks in a >> more timely fashion directly from the current holder. The result is >> that the data visible in ARIN registry may become more inaccurate over >> time. >> >> Policy statement: >> This proposal eliminates all needs-based evaluation language for >> sections 8.2 and 8.3, allowing transfers to be reflected in the >> database as they occur following an agreement of transfer from the >> resource provider to the recipient. >> >> Section 8.1 Principles: >> - Strike the fragment from the 3rd paragraph which reads ", based on >> justified need, " >> so the resulting text reads >> "Number resources are issued to organizations, not to individuals >> representing those organizations." >> Section 8.2 Mergers and Acquisitions: >> - Change the 4th bullet from: >> "The resources to be transferred will be subject to ARIN policies." >> to: >> "The resources to be transferred will be subject to ARIN policies, >> excluding any policies related to needs-based justification." >> >> - Strike the final paragraph which begins "In the event that number >> resources of the combined organizations are no longer justified under ARIN >> policy ..." >> >> Section 8.3 Transfers between Specified Recipients within the ARIN Region: >> - Change the first bullet under "Conditions on 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: >> "The recipient must sign an RSA." >> >> - Change the 2nd bullet under "Conditions on recipient of the transfer" from: >> "The resources to be transferred will be subject to ARIN policies." >> to: >> "The resources to be transferred will be subject to ARIN policies, >> excluding any policies related to needs-based justification." >> >> Comments: >> a. Timetable for implementation: Immediate b. Anything else As the >> "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and >> ARIN) have now been exhausted, networks in need of additional IPv4 >> addresses have shifted away from the practice of receiving them from >> the RIR's resource pool. Instead, networks in need are seeking out >> current holders of IPv4 resources who are willing to transfer them in >> order to fulfill that need. Accordingly, the RIR's primary >> responsibility vis-?-vis IPv4 netblock governance has shifted from >> "allocation" to ensuring an accurate registry database. >> >> The RIPE registry can be used as a reference of one which has evolved >> over the past couple years to shift their focus away from >> conservation/allocation and towards database accuracy. IPv4 netblock >> transfers within that RIR consist merely of validating authenticity of >> the parties requesting a transfer. >> Provided the organizations meet the basic requirement of RIR >> membership, and that the transferring organization has the valid >> authority to request the transfer, the transaction completes without >> any "needs-based" review. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List ( ARIN-PPML at arin.net ). >> Unsubscribe or manage 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 >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List ( ARIN-PPML at arin.net ). >> Unsubscribe or manage 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. From jschiller at google.com Fri Feb 19 13:43:02 2016 From: jschiller at google.com (Jason Schiller) Date: Fri, 19 Feb 2016 13:43:02 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: <56C6A602.8050303@cameron.net> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> <823499847.484118.1455857416654.JavaMail.zimbra@network1.net> <56C6A602.8050303@cameron.net> Message-ID: Paul, Lets assume that you are using a /22 and a /23 from your upstream provider, and they now want it back. Lets also assume that you have good documentation to show how you are using that Provider Aggregatable IP space, and 80+% is in use. You could then (if you don't already have an ARIN OrgID) use your US or Canadian, or Caribbean Government issued business tax ID number to establish an OrgID. You could then get ARIN pre-approval for transfer of a /22 and a /23. (You may be able to justify more based on two year growth projections). Once approved to can complete as many transfers of IPv4 space up to the amount approved within a two years from when the approval is granted. Each discrete transfer will cost you $500 (in addition to whatever the IP space costs you). At any point in the process you can show all of your currently held resources are above 80% and get a new pre-approval for a two year supply. E.g. you are using a /22 and a /23 which you plan to return. You can show you used you most recent /23 over the last two years, and you expect future continued growth. You can likely get a /21. Then in six months time you can show 80+% utilization of the /21. That means the new /23 was used up in 6 months. If future growth is anticipated at the same rate a two year supply would be a /21. You could likely get pre-approval for a /21 and have up to two years to complete one or more transfer equalling up to a /21. If it takes longer than two years, your pre-approval expires, and you have to once again show 80% utilization and a new two year growth projection. The OrgID has to be with your legal entity. ARIN does sometime fix OrgIDs when it is a simple change as in we are "Company, Inc." not "Company Incorporated"... this was clearly a mistake when we made the org, or if you can show M&A activity (typically legal paperwork of public record filed with the secretary of the state where the entity was created or the surviving legal entity from the M&A) and the direct ARIN issued resources are used at 80+% then they will update transfer the resources to the newly formed (correct) OrgID On Fri, Feb 19, 2016 at 12:20 AM, Paul wrote: > I have a question. Our small ISP company is losing a /22 and a /23 we were > reallocated years > ago. The company sold and now is requiring us to give these back. This was > unexpected. We did not see that coming and by the time we got the news and > started > the process to directly acquire IPv4 ARIN was out. > > My question is: if we justify a certain IP Block maybe a /21 or /22. Is it > true if we acquire > them a /24 at a time we have to wait 12 months before we can get the next > transfer > approved? and have to pay another $500 for each /24 we get transferred in. > So if we are lucky to find a legacy owner, I have been told by ARIN that > they need proof of the company > from the secretary of state. Back in the 80's and 90's fictitious names > did not have to > be registered by most states especially in the case of a sole > proprietorship or a > small corporation using an unregistered DBA. This seems to be the case of > acquiring > and trying to transfer legacy IP Blocks in to ARIN. We were required to > get a new ORG-ID > because the dba we were using at the time of the re-allocation wasn't > registered with the state. > It was perfectly legal at the time the ORG-ID was issued. This is the > biggest obstacle > I have had. I am scared to acquire Legacy Resources because ARIN threatens > to > claw them back if I try to transfer and register them. The big companies > have lawyers that > can fight the ARIN policies and win, we do not. > > If I am misunderstanding the transfer system please clue me in. This is > extremely > expensive for a small ISP like us. I see both sides of the proposal as > detrimental > to small ISP's. We are currently having to re-IP 8 /24's to a /27. Very > hard to do! > > I want what ever it takes to transfer in resources up to the justification > amount. > It might take 1 year maybe 10 years and not be charged on every /24 up to > our justification.. > > IPv6 direct allocations were supposed to get a $500 direct allocation by > now. > A $500 direct allocation of IPv6 would help but we have to find enough IPv4 > to stay in business. Currently our fiber provider can provide IPv6 to our > rural area. > > Please help me understand the bureaucracy that ARIN is? > > Thanks > Paul McNary > McNary Computer Services > > > > On 2/18/2016 10:50 PM, Randy Carpenter wrote: > > So, you are saying that you need addresses, but can't justify it? I keep hearing the argument and it makes no sense. > > I manage the IP networks of a bunch of small ISPs. I have never had an issue with justifying their needs. There certainly are instances where it would be nice to have some more space to have more flexibility and for future needs. But, we can't justify the actual need, so we shouldn't get the space. Others have a need and can justify it, therefore they should be able to get it. > > Making it trivial to get space would lead to those who do *not* need it getting it because they can, which will reduce the amount of space available to those who actually need it. > > I oppose vehemently. > > thanks, > -Randy > > > ----- On Feb 18, 2016, at 11:07 PM, Steven Ryerse SRyerse at eclipse-networks.com wrote: > > > Milton is right! We are one of those small ISPs and the deck is stacked against > us on purpose by larger organizations. It is time to move on and stop arranging > the deck chairs on the IPv4 Titanic like other regions have. It?s 2016 not > 2001. I support this policy! > > > > > > > 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 ? > > > > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net ] On Behalf > Of Mueller, Milton L > Sent: Thursday, February 18, 2016 10:47 PM > To: Jason Schiller > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks > > > > > > > > Really. Am I going to have to be the first to point out the irony of Google > employees complaining that companies with "deep pockets" and "the most > profitable services" will dominate the address market if we make minor > relaxations of need assessments? > > > > What's wrong with this picture? Think, folks. > > > > Isn't it obvious that companies like Google are in a very good position to get > the addresses they want - via less than transparent market mechanisms such as > options contracts and acquisitions? And isn't it possible that they might be > trying to prevent smaller companies from participating in the market by > throwing up artificial barriers? > > > > All this talk of "fairness" overlooks the fact that it's more fair to have > simple, transparent bidding and less bureaucracy. Smaller bidders can easily > afford smaller chunks of numbers, and they benefit from the reduced > administrative burden and delays associated with pointless and restrictive > needs assessments. When I hear smaller ISPs who need addresses making Jason's > arguments, I might take them seriously. Until then, no. > > > > --MM > > > > From: arin-ppml-bounces at arin.net < arin-ppml-bounces at arin.net > on behalf of > Jason Schiller < jschiller at google.com > > > > Sent: Thursday, February 18, 2016 3:11 PM > To: Vaughn Thurman - Swift Systems > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks > > > > > > +1 to what MCTim, Owen, and Vaughn said. > > > > > > In general I oppose transfers with no need. > > > > > > If there are "networks in need of additional IPv4 addresses", surely they should > be able to show this, in accord with long standing practice. > > > > > > I'd rather us not move to a situation which enables/encourages speculation and > profit taking (or rent-seeking if you will) in re: IP resource distribution. > > > > > > I'd also rather not encourage one competitor in a business segment to be able to > better stockpile addresses and for that to become a competitive advantage > > > against other providers in the space. Additionally if this is done in a wide > enough scale it can sufficiently lengthen wide spread IPv6 adoption. > > > > > > This policy would also allow for companies with the deepest pockets and the most > profitable services to concentrate IPv4 space. I'm not sure that is more "fair" > > > than the pre-existing framework for "fair". > > > > > > __Jason > > > > > > > > > > > > On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems wrote: > > > > > +1 > > Sent from my mobile device, please forgive brevity and typos. > > > > On Feb 18, 2016, at 2:16 PM, Owen DeLong < owen at delong.com > wrote: > > > > > > +1 ? McTim said it very well. > > > > > > Owen > > > > > > > > > On Feb 18, 2016, at 10:34 , McTim < dogwallah at gmail.com > wrote: > > > > > > I am opposed. > > > > > > If there are " networks in need of additional IPv4 addresses", surely they > should be able to show this, in accord with long standing practice. > > > > > > I'd rather us not move to a situation which enables/encourages speculation and > profit taking (or rent-seeking if you will) in re: IP resource distribution. > > > > > > Regards, > > > > > > McTim > > > > > > > > > On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer < lsawyer at gci.com > wrote: > > > > Good afternoon - > > Based on feedback from Montreal as well as internal discussions, I've reworked > this policy. > AC members and ARIN staff are looking for additional feedback, as well as your > position in terms > of supporting or opposing this draft policy. > > We'll be discussing this policy, as well as any feedback provided on this week's > AC teleconference, > so I'm very appreciative of your input. > > Thanks, > > Leif Sawyer > Shepherd - ARIN-2015-9 > > NRPM section 8: https://www.arin.net/policy/nrpm.html#eight > > Most current draft policy text follows: > -- > > Draft Policy ARIN-2015-9 > Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 > netblocks > Original Date: 23 September 2015 > Updated: 16 February, 2016 > > Problem statement: > The current needs-based evaluation language in NRPM sections 8.2 and 8.3, > regarding transfer of IPv4 > netblocks from one organization to another, may cause a recipient organization > to bypass the ARIN > registry entirely in order to secure the needed IPv4 netblocks in a more timely > fashion directly from the > current holder. The result is that the data visible in ARIN registry may become > more inaccurate over > time. > > Policy statement: > This proposal eliminates all needs-based evaluation language for sections 8.2 > and 8.3, allowing > transfers to be reflected in the database as they occur following an agreement > of transfer from the > resource provider to the recipient. > > Section 8.1 Principles: > - Strike the fragment from the 3rd paragraph which reads > ", based on justified need, " > so the resulting text reads > "Number resources are issued to organizations, not to individuals representing > those organizations." > Section 8.2 Mergers and Acquisitions: > - Change the 4th bullet from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, excluding any > policies related to needs-based justification." > > - Strike the final paragraph which begins "In the event that number resources of > the combined organizations are no longer justified under ARIN policy ..." > > Section 8.3 Transfers between Specified Recipients within the ARIN Region: > - Change the first bullet under "Conditions on 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: > "The recipient must sign an RSA." > > - Change the 2nd bullet under "Conditions on recipient of the transfer" from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, excluding any > policies related to needs-based justification." > > Comments: > a. Timetable for implementation: Immediate > b. Anything else > As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and ARIN) > have now been > exhausted, networks in need of additional IPv4 addresses have shifted away from > the practice of > receiving them from the RIR's resource pool. Instead, networks in need are > seeking out current holders > of IPv4 resources who are willing to transfer them in order to fulfill that > need. Accordingly, the RIR's > primary responsibility vis-?-vis IPv4 netblock governance has shifted from > "allocation" to ensuring an > accurate registry database. > > The RIPE registry can be used as a reference of one which has evolved over the > past couple years to > shift their focus away from conservation/allocation and towards database > accuracy. IPv4 netblock > transfers within that RIR consist merely of validating authenticity of the > parties requesting a transfer. > Provided the organizations meet the basic requirement of RIR membership, and > that the transferring > organization has the valid authority to request the transfer, the transaction > completes without any > "needs-based" review. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). > Unsubscribe or manage 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 > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). > Unsubscribe or manage 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. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at:http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Fri Feb 19 14:01:44 2016 From: mike at iptrading.com (Mike Burns) Date: Fri, 19 Feb 2016 14:01:44 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 In-Reply-To: References: <003501d16b2d$0d0a8a70$271f9f50$@iptrading.com> Message-ID: <009b01d16b47$f9683060$ec389120$@iptrading.com> Hi McTim, https://labs.ripe.net/Members/wilhelm/ipv4-transfers-in-the-ripe-ncc-service-region That RIPE labs report is not evidence of the speculation we are considering in the context of the current policy. You are opposing this policy because you think it will enable/encourage speculation in the transfer market. This policy is related to transfers, not to over-allocations made under the old regime. This particular country's addresses were not purchased on the transfer market. They were accumulated prior to exhaust under the then-extant needs-based allocations policies, aka longstanding policies, aka proper stewardship. And then (somewhat) after exhaust via gaming the "/22 for new ISPs" rule at RIPE. This is not evidence of speculation on the transfer market, it is merely the evidence that market forces act on this resource already. They can induce corruption, rules-avoidance, oh yes indeed they can. But as I sort of said, that genie is out of the bottle. We should be attentive related to evidence of this kind of speculation involving allocations from the final free pool in AFRINIC, I am sure we both agree on that. Changing the rules about needs-testing paid transfers is not going to enable/encourage or disable/discourage profit and rent-seeking. Profit and rent-seeking is allowed under current policy and will happen regardless of policy anyway. That won't be significantly changed by maintaining needs tests for ARIN transfers. After all, if you can't justify, become a RIPE member and buy RIPE addresses. It's as simple as that. Anybody can do it, plus they get a /22 for their trouble! And then they can buy RIPE addresses without demonstrating need. So what is the point of retaining this needs test in the current environment? We can't stop market forces from acting on IPv4 addresses, but we should understand that these forces can also induce the movement of unused resources into productive use. In fact that is the natural thing. We have brokered the sale of so many blocks which were unused for decades. This is evidence of this positive effect of the market. Now since I have admitted that market forces can lead to corruption and rules-avoidance, can you acknowledge that bringing dusty old blocks back into productive use is a positive effect of the market? One ideologue to another ? ;-) Anyway I guess we both understand each other's positions by now, so I will just register my support for the policy and step off the soapbox. Regards, Mike PS made it to the end without mentioning Whois accuracy! -----Original Message----- From: McTim [mailto:dogwallah at gmail.com] Sent: Friday, February 19, 2016 12:17 PM To: Mike Burns Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 On Fri, Feb 19, 2016 at 10:49 AM, Mike Burns wrote: > The existence of your company and other "brokers" isn't evidence > enough that people want to make money solely by buying and selling v4 resources? > > Methinks you fail to see the forest for the trees! > > Regards, > > McTim > >> Hi McTim, > > I'm really not sure what you are saying above, but actually the > existence of brokers like me is in fact evidence that people want to > make money solely by buying and selling IPv4 addresses. Of course, there has been speculation going on for years in the EU. Look at the top ten by country table near the bottom of this page: https://labs.ripe.net/Members/wilhelm/ipv4-transfers-in-the-ripe-ncc-service-region and ask yourself why one small country punches above its weight in exported v4. While these PI blocks were acquired within policy, it is clear that they were obtained for later resale, which is definition #2 below: spec?u?la?tion ?speky??l?SH(?)n/ noun 1. the forming of a theory or conjecture without firm evidence. "there has been widespread speculation that he plans to quit" 2. investment in stocks, property, or other ventures in the hope of gain but with the risk of loss. "the company's move into property speculation" So I am not in favor of removing restrictions on bad behaviour just because some have engaged in said behaviour in other regions. I am not saying this is fraudulent behaviour, but certainly speculative in nature and not in the best interests of the Internet community. That of course is my ideology showing, and I make no bones about it. I am a big fan of accuracy in public network information databases, which is why I authored "no reverse without assignment" in the AFRINIC region, so the whole "you don't care about registry accuracy' argument doesn't fly with me. -- Cheers, McTim From bjones at vt.edu Fri Feb 19 14:11:48 2016 From: bjones at vt.edu (Brian Jones) Date: Fri, 19 Feb 2016 14:11:48 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: References: Message-ID: Support. -- Brian On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer wrote: > Good afternoon - > > Based on feedback from Montreal as well as internal discussions, I've > reworked this policy. > AC members and ARIN staff are looking for additional feedback, as well as > your position in terms > of supporting or opposing this draft policy. > > We'll be discussing this policy, as well as any feedback provided on > this week's AC teleconference, > so I'm very appreciative of your input. > > Thanks, > > Leif Sawyer > Shepherd - ARIN-2015-9 > > NRPM section 8: https://www.arin.net/policy/nrpm.html#eight > > Most current draft policy text follows: > -- > > Draft Policy ARIN-2015-9 > Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers > of IPv4 netblocks > Original Date: 23 September 2015 > Updated: 16 February, 2016 > > Problem statement: > The current needs-based evaluation language in NRPM sections 8.2 and 8.3, > regarding transfer of IPv4 > netblocks from one organization to another, may cause a recipient > organization to bypass the ARIN > registry entirely in order to secure the needed IPv4 netblocks in a more > timely fashion directly from the > current holder. The result is that the data visible in ARIN registry may > become more inaccurate over > time. > > Policy statement: > This proposal eliminates all needs-based evaluation language for sections > 8.2 and 8.3, allowing > transfers to be reflected in the database as they occur following an > agreement of transfer from the > resource provider to the recipient. > > Section 8.1 Principles: > - Strike the fragment from the 3rd paragraph which reads > ", based on justified need, " > so the resulting text reads > "Number resources are issued to organizations, not to individuals > representing those organizations." > Section 8.2 Mergers and Acquisitions: > - Change the 4th bullet from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, > excluding any policies related to needs-based justification." > > - Strike the final paragraph which begins "In the event that number > resources of the combined organizations are no longer justified under ARIN > policy ..." > > Section 8.3 Transfers between Specified Recipients within the ARIN Region: > - Change the first bullet under "Conditions on 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: > "The recipient must sign an RSA." > > - Change the 2nd bullet under "Conditions on recipient of the transfer" > from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, > excluding any policies related to needs-based justification." > > Comments: > a. Timetable for implementation: Immediate > b. Anything else > As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and > ARIN) have now been > exhausted, networks in need of additional IPv4 addresses have shifted away > from the practice of > receiving them from the RIR's resource pool. Instead, networks in need are > seeking out current holders > of IPv4 resources who are willing to transfer them in order to fulfill > that need. Accordingly, the RIR's > primary responsibility vis-?-vis IPv4 netblock governance has shifted from > "allocation" to ensuring an > accurate registry database. > > The RIPE registry can be used as a reference of one which has evolved over > the past couple years to > shift their focus away from conservation/allocation and towards database > accuracy. IPv4 netblock > transfers within that RIR consist merely of validating authenticity of the > parties requesting a transfer. > Provided the organizations meet the basic requirement of RIR membership, > and that the transferring > organization has the valid authority to request the transfer, the > transaction completes without any > "needs-based" review. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 Fri Feb 19 16:05:29 2016 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 19 Feb 2016 21:05:29 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <64759736.483998.1455856193822.JavaMail.zimbra@network1.net> Message-ID: <4c441ed1455143799ad02787e79f9120@eclipse-networks.com> If ARIN does not have the resources to allocate because of runout, how pray tell can an ARIN policy be used to corner the market? You can?t get blood out of a turnip. There is nothing to stop someone from buying a Legacy block completely outside of ARIN now if they choose to do that. We know that current ARIN policies are not stopping brokers from doing this - as there is a brisk business of blocks being traded in one way or another. You are just rearranging deck chairs on the Titanic which has already sunk and is already at the bottom of the sea. I wonder if the fish down there really care where those chairs are arranged? The common sense thing to do would be to modify ARINs policies to encourage all transactions to go thru ARIN which would lead to more supply for everyone. This would be in line with ARIN?s mission to further the Internet. Unfortunately common sense rarely prevails in this community. 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 Jason Schiller Sent: Friday, February 19, 2016 1:08 PM To: Randy Carpenter Cc: ARIN PPML Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks Removing barriers would allow companies with enough money to out right buy more than a two year supply of IPv4 addresses if they believed their likelihood of needing a longer time horizon justifies the cost. They could complete the transaction, transfer the address space in whole, and use as they desired over whatever time horizon they saw fit. This is different to a buying a future where money is paid to hold IPv4 addresses, and make them available for sipping from in two year (or less) sized increments under the ARIN transfer policy. This requires demonstrating efficient utilization of currently held resources, and then only permits a maximum transfer of two year supply, after which a new demonstration of efficient utilization of currently held resources, and a new two year window can be established. This second approach has much risk associated. Risk of the transfer source going bankrupt, risk of the transfer source breaching the contract, risk of the transfer source finding more favorable terms and transferring the remaining future to another party, risk of the transfer recipient having underutilization and have an inability to get additional resources, risk of transferring the resources to the wrong OrgID (realizing a new use case under one OrgID evaporates, and a different new use case appears under a different OrgID). As such, the inherent risk of a future will likely limit the spend. Reducing or eliminating this risk will encourage the behavior. This is different than just paying money to get unlimited use of IPv4 resources outside of ARIN policy, with no transfer, and only a letter of authority to route the space, a re-allocate or re-assignment SWIP, or a public comment indicating who has the right of use. This third approach has the risk of the source going bankrupt and the risk that the source could easily revoke the LOA, SWIP or public comment, and ask providers to not route the IP space. It has the added reputation risk that the recipient of the IP space is acting below board. As such risk is even greater than the previous case and will likewise have a greater limitation on the spend. The final case is renting of IPv4 space. This differs from the previous case in that the spend is ongoing (e.g. monthly or yearly). The risk is similar to the previous case except if the IPv4 addresses are revoked payment is stopped. While the recipient has not lost their future spend, they also may find themselves suddenly out of IPv4 space. With the difficulty of renumbering, they may find they are forced to pay predatory pricing from some period of time, and double rent new IP space while they number out of the old (excessively high cost) IPv4 space. Furthermore, if IPv4 space is not available for rent at a reasonable price, they will be locked in to paying an unreasonable price. Due to the uncertainty and possibility of lock in and predatory pricing I would argue this arrangement is even more risky than the previous arrangement if long term (think more than 2 years) use of IPv4 is desired. ___Jason On Thu, Feb 18, 2016 at 11:29 PM, Randy Carpenter > wrote: Are you arguing that by removing the barriers that it would make it more difficult for Google to get more addresses? If not, then the point is moot. thanks, -Randy ----- On Feb 18, 2016, at 10:47 PM, Mueller, Milton L milton at gatech.edu wrote: > Really. Am I going to have to be the first to point out the irony of Google > employees complaining that companies with "deep pockets" and "the most > profitable services" will dominate the address market if we make minor > relaxations of need assessments? > > > > > What's wrong with this picture? Think, folks. > > > > > Isn't it obvious that companies like Google are in a very good position to get > the addresses they want - via less than transparent market mechanisms such as > options contracts and acquisitions? And isn't it possible that they might be > trying to prevent smaller companies from participating in the market by > throwing up artificial barriers? > > > > > All this talk of "fairness" overlooks the fact that it's more fair to have > simple, transparent bidding and less bureaucracy. Smaller bidders can easily > afford smaller chunks of numbers, and they benefit from the reduced > administrative burden and delays associated with pointless and restrictive > needs assessments. When I hear smaller ISPs who need addresses making Jason's > arguments, I might take them seriously. Until then, no. > > > > > > --MM > > > > > From: arin-ppml-bounces at arin.net > on behalf of Jason > Schiller > > Sent: Thursday, February 18, 2016 3:11 PM > To: Vaughn Thurman - Swift Systems > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks > +1 to what MCTim, Owen, and Vaughn said. > > In general I oppose transfers with no need. > > If there are "networks in need of additional IPv4 addresses", surely they should > be able to show this, in accord with long standing practice. > > I'd rather us not move to a situation which enables/encourages speculation and > profit taking (or rent-seeking if you will) in re: IP resource distribution. > > I'd also rather not encourage one competitor in a business segment to be able to > better stockpile addresses and for that to become a competitive advantage > against other providers in the space. Additionally if this is done in a wide > enough scale it can sufficiently lengthen wide spread IPv6 adoption. > > This policy would also allow for companies with the deepest pockets and the most > profitable services to concentrate IPv4 space. I'm not sure that is more "fair" > than the pre-existing framework for "fair". > > __Jason > > > > On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems < > vaughn at swiftsystems.com > wrote: > > > > +1 > > Sent from my mobile device, please forgive brevity and typos. > > On Feb 18, 2016, at 2:16 PM, Owen DeLong < owen at delong.com > wrote: > > > > > +1 ? McTim said it very well. > > Owen > > > > > On Feb 18, 2016, at 10:34 , McTim < dogwallah at gmail.com > wrote: > > I am opposed. > > If there are " networks in need of additional IPv4 addresses", surely they > should be able to show this, in accord with long standing practice. > > I'd rather us not move to a situation which enables/encourages speculation and > profit taking (or rent-seeking if you will) in re: IP resource distribution. > > Regards, > > McTim > > > On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer < lsawyer at gci.com > wrote: > > > Good afternoon - > > Based on feedback from Montreal as well as internal discussions, I've reworked > this policy. > AC members and ARIN staff are looking for additional feedback, as well as your > position in terms > of supporting or opposing this draft policy. > > We'll be discussing this policy, as well as any feedback provided on this week's > AC teleconference, > so I'm very appreciative of your input. > > Thanks, > > Leif Sawyer > Shepherd - ARIN-2015-9 > > NRPM section 8: https://www.arin.net/policy/nrpm.html#eight > > Most current draft policy text follows: > -- > > Draft Policy ARIN-2015-9 > Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 > netblocks > Original Date: 23 September 2015 > Updated: 16 February, 2016 > > Problem statement: > The current needs-based evaluation language in NRPM sections 8.2 and 8.3, > regarding transfer of IPv4 > netblocks from one organization to another, may cause a recipient organization > to bypass the ARIN > registry entirely in order to secure the needed IPv4 netblocks in a more timely > fashion directly from the > current holder. The result is that the data visible in ARIN registry may become > more inaccurate over > time. > > Policy statement: > This proposal eliminates all needs-based evaluation language for sections 8.2 > and 8.3, allowing > transfers to be reflected in the database as they occur following an agreement > of transfer from the > resource provider to the recipient. > > Section 8.1 Principles: > - Strike the fragment from the 3rd paragraph which reads > ", based on justified need, " > so the resulting text reads > "Number resources are issued to organizations, not to individuals representing > those organizations." > Section 8.2 Mergers and Acquisitions: > - Change the 4th bullet from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, excluding any > policies related to needs-based justification." > > - Strike the final paragraph which begins "In the event that number resources of > the combined organizations are no longer justified under ARIN policy ..." > > Section 8.3 Transfers between Specified Recipients within the ARIN Region: > - Change the first bullet under "Conditions on 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: > "The recipient must sign an RSA." > > - Change the 2nd bullet under "Conditions on recipient of the transfer" from: > "The resources to be transferred will be subject to ARIN policies." > to: > "The resources to be transferred will be subject to ARIN policies, excluding any > policies related to needs-based justification." > > Comments: > a. Timetable for implementation: Immediate > b. Anything else > As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and ARIN) > have now been > exhausted, networks in need of additional IPv4 addresses have shifted away from > the practice of > receiving them from the RIR's resource pool. Instead, networks in need are > seeking out current holders > of IPv4 resources who are willing to transfer them in order to fulfill that > need. Accordingly, the RIR's > primary responsibility vis-?-vis IPv4 netblock governance has shifted from > "allocation" to ensuring an > accurate registry database. > > The RIPE registry can be used as a reference of one which has evolved over the > past couple years to > shift their focus away from conservation/allocation and towards database > accuracy. IPv4 netblock > transfers within that RIR consist merely of validating authenticity of the > parties requesting a transfer. > Provided the organizations meet the basic requirement of RIR membership, and > that the transferring > organization has the valid authority to request the transfer, the transaction > completes without any > "needs-based" review. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). > Unsubscribe or manage 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 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). > Unsubscribe or manage 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. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage 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: 1468 bytes Desc: image001.jpg URL: From pmcnary at cameron.net Fri Feb 19 16:09:14 2016 From: pmcnary at cameron.net (Paul) Date: Fri, 19 Feb 2016 15:09:14 -0600 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: <4c441ed1455143799ad02787e79f9120@eclipse-networks.com> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <64759736.483998.1455856193822.JavaMail.zimbra@network1.net> <4c441ed1455143799ad02787e79f9120@eclipse-networks.com> Message-ID: <56C7847A.7090100@cameron.net> However I was told by ARIN, a small ISP like me they could claw back any Legacy resources I acquired outside of the ARIN system. The big guys aren't intimidated by this but we are. The money required to even acquire 1 /24 is now big time. And lack of a direct allocation of IPv6 for $500 is a major obstruction for small ISP's. On 2/19/2016 3:05 PM, Steven Ryerse wrote: > > If ARIN does not have the resources to allocate because of runout, how > pray tell can an ARIN policy be used to corner the market? You can?t > get blood out of a turnip. There is nothing to stop someone from > buying a Legacy block completely outside of ARIN now if they choose to > do that. We know that current ARIN policies are not stopping brokers > from doing this - as there is a brisk business of blocks being traded > in one way or another. You are just rearranging deck chairs on the > Titanic which has already sunk and is already at the bottom of the > sea. I wonder if the fish down there really care where those chairs > are arranged? > > The common sense thing to do would be to modify ARINs policies to > encourage all transactions to go thru ARIN which would lead to more > supply for everyone. This would be in line with ARIN?s mission to > further the Internet. Unfortunately common sense rarely prevails in > this community. > > /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 *Jason Schiller > *Sent:* Friday, February 19, 2016 1:08 PM > *To:* Randy Carpenter > *Cc:* ARIN PPML > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks > > Removing barriers would allow companies with enough money to out right > buy more than a two year supply of IPv4 addresses if they believed > their likelihood of needing a longer time horizon justifies the cost. > They could complete the transaction, transfer the address space in > whole, and use as they desired over whatever time horizon they saw fit. > > This is different to a buying a future where money is paid to hold > IPv4 addresses, and make them available for sipping from in two year > (or less) sized increments under the ARIN transfer policy. This > requires demonstrating efficient utilization of currently held > resources, and then only permits a maximum transfer of two year > supply, after which a new demonstration of efficient utilization of > currently held resources, and a new two year window can be established. > > This second approach has much risk associated. Risk of the transfer > source going bankrupt, risk of the transfer source breaching the > contract, risk of the transfer source finding more favorable terms and > transferring the remaining future to another party, risk of the > transfer recipient having underutilization and have an inability to > get additional resources, risk of transferring the resources to the > wrong OrgID (realizing a new use case under one OrgID evaporates, and > a different new use case appears under a different OrgID). > > As such, the inherent risk of a future will likely limit the spend. > > Reducing or eliminating this risk will encourage the behavior. > > This is different than just paying money to get unlimited use of IPv4 > resources outside of ARIN policy, with no transfer, and only a letter > of authority to route the space, a re-allocate or re-assignment SWIP, > or a public comment indicating who has the right of use. > > This third approach has the risk of the source going bankrupt and the > risk that the source could easily revoke the LOA, SWIP or public > comment, and ask providers to not route the IP space. It has the > added reputation risk that the recipient of the IP space is acting > below board. > > As such risk is even greater than the previous case and will likewise > have a greater limitation on the spend. > > The final case is renting of IPv4 space. This differs from the > previous case in that the spend is ongoing (e.g. monthly or yearly). > > The risk is similar to the previous case except if the IPv4 addresses > are revoked payment is stopped. While the recipient has not lost > their future spend, they also may find themselves suddenly out of IPv4 > space. With the difficulty of renumbering, they may find they are > forced to pay predatory pricing from some period of time, and double > rent new IP space while they number out of the old (excessively high > cost) IPv4 space. Furthermore, if IPv4 space is not available for rent > at a reasonable price, they will be locked in to paying an > unreasonable price. > > Due to the uncertainty and possibility of lock in and predatory > pricing I would argue this arrangement is even more risky than the > previous arrangement if long term (think more than 2 years) use of > IPv4 is desired. > > ___Jason > > On Thu, Feb 18, 2016 at 11:29 PM, Randy Carpenter > > wrote: > > > Are you arguing that by removing the barriers that it would make > it more difficult for Google to get more addresses? If not, then > the point is moot. > > > thanks, > -Randy > > > > ----- On Feb 18, 2016, at 10:47 PM, Mueller, Milton L > milton at gatech.edu wrote: > > > Really. Am I going to have to be the first to point out the > irony of Google > > employees complaining that companies with "deep pockets" and > "the most > > profitable services" will dominate the address market if we make > minor > > relaxations of need assessments? > > > > > > > > > > What's wrong with this picture? Think, folks. > > > > > > > > > > Isn't it obvious that companies like Google are in a very good > position to get > > the addresses they want - via less than transparent market > mechanisms such as > > options contracts and acquisitions? And isn't it possible that > they might be > > trying to prevent smaller companies from participating in the > market by > > throwing up artificial barriers? > > > > > > > > > > All this talk of "fairness" overlooks the fact that it's more > fair to have > > simple, transparent bidding and less bureaucracy. Smaller > bidders can easily > > afford smaller chunks of numbers, and they benefit from the reduced > > administrative burden and delays associated with pointless and > restrictive > > needs assessments. When I hear smaller ISPs who need addresses > making Jason's > > arguments, I might take them seriously. Until then, no. > > > > > > > > > > > > --MM > > > > > > > > > > From: arin-ppml-bounces at arin.net > > on behalf of Jason > > Schiller > > > Sent: Thursday, February 18, 2016 3:11 PM > > To: Vaughn Thurman - Swift Systems > > Cc: ARIN PPML > > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based > > evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks > > +1 to what MCTim, Owen, and Vaughn said. > > > > In general I oppose transfers with no need. > > > > If there are "networks in need of additional IPv4 addresses", > surely they should > > be able to show this, in accord with long standing practice. > > > > I'd rather us not move to a situation which enables/encourages > speculation and > > profit taking (or rent-seeking if you will) in re: IP resource > distribution. > > > > I'd also rather not encourage one competitor in a business > segment to be able to > > better stockpile addresses and for that to become a competitive > advantage > > against other providers in the space. Additionally if this is > done in a wide > > enough scale it can sufficiently lengthen wide spread IPv6 adoption. > > > > This policy would also allow for companies with the deepest > pockets and the most > > profitable services to concentrate IPv4 space. I'm not sure that > is more "fair" > > than the pre-existing framework for "fair". > > > > __Jason > > > > > > > > On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems < > > vaughn at swiftsystems.com > wrote: > > > > > > > > +1 > > > > Sent from my mobile device, please forgive brevity and typos. > > > > On Feb 18, 2016, at 2:16 PM, Owen DeLong < owen at delong.com > > wrote: > > > > > > > > > > +1 ? McTim said it very well. > > > > Owen > > > > > > > > > > On Feb 18, 2016, at 10:34 , McTim < dogwallah at gmail.com > > wrote: > > > > I am opposed. > > > > If there are " networks in need of additional IPv4 addresses", > surely they > > should be able to show this, in accord with long standing practice. > > > > I'd rather us not move to a situation which enables/encourages > speculation and > > profit taking (or rent-seeking if you will) in re: IP resource > distribution. > > > > Regards, > > > > McTim > > > > > > On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer < lsawyer at gci.com > > wrote: > > > > > > Good afternoon - > > > > Based on feedback from Montreal as well as internal discussions, > I've reworked > > this policy. > > AC members and ARIN staff are looking for additional feedback, > as well as your > > position in terms > > of supporting or opposing this draft policy. > > > > We'll be discussing this policy, as well as any feedback > provided on this week's > > AC teleconference, > > so I'm very appreciative of your input. > > > > Thanks, > > > > Leif Sawyer > > Shepherd - ARIN-2015-9 > > > > NRPM section 8: https://www.arin.net/policy/nrpm.html#eight > > > > > Most current draft policy text follows: > > -- > > > > Draft Policy ARIN-2015-9 > > Eliminating needs-based evaluation for Section 8.2 and 8.3 > transfers of IPv4 > > netblocks > > Original Date: 23 September 2015 > > Updated: 16 February, 2016 > > > > Problem statement: > > The current needs-based evaluation language in NRPM sections 8.2 > and 8.3, > > regarding transfer of IPv4 > > netblocks from one organization to another, may cause a > recipient organization > > to bypass the ARIN > > registry entirely in order to secure the needed IPv4 netblocks > in a more timely > > fashion directly from the > > current holder. The result is that the data visible in ARIN > registry may become > > more inaccurate over > > time. > > > > Policy statement: > > This proposal eliminates all needs-based evaluation language for > sections 8.2 > > and 8.3, allowing > > transfers to be reflected in the database as they occur > following an agreement > > of transfer from the > > resource provider to the recipient. > > > > Section 8.1 Principles: > > - Strike the fragment from the 3rd paragraph which reads > > ", based on justified need, " > > so the resulting text reads > > "Number resources are issued to organizations, not to > individuals representing > > those organizations." > > Section 8.2 Mergers and Acquisitions: > > - Change the 4th bullet from: > > "The resources to be transferred will be subject to ARIN policies." > > to: > > "The resources to be transferred will be subject to ARIN > policies, excluding any > > policies related to needs-based justification." > > > > - Strike the final paragraph which begins "In the event that > number resources of > > the combined organizations are no longer justified under ARIN > policy ..." > > > > Section 8.3 Transfers between Specified Recipients within the > ARIN Region: > > - Change the first bullet under "Conditions on 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: > > "The recipient must sign an RSA." > > > > - Change the 2nd bullet under "Conditions on recipient of the > transfer" from: > > "The resources to be transferred will be subject to ARIN policies." > > to: > > "The resources to be transferred will be subject to ARIN > policies, excluding any > > policies related to needs-based justification." > > > > Comments: > > a. Timetable for implementation: Immediate > > b. Anything else > > As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, > LACNIC, and ARIN) > > have now been > > exhausted, networks in need of additional IPv4 addresses have > shifted away from > > the practice of > > receiving them from the RIR's resource pool. Instead, networks > in need are > > seeking out current holders > > of IPv4 resources who are willing to transfer them in order to > fulfill that > > need. Accordingly, the RIR's > > primary responsibility vis-?-vis IPv4 netblock governance has > shifted from > > "allocation" to ensuring an > > accurate registry database. > > > > The RIPE registry can be used as a reference of one which has > evolved over the > > past couple years to > > shift their focus away from conservation/allocation and towards > database > > accuracy. IPv4 netblock > > transfers within that RIR consist merely of validating > authenticity of the > > parties requesting a transfer. > > Provided the organizations meet the basic requirement of RIR > membership, and > > that the transferring > > organization has the valid authority to request the transfer, > the transaction > > completes without any > > "needs-based" review. > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net > ). > > Unsubscribe or manage 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 > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net > ). > > Unsubscribe or manage 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 contactinfo 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. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage 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: not available Type: image/jpeg Size: 1468 bytes Desc: not available URL: From SRyerse at eclipse-networks.com Fri Feb 19 16:19:06 2016 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 19 Feb 2016 21:19:06 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: <248377227.487901.1455907210853.JavaMail.zimbra@network1.net> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> <823499847.484118.1455857416654.JavaMail.zimbra@network1.net> <248377227.487901.1455907210853.JavaMail.zimbra@network1.net> Message-ID: <50bc9ef4d9dd4b978c208f08ee71a9ff@eclipse-networks.com> I suppose I could try and fight the old fight but with runout here the world has changed. I think the most prudent thing to do is to ease policies to try and encourage unused IPv4 resources to become available for all including all of those Legacy blocks. As other regions reach runout, the demand will increase and so will the profits on resources outside of ARIN's control. 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: Randy Carpenter [mailto:rcarpen at network1.net] Sent: Friday, February 19, 2016 1:40 PM To: Steven Ryerse Cc: ARIN PPML Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks That didn't really answer my question. If you have a philosophical argument, that is fine. What you said, however, is that the "desk is stacked against you on purpose by larger organizations." If that is the case, how is giving the larger organizations even more ability to control the market going to benefit you? thanks, -Randy ----- On Feb 19, 2016, at 12:28 AM, Steven Ryerse SRyerse at eclipse-networks.com wrote: > Loosening up the policies is working fine in other regions. What > justification do you really have to not do it here?? In case you > don't know, brokers are doing a brisk business in IPv4 blocks outside > of ARIN, and every time one sells the database gets less accurate. > All of the arguments about cornering the market or whatever are not > happening in other regions and there is no reason why our region is somehow different. > > With runout we now just have policies to prevent IPv4 runout that has > already happened. Isn't it time for this Region to join the rest of > the world we used to lead? > > > 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: Randy Carpenter [mailto:rcarpen at network1.net] > Sent: Thursday, February 18, 2016 11:50 PM > To: Steven Ryerse > Cc: ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating > needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 > netblocks > > > So, you are saying that you need addresses, but can't justify it? I > keep hearing the argument and it makes no sense. > > I manage the IP networks of a bunch of small ISPs. I have never had an > issue with justifying their needs. There certainly are instances where > it would be nice to have some more space to have more flexibility and for future needs. > But, we can't justify the actual need, so we shouldn't get the space. > Others have a need and can justify it, therefore they should be able to get it. > > Making it trivial to get space would lead to those who do *not* need > it getting it because they can, which will reduce the amount of space > available to those who actually need it. > > I oppose vehemently. > > thanks, > -Randy > > > ----- On Feb 18, 2016, at 11:07 PM, Steven Ryerse > SRyerse at eclipse-networks.com > wrote: > >> Milton is right! We are one of those small ISPs and the deck is >> stacked against us on purpose by larger organizations. It is time to >> move on and stop arranging the deck chairs on the IPv4 Titanic like >> other regions have. It?s 2016 not 2001. I support this policy! >> >> >> >> >> >> >> 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 ? >> >> >> >> >> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >> On Behalf Of Mueller, Milton L >> Sent: Thursday, February 18, 2016 10:47 PM >> To: Jason Schiller >> Cc: ARIN PPML >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating >> needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 >> netblocks >> >> >> >> >> >> >> >> Really. Am I going to have to be the first to point out the irony of >> Google employees complaining that companies with "deep pockets" and >> "the most profitable services" will dominate the address market if we >> make minor relaxations of need assessments? >> >> >> >> What's wrong with this picture? Think, folks. >> >> >> >> Isn't it obvious that companies like Google are in a very good >> position to get the addresses they want - via less than transparent >> market mechanisms such as options contracts and acquisitions? And >> isn't it possible that they might be trying to prevent smaller >> companies from participating in the market by throwing up artificial barriers? >> >> >> >> All this talk of "fairness" overlooks the fact that it's more fair to >> have simple, transparent bidding and less bureaucracy. Smaller >> bidders can easily afford smaller chunks of numbers, and they benefit >> from the reduced administrative burden and delays associated with >> pointless and restrictive needs assessments. When I hear smaller ISPs >> who need addresses making Jason's arguments, I might take them seriously. Until then, no. >> >> >> >> --MM >> >> >> >> From: arin-ppml-bounces at arin.net < arin-ppml-bounces at arin.net > on >> behalf of Jason Schiller < jschiller at google.com > >> >> >> Sent: Thursday, February 18, 2016 3:11 PM >> To: Vaughn Thurman - Swift Systems >> Cc: ARIN PPML >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating >> needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 >> netblocks >> >> >> >> >> >> +1 to what MCTim, Owen, and Vaughn said. >> >> >> >> >> >> In general I oppose transfers with no need. >> >> >> >> >> >> If there are "networks in need of additional IPv4 addresses", surely >> they should be able to show this, in accord with long standing practice. >> >> >> >> >> >> I'd rather us not move to a situation which enables/encourages >> speculation and profit taking (or rent-seeking if you will) in re: IP >> resource distribution. >> >> >> >> >> >> I'd also rather not encourage one competitor in a business segment to >> be able to better stockpile addresses and for that to become a >> competitive advantage >> >> >> against other providers in the space. Additionally if this is done in >> a wide enough scale it can sufficiently lengthen wide spread IPv6 adoption. >> >> >> >> >> >> This policy would also allow for companies with the deepest pockets >> and the most profitable services to concentrate IPv4 space. I'm not >> sure that is more "fair" >> >> >> than the pre-existing framework for "fair". >> >> >> >> >> >> __Jason >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems < >> vaughn at swiftsystems.com > wrote: >> >> >> >> >> +1 >> >> Sent from my mobile device, please forgive brevity and typos. >> >> >> >> On Feb 18, 2016, at 2:16 PM, Owen DeLong < owen at delong.com > wrote: >> >> >> >> >> >> +1 ? McTim said it very well. >> >> >> >> >> >> Owen >> >> >> >> >> >> >> >> >> On Feb 18, 2016, at 10:34 , McTim < dogwallah at gmail.com > wrote: >> >> >> >> >> >> I am opposed. >> >> >> >> >> >> If there are " networks in need of additional IPv4 addresses", surely >> they should be able to show this, in accord with long standing practice. >> >> >> >> >> >> I'd rather us not move to a situation which enables/encourages >> speculation and profit taking (or rent-seeking if you will) in re: IP >> resource distribution. >> >> >> >> >> >> Regards, >> >> >> >> >> >> McTim >> >> >> >> >> >> >> >> >> On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer < lsawyer at gci.com > wrote: >> >> >> >> Good afternoon - >> >> Based on feedback from Montreal as well as internal discussions, I've >> reworked this policy. >> AC members and ARIN staff are looking for additional feedback, as >> well as your position in terms of supporting or opposing this draft policy. >> >> We'll be discussing this policy, as well as any feedback provided on >> this week's AC teleconference, so I'm very appreciative of your input. >> >> Thanks, >> >> Leif Sawyer >> Shepherd - ARIN-2015-9 >> >> NRPM section 8: https://www.arin.net/policy/nrpm.html#eight >> >> Most current draft policy text follows: >> -- >> >> Draft Policy ARIN-2015-9 >> Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers >> of IPv4 netblocks Original Date: 23 September 2015 >> Updated: 16 February, 2016 >> >> Problem statement: >> The current needs-based evaluation language in NRPM sections 8.2 and >> 8.3, regarding transfer of IPv4 netblocks from one organization to >> another, may cause a recipient organization to bypass the ARIN >> registry entirely in order to secure the needed IPv4 netblocks in a >> more timely fashion directly from the current holder. The result is >> that the data visible in ARIN registry may become more inaccurate >> over time. >> >> Policy statement: >> This proposal eliminates all needs-based evaluation language for >> sections 8.2 and 8.3, allowing transfers to be reflected in the >> database as they occur following an agreement of transfer from the >> resource provider to the recipient. >> >> Section 8.1 Principles: >> - Strike the fragment from the 3rd paragraph which reads ", based on >> justified need, " >> so the resulting text reads >> "Number resources are issued to organizations, not to individuals >> representing those organizations." >> Section 8.2 Mergers and Acquisitions: >> - Change the 4th bullet from: >> "The resources to be transferred will be subject to ARIN policies." >> to: >> "The resources to be transferred will be subject to ARIN policies, >> excluding any policies related to needs-based justification." >> >> - Strike the final paragraph which begins "In the event that number >> resources of the combined organizations are no longer justified under >> ARIN policy ..." >> >> Section 8.3 Transfers between Specified Recipients within the ARIN Region: >> - Change the first bullet under "Conditions on 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: >> "The recipient must sign an RSA." >> >> - Change the 2nd bullet under "Conditions on recipient of the transfer" from: >> "The resources to be transferred will be subject to ARIN policies." >> to: >> "The resources to be transferred will be subject to ARIN policies, >> excluding any policies related to needs-based justification." >> >> Comments: >> a. Timetable for implementation: Immediate b. Anything else As the >> "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and >> ARIN) have now been exhausted, networks in need of additional IPv4 >> addresses have shifted away from the practice of receiving them from >> the RIR's resource pool. Instead, networks in need are seeking out >> current holders of IPv4 resources who are willing to transfer them in >> order to fulfill that need. Accordingly, the RIR's primary >> responsibility vis-?-vis IPv4 netblock governance has shifted from >> "allocation" to ensuring an accurate registry database. >> >> The RIPE registry can be used as a reference of one which has evolved >> over the past couple years to shift their focus away from >> conservation/allocation and towards database accuracy. IPv4 netblock >> transfers within that RIR consist merely of validating authenticity >> of the parties requesting a transfer. >> Provided the organizations meet the basic requirement of RIR >> membership, and that the transferring organization has the valid >> authority to request the transfer, the transaction completes without >> any "needs-based" review. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List ( ARIN-PPML at arin.net ). >> Unsubscribe or manage 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 >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List ( ARIN-PPML at arin.net ). >> Unsubscribe or manage 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. From sethm at rollernet.us Fri Feb 19 16:32:55 2016 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 19 Feb 2016 13:32:55 -0800 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: <50bc9ef4d9dd4b978c208f08ee71a9ff@eclipse-networks.com> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> <823499847.484118.1455857416654.JavaMail.zimbra@network1.net> <248377227.487901.1455907210853.JavaMail.zimbra@network1.net> <50bc9ef4d9dd4b978c208f08ee71a9ff@eclipse-networks.com> Message-ID: <56C78A07.8080500@rollernet.us> On 2/19/16 13:19, Steven Ryerse wrote: > I suppose I could try and fight the old fight but with runout here the world has changed. I think the most prudent thing to do is to ease policies to try and encourage unused IPv4 resources to become available for all including all of those Legacy blocks. As other regions reach runout, the demand will increase and so will the profits on resources outside of ARIN's control. What other regions are you referring to? All except AfriNIC have already exhausted the free pools. ~Seth From milton at gatech.edu Fri Feb 19 16:44:10 2016 From: milton at gatech.edu (Mueller, Milton L) Date: Fri, 19 Feb 2016 21:44:10 +0000 Subject: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 In-Reply-To: References: <003501d16b2d$0d0a8a70$271f9f50$@iptrading.com> Message-ID: > So I am not in favor of removing restrictions on bad behaviour just because > some have engaged in said behaviour in other regions. I am not saying this is You haven't explained why this is bad behavior. Can you tell me a specific harm that has been done to a specific network operator, user, etc. because of this "speculation" (I would say, arbitrage). > I am a big fan of accuracy in public network information databases, which is > why I authored "no reverse without assignment" in the AFRINIC region, so > the whole "you don't care about registry accuracy' argument doesn't fly with > me. Totally agree, you fully appreciate the need for registry accuracy. I think what people are concerned about is that your anti-market approach to IPv4 transfers might be undermining that goal regardless of your intentions. From milton at gatech.edu Fri Feb 19 16:45:56 2016 From: milton at gatech.edu (Mueller, Milton L) Date: Fri, 19 Feb 2016 21:45:56 +0000 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: <64759736.483998.1455856193822.JavaMail.zimbra@network1.net> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <64759736.483998.1455856193822.JavaMail.zimbra@network1.net> Message-ID: > -----Original Message----- > > Are you arguing that by removing the barriers that it would make it more > difficult for Google to get more addresses? If not, then the point is moot. I am saying Google is entirely unaffected by those barriers, but small operators are not. So the point is not moot. From bcornett at servlet.com Fri Feb 19 16:49:55 2016 From: bcornett at servlet.com (Bruce Cornett) Date: Fri, 19 Feb 2016 16:49:55 -0500 Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks In-Reply-To: References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <64759736.483998.1455856193822.JavaMail.zimbra@network1.net> Message-ID: <56C78E03.4080300@servlet.com> I have to agree with this statement. It's a tough business for us little guys. On 02/19/2016 04:45 PM, Mueller, Milton L wrote:> I am saying Google is entirely unaffected by those barriers, but small operators are not. > So the point is not moot. Bruce Cornett Servlet Internet Services From elvis at velea.eu Fri Feb 19 18:29:12 2016 From: elvis at velea.eu (Elvis Daniel Velea) Date: Fri, 19 Feb 2016 15:29:12 -0800 Subject: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 In-Reply-To: <009b01d16b47$f9683060$ec389120$@iptrading.com> References: <003501d16b2d$0d0a8a70$271f9f50$@iptrading.com> <009b01d16b47$f9683060$ec389120$@iptrading.com> Message-ID: <56C7A548.7000507@velea.eu> +1 I also support this policy change proposal. regards, elvis On 2/19/16 11:01 AM, Mike Burns wrote: > Hi McTim, > > https://labs.ripe.net/Members/wilhelm/ipv4-transfers-in-the-ripe-ncc-service-region > > That RIPE labs report is not evidence of the speculation we are considering in the context of the current policy. > You are opposing this policy because you think it will enable/encourage speculation in the transfer market. > This policy is related to transfers, not to over-allocations made under the old regime. > > This particular country's addresses were not purchased on the transfer market. They were accumulated prior to exhaust under the then-extant needs-based allocations policies, aka longstanding policies, aka proper stewardship. And then (somewhat) after exhaust via gaming the "/22 for new ISPs" rule at RIPE. > > This is not evidence of speculation on the transfer market, it is merely the evidence that market forces act on this resource already. They can induce corruption, rules-avoidance, oh yes indeed they can. > But as I sort of said, that genie is out of the bottle. > We should be attentive related to evidence of this kind of speculation involving allocations from the final free pool in AFRINIC, I am sure we both agree on that. > > Changing the rules about needs-testing paid transfers is not going to enable/encourage or disable/discourage profit and rent-seeking. Profit and rent-seeking is allowed under current policy and will happen regardless of policy anyway. > That won't be significantly changed by maintaining needs tests for ARIN transfers. > > After all, if you can't justify, become a RIPE member and buy RIPE addresses. It's as simple as that. > Anybody can do it, plus they get a /22 for their trouble! And then they can buy RIPE addresses without demonstrating need. > So what is the point of retaining this needs test in the current environment? > > We can't stop market forces from acting on IPv4 addresses, but we should understand that these forces can also induce the movement of unused resources into productive use. In fact that is the natural thing. We have brokered the sale of so many blocks which were unused for decades. This is evidence of this positive effect of the market. > > Now since I have admitted that market forces can lead to corruption and rules-avoidance, can you acknowledge that bringing dusty old blocks back into productive use is a positive effect of the market? > One ideologue to another ? ;-) > > Anyway I guess we both understand each other's positions by now, so I will just register my support for the policy and step off the soapbox. > > Regards, > Mike > > PS made it to the end without mentioning Whois accuracy! > > > > > -----Original Message----- > From: McTim [mailto:dogwallah at gmail.com] > Sent: Friday, February 19, 2016 12:17 PM > To: Mike Burns > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 > > On Fri, Feb 19, 2016 at 10:49 AM, Mike Burns wrote: >> The existence of your company and other "brokers" isn't evidence >> enough that people want to make money solely by buying and selling v4 resources? >> >> Methinks you fail to see the forest for the trees! >> >> Regards, >> >> McTim >> >>> Hi McTim, >> I'm really not sure what you are saying above, but actually the >> existence of brokers like me is in fact evidence that people want to >> make money solely by buying and selling IPv4 addresses. > > > > > Of course, there has been speculation going on for years in the EU. > > Look at the top ten by country table near the bottom of this page: > > https://labs.ripe.net/Members/wilhelm/ipv4-transfers-in-the-ripe-ncc-service-region > > and ask yourself why one small country punches above its weight in exported v4. > > While these PI blocks were acquired within policy, it is clear that they were obtained for later resale, which is definition #2 below: > > spec?u?la?tion > ?speky??l?SH(?)n/ > noun > > 1. > the forming of a theory or conjecture without firm evidence. > "there has been widespread speculation that he plans to quit" > 2. > investment in stocks, property, or other ventures in the hope of gain but with the risk of loss. > "the company's move into property speculation" > > > So I am not in favor of removing restrictions on bad behaviour just because some have engaged in said behaviour in other regions. I am not saying this is fraudulent behaviour, but certainly speculative in nature and not in the best interests of the Internet community. That of course is my ideology showing, and I make no bones about it. > > I am a big fan of accuracy in public network information databases, which is why I authored "no reverse without assignment" in the AFRINIC region, so the whole "you don't care about registry accuracy' argument doesn't fly with me. > > > -- > Cheers, > > McTim > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 dmahoney at dataonenetworks.biz Fri Feb 19 19:10:23 2016 From: dmahoney at dataonenetworks.biz (dmahoney at dataonenetworks.biz) Date: Fri, 19 Feb 2016 19:10:23 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 In-Reply-To: <56C7A548.7000507@velea.eu> References: <003501d16b2d$0d0a8a70$271f9f50$@iptrading.com> <009b01d16b47$f9683060$ec389120$@iptrading.com> <56C7A548.7000507@velea.eu> Message-ID: <56C7AEEF.50609@dataonenetworks.biz> +1 Here also as I also support this policy change proposal. Regards, Don On 2/19/16 6:29 PM, Elvis Daniel Velea wrote: > +1 > > I also support this policy change proposal. > > regards, > elvis > > On 2/19/16 11:01 AM, Mike Burns wrote: >> Hi McTim, >> >> https://labs.ripe.net/Members/wilhelm/ipv4-transfers-in-the-ripe-ncc-service-region >> >> >> That RIPE labs report is not evidence of the speculation we are >> considering in the context of the current policy. >> You are opposing this policy because you think it will >> enable/encourage speculation in the transfer market. >> This policy is related to transfers, not to over-allocations made >> under the old regime. >> >> This particular country's addresses were not purchased on the >> transfer market. They were accumulated prior to exhaust under the >> then-extant needs-based allocations policies, aka longstanding >> policies, aka proper stewardship. And then (somewhat) after exhaust >> via gaming the "/22 for new ISPs" rule at RIPE. >> >> This is not evidence of speculation on the transfer market, it is >> merely the evidence that market forces act on this resource already. >> They can induce corruption, rules-avoidance, oh yes indeed they can. >> But as I sort of said, that genie is out of the bottle. >> We should be attentive related to evidence of this kind of >> speculation involving allocations from the final free pool in >> AFRINIC, I am sure we both agree on that. >> >> Changing the rules about needs-testing paid transfers is not going to >> enable/encourage or disable/discourage profit and rent-seeking. >> Profit and rent-seeking is allowed under current policy and will >> happen regardless of policy anyway. >> That won't be significantly changed by maintaining needs tests for >> ARIN transfers. >> >> After all, if you can't justify, become a RIPE member and buy RIPE >> addresses. It's as simple as that. >> Anybody can do it, plus they get a /22 for their trouble! And then >> they can buy RIPE addresses without demonstrating need. >> So what is the point of retaining this needs test in the current >> environment? >> >> We can't stop market forces from acting on IPv4 addresses, but we >> should understand that these forces can also induce the movement of >> unused resources into productive use. In fact that is the natural >> thing. We have brokered the sale of so many blocks which were unused >> for decades. This is evidence of this positive effect of the market. >> >> Now since I have admitted that market forces can lead to corruption >> and rules-avoidance, can you acknowledge that bringing dusty old >> blocks back into productive use is a positive effect of the market? >> One ideologue to another ? ;-) >> >> Anyway I guess we both understand each other's positions by now, so I >> will just register my support for the policy and step off the soapbox. >> >> Regards, >> Mike >> >> PS made it to the end without mentioning Whois accuracy! >> >> >> >> >> -----Original Message----- >> From: McTim [mailto:dogwallah at gmail.com] >> Sent: Friday, February 19, 2016 12:17 PM >> To: Mike Burns >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 128, Issue 7 >> >> On Fri, Feb 19, 2016 at 10:49 AM, Mike Burns wrote: >>> The existence of your company and other "brokers" isn't evidence >>> enough that people want to make money solely by buying and selling >>> v4 resources? >>> >>> Methinks you fail to see the forest for the trees! >>> >>> Regards, >>> >>> McTim >>> >>>> Hi McTim, >>> I'm really not sure what you are saying above, but actually the >>> existence of brokers like me is in fact evidence that people want to >>> make money solely by buying and selling IPv4 addresses. >> >> >> >> >> Of course, there has been speculation going on for years in the EU. >> >> Look at the top ten by country table near the bottom of this page: >> >> https://labs.ripe.net/Members/wilhelm/ipv4-transfers-in-the-ripe-ncc-service-region >> >> >> and ask yourself why one small country punches above its weight in >> exported v4. >> >> While these PI blocks were acquired within policy, it is clear that >> they were obtained for later resale, which is definition #2 below: >> >> spec?u?la?tion >> ?speky??l?SH(?)n/ >> noun >> >> 1. >> the forming of a theory or conjecture without firm evidence. >> "there has been widespread speculation that he plans to quit" >> 2. >> investment in stocks, property, or other ventures in the hope of gain >> but with the risk of loss. >> "the company's move into property speculation" >> >> >> So I am not in favor of removing restrictions on bad behaviour just >> because some have engaged in said behaviour in other regions. I am >> not saying this is fraudulent behaviour, but certainly speculative in >> nature and not in the best interests of the Internet community. That >> of course is my ideology showing, and I make no bones about it. >> >> I am a big fan of accuracy in public network information databases, >> which is why I authored "no reverse without assignment" in the >> AFRINIC region, so the whole "you don't care about registry accuracy' >> argument doesn't fly with me. >> >> >> -- >> Cheers, >> >> McTim >> >> >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage 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 ctacit at tacitlaw.com Mon Feb 22 12:41:56 2016 From: ctacit at tacitlaw.com (Christian Tacit) Date: Mon, 22 Feb 2016 17:41:56 +0000 Subject: [arin-ppml] Draft Policy ARIN 2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) - Changes to Text Message-ID: <059cb077b3f544ba89f69551ae5cd393@S05-MBX03-12.S05.local> I am writing to advise of changes made today to the text of Draft Policy ARIN-2015-2. On February 9, 2016 I presented ARIN-2015-2 and the additional new proposed language that I had circulated on PPML on January 31, 2016 at the NANOG PPC. (The additional proposed language had received no comments on PPML between January 31 and the date of the NANONG PPC.) It seems like the additional text has struck the right balance between enabling multi-region network operators to use their resources in the regions in which they need them via inter-RIR transfers to affiliates and ensuring that the anti-flip provisions are not too readily circumvented by entities that could use the those transfer provisions in a fraudulent manner instead. I say this because there were no comments received on PPML at the PPC about how that balance was being struck after the proposed language change was presented, whereas in the past, that had been the most significant aspect of the discussion. At the PPC, one person said he was in favour of the Draft Policy. There was only one other comment, and it focused on the fact that the text was still rather cumbersome and difficult to parse. In order to alleviate this concern, in the course of modifying the Draft Policy today, I have made one further modification that would simplify the text, by creating a definition of "affiliated" and using that definition in the fourth bullet of section 8.4. Based on all of this, the text and related information for the Draft Policy now read as follows: Draft Policy ARIN 2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Date: 15 April 2015 Problem Statement: Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt. Policy statement: Replace 8.4, bullet 4, to read: "Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request, unless the source entities are affiliated with the recipient entities outside the ARIN region. This restriction does not include M&A transfers." Add new section 2.17 that reads: The term "affiliated" means that an entity that directly, or indirectly through one or more intermediaries, controls, is controlled by, or is under common control with another entity. Add new section 2.18 that reads: The term "control" means the possession, directly or indirectly, through the ownership of voting securities, by contract, arrangement, understanding, relationship or otherwise, of the power to direct or cause the direction of the management and policies of a person. The beneficial ownership of more than 50 percent of a corporation's voting shares shall be deemed to constitute control. Comments: The intention of this change is to allow organizations to perform inter-RIR transfers of space received via an 8.3 transfer regardless of the date transferred to ARIN. A common example is that an organization acquires a block located in the ARIN region, transfers it to ARIN, then 3 months later, the organization announces that it wants to launch new services out of region. Under current policy, the organization is prohibited from moving some or all of those addresses to that region's Whois; the numbers are locked in ARIN's Whois. It's important to note that 8.3 transfers are approved for a 24 month supply, and it would not be unheard of for a business model to change within the first 12 months after approval. The proposal also introduces a requirement for an affiliation relationship between the source and recipient entity, based on established corporate law principles, so as to make it reasonably likely that eliminating the 12 month anti-flip period in that situation will meet the needs of organizations that operate networks in more than one region without encouraging abuse. a. Timetable for implementation: Immediate b. Anything else: N/A Chris Tacit -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Wed Feb 24 04:48:26 2016 From: info at arin.net (ARIN) Date: Wed, 24 Feb 2016 04:48:26 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - February 2016 Message-ID: <56CD7C6A.3060902@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) met on 18 February 2016. The AC moved the following to last call (to be posted separately to last call): Recommended Draft Policy ARIN-2015-5: Out of region use Recommended Draft Policy ARIN-2015-11: Remove transfer language which only applied pre-exhaustion of IPv4 pool Having found the following Draft Policy to be fully developed and meeting ARIN's Principles of Internet Number Resource Policy, the AC recommended it for adoption (to be posted separately for discussion as a Recommended Draft Policy): Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy The AC is continuing to work on: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Draft Policy ARIN-2015-6: Transfers and Multi-national Networks Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Feb 24 04:49:10 2016 From: info at arin.net (ARIN) Date: Wed, 24 Feb 2016 04:49:10 -0500 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-5: Out of region use Message-ID: <56CD7C96.7090805@arin.net> The ARIN Advisory Council (AC) met on 18 February 2016 and decided to send the following to last call: Recommended Draft Policy ARIN-2015-5: Out of region use Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 9 March 2016. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Recommended Draft Policy ARIN-2015-5 Out of region use AC's assessment of conformance with the Principles of Internet Number Resource Policy: ARIN-2015-5 enables fair and impartial number resource administration by allowing any ARIN Organization with a real and substantial connection to the ARIN region to use number resources out of region without prejudice. This proposal is technically sound, as it addresses the key concerns related to the unlimited openness of out of region use and enables ARIN staff to implement the policy efficiently. The policy received a unanimous show of support at the ARIN PPM in Montreal as well as the PPC in San Diego. Problem statement: Current policy neither clearly forbids nor clearly permits out of region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has explored several options to restrict or otherwise limit out of region use or loosen controls and totally authorize such use. None of these options have gained consensus within the community. The next logical option is a proposal that clearly permits out of region use while addressing the key concerns expressed about unlimited openness to out of region use and enables ARIN staff to implement the policy efficiently. Policy statement: Create new Section X: ARIN registered resources may be used outside the ARIN service region. Out of region use of ARIN registered resources are valid justification for additional number resources, provided that the applicant has a real and substantial connection with the ARIN region which applicant must prove (as described below) and is using the same type of resources (with a delegation lineage back to an ARIN allocation or assignment) within the ARIN service region as follows: * IPv4: At least a /22 used in region * IPv6: At least a /44 used in region * ASN: At least one ASN present on one or more peering sessions and/or routers within the region. A real and substantial connection shall be defined as carrying on business in the ARIN region in a meaningful manner. The determination as to whether an entity is carrying on business in the ARIN region in a meaningful manner shall be made by ARIN. Simply being incorporated in the ARIN region shall not be sufficient, on its own, to prove that an entity is carrying on business in the ARIN region in a meaningful manner. Methods that entities may consider using, including cumulatively, to prove that they are carrying on business in the ARIN region in a meaningful manner include: * Demonstrating a physical presence in the ARIN region through a bricks and mortar location that is actually used for the purposes of conducting business in the ARIN region in a meaningful manner. That is to say, the location is not merely a registered office that serves no other business purpose. * Demonstrating that the entity has staff in the ARIN region. The greater the number of staff, the stronger this connecting factor is. * Demonstrating that the entity holds assets in the ARIN region. The greater the asset value, the stronger this connecting factor is. * Demonstrating that the entity provides services to and solicits sales from residents of the ARIN region. * Demonstrating that the entity holds periodic meetings in the ARIN region. * Demonstrating that the entity raises investment capital from investors in the ARIN region. * Demonstrating that the entity has a registered corporation in the ARIN region, although this factor on its own shall not be sufficient. * Other fact based criterion that the entity considers appropriate and submits for ARIN's review. The weight accorded to any of the above-noted factors, if any, shall be determined solely by ARIN. The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR's service region, an officer of the application must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to obtain from the applicant a listing of all the applicant's number holdings in the region(s) of proposed use, when there are factual reasons to support the request. Comments: a) Timetable for implementation: Various iterations of this policy have been presented and debated by ARIN for well over a year now. Given the amount of time that has already been spent on developing a policy, ideally, this policy would be implemented as soon as possible. b) Explanation of draft policy: The draft policy addresses both the problem statement as well as the concerns raised at ARIN 35 by participants as well as ARIN counsel. Firstly, the draft policy addresses the concerns of ARIN counsel as well as some of the participants at ARIN 35 by ensuring that anyone requesting numbered resources from ARIN has a real and substantial connection with the ARIN region. This should go a long way to addressing concerns about fraud, legal liability, and interference with the jurisdiction of other RIRs. In addition, by placing the burden of proof for demonstrating a real and substantial connection with the ARIN region on the applicant, the amount of work required of ARIN staff to apply the policy will be reduced. The factors noted above are suggestions that an entity may use to demonstrate to ARIN that it is carrying on business in the ARIN region in a meaningful manner. These factors are all indicative, some more than others, that an entity has a real and substantial connection to the ARIN region through the carrying on of business in the ARIN region in a meaningful manner. Not all of the factors will apply in a given case and proving a single factor may not be enough to satisfy ARIN that an entity is carrying on business in the region in a meaningful manner. The list of factors is meant to be quite broad, including an open-ended factor, in order to capture the diversity of businesses that operate in the ARIN region and that may justifiably require numbered resources from ARIN. This approach is very similar to the practical method that courts typically apply to assess whether parties have a sufficient connection to a jurisdiction so as to require them to submit themselves to the courts of that jurisdiction. This draft policy is a substantial improvement over the previous version of ARIN-2014-1 in terms of reducing the overall risk to the community by requiring a real and substantial connection between an entity requesting resources and the ARIN region. ##### ARIN STAFF & LEGAL ASSESSMENT Draft Policy ARIN-2015-5 OUT OF REGION USE Date of Assessment: 17 September 2015 ___ 1. Summary (Staff Understanding) This proposal would allow an organization to receive Internet number resources from ARIN for use out of region as long as the applicant is currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively. In addition, the applicant must have a real and substantial connection with the ARIN region, which the applicant shall be responsible for proving. ___ 2. Comments A. ARIN Staff Comments This policy would increase the complexity of ARIN staff review work in request cases that fit the profile of this policy. There would in an increase in the vetting and utilization verification work currently conducted by ARIN staff. This policy would be placed in the NRPM as section 9, "Out of Region Use". B. ARIN General Counsel ? Legal Assessment If the policy is enacted it will require ARIN staff to work with counsel with some attendant increase in costs in the first year to manage implementation. The policy is consistent with standard legal principles routinely utilized in the ARIN region. The policy creates no material legal risks. ___ 3. Resource Impact From a request review standpoint, implementation of this policy would require additional review steps for Internet number resource requests. It could have future staffing implications based on the amount of additional work the policy could present. It is estimated that implementation could occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Updated guidelines and internal procedures * Staff training Implementation of this policy may allow for registrations in the ARIN database that require unicode character sets. From an engineering standpoint, implementation of this policy could have a major resource impact. It is estimated that implementation would occur within 12 months, instead of the 3 months cited above, after ratification by the ARIN Board of Trustees if ARIN is required to support unicode character sets. The following would be needed in order to implement: * Engineering: Engineering efforts to handle out of region business rules may be substantial as our system only supports ascii now. If there is a need for unicode character sets, then there is a substantial amount of work required to upgrade the DB and applications to support unicode. Additionally, we would need to discuss how to display unicode characters in port 43 whois. From info at arin.net Wed Feb 24 04:49:30 2016 From: info at arin.net (ARIN) Date: Wed, 24 Feb 2016 04:49:30 -0500 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-11: Remove transfer language which only applied pre-exhaustion of IPv4 pool Message-ID: <56CD7CAA.5020009@arin.net> The ARIN Advisory Council (AC) met on 18 February 2016 and decided to send the following to last call: Recommended Draft Policy ARIN-2015-11: Remove transfer language which only applied pre-exhaustion of IPv4 pool Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 9 March 2016. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Recommended Draft Policy ARIN-2015-11 Remove transfer language which only applied pre-exhaustion of IPv4 pool AC's assessment of conformance with the Principles of Internet Number Resource Policy: ARIN 2015-11 contributes to fair and impartial number resource administration by removing from the NRPM text that has become inoperative since the depletion of the IPv4 free pool in September 2015, thereby avoiding confusion among people applying for 8.3 or 8.4 transfers. This proposal is technically sound, in that the removal of the text in question does not create any contradictions or loopholes in the application of policies that still matter. The proposal was supported by some community members on PPML and at the ARIN meeting in Montreal, and did not generate any opposition. Problem Statement: The current policies in NRPM sections 8.3, and 8.4 include language which is in effect "until exhaustion." As ARIN is no longer able to fulfil IPv4 requests (per 01 July 2015 press release https://www.arin.net/about_us/media/releases/20150701.html), exhaustion has effectively occurred. This proposal serves to remove the outdated language from the NRPM. Policy statement: Remove sections of the NRPM which were only affective until IPv4 pool exhaustion occurred, as follows: Section 8.3 Transfers between Specified Recipients within the ARIN Region: - Remove entirely the second bullet which reads "The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first." Section 8.4 Inter-RIR Transfers to Specified Recipients: - Remove entirely the third bullet which reads "Source entities within the ARIN region will not be eligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first." Comments: Timetable for implementation: Immediate ##### ARIN STAFF & LEGAL ASSESSMENT Draft Policy ARIN-2015-11 REMOVE TRANSFER LANGUAGE WHICH ONLY APPLIED PRE-EXHAUSTION OF IPV4 POOL Date of Assessment: 22 October 2015 ___ 1. Summary (Staff Understanding) This proposal calls for the removal of language in 8.3 and 8.4 of NRPM that sets a condition on the amount of time that must pass before the source of an 8.3 or 8.4 transfer may request additional IPv4 address space as a recipient. ___ 2. Comments A. ARIN Staff Comments * Since ARIN staff considers the depletion of the IPv4 address space as a single, one-time, event that has already occurred on September 24, 2015, the subject language no longer applies to new IPv4 recipient requests going forward. As of September 24, 2015, ARIN staff no longer applies a 12-month lock-out to organizations requesting to receive IPv4 who have previously been the source of an IPv4 allocation/assignment through an 8.3 or 8.4 transfer. * ARIN staff considers the removal of policy language to have no effect on processing of requests; it appears to be purely removal of inoperative policy text. * ARIN staff notes that both 8.3 and 8.4 have language that prevents organizations from being a source in an approved 8.3 or 8.4 transfer if they have been a recipient of IPv4 address space in the 12 months prior, and this language is presently operative and would remain so even if the proposal change is made. * This policy could be implemented as written. B. ARIN General Counsel ? Legal Assessment No material legal issues. ___ 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Updated guidelines and internal procedures * Staff training From narten at us.ibm.com Fri Feb 26 00:53:02 2016 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 26 Feb 2016 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201602260553.u1Q5r2tL032111@rotala.raleigh.ibm.com> Total of 23 messages in the last 7 days. script run at: Fri Feb 26 00:53:02 EST 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 13.04% | 3 | 22.30% | 105827 | sryerse at eclipse-networks.com 8.70% | 2 | 22.09% | 104830 | pmcnary at cameron.net 8.70% | 2 | 18.07% | 85784 | jschiller at google.com 13.04% | 3 | 6.36% | 30167 | info at arin.net 8.70% | 2 | 3.50% | 16600 | milton at gatech.edu 8.70% | 2 | 3.34% | 15865 | mike at iptrading.com 4.35% | 1 | 5.44% | 25811 | ctacit at tacitlaw.com 4.35% | 1 | 4.17% | 19800 | rcarpen at network1.net 4.35% | 1 | 3.60% | 17100 | bjones at vt.edu 4.35% | 1 | 2.57% | 12178 | elvis at velea.eu 4.35% | 1 | 2.36% | 11211 | dmahoney at dataonenetworks.biz 4.35% | 1 | 1.86% | 8813 | dogwallah at gmail.com 4.35% | 1 | 1.74% | 8265 | narten at us.ibm.com 4.35% | 1 | 1.38% | 6565 | sethm at rollernet.us 4.35% | 1 | 1.23% | 5835 | bcornett at servlet.com --------+------+--------+----------+------------------------ 100.00% | 23 |100.00% | 474651 | Total