From info at arin.net Tue Mar 1 14:29:01 2016 From: info at arin.net (ARIN) Date: Tue, 01 Mar 2016 14:29:01 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy Message-ID: <56D5ED7D.4050508@arin.net> Recommended Draft Policy ARIN-2015-3 Remove 30 day utilization requirement in end-user IPv4 policy On 18 February 2016 the ARIN Advisory Council (AC) recommended ARIN-2015-3 for adoption, making it a Recommended Draft Policy. ARIN-2015-3 is below and can be found at: https://www.arin.net/policy/proposals/2015_3.html You are encouraged to discuss Draft Policy 2015-3 on the PPML prior to its presentation at the next ARIN Public Policy Meeting. 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-3 Remove 30 day utilization requirement in end-user IPv4 policy AC's assessment of conformance with the Principles of Internet Number Resource Policy: ARIN 2015-3 contributes to fair and impartial number resource administration by removing from the NRPM text that is operationally unrealistic for the reasons discussed in the problem statement. This proposal is technically sound, in that the removal of the text will more closely align with the way staff applies the existing policy in relation to 8.3 transfers. The proposal was supported by community members at the ARIN PPM in Montreal and on PPML with some dissent. 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 criterion 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 ##### ARIN STAFF ASSESSMENT Draft Policy ARIN-2015-3 Remove 30 day utilization requirement in end-user IPv4 policy Date of Assessment: 16 February 2016 ___ 1. Summary (Staff Understanding) This proposal would remove the 25% utilization (within 30 days of issuance) criteria bullet point from NRPM 4.3.3. ___ 2. Comments A. ARIN Staff Comments This policy would more closely align with the way staff applies the existing policy in relation to 8.3 transfers. Because there is no longer an IPv4 free pool and many IPv4 requests are likely to be satisfied by 8.3 transfers, the adoption of this policy should have no major impact on operations and could be implemented as written. Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to obsolete RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within 30 days of issuance) requirement. Staff suggests removing the first two sentences of 4.2.3.6 to remove the references to RFC 2050 and the 25% requirement. Additionally, staff suggests removing the reference to the obsolete RFC 2050 in section 4.3.3. B. ARIN General Counsel ? Legal Assessment No material legal risk in this policy. ___ 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur immediately after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Updated guidelines and internal procedures * Staff training ___ 4. Proposal / Draft Policy Text Assessed Date: 27 January 2016 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 From owen at delong.com Tue Mar 1 17:00:02 2016 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Mar 2016 14:00:02 -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: <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> Message-ID: <41BAD343-3BE1-4ABC-895C-657E6237F068@delong.com> This policy is an example of rearranging the IPv4 deck chairs. So your statement is not consistent with your support of the policy. Owen > On Feb 18, 2016, at 20:07 , Steven Ryerse 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 > 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 > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Mar 1 17:11:12 2016 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Mar 2016 14:11:12 -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: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> <823499847.484118.1455857416654.JavaMail.zimbra@network1.net> Message-ID: <67C0BBE8-121F-4427-8FA5-0D6859E116CA@delong.com> In most of the rest of the world, attempting to purchase a supply of addresses to prevent your competitors from gaining access to them would be considered an anti-trust issue and would likely face prosecution. In the US (I?m not sure about the rest of the ARIN region), it would likely be viewed as shrewd business practice. That?s the difference. Owen > On Feb 18, 2016, at 21:28 , Steven Ryerse 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. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From matthew at matthew.at Tue Mar 1 17:32:36 2016 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 1 Mar 2016 14:32:36 -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: <67C0BBE8-121F-4427-8FA5-0D6859E116CA@delong.com> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> <823499847.484118.1455857416654.JavaMail.zimbra@network1.net> <67C0BBE8-121F-4427-8FA5-0D6859E116CA@delong.com> Message-ID: <56D61884.6070403@matthew.at> On 3/1/2016 2:11 PM, Owen DeLong wrote: > In most of the rest of the world, attempting to purchase a supply of addresses to prevent your competitors from gaining access to them would be considered an anti-trust issue and would likely face prosecution. > > In the US (I?m not sure about the rest of the ARIN region), it would likely be viewed as shrewd business practice. > > That?s the difference. > Doesn't the rollout of IPv6 make this impossible? Matthew Kaufman From SRyerse at eclipse-networks.com Wed Mar 2 15:13:50 2016 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 2 Mar 2016 20:13: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 In-Reply-To: <41BAD343-3BE1-4ABC-895C-657E6237F068@delong.com> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> <41BAD343-3BE1-4ABC-895C-657E6237F068@delong.com> Message-ID: Obviously Milton doesn?t share that opinion per his comments below and neither do I. 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: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, March 1, 2016 5:00 PM To: Steven Ryerse Cc: Mueller, Milton L ; Jason Schiller ; 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 This policy is an example of rearranging the IPv4 deck chairs. So your statement is not consistent with your support of the policy. Owen On Feb 18, 2016, at 20:07 , Steven Ryerse > 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 > 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 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From SRyerse at eclipse-networks.com Wed Mar 2 15:16:44 2016 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 2 Mar 2016 20:16: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: <56D61884.6070403@matthew.at> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> <823499847.484118.1455857416654.JavaMail.zimbra@network1.net> <67C0BBE8-121F-4427-8FA5-0D6859E116CA@delong.com> <56D61884.6070403@matthew.at> Message-ID: <8d421dc5245e4d2a92e1f7653069ea42@eclipse-networks.com> I think Mathew's comment is correct and I think your concerns about the market being cornered are unfounded as the real life experience shows the markets have not been cornered in other regions. IPv6 makes trying to corner the IPv4 market a huge risk. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Kaufman Sent: Tuesday, March 1, 2016 5:33 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 On 3/1/2016 2:11 PM, Owen DeLong wrote: > In most of the rest of the world, attempting to purchase a supply of addresses to prevent your competitors from gaining access to them would be considered an anti-trust issue and would likely face prosecution. > > In the US (I?m not sure about the rest of the ARIN region), it would likely be viewed as shrewd business practice. > > That?s the difference. > Doesn't the rollout of IPv6 make this impossible? Matthew Kaufman _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From milton at gatech.edu Wed Mar 2 17:06:01 2016 From: milton at gatech.edu (Mueller, Milton L) Date: Wed, 2 Mar 2016 22:06:01 +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: <41BAD343-3BE1-4ABC-895C-657E6237F068@delong.com> References: <0308CD68-0F5A-4517-9925-CEE8392AEF8A@swiftsystems.com> <84e92e8d406243f0a58a0476b201aaa0@eclipse-networks.com> <41BAD343-3BE1-4ABC-895C-657E6237F068@delong.com> Message-ID: First, the IPv4 Internet is not sinking! So the analogy is a bit inappropriate. But if by ?rearranging deck chairs? one means ?doing something that makes no sense given impending realities,? I would think that requiring free-pool era needs assessments for small IPv4 transfers in a time characterized by an exhausted free pool and price-based rationing of the resource is very much a rearranging of the deck chairs. It might be more fun to compare certain participants in this debate to Captain Ahab seeking to slay the White Whale of a cornered, speculative IPv4 market, and destroying himself and his entire ship in the process. --MM From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, March 1, 2016 5:00 PM To: Steven Ryerse Cc: Mueller, Milton L ; Jason Schiller ; 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 This policy is an example of rearranging the IPv4 deck chairs. So your statement is not consistent with your support of the policy. Owen On Feb 18, 2016, at 20:07 , Steven Ryerse > 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 > 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 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage 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 narten at us.ibm.com Fri Mar 4 00:53:02 2016 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 04 Mar 2016 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201603040553.u245r3ET004455@rotala.raleigh.ibm.com> Total of 8 messages in the last 7 days. script run at: Fri Mar 4 00:53:02 EST 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 25.00% | 2 | 32.08% | 83806 | owen at delong.com 25.00% | 2 | 30.85% | 80585 | sryerse at eclipse-networks.com 12.50% | 1 | 27.39% | 71558 | milton at gatech.edu 12.50% | 1 | 4.57% | 11933 | info at arin.net 12.50% | 1 | 2.84% | 7416 | narten at us.ibm.com 12.50% | 1 | 2.28% | 5945 | matthew at matthew.at --------+------+--------+----------+------------------------ 100.00% | 8 |100.00% | 261243 | Total From michael at linuxmagic.com Mon Mar 7 18:14:04 2016 From: michael at linuxmagic.com (Michael Peddemors) Date: Mon, 7 Mar 2016 15:14:04 -0800 Subject: [arin-ppml] Just so it is recorded here (DNSSEC.. ) outages today.. Message-ID: <56DE0B3C.60903@linuxmagic.com> We had a flurry of reports from various customers, problems with reverse DNS lookups.. Limited to the 65/8 IPv4, and from apparent reports, related to a failure to update a DNSSEC signature.. Reported: Anyone with a DNSSEC enforced name server will have problems with PTR queries for that range. Someone with more inside knowledge can provide more details, I am sure.. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From ndavis at arin.net Mon Mar 7 20:59:18 2016 From: ndavis at arin.net (Nate Davis) Date: Tue, 8 Mar 2016 01:59:18 +0000 Subject: [arin-ppml] Just so it is recorded here (DNSSEC.. ) outages today.. In-Reply-To: <56DE0B3C.60903@linuxmagic.com> References: <56DE0B3C.60903@linuxmagic.com> Message-ID: Michael - thanks for reporting the issue. ARIN Engineering resolved the DNSSEC failure shortly after you reported the issue. They are currently looking into the cause of the failure. All DNSSEC functions should be operating properly at this time. Regards, Nate Davis Chief Operating Officer American Registry for Internet Numbers On 3/7/16, 6:14 PM, "arin-ppml-bounces at arin.net on behalf of Michael Peddemors" wrote: >We had a flurry of reports from various customers, problems with reverse >DNS lookups.. > >Limited to the 65/8 IPv4, and from apparent reports, related to a >failure to update a DNSSEC signature.. > >Reported: Anyone with a DNSSEC enforced name server will have problems >with PTR queries for that range. > >Someone with more inside knowledge can provide more details, I am sure.. > > > >-- >"Catch the Magic of Linux..." >------------------------------------------------------------------------ >Michael Peddemors, President/CEO LinuxMagic Inc. >Visit us at http://www.linuxmagic.com @linuxmagic >------------------------------------------------------------------------ >A Wizard IT Company - For More Info http://www.wizard.ca >"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. >------------------------------------------------------------------------ >604-682-0300 Beautiful British Columbia, Canada > >This email and any electronic data contained are confidential and intended >solely for the use of the individual or entity to which they are >addressed. >Please note that any views or opinions presented in this email are solely >those of the author and are not intended to represent those of the >company. > >_______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. From frnkblk at iname.com Mon Mar 7 22:28:27 2016 From: frnkblk at iname.com (frnkblk at iname.com) Date: Mon, 7 Mar 2016 21:28:27 -0600 Subject: [arin-ppml] Just so it is recorded here (DNSSEC.. ) outages today.. In-Reply-To: References: <56DE0B3C.60903@linuxmagic.com> Message-ID: <000001d178ea$958fe190$c0afa4b0$@iname.com> Nate, Please let us know if ARIN monitors all their zones for DNSSEC signature expiration. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Nate Davis Sent: Monday, March 07, 2016 7:59 PM To: Michael Peddemors ; arin-ppml at arin.net Subject: Re: [arin-ppml] Just so it is recorded here (DNSSEC.. ) outages today.. Michael - thanks for reporting the issue. ARIN Engineering resolved the DNSSEC failure shortly after you reported the issue. They are currently looking into the cause of the failure. All DNSSEC functions should be operating properly at this time. Regards, Nate Davis Chief Operating Officer American Registry for Internet Numbers On 3/7/16, 6:14 PM, "arin-ppml-bounces at arin.net on behalf of Michael Peddemors" wrote: >We had a flurry of reports from various customers, problems with reverse >DNS lookups.. > >Limited to the 65/8 IPv4, and from apparent reports, related to a >failure to update a DNSSEC signature.. > >Reported: Anyone with a DNSSEC enforced name server will have problems >with PTR queries for that range. > >Someone with more inside knowledge can provide more details, I am sure.. > > > >-- >"Catch the Magic of Linux..." >------------------------------------------------------------------------ >Michael Peddemors, President/CEO LinuxMagic Inc. >Visit us at http://www.linuxmagic.com @linuxmagic >------------------------------------------------------------------------ >A Wizard IT Company - For More Info http://www.wizard.ca >"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. >------------------------------------------------------------------------ >604-682-0300 Beautiful British Columbia, Canada > >This email and any electronic data contained are confidential and intended >solely for the use of the individual or entity to which they are >addressed. >Please note that any views or opinions presented in this email are solely >those of the author and are not intended to represent those of the >company. > >_______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From christopher.morrow at gmail.com Tue Mar 8 10:45:38 2016 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 8 Mar 2016 10:45:38 -0500 Subject: [arin-ppml] Just so it is recorded here (DNSSEC.. ) outages today.. In-Reply-To: <000001d178ea$958fe190$c0afa4b0$@iname.com> References: <56DE0B3C.60903@linuxmagic.com> <000001d178ea$958fe190$c0afa4b0$@iname.com> Message-ID: Also, i'd be super awesome if there would be a pretty detailed post-mortem document published about what happened, how it happened and how it was discovered/repaired. I believe ARIN isn't the only one having these issues, so publishing so other folk can learn would be great! -crhis On Mon, Mar 7, 2016 at 10:28 PM, wrote: > Nate, > > Please let us know if ARIN monitors all their zones for DNSSEC signature > expiration. > > Frank > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Nate Davis > Sent: Monday, March 07, 2016 7:59 PM > To: Michael Peddemors ; arin-ppml at arin.net > Subject: Re: [arin-ppml] Just so it is recorded here (DNSSEC.. ) outages > today.. > > Michael - thanks for reporting the issue. > > ARIN Engineering resolved the DNSSEC failure shortly after you reported > the issue. They are currently looking into the cause of the failure. All > DNSSEC functions should be operating properly at this time. > > Regards, > > Nate Davis > Chief Operating Officer > American Registry for Internet Numbers > > > > > On 3/7/16, 6:14 PM, "arin-ppml-bounces at arin.net on behalf of Michael > Peddemors" michael at linuxmagic.com> wrote: > >>We had a flurry of reports from various customers, problems with reverse >>DNS lookups.. >> >>Limited to the 65/8 IPv4, and from apparent reports, related to a >>failure to update a DNSSEC signature.. >> >>Reported: Anyone with a DNSSEC enforced name server will have problems >>with PTR queries for that range. >> >>Someone with more inside knowledge can provide more details, I am sure.. >> >> >> >>-- >>"Catch the Magic of Linux..." >>------------------------------------------------------------------------ >>Michael Peddemors, President/CEO LinuxMagic Inc. >>Visit us at http://www.linuxmagic.com @linuxmagic >>------------------------------------------------------------------------ >>A Wizard IT Company - For More Info http://www.wizard.ca >>"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. >>------------------------------------------------------------------------ >>604-682-0300 Beautiful British Columbia, Canada >> >>This email and any electronic data contained are confidential and intended >>solely for the use of the individual or entity to which they are >>addressed. >>Please note that any views or opinions presented in this email are solely >>those of the author and are not intended to represent those of the >>company. >> >>_______________________________________________ >>PPML >>You are receiving this message because you are subscribed to >>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>Unsubscribe or manage your mailing list subscription at: >>http://lists.arin.net/mailman/listinfo/arin-ppml >>Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From chris at semihuman.com Tue Mar 8 11:05:11 2016 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 8 Mar 2016 08:05:11 -0800 Subject: [arin-ppml] Just so it is recorded here (DNSSEC.. ) outages today.. In-Reply-To: References: <56DE0B3C.60903@linuxmagic.com> <000001d178ea$958fe190$c0afa4b0$@iname.com> Message-ID: <37E922BF-B613-4248-96AF-83EB0B8990D2@semihuman.com> Agreed with Chris? sentiment. I?m a firm believer in the blameless post-mortem particularly when paired with action items to avoid repeat occurrences, and I?d hope that others can learn from the technical issues involved. On top of that, everyone loves a good war story :) Thanks, -C > On Mar 8, 2016, at 7:45 AM, Christopher Morrow wrote: > > Also, i'd be super awesome if there would be a pretty detailed > post-mortem document published about what happened, how it happened > and how it was discovered/repaired. > > I believe ARIN isn't the only one having these issues, so publishing > so other folk can learn would be great! > > -crhis > > On Mon, Mar 7, 2016 at 10:28 PM, wrote: >> Nate, >> >> Please let us know if ARIN monitors all their zones for DNSSEC signature >> expiration. >> >> Frank >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Nate Davis >> Sent: Monday, March 07, 2016 7:59 PM >> To: Michael Peddemors ; arin-ppml at arin.net >> Subject: Re: [arin-ppml] Just so it is recorded here (DNSSEC.. ) outages >> today.. >> >> Michael - thanks for reporting the issue. >> >> ARIN Engineering resolved the DNSSEC failure shortly after you reported >> the issue. They are currently looking into the cause of the failure. All >> DNSSEC functions should be operating properly at this time. >> >> Regards, >> >> Nate Davis >> Chief Operating Officer >> American Registry for Internet Numbers >> >> >> >> >> On 3/7/16, 6:14 PM, "arin-ppml-bounces at arin.net on behalf of Michael >> Peddemors" > michael at linuxmagic.com> wrote: >> >>> We had a flurry of reports from various customers, problems with reverse >>> DNS lookups.. >>> >>> Limited to the 65/8 IPv4, and from apparent reports, related to a >>> failure to update a DNSSEC signature.. >>> >>> Reported: Anyone with a DNSSEC enforced name server will have problems >>> with PTR queries for that range. >>> >>> Someone with more inside knowledge can provide more details, I am sure.. >>> >>> >>> >>> -- >>> "Catch the Magic of Linux..." >>> ------------------------------------------------------------------------ >>> Michael Peddemors, President/CEO LinuxMagic Inc. >>> Visit us at http://www.linuxmagic.com @linuxmagic >>> ------------------------------------------------------------------------ >>> A Wizard IT Company - For More Info http://www.wizard.ca >>> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. >>> ------------------------------------------------------------------------ >>> 604-682-0300 Beautiful British Columbia, Canada >>> >>> This email and any electronic data contained are confidential and intended >>> solely for the use of the individual or entity to which they are >>> addressed. >>> Please note that any views or opinions presented in this email are solely >>> those of the author and are not intended to represent those of the >>> company. >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 ndavis at arin.net Tue Mar 8 12:59:10 2016 From: ndavis at arin.net (Nate Davis) Date: Tue, 8 Mar 2016 17:59:10 +0000 Subject: [arin-ppml] Just so it is recorded here (DNSSEC.. ) outages today.. In-Reply-To: <37E922BF-B613-4248-96AF-83EB0B8990D2@semihuman.com> References: <56DE0B3C.60903@linuxmagic.com> <000001d178ea$958fe190$c0afa4b0$@iname.com> <37E922BF-B613-4248-96AF-83EB0B8990D2@semihuman.com> Message-ID: ARIN's DNS process moves DNS data from the internal database to a Secure64 DNSSEC appliance to a hidden distribution master. From the hidden distribution master, zones are fetched to name server constellations from ARIN, VeriSign, and PCH. About two weeks ago a script was run that reset the serial on a zone in the database. This script was run to accommodate an inter-RIR network transfer, and is not executed during the normal course of operations. It reset the serial in our database in an unexpected way, and consequently zone transfers from the Secure64 to our distribution master did not occur. This script was cumbersome and error prone, and had already been identified to be replaced in the upcoming, planned deployment this weekend. This incident exposed a gap in our monitoring that we are fixing. Our current, legacy monitoring system does not adequately identify the serial number inconsistencies between the DNS nodes, nor does it adequately handle issues with DNSSEC signature validation. We have work underway to replace our old monitoring system with a new system that solves these problems. This update is being posted to both arin-ppml and arin-tech-discuss. To avoid non-policy related discussion on PPML, we encourage follow up discussion on arin-tech-discuss, a public mailing list that ARIN?s engineering team monitors. For those not familiar with arin-tech-discuss, please subscribe here: http://lists.arin.net/mailman/listinfo/arin-tech-discuss Regards, Nate Davis On 3/8/16, 11:05 AM, "arin-ppml-bounces at arin.net on behalf of Chris Woodfield" wrote: >Agreed with Chris? sentiment. I?m a firm believer in the blameless >post-mortem particularly when paired with action items to avoid repeat >occurrences, and I?d hope that others can learn from the technical issues >involved. > >On top of that, everyone loves a good war story :) > >Thanks, > >-C > >> On Mar 8, 2016, at 7:45 AM, Christopher Morrow >> wrote: >> >> Also, i'd be super awesome if there would be a pretty detailed >> post-mortem document published about what happened, how it happened >> and how it was discovered/repaired. >> >> I believe ARIN isn't the only one having these issues, so publishing >> so other folk can learn would be great! >> >> -crhis >> >> On Mon, Mar 7, 2016 at 10:28 PM, wrote: >>> Nate, >>> >>> Please let us know if ARIN monitors all their zones for DNSSEC >>>signature >>> expiration. >>> >>> Frank >>> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >>> Behalf Of Nate Davis >>> Sent: Monday, March 07, 2016 7:59 PM >>> To: Michael Peddemors ; arin-ppml at arin.net >>> Subject: Re: [arin-ppml] Just so it is recorded here (DNSSEC.. ) >>>outages >>> today.. >>> >>> Michael - thanks for reporting the issue. >>> >>> ARIN Engineering resolved the DNSSEC failure shortly after you reported >>> the issue. They are currently looking into the cause of the failure. >>>All >>> DNSSEC functions should be operating properly at this time. >>> >>> Regards, >>> >>> Nate Davis >>> Chief Operating Officer >>> American Registry for Internet Numbers >>> >>> >>> >>> >>> On 3/7/16, 6:14 PM, "arin-ppml-bounces at arin.net on behalf of Michael >>> Peddemors" >> michael at linuxmagic.com> wrote: >>> >>>> We had a flurry of reports from various customers, problems with >>>>reverse >>>> DNS lookups.. >>>> >>>> Limited to the 65/8 IPv4, and from apparent reports, related to a >>>> failure to update a DNSSEC signature.. >>>> >>>> Reported: Anyone with a DNSSEC enforced name server will have problems >>>> with PTR queries for that range. >>>> >>>> Someone with more inside knowledge can provide more details, I am >>>>sure.. >>>> >>>> >>>> >>>> -- >>>> "Catch the Magic of Linux..." >>>> >>>>----------------------------------------------------------------------- >>>>- >>>> Michael Peddemors, President/CEO LinuxMagic Inc. >>>> Visit us at http://www.linuxmagic.com @linuxmagic >>>> >>>>----------------------------------------------------------------------- >>>>- >>>> A Wizard IT Company - For More Info http://www.wizard.ca >>>> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices >>>>Ltd. >>>> >>>>----------------------------------------------------------------------- >>>>- >>>> 604-682-0300 Beautiful British Columbia, Canada >>>> >>>> This email and any electronic data contained are confidential and >>>>intended >>>> solely for the use of the individual or entity to which they are >>>> addressed. >>>> Please note that any views or opinions presented in this email are >>>>solely >>>> those of the author and are not intended to represent those of the >>>> company. >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > >_______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. From jschiller at google.com Tue Mar 8 14:01:24 2016 From: jschiller at google.com (Jason Schiller) Date: Tue, 8 Mar 2016 14:01:24 -0500 Subject: [arin-ppml] Thoughts on 2015-7 In-Reply-To: References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com> Message-ID: I haven't seen any progress on this and though I would bump the thread... The problem as I understand it is that transfers are hard, and you cannot predict what you will get approved for. In my simplified approach, an organization should easily know how much address space they are holding, and if it will pass the simple test of: 1. is each aggregate more than 50% in use 2. is all my IP space more that 80% in use. And they know they can complete one or more transfers up to doubling over the next two years. comments in line __Jason On Thu, Feb 11, 2016 at 1:09 AM, Scott Leibrand wrote: > 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".) > Yes. from a simplified perspective... if you have space and it is efficiently utilized (over 80% on average, and not block less than 50%) then you are pre-approved to make one or more transfers within a two year window, up to doubling your current holdings You can re-verify efficient use at any time, and get a new two year window to to make one or more transfers up to doubling your current holdings. The un-simple process is still an avenue. There probably needs to be some accommodation for a simple process for non-address holders. > > 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 >> >> > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.morrow at gmail.com Wed Mar 9 11:34:12 2016 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 9 Mar 2016 11:34:12 -0500 Subject: [arin-ppml] Just so it is recorded here (DNSSEC.. ) outages today.. In-Reply-To: References: <56DE0B3C.60903@linuxmagic.com> <000001d178ea$958fe190$c0afa4b0$@iname.com> <37E922BF-B613-4248-96AF-83EB0B8990D2@semihuman.com> Message-ID: Thanks! (I have a few questions, which may not be answerable here, I suppose.. if they can be answered that'd be cool though) On Tue, Mar 8, 2016 at 12:59 PM, Nate Davis wrote: > > ARIN's DNS process moves DNS data from the internal database to a Secure64 > DNSSEC appliance to a hidden distribution master. From the hidden > distribution > master, zones are fetched to name server constellations from ARIN, > VeriSign, and PCH. > > About two weeks ago a script was run that reset the serial on a zone in > the database. This script was run to accommodate an inter-RIR network This script sounds like something that should/would happen periodically? (whenever there's an xfer I guess?) is that correct? > transfer, and is not executed during the normal course of operations. It > reset the serial in our database in an unexpected way, and consequently > zone transfers from the Secure64 to our distribution master did not occur. > 'unexpected way' was decreased the serial? made it a string not an integer? other? (ie: Can I dork up my zone by setting the serial in the same fashion? what should I look for?) > This script was cumbersome and error prone, and had already been > identified to be replaced in the upcoming, planned deployment this weekend. > neat, ok. > This incident exposed a gap in our monitoring that we are fixing. Our is/was the gap: "Make sure serial is monotonically increasing" or is/was it: "If you are going to backup the serial, be sure to force a reload on all masters via process X" (ie: If I make a serial change, what other things should I look for? what monitoring gap do I also have?) > current, legacy monitoring system does not adequately identify the serial > number inconsistencies between the DNS nodes, nor does it adequately > handle issues with DNSSEC signature validation. We have work underway to > replace our old monitoring system with a new system that solves these > problems. The legacy/current system should be doing the moral equivalane of: for s in $(dig +short NS zone); do dig SOA +short zone @${s} done and make sure that all servers agree that the serial/soa is the same... right? Was there other verification that was happening? (or not) is the above too naive? should we be looking for other things? For dnssec I suppose you'd be doing the above but pulling rrsig for the SOA and making sure they are all the same. > This update is being posted to both arin-ppml and arin-tech-discuss. To > avoid non-policy related discussion on PPML, we encourage follow up > discussion > on arin-tech-discuss, a public mailing list that ARIN?s engineering team > monitors. For those not > familiar with arin-tech-discuss, please subscribe here: > http://lists.arin.net/mailman/listinfo/arin-tech-discuss > oh :) > Regards, > > Nate Davis > > > On 3/8/16, 11:05 AM, "arin-ppml-bounces at arin.net on behalf of Chris > Woodfield" > wrote: > >>Agreed with Chris? sentiment. I?m a firm believer in the blameless >>post-mortem particularly when paired with action items to avoid repeat >>occurrences, and I?d hope that others can learn from the technical issues >>involved. >> >>On top of that, everyone loves a good war story :) >> >>Thanks, >> >>-C >> >>> On Mar 8, 2016, at 7:45 AM, Christopher Morrow >>> wrote: >>> >>> Also, i'd be super awesome if there would be a pretty detailed >>> post-mortem document published about what happened, how it happened >>> and how it was discovered/repaired. >>> >>> I believe ARIN isn't the only one having these issues, so publishing >>> so other folk can learn would be great! >>> >>> -crhis >>> >>> On Mon, Mar 7, 2016 at 10:28 PM, wrote: >>>> Nate, >>>> >>>> Please let us know if ARIN monitors all their zones for DNSSEC >>>>signature >>>> expiration. >>>> >>>> Frank >>>> >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >>>> Behalf Of Nate Davis >>>> Sent: Monday, March 07, 2016 7:59 PM >>>> To: Michael Peddemors ; arin-ppml at arin.net >>>> Subject: Re: [arin-ppml] Just so it is recorded here (DNSSEC.. ) >>>>outages >>>> today.. >>>> >>>> Michael - thanks for reporting the issue. >>>> >>>> ARIN Engineering resolved the DNSSEC failure shortly after you reported >>>> the issue. They are currently looking into the cause of the failure. >>>>All >>>> DNSSEC functions should be operating properly at this time. >>>> >>>> Regards, >>>> >>>> Nate Davis >>>> Chief Operating Officer >>>> American Registry for Internet Numbers >>>> >>>> >>>> >>>> >>>> On 3/7/16, 6:14 PM, "arin-ppml-bounces at arin.net on behalf of Michael >>>> Peddemors" >>> michael at linuxmagic.com> wrote: >>>> >>>>> We had a flurry of reports from various customers, problems with >>>>>reverse >>>>> DNS lookups.. >>>>> >>>>> Limited to the 65/8 IPv4, and from apparent reports, related to a >>>>> failure to update a DNSSEC signature.. >>>>> >>>>> Reported: Anyone with a DNSSEC enforced name server will have problems >>>>> with PTR queries for that range. >>>>> >>>>> Someone with more inside knowledge can provide more details, I am >>>>>sure.. >>>>> >>>>> >>>>> >>>>> -- >>>>> "Catch the Magic of Linux..." >>>>> >>>>>----------------------------------------------------------------------- >>>>>- >>>>> Michael Peddemors, President/CEO LinuxMagic Inc. >>>>> Visit us at http://www.linuxmagic.com @linuxmagic >>>>> >>>>>----------------------------------------------------------------------- >>>>>- >>>>> A Wizard IT Company - For More Info http://www.wizard.ca >>>>> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices >>>>>Ltd. >>>>> >>>>>----------------------------------------------------------------------- >>>>>- >>>>> 604-682-0300 Beautiful British Columbia, Canada >>>>> >>>>> This email and any electronic data contained are confidential and >>>>>intended >>>>> solely for the use of the individual or entity to which they are >>>>> addressed. >>>>> Please note that any views or opinions presented in this email are >>>>>solely >>>>> those of the author and are not intended to represent those of the >>>>> company. >>>>> >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>>> >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage 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 christopher.morrow at gmail.com Wed Mar 9 11:35:41 2016 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 9 Mar 2016 11:35:41 -0500 Subject: [arin-ppml] Just so it is recorded here (DNSSEC.. ) outages today.. In-Reply-To: References: <56DE0B3C.60903@linuxmagic.com> <000001d178ea$958fe190$c0afa4b0$@iname.com> <37E922BF-B613-4248-96AF-83EB0B8990D2@semihuman.com> Message-ID: On Wed, Mar 9, 2016 at 11:34 AM, Christopher Morrow wrote: >> This update is being posted to both arin-ppml and arin-tech-discuss. To >> avoid non-policy related discussion on PPML, we encourage follow up >> discussion >> on arin-tech-discuss, a public mailing list that ARIN?s engineering team >> monitors. For those not >> familiar with arin-tech-discuss, please subscribe here: >> http://lists.arin.net/mailman/listinfo/arin-tech-discuss oh, so... that list archives here: http://lists.arin.net/pipermail/arin-tech-discuss/2016-March/thread.html your message didn't make it to the list? (I think, if I'm reading the archive correctly at least) -chris From ndavis at arin.net Wed Mar 9 13:24:36 2016 From: ndavis at arin.net (Nate Davis) Date: Wed, 9 Mar 2016 18:24:36 +0000 Subject: [arin-ppml] Just so it is recorded here (DNSSEC.. ) outages today.. In-Reply-To: References: <56DE0B3C.60903@linuxmagic.com> <000001d178ea$958fe190$c0afa4b0$@iname.com> <37E922BF-B613-4248-96AF-83EB0B8990D2@semihuman.com> Message-ID: On 3/9/16, 11:35 AM, "Christopher Morrow" wrote: >On Wed, Mar 9, 2016 at 11:34 AM, Christopher Morrow > wrote: >>> This update is being posted to both arin-ppml and arin-tech-discuss. >>>To >>> avoid non-policy related discussion on PPML, we encourage follow up >>> discussion >>> on arin-tech-discuss, a public mailing list that ARIN?s engineering >>>team >>> monitors. For those not >>> familiar with arin-tech-discuss, please subscribe here: >>> http://lists.arin.net/mailman/listinfo/arin-tech-discuss > > >oh, so... that list archives here: >http://lists.arin.net/pipermail/arin-tech-discuss/2016-March/thread.html > >your message didn't make it to the list? (I think, if I'm reading the >archive correctly at least) > >-chris Chris - you are correct in that my PPML message did not make it to arin-tech-discuss but now has - along with your follow up questions regarding ARIN?s DNSSEC issue. Mark Kosters will be responding to your questions through arin-tech-discuss. Best Regards, Nate From narten at us.ibm.com Fri Mar 11 00:53:02 2016 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 11 Mar 2016 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201603110553.u2B5r2SY009333@rotala.raleigh.ibm.com> Total of 11 messages in the last 7 days. script run at: Fri Mar 11 00:53:02 EST 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 27.27% | 3 | 25.91% | 31955 | christopher.morrow at gmail.com 27.27% | 3 | 22.30% | 27504 | ndavis at arin.net 9.09% | 1 | 26.06% | 32141 | jschiller at google.com 9.09% | 1 | 7.91% | 9752 | chris at semihuman.com 9.09% | 1 | 7.14% | 8812 | frnkblk at iname.com 9.09% | 1 | 5.66% | 6981 | narten at us.ibm.com 9.09% | 1 | 5.02% | 6190 | michael at linuxmagic.com --------+------+--------+----------+------------------------ 100.00% | 11 |100.00% | 123335 | Total From christopher.morrow at gmail.com Tue Mar 15 17:09:53 2016 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 15 Mar 2016 17:09:53 -0400 Subject: [arin-ppml] Just so it is recorded here (DNSSEC.. ) outages today.. In-Reply-To: References: <56DE0B3C.60903@linuxmagic.com> <000001d178ea$958fe190$c0afa4b0$@iname.com> <37E922BF-B613-4248-96AF-83EB0B8990D2@semihuman.com> Message-ID: On Wed, Mar 9, 2016 at 1:24 PM, Nate Davis wrote: > On 3/9/16, 11:35 AM, "Christopher Morrow" > Chris - you are correct in that my PPML message did not make it to > arin-tech-discuss but now has - along with your > follow up questions regarding ARIN?s DNSSEC issue. > thanks! (and yikes, I forgot to deal with the subscription automessage, darn!) > Mark Kosters will be responding to your questions through > arin-tech-discuss. great! I'll go read and reply (now that I actually did subscribe) From narten at us.ibm.com Fri Mar 18 00:53:03 2016 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 18 Mar 2016 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201603180453.u2I4r3p9015451@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri Mar 18 00:53:02 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 51.04% | 7283 | christopher.morrow at gmail.com 50.00% | 1 | 48.96% | 6985 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 14268 | Total From David_Huberman at outlook.com Tue Mar 22 12:03:03 2016 From: David_Huberman at outlook.com (David Huberman) Date: Tue, 22 Mar 2016 16:03:03 +0000 Subject: [arin-ppml] Hijackings on the increase? Message-ID: Hello, I'm at the ARIN On the Road event in Austin, TX today. Eddie Diego from the ARIN staff is giving an excellent talk on registration services. He has pointed out in his slides, however, that hijackings of address blocks in Whois is on the rise. Can someone at ARIN please discuss this a little on PPML -- data, things we can do to minimize risk, etc. Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at sandiford.com Tue Mar 22 12:36:13 2016 From: bill at sandiford.com (Bill Sandiford) Date: Tue, 22 Mar 2016 12:36:13 -0400 Subject: [arin-ppml] Hijackings on the increase? In-Reply-To: References: Message-ID: Interestingly enough, a few of the IXPs operating in Canada had adverse affects 48 hours ago as a result of an attempted (successful?!?) hijacking attempt of the IPv4 blocks used on their peering LANs. > On Mar 22, 2016, at 12:03 PM, David Huberman wrote: > > Hello, > > I'm at the ARIN On the Road event in Austin, TX today. Eddie Diego from the ARIN staff is giving an excellent talk on registration services. He has pointed out in his slides, however, that hijackings of address blocks in Whois is on the rise. > > Can someone at ARIN please discuss this a little on PPML -- data, things we can do to minimize risk, etc. > > Thanks, > David > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Tue Mar 22 12:54:48 2016 From: info at arin.net (ARIN) Date: Tue, 22 Mar 2016 12:54:48 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - March 2016 Message-ID: <56F178D8.6050505@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) met on 17 March 2016. The AC recommended the following to the ARIN Board of Trustees for adoption: 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 The AC accepted the following Proposal as a Draft Policy (it will be posted for discussion): Draft Policy 2016-1 Reserved Pool Transfer Policy The AC abandoned the following: Draft Policy ARIN-2015-6: Transfers and Multi-national Networks The AC stated, "The ARIN Advisory Council based on input from the community has voted to abandon ARIN 2015-6 Transfers and Multi-National Networks. The proposal was similar to ARIN 2015-5 Out of Region Use, which has completed last call and been recommended for Adoption. The community feedback was to maintain the proposal as a secondary option, with 2015-5 as the preferred course of action." The AC is continuing to work on: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy 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 The AC abandoned 2015-6. Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Mar 22 12:55:21 2016 From: info at arin.net (ARIN) Date: Tue, 22 Mar 2016 12:55:21 -0400 Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy Message-ID: <56F178F9.7020608@arin.net> Draft Policy ARIN-2016-1 Reserved Pool Transfer Policy On 17 March 2016 the ARIN Advisory Council (AC) accepted "ARIN-prop-226 Reserved Pool Transfer Policy" as a Draft Policy. Draft Policy ARIN-2016-1 is below and can be found at: https://www.arin.net/policy/proposals/2016_1.html You are encouraged to discuss the merits and your concerns of Draft Policy 2016-1 on the Public Policy Mailing List. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (PDP) can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2016-1 Reserved Pool Transfer Policy Date: 22 March 2016 Problem Statement: Section 8 of the current NRPM does not distinguish between the transfer of blocks from addresses that have been reserved for specific uses and other addresses that can be transferred. In sections 4.4 and 4.10 there are specific address blocks set aside, based on the need for critical infrastructure and IPv6 transitions. Two issues arise if transfers of reserved address space occur under the current language of section 8. First, if transfers of 4.4 or 4.10 space occur under the current policy requirements set forth in sections 8.3 and 8.4, the recipients will be able to acquire space that was originally reserved for a specific purpose without ever providing evidence that they will be using the space for either critical infrastructure or IPv6 transition. Second, if we allow an allocation or assignment from the block reserved in section 4.10 to be transferred out of the region, it would complicate the single aggregate from which providers are being asked to allow in block sizes smaller than a /24. This policy would limit the transfer of addresses from reserved pools. Policy statement: Add to Section 8.3 and Section 8.4 under the "Conditions on source of the transfer:" Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer. Timetable for implementation: Immediate From richardj at arin.net Wed Mar 23 10:14:40 2016 From: richardj at arin.net (Richard Jimmerson) Date: Wed, 23 Mar 2016 14:14:40 +0000 Subject: [arin-ppml] Hijackings on the increase? Message-ID: <56D9A1DB-E4A8-4423-A1DB-93949F2E184E@arin.net> Hello David, There has been an increase in organization and point of contact recovery requests in the past six months. These recovery requests are increasingly targeted at organizations and/or points of contact that have not been maintained in ARIN?s database for up to ten years or more. ARIN staff uses internal practices developed over the last several years to verify the legitimacy of these requests. Their processing is very similar to the chain of custody and verification work conducted for transfers. We are finding a larger than usual number of these requests either being denied by ARIN staff or abandoned by the individual who submitted them. An increasing number of these requests appear to be hijacking attempts of legacy IPv4 registrations. One thing that might help would be if organizations that have performed acquisitions over the years would be more proactive in updating their registrations at ARIN. This reduces the number of resources that have outdated information and thus reduces the potential target area in the registry for hijacking attacks. We will be reporting on this and other registration trends we are experiencing at the upcoming ARIN meeting that takes place in April. Regards, Richard Jimmerson CIO & Acting Director of Registration Services American Registry for Internet Numbers From: > on behalf of David Huberman > Date: Tuesday, March 22, 2016 at 12:03 PM To: "arin-ppml at arin.net" > Subject: [arin-ppml] Hijackings on the increase? Hello, I'm at the ARIN On the Road event in Austin, TX today. Eddie Diego from the ARIN staff is giving an excellent talk on registration services. He has pointed out in his slides, however, that hijackings of address blocks in Whois is on the rise. Can someone at ARIN please discuss this a little on PPML -- data, things we can do to minimize risk, etc. Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Thu Mar 24 16:25:15 2016 From: info at arin.net (ARIN) Date: Thu, 24 Mar 2016 16:25:15 -0400 Subject: [arin-ppml] Update "return" language for 8.2 M&A transfers - Notice of intent to make editorial update Message-ID: <56F44D2B.3000501@arin.net> The ARIN Advisory Council (AC) has requested that the following proposed editorial update to the Number Resource Policy Manual (NRPM) be posted for review by the community. The review period will close on 23 April 2016. The AC provided the following statement: ---- Update "return" language for 8.2 M&A transfers "The policy experience report at ARIN 36 highlighted an issue in the current 8.2 Mergers & Acquisitions Transfer Policy. The current policy uses the phrase "work with the resource holder(s) to return". The word "return" in this context is being misinterpreted by organizations as "revoke." https://www.arin.net/participate/meetings/reports/ARIN_36/PDF/thursday/jimmerson_policy.pdf The goal of this policy is to clarify that returns are voluntary actions by an organization and ARIN does not revoke address blocks for under-utilization under section 6 the current Registration Services Agreement (RSA). https://www.arin.net/resources/agreements/rsa.pdf Based on this position, the ARIN AC proposes that the following editorial change be made to the NRPM. Replace NRPM 8.2 paragraph: In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy. With the following paragraph: ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN policy. In that event, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN. ---- The process for editorial updates to the NRPM is found in Part One, Section 3.1, paragraph 3 of the PDP: "Changes to policy that are purely editorial and non-substantial in nature are outside the scope of the full Policy Development Process and may only be made with 30 days public notice followed by the concurrence of both the ARIN Advisory Council and ARIN Board of Trustees that the changes are non-substantial in nature." The ARIN Number Resource Policy Manual is here: https://www.arin.net/policy/nrpm.html 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 narten at us.ibm.com Fri Mar 25 00:53:02 2016 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 25 Mar 2016 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201603250453.u2P4r3gc006013@rotala.raleigh.ibm.com> Total of 7 messages in the last 7 days. script run at: Fri Mar 25 00:53:02 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 42.86% | 3 | 30.47% | 20992 | info at arin.net 14.29% | 1 | 24.29% | 16734 | richardj at arin.net 14.29% | 1 | 22.45% | 15464 | bill at sandiford.com 14.29% | 1 | 13.01% | 8960 | david_huberman at outlook.com 14.29% | 1 | 9.79% | 6746 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 7 |100.00% | 68896 | Total