From eden.mononym at icloud.com Wed Mar 1 12:55:48 2017 From: eden.mononym at icloud.com (Eden Mononym) Date: Wed, 01 Mar 2017 17:55:48 +0000 (GMT) Subject: [arin-ppml] Hello World Message-ID: <84a329f3-0ce1-45e4-8819-d04372c111b3@me.com> Hello, I am Robert Walthall (Formerly of Buchla Electronic Musical Instruments) Just saying hi! :) Cant wait to see positive changes. All the best, Robert [Artist: Eden Mononym????? Web: www.edenmononym.com ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Mar 3 00:53:23 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 03 Mar 2017 00:53:23 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201703030553.v235rNWj008954@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri Mar 3 00:53:18 EST 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 50.91% | 8859 | eden.mononym at icloud.com 50.00% | 1 | 49.09% | 8543 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 17402 | Total From narten at us.ibm.com Fri Mar 10 00:53:22 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 10 Mar 2017 00:53:22 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201703100553.v2A5rMXa027368@rotala.raleigh.ibm.com> Total of 1 messages in the last 7 days. script run at: Fri Mar 10 00:53:17 EST 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 8488 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 8488 | Total From owen at delong.com Thu Mar 16 13:17:18 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Mar 2017 10:17:18 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers In-Reply-To: References: <58AC9BC4.3040804@arin.net> <6C3DCB05-5F93-4A04-8CE7-59F1D4FCB36B@delong.com> Message-ID: <4F4E0DD5-05C8-4782-A108-D8087940CF5E@delong.com> I?m saying that the alternate text Scott proposed is actually harder to understand and has the additional negative potential for unintended consequences of accidental desynchronization. Owen > On Feb 22, 2017, at 12:00 PM, Jason Schiller wrote: > > Owen, > > Just to be clear. You think the text as written is better, more understandable, and clearer, but you believe it will still operate the same way regardless of the text, namely: > > Once approved for a certain size block, you can complete multiple transfers that add up to that size within a two year window. > > ___Jason > > On Wed, Feb 22, 2017 at 2:15 PM, Owen DeLong > wrote: > I disagree? First, I think it?s actually harder to understand. Second, I think it is a bad idea to create multiple specifications or specification points for the pre-authorization window because it creates a potential for accidental desynchronization in future policy efforts. > > Owen > >> On Feb 22, 2017, at 10:48 , Jason Schiller > wrote: >> >> I got the impression from Scott that alternate text was more clear and preferred. >> (note I'm not advocating for it, I believe it has no impact on implementation). >> >> 8.5.7 Alternative Additional IPv4 Address Block Criteria >> >> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 address blocks by demonstrating 80% utilization of their currently allocated space. If they do so, they are pre-authorized for a two year window to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16. >> >> An organization may qualify via 8.5.7 for a total of a /16 equivalent in any 6 month period. >> >> ___Jason >> >> On Tue, Feb 21, 2017 at 2:57 PM, ARIN > wrote: >> On 16 February 2017 the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status: >> >> ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers >> >> The text of the Recommended Draft Policy is below, and may also be found at: >> https://www.arin.net/policy/proposals/2016_3.html >> >> You are encouraged to discuss all Recommended Draft Policies on PPML >> prior to their presentation at the next ARIN Public Policy Meeting (PPM) or Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus. >> >> The PDP can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers >> >> Version Date: 16 February 2017 >> >> AC's Statement of Conformance with ARIN's Principles of Internet Number Resource Policy >> >> This proposal is technically sound and enables fair and impartial number policy by allowing transfers to specified recipients of blocks of a certain size to occur without a needs assessment performed by ARIN staff. The Staff and Legal Assessment raised no material issues, and there has been consistent support on both the mailing list and at the Dallas ARIN meeting for incorporating this mechanism into NRPM. >> >> Problem Statement: >> >> ARIN transfer policy currently inherits all its demonstrated need requirements for IPv4 transfers from NRPM sections 4. Because that section was written primarily to deal with free pool allocations, it is much more complicated than is really necessary for transfers. >> >> This proposal allows organizations using 80% of their current space to double their current holdings via 8.3 or 8.4 specified transfers, up to a /16 equivalent. >> >> Policy Statement: >> >> Add a new section: >> >> 8.5.7 Alternative Additional IPv4 Address Block Criteria >> >> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 address blocks by demonstrating 80% utilization of their currently allocated space. If they do so, they qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16. >> >> An organization may qualify via 8.5.7 for a total of a /16 equivalent in any 6 month period. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com |571-266-0006 >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com |571-266-0006 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Mar 17 00:53:27 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 17 Mar 2017 00:53:27 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201703170453.v2H4rSFa005781@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri Mar 17 00:53:22 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 74.59% | 23769 | owen at delong.com 50.00% | 1 | 25.41% | 8098 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 31867 | Total From job at ntt.net Mon Mar 20 19:58:39 2017 From: job at ntt.net (Job Snijders) Date: Tue, 21 Mar 2017 00:58:39 +0100 Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement? In-Reply-To: References: <20170130084222.GA1111@hanna.meerval.net> <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net> <20170130201400.GD35120@Vurt.local> Message-ID: <20170320235839.cv2rsquynpcqgobu@Vurt.local> Dear John, On Tue, Jan 31, 2017 at 09:42:50PM +0000, John Curran wrote: > On 30 Jan 2017, at 3:14 PM, Job Snijders wrote: > >> Is it the presence of legal constraints that it is the concern, or > >> the fact that ARIN requires explicit downloading (and thus > >> awareness of this fact) that is the issue? > > > > Both are a concern. Please note that I am not advocating that all > > legal constraints should be lifted, for me its the results that > > matter: at this point in time it appears that ARIN's TAL is not > > bundled with common RPKI tools, and that to me is a problem. > > > > While ARIN?s Board of Trustees has been quite consistent in its > position that RPKI services are to be offered under clear terms and > conditions, I will also bring this email thread to their attention for > further consideration. I was wondering whether you can provide the community with an update on this issue. Kind regards, Job From jcurran at arin.net Tue Mar 21 08:40:09 2017 From: jcurran at arin.net (John Curran) Date: Tue, 21 Mar 2017 12:40:09 +0000 Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement? In-Reply-To: <20170320235839.cv2rsquynpcqgobu@Vurt.local> References: <20170130084222.GA1111@hanna.meerval.net> <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net> <20170130201400.GD35120@Vurt.local> <20170320235839.cv2rsquynpcqgobu@Vurt.local> Message-ID: On 20 Mar 2017, at 7:58 PM, Job Snijders wrote: > > Dear John, > > On Tue, Jan 31, 2017 at 09:42:50PM +0000, John Curran wrote: >> On 30 Jan 2017, at 3:14 PM, Job Snijders wrote: >>>> Is it the presence of legal constraints that it is the concern, or >>>> the fact that ARIN requires explicit downloading (and thus >>>> awareness of this fact) that is the issue? >>> >>> Both are a concern. Please note that I am not advocating that all >>> legal constraints should be lifted, for me its the results that >>> matter: at this point in time it appears that ARIN's TAL is not >>> bundled with common RPKI tools, and that to me is a problem. >> >> >> >> While ARIN?s Board of Trustees has been quite consistent in its >> position that RPKI services are to be offered under clear terms and >> conditions, I will also bring this email thread to their attention for >> further consideration. > > I was wondering whether you can provide the community with an update on > this issue. Job - Yes (and I should probably have been clearer in setting expectations in this regard...) There is no update yet, as the next face-to-face meeting of the Board of Trustees hasn?t yet occurred. Best ETA for an update is mid-April. Thanks! /John John Curran President and CEO ARIN From info at arin.net Tue Mar 21 13:26:40 2017 From: info at arin.net (ARIN) Date: Tue, 21 Mar 2017 13:26:40 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - March 2017 Message-ID: <58D16250.2020607@arin.net> In accordance with the Policy Development Process (PDP), the Advisory Council (AC) met on 16 March 2017. The AC has advanced the following Proposals to Draft Policy status (each will be posted for discussion): * ARIN-prop-237: Clarify Slow Start for Transfers * ARIN-prop-238: Removal of Community Networks * ARIN-prop-239: Update to NPRM 3.6: Annual Whois POC Validation The AC advances Proposals to Draft Policy status once they are found to be within the scope of the PDP, and contain a clear problem statement and suggested changes to Internet number resource policy text. The AC has advanced the following to Recommended Draft Policy status (will be posted separately as such): * ARIN-2016-9: Streamline Merger & Acquisition Transfers The AC advances Draft Policies to Recommended Draft Policy status once they have been fully developed and meet ARIN's Principles of Internet Number Resource Policy. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The AC is continuing to work on: * Draft Policy ARIN-2016-3: Alternative Simplified Criteria for Justifying Small IPv4 Transfers * Draft Policy ARIN-2016-8: Removal of Indirect POC Validation Requirement * ARIN-prop-235: Clarify generic references to "IP Addresses" in NRPM * ARIN-prop-236: Remove reciprocity requirement for inter-RIR transfers The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) From info at arin.net Tue Mar 21 13:31:09 2017 From: info at arin.net (ARIN) Date: Tue, 21 Mar 2017 13:31:09 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers Message-ID: <58D1635D.8090702@arin.net> On 16 March 2017, the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status: ARIN-2016-9: Streamline Merger & Acquisition Transfers The text of the Recommended Draft Policy is below, and may also be found at: https://www.arin.net/policy/proposals/2016_9.html You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus. The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers Date: 21 March 2017 AC assessment of conformance with the Principles of Internet Number Resource Policy: The proposal is technically sound and enables fair and impartial number policy by ensuring that new organizations involved in mergers and acquisitions may conduct such activities with a reduced procedural burden from ARIN. The staff and legal review noted three issues, all of which have been addressed. There is support for the proposal on PPML and concerns that have been raised by the community regarding the proposal on PPML or elsewhere have also been addressed. Problem Statement: In some 8.2 transfer situations, the current policy has the unwanted side effect of encouraging organizations not to update registration data, thus leaving the number resource in the name of a now defunct entity. It is not uncommon for an entity which has bought another entity (with existing number resources) to leave Organizational data (Whois) in the name of the acquired company. The requirements in Section 8.2 put a justification burden on the acquiring organization, which was a legitimate protection while free pool assignments were available. It is worth revisiting Section 8.2 and looking for opportunities to simplify the policy in the interest of improving the registry data. Consider the following: 1. In the case where both organizations (acquirer, acquired) have justified their existing number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the policies that were in force at the time of issuance, the number resources have already been justified once. 2. ARIN does not customarily require organizations holding address space to document utilization except when they are asking ARIN to issue more space. 3. Section 8.2 M&A is not asking ARIN to issue more space or provide authorization to acquire space in an 8.3 transfer. It is simply updating ARIN's database to reflect the current reality, that control of a company has changed. Language that speaks of required return or transfer of space is of questionable enforceability in the context of the current RSA (section 6, "ARIN has no right to revoke any Included Number Resources under this Agreement due to lack of utilization by Holder"). Clauses that serve to scare organizations away from updating their information are counter to the goal of maintaining good data in Whois. Policy should allow ARIN staff to concentrate finite resources on ascertaining chain of custody so as to minimize the chance of fraudulent transfers rather than auditing space already issued. Policy statement: Delete the bullet point in NRPM 8.2 that reads: For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation. Add this statement to list of conditions for clarity: "The Internet number resources being transferred as part of an 8.2 transfer will not be subject to an additional needs-based assessment during the process of the 8.2 transfer." Add this conditional to the bottom of 8.2 for linguistic clarity: "AND one or more of the following: The recipient must provide evidence that they have acquired the assets that use the resources to be transferred from the current registrant. OR The recipient must show that they have acquired the entire entity which is the current registrant." Remove the following paragraph from Section 8.2 of the NRPM: ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. 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. These four changes will leave Section 8.2 looking like this: 8.2. Mergers and Acquisitions ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions: The current registrant must not be involved in any dispute as to the status of the resources to be transferred. The new entity must sign an RSA covering all resources to be transferred. The resources to be transferred will be subject to ARIN policies. The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy. The Internet number resources being transferred as part of an 8.2 transfer will not be subject to an additional needs-based assessment during the process of the 8.2 transfer. AND one or more of the following: The recipient must provide evidence that they have acquired the assets that use the resources to be transferred from the current registrant. OR The recipient must show that they have acquired the entire entity which is the current registrant. Comments: Timetable for implementation: Immediate From info at arin.net Tue Mar 21 13:34:53 2017 From: info at arin.net (ARIN) Date: Tue, 21 Mar 2017 13:34:53 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-1: Clarify Slow Start for Transfers Message-ID: <58D1643D.3000604@arin.net> On 16 March 2017, the ARIN Advisory Council (AC) accepted "ARIN-prop-237: Clarify Slow Start for Transfers" as a Draft Policy. Draft Policy text is below and can be found at: https://www.arin.net/policy/proposals/2017_1.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-1: Clarify Slow Start for Transfers Date: 21 March 2017 With the adoption of 2015-5, transfer policy is severed from ARIN allocation / assignment policy. It is no longer clear how slow start applies (if at all) to justifying a transfer. Having a slow start algorithm available to the transfer market will make for a more predictable and more right sized blocks in line with organizational growth. Problem Discussion: In a pre-transfer world ISPs who are growing rapidly, or have no history of utilization to support their IPv4 two year growth requirements, could qualify under slow start. The initial block was either a small block (between /24 and /21), or double what they efficiently used in the previous year. If thate space was used in less than a year, they could get twice as much the next time. The implementation of Policy 2016-5 severs transfer policy form section 4 where the slow start rules are defined. As a result it is unclear if the slow start process can be used to justify a specified transfer. Additionally, the inability to complete regular transfers could lead to a situation where lack of IPv4 addresses is rate limiting deployment. As a result demonstrated utilization of the last 12 months may not be indicative of actual growth. NRPM 8.5.3 / 8.5.4 (ARIN Policy 2016-4) supports an initial block of only a /24 if there is no allocation or assignment. Policy Proposal 2016-3 (the sister policy to 2016-4) supports a larger block (after demonstration of efficient utilization) equal to their current holdings up to a /16 every 6 months. Because 2016-3 no longer permits using a /16 at a time and demonstrating utilization before coming back for another, organizations who are growing at more than a /15 a year are forced to use the two year forward looking projected growth as justification. This prediction is difficult to measure, difficult to justify, difficult to verify, and provides unpredictability to the amount of time a justification requires to be processed, and the likelihood of approval. This process favors organizations who more aggressively optimistic and has no penalty if an organization fails to meet their plans. Problem solution: Permit organizations who demonstrate efficient utilization to use the utilization of their most recent specified transfer(s) to extrapolate a two year growth projection allowing a specified transfer of up to double the size of the transfers used in the justification. Policy statement: Current policy: 8.5.5. Block size Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN. Proposed changes: Add the following to the end of 8.5.5: Organizations may demonstrate a 24 month future projection based on the average amount of time required to efficiently utilize one or more of their most recent specified transfers. The organization must show efficient utilization of at least 50% of all specified transfers from the current date back to the the date of the earliest specified transfer included in the request. The organization will be pre-authorized for a two year window to complete one or more specified transfers up to the total number of IPv4 addresses of the transfers included in the request, divided by the number of days (no less than 90) since the earliest specified transfer included in the request was completed, multiplied by 730. Comments: Timetable for implementation: Immediate From info at arin.net Tue Mar 21 13:35:26 2017 From: info at arin.net (ARIN) Date: Tue, 21 Mar 2017 13:35:26 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-2: Removal of Community Networks Message-ID: <58D1645E.4070101@arin.net> On 16 March 2017, the ARIN Advisory Council (AC) accepted "ARIN-prop-238: Removal of Community Networks" as a Draft Policy. Draft Policy text is below and can be found at: https://www.arin.net/policy/proposals/2017_2.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-2: Removal of Community Networks Date: 21 March 2017 Problem Statement: The Community Networks section of the NRPM has not been utilized since it was implemented in January 2010. A recent policy ARIN-2016-7, to increase the number of use cases, was abandoned by the Advisory Council due to lack of feedback. The policy should be removed to simplify the NRPM. Policy statement: Remove the following 2 sections. 2.11 Community Network 6.5.9 Community Network Assingments Comments: Timetable for implementation: Immediate From info at arin.net Tue Mar 21 13:36:20 2017 From: info at arin.net (ARIN) Date: Tue, 21 Mar 2017 13:36:20 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation Message-ID: <58D16494.1000708@arin.net> On 16 March 2017, the ARIN Advisory Council (AC) accepted "ARIN-prop-239: Update to NPRM 3.6: Annual Whois POC Validation" as a Draft Policy. Draft Policy text is below and can be found at: https://www.arin.net/policy/proposals/2017_3.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation Date: 21 March 2017 Problem Statement: The ARIN public access WHOIS directory service is used by the general public and organizations charged with the protection of the public, for a wide variety of purposes, including: ? Assuring the security and reliability of the network by identifying points of contact for IP number resource for network operators, ISPs, and certified computer incident response teams; ? Assisting businesses, consumer groups, medical and healthcare organizations, and other organizations in combating abuse; ? Assisting organizations responsible for the safety of the general public in finding information about potential offenders using IP number resources so that the organizations are able to comply with national, civil and criminal due process laws and to provide justice for victims; and ? Ensuring IP number resource holders worldwide are properly registered, so individuals, consumers and the public are empowered to resolve abusive practices that impact safety and security. Organizations charged with the protection of the public, including consumer protection, civil safety and law enforcement, utilize the ARIN public access WHOIS directory in their investigations. From a public safety perspective, the failure to have accurate ARIN public access WHOIS information can present the following challenges: ? Ability of public safety and law enforcement agencies to rapidly identify IP number resources used in on-going abusive activities; ? Wasted network operator resources spent on responding to potentially misdirected legal requests; and ? Domain name and IP number resources hijacking, resulting in the potential use of those domain names and IP number resources for criminal activity. As the amount of criminal activity enabled by the Internet continues to grow globally, users whose IP number resources are abused (for example, by spamming, IP address spoofing, DDOS attacks, etc.) need to be able to obtain redress. For organizations tasked with protecting the general public, one of the most important registration records in the ARIN public access WHOIS directory is that of the last ISP in the chain of network operators providing connectivity. To ensure the accuracy of the WHOIS directory and to facilitate timely/effective response to abusive and criminal activity, the ARIN public access WHOIS directory must be up-to-date and map IP number resources to the correct network provider. Privacy, safety and security are all equally important outcomes, and depend, to a large extent, on the accuracy of the ARIN public access WHOIS directory. The problem of potentially inaccurate information is most acute with registrations that were given out prior to the formation of ARIN. These registrations, often termed "legacy" are held by thousands of entities that do not have updated and verified points of contact that are able to be found in the public access WHOIS directory. Many of the original points of contact were removed, and replaced with placeholder records that do not provide any value. This inaccurate information leaves victims and responders without the means of proper redress. Lastly, current ARIN practices do not allow organizations that have been merged or acquired to update their point of contact records without having to enter into a contractual relationship with ARIN. This causes many organizations to not go through the process of updating even their point of contact records. Policy statement: Current text: 3.6 Annual Whois POC Validation 3.6.1 Method of Annual Verification During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy. Proposed revised text: 3.6 Annual Validation of ARIN's Public Access WHOIS Point of Contact Data 3.6.1 Annual POC Verification ARIN will perform an annual verification of point of contact data each year on the date the POC was registered, beginning on January 1 each year using the procedure provided in 3.6.4. 3.6.2 Specified Public WHOIS Points of Contact for Verification Each of the following Points of Contact are to be verified annually and will be referred to as Points of Contact throughout this policy: - Admin - Tech - NOC - Abuse 3.6.3 Organizations Covered by this Policy This policy applies to every Organization that holds a direct assignment, direct allocation, AS number or reallocation from ARIN. This includes but is not limited to upstream ISPs and downstream ISP customers (as defined by NRPM 2.5 and 2.6), but not reassignments made to downstream customers or end user customers. 3.6.4 Procedure to Increase Valid Legacy Point of Contact Participation To encourage Organizations that are deemed to be "legacy" (ones that predated the existence of ARIN and do not have a contractual relationship with ARIN), legacy resource holders shall be able to update the points of contact for the Organization without entering into a contractual relationship with ARIN. 3.6.5 ARIN Staff Procedure for Verification Email notification will be sent to each of the Points of Contact in section 3.6.2 on an annual basis. Each Point of Contact will have up to sixty (60) days from the date of the notification in which to respond with confirmation as to the public WHOIS contact data or to submit data to correct and complete it. Validation can occur via the ARIN Online account, or, alternatively, by clicking the validation link in the email notification. After the sixty (60) day period, non-responsive Point of Contact records will be marked as "non-responsive" in the public WHOIS directory. 3.6.7 Non-Responsive Point of Contact Records After an additional ninety (90) days after the Point of Contact record has been marked as "non-responsive", ARIN's staff after through research and analysis, will mark those non validated, abandoned or otherwise illegitimate POC records "invalid". Records marked "invalid" will be taken out of the reverse DNS and their associated resources will be removed from the public WHOIS, thereby disabling reverse DNS. ARIN will make available the necessary resources to ensure enforcement of this policy. Comments: Timetable for implementation: to be based upon discussions with ARIN's staff. From scottleibrand at gmail.com Tue Mar 21 14:10:19 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 21 Mar 2017 11:10:19 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers In-Reply-To: <58D1635D.8090702@arin.net> References: <58D1635D.8090702@arin.net> Message-ID: <8E59E243-A70C-413A-82EF-25AB24329FFE@gmail.com> I support this policy: I think that text being removed has reached the end of its useful life, and keeping it in place will do more harm than good in the future. Scott > On Mar 21, 2017, at 10:31 AM, ARIN wrote: > > On 16 March 2017, the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status: > > ARIN-2016-9: Streamline Merger & Acquisition Transfers > > The text of the Recommended Draft Policy is below, and may also be found at: > > https://www.arin.net/policy/proposals/2016_9.html > > You are encouraged to discuss all Recommended Draft Policies on PPML > prior to their presentation at the next ARIN Public Policy Consultation > (PPC). PPML and PPC discussions are invaluable to the AC when > determining community consensus. > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > > Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers > > Date: 21 March 2017 > > AC assessment of conformance with the Principles of Internet Number > Resource Policy: > > The proposal is technically sound and enables fair and impartial number policy by ensuring that new organizations involved in mergers and acquisitions may conduct such activities with a reduced procedural burden from ARIN. The staff and legal review noted three issues, all of which have been addressed. There is support for the proposal on PPML and concerns that have been raised by the community regarding the proposal on PPML or elsewhere have also been addressed. > > Problem Statement: > > In some 8.2 transfer situations, the current policy has the unwanted side effect of encouraging organizations not to update registration data, thus leaving the number resource in the name of a now defunct entity. > > It is not uncommon for an entity which has bought another entity (with existing number resources) to leave Organizational data (Whois) in the name of the acquired company. The requirements in Section 8.2 put a justification burden on the acquiring organization, which was a legitimate protection while free pool assignments were available. It is worth revisiting Section 8.2 and looking for opportunities to simplify the policy in the interest of improving the registry data. > > Consider the following: > > 1. In the case where both organizations (acquirer, acquired) have justified their existing number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the policies that were in force at the time of issuance, the number resources have already been justified once. > > 2. ARIN does not customarily require organizations holding address space to document utilization except when they are asking ARIN to issue more space. > > 3. Section 8.2 M&A is not asking ARIN to issue more space or provide authorization to acquire space in an 8.3 transfer. It is simply updating ARIN's database to reflect the current reality, that control of a company has changed. > > Language that speaks of required return or transfer of space is of questionable enforceability in the context of the current RSA (section 6, "ARIN has no right to revoke any Included Number Resources under this Agreement due to lack of utilization by Holder"). > > Clauses that serve to scare organizations away from updating their information are counter to the goal of maintaining good data in Whois. > Policy should allow ARIN staff to concentrate finite resources on ascertaining chain of custody so as to minimize the chance of fraudulent transfers rather than auditing space already issued. > > Policy statement: > > Delete the bullet point in NRPM 8.2 that reads: > > For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation. > > Add this statement to list of conditions for clarity: > > "The Internet number resources being transferred as part of an 8.2 transfer will not be subject to an additional needs-based assessment during the process of the 8.2 transfer." > > Add this conditional to the bottom of 8.2 for linguistic clarity: > > "AND one or more of the following: > > The recipient must provide evidence that they have acquired the assets that use the resources to be transferred from the current registrant. > > OR > > The recipient must show that they have acquired the entire entity which is the current registrant." > > Remove the following paragraph from Section 8.2 of the NRPM: > > ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. 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. > > These four changes will leave Section 8.2 looking like this: > > 8.2. Mergers and Acquisitions > > ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions: > > The current registrant must not be involved in any dispute as to the status of the resources to be transferred. > > The new entity must sign an RSA covering all resources to be transferred. > > The resources to be transferred will be subject to ARIN policies. > > The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy. > > The Internet number resources being transferred as part of an 8.2 transfer will not be subject to an additional needs-based assessment during the process of the 8.2 transfer. > > AND one or more of the following: > > The recipient must provide evidence that they have acquired the assets that use the resources to be transferred from the current registrant. > > OR > > The recipient must show that they have acquired the entire entity which is the current registrant. > > Comments: > > Timetable for implementation: Immediate > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From scottleibrand at gmail.com Tue Mar 21 14:14:34 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 21 Mar 2017 11:14:34 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-1: Clarify Slow Start for Transfers In-Reply-To: <58D1643D.3000604@arin.net> References: <58D1643D.3000604@arin.net> Message-ID: <85097D96-4C1B-479C-B7E1-6A896AD31954@gmail.com> It seems that this could be read as more restrictive than current policy. To make sure it isn't, we could do something like add the word "Alternatively," before "organizations may demonstrate a 24 month future projection" at the beginning of the newly added text. Scott > On Mar 21, 2017, at 10:34 AM, ARIN wrote: > > On 16 March 2017, the ARIN Advisory Council (AC) accepted "ARIN-prop-237: Clarify Slow Start for Transfers" as a Draft Policy. > > Draft Policy text is below and can be found at: > https://www.arin.net/policy/proposals/2017_1.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-1: Clarify Slow Start for Transfers > > Date: 21 March 2017 > > With the adoption of 2015-5, transfer policy is severed from ARIN allocation / assignment policy. It is no longer clear how slow start applies (if at all) to justifying a transfer. Having a slow start algorithm available to the transfer market will make for a more predictable and more right sized blocks in line with organizational growth. > > Problem Discussion: > > In a pre-transfer world ISPs who are growing rapidly, or have no history of utilization to support their IPv4 two year growth requirements, could qualify under slow start. > > The initial block was either a small block (between /24 and /21), or double what they efficiently used in the previous year. If thate space was used in less than a year, they could get twice as much the next time. > > The implementation of Policy 2016-5 severs transfer policy form section 4 where the slow start rules are defined. As a result it is unclear if the slow start process can be used to justify a specified transfer. > > Additionally, the inability to complete regular transfers could lead to a situation where lack of IPv4 addresses is rate limiting deployment. As a result demonstrated utilization of the last 12 months may not be indicative of actual growth. > > NRPM 8.5.3 / 8.5.4 (ARIN Policy 2016-4) supports an initial block of only a /24 if there is no allocation or assignment. > > Policy Proposal 2016-3 (the sister policy to 2016-4) supports a larger block (after demonstration of efficient utilization) equal to their current holdings up to a /16 every 6 months. > > Because 2016-3 no longer permits using a /16 at a time and demonstrating utilization before coming back for another, organizations who are growing at more than a /15 a year are forced to use the two year forward looking projected growth as justification. > > This prediction is difficult to measure, difficult to justify, difficult to verify, and provides unpredictability to the amount of time a justification requires to be processed, and the likelihood of approval. This process favors organizations who more aggressively optimistic and has no penalty if an organization fails to meet their plans. > > Problem solution: > > Permit organizations who demonstrate efficient utilization to use the utilization of their most recent specified transfer(s) to extrapolate a two year growth projection allowing a specified transfer of up to double the size of the transfers used in the justification. > > Policy statement: > > Current policy: > > 8.5.5. Block size > > Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN. > > Proposed changes: > > Add the following to the end of 8.5.5: > > Organizations may demonstrate a 24 month future projection based on the average amount of time required to efficiently utilize one or more of their most recent specified transfers. > > The organization must show efficient utilization of at least 50% of all specified transfers from the current date back to the the date of the earliest specified transfer included in the request. The organization will be pre-authorized for a two year window to complete one or more specified transfers up to the total number of IPv4 addresses of the transfers included in the request, divided by the number of days (no less than 90) since the earliest specified transfer included in the request was completed, multiplied by 730. > > Comments: > > Timetable for implementation: Immediate > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From scottleibrand at gmail.com Tue Mar 21 14:16:01 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 21 Mar 2017 11:16:01 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-2: Removal of Community Networks In-Reply-To: <58D1645E.4070101@arin.net> References: <58D1645E.4070101@arin.net> Message-ID: <42A28206-426D-4777-B7E5-F2463AE69145@gmail.com> I support this policy until/unless we hear from an actual community network that is actually applying for space under the Community Networks section of the NRPM (and would not qualify as easily otherwise). Scott > On Mar 21, 2017, at 10:35 AM, ARIN wrote: > > On 16 March 2017, the ARIN Advisory Council (AC) accepted "ARIN-prop-238: Removal of Community Networks" as a Draft Policy. > > Draft Policy text is below and can be found at: > https://www.arin.net/policy/proposals/2017_2.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-2: Removal of Community Networks > > Date: 21 March 2017 > > Problem Statement: > > The Community Networks section of the NRPM has not been utilized since it was implemented in January 2010. A recent policy ARIN-2016-7, to increase the number of use cases, was abandoned by the Advisory Council due to lack of feedback. The policy should be removed to simplify the NRPM. > > Policy statement: > > Remove the following 2 sections. > > 2.11 Community Network > > 6.5.9 Community Network Assingments > > Comments: > > Timetable for implementation: Immediate > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jschiller at google.com Tue Mar 21 15:07:01 2017 From: jschiller at google.com (Jason Schiller) Date: Tue, 21 Mar 2017 15:07:01 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-2: Removal of Community Networks In-Reply-To: <42A28206-426D-4777-B7E5-F2463AE69145@gmail.com> References: <58D1645E.4070101@arin.net> <42A28206-426D-4777-B7E5-F2463AE69145@gmail.com> Message-ID: I would offer a friendly amendment to Scott's request to open the question up more generally... (we should not confuse if a policy is being used, with if it is needed). Can "Community Networks" please chime into this thread and explain one (or all) of the following: 1. Why are you (or other communities networks in general) having or had trouble getting resources? 2. Is the current policy is sufficient for you (and other community networks like you) to get space without sections 2.11 and 6.5.9? 3. Do you (and others like you) believe they should qualify under "Community Networks" but do not because the definition is overly narrow? [explain how we might extend the definition to cover you] 4. Did you get space under a different policy, but still believe you would have been better served if you were able to fit under the "Communities Networks" definition? If we don't hear from "community networks" by the time we discuss this as a recommended draft then I would support the removal. If we do hear from "community networks" then I would use their advice to determine if special consideration for community networks is useful or not, and if the current policy meets their needs, requires modification, or is completely unneeded. Please note if you think you should be considered a community network, and why. (e.g. I am Your Neighborhood Net. We should be considered a community network because we offer "free" WiFi to our community. We hold monthly meetings that cost $10 / person, but half of that covers the price of the pizza, the rest is a donation for our ISP fees and replacement equipment. Occasionally, a community member will buy and donate an access point so they can get better coverage, or speed. Neither Your Neighborhood Net, nor people associated with it make any money) Please ask any community networks you know to chime in on this thread! ___Jason On Tue, Mar 21, 2017 at 2:16 PM, Scott Leibrand wrote: > I support this policy until/unless we hear from an actual community > network that is actually applying for space under the Community Networks > section of the NRPM (and would not qualify as easily otherwise). > > Scott > > > On Mar 21, 2017, at 10:35 AM, ARIN wrote: > > > > On 16 March 2017, the ARIN Advisory Council (AC) accepted > "ARIN-prop-238: Removal of Community Networks" as a Draft Policy. > > > > Draft Policy text is below and can be found at: > > https://www.arin.net/policy/proposals/2017_2.html > > > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion in order to assess the conformance of this draft > policy with ARIN's Principles of Internet number resource policy as stated > in the Policy Development Process (PDP). Specifically, these principles are: > > > > * Enabling Fair and Impartial Number Resource Administration > > * Technically Sound > > * Supported by the Community > > > > The PDP can be found at: > > https://www.arin.net/policy/pdp.html > > > > Draft Policies and Proposals under discussion can be found at: > > https://www.arin.net/policy/proposals/index.html > > > > Regards, > > > > Sean Hopkins > > Policy Analyst > > American Registry for Internet Numbers (ARIN) > > > > > > > > Draft Policy ARIN-2017-2: Removal of Community Networks > > > > Date: 21 March 2017 > > > > Problem Statement: > > > > The Community Networks section of the NRPM has not been utilized since > it was implemented in January 2010. A recent policy ARIN-2016-7, to > increase the number of use cases, was abandoned by the Advisory Council due > to lack of feedback. The policy should be removed to simplify the NRPM. > > > > Policy statement: > > > > Remove the following 2 sections. > > > > 2.11 Community Network > > > > 6.5.9 Community Network Assingments > > > > Comments: > > > > Timetable for implementation: Immediate > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Tue Mar 21 15:19:19 2017 From: jschiller at google.com (Jason Schiller) Date: Tue, 21 Mar 2017 15:19:19 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-1: Clarify Slow Start for Transfers In-Reply-To: <85097D96-4C1B-479C-B7E1-6A896AD31954@gmail.com> References: <58D1643D.3000604@arin.net> <85097D96-4C1B-479C-B7E1-6A896AD31954@gmail.com> Message-ID: I don't believe the originator still owns the text, but I would personally accept the insertion of alternatively. This was indeed meant to be in addition, to other ways that you may try to explain a two year need, here is a a tried and true way that ARIN will accept under very clear and measurable metrics. Rather than "alternatively" it might be useful to clarify that this is "one way" demonstrate a two year need. It isn't really an alternate mechanism. But this is more of a nit than anything else, and I believe "alternatively" will still yield the right behavior. ___Jason On Tue, Mar 21, 2017 at 2:14 PM, Scott Leibrand wrote: > It seems that this could be read as more restrictive than current policy. > To make sure it isn't, we could do something like add the word > "Alternatively," before "organizations may demonstrate a 24 month future > projection" at the beginning of the newly added text. > > Scott > > > On Mar 21, 2017, at 10:34 AM, ARIN wrote: > > > > On 16 March 2017, the ARIN Advisory Council (AC) accepted > "ARIN-prop-237: Clarify Slow Start for Transfers" as a Draft Policy. > > > > Draft Policy text is below and can be found at: > > https://www.arin.net/policy/proposals/2017_1.html > > > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion in order to assess the conformance of this draft > policy with ARIN's Principles of Internet Number Resource Policy as stated > in the Policy Development Process (PDP). Specifically, these principles are: > > > > * Enabling Fair and Impartial Number Resource Administration > > * Technically Sound > > * Supported by the Community > > > > The PDP can be found at: > > https://www.arin.net/policy/pdp.html > > > > Draft Policies and Proposals under discussion can be found at: > > https://www.arin.net/policy/proposals/index.html > > > > Regards, > > > > Sean Hopkins > > Policy Analyst > > American Registry for Internet Numbers (ARIN) > > > > > > > > Draft Policy ARIN-2017-1: Clarify Slow Start for Transfers > > > > Date: 21 March 2017 > > > > With the adoption of 2015-5, transfer policy is severed from ARIN > allocation / assignment policy. It is no longer clear how slow start > applies (if at all) to justifying a transfer. Having a slow start > algorithm available to the transfer market will make for a more predictable > and more right sized blocks in line with organizational growth. > > > > Problem Discussion: > > > > In a pre-transfer world ISPs who are growing rapidly, or have no history > of utilization to support their IPv4 two year growth requirements, could > qualify under slow start. > > > > The initial block was either a small block (between /24 and /21), or > double what they efficiently used in the previous year. If thate space was > used in less than a year, they could get twice as much the next time. > > > > The implementation of Policy 2016-5 severs transfer policy form section > 4 where the slow start rules are defined. As a result it is unclear if the > slow start process can be used to justify a specified transfer. > > > > Additionally, the inability to complete regular transfers could lead to > a situation where lack of IPv4 addresses is rate limiting deployment. As a > result demonstrated utilization of the last 12 months may not be indicative > of actual growth. > > > > NRPM 8.5.3 / 8.5.4 (ARIN Policy 2016-4) supports an initial block of > only a /24 if there is no allocation or assignment. > > > > Policy Proposal 2016-3 (the sister policy to 2016-4) supports a larger > block (after demonstration of efficient utilization) equal to their current > holdings up to a /16 every 6 months. > > > > Because 2016-3 no longer permits using a /16 at a time and demonstrating > utilization before coming back for another, organizations who are growing > at more than a /15 a year are forced to use the two year forward looking > projected growth as justification. > > > > This prediction is difficult to measure, difficult to justify, difficult > to verify, and provides unpredictability to the amount of time a > justification requires to be processed, and the likelihood of approval. > This process favors organizations who more aggressively optimistic and has > no penalty if an organization fails to meet their plans. > > > > Problem solution: > > > > Permit organizations who demonstrate efficient utilization to use the > utilization of their most recent specified transfer(s) to extrapolate a two > year growth projection allowing a specified transfer of up to double the > size of the transfers used in the justification. > > > > Policy statement: > > > > Current policy: > > > > 8.5.5. Block size > > > > Organizations may qualify for the transfer of a larger initial block, or > an additional block, by providing documentation to ARIN which details the > use of at least 50% of the requested IPv4 block size within 24 months. An > officer of the organization shall attest to the documentation provided to > ARIN. > > > > Proposed changes: > > > > Add the following to the end of 8.5.5: > > > > Organizations may demonstrate a 24 month future projection based on the > average amount of time required to efficiently utilize one or more of their > most recent specified transfers. > > > > The organization must show efficient utilization of at least 50% of all > specified transfers from the current date back to the the date of the > earliest specified transfer included in the request. The organization will > be pre-authorized for a two year window to complete one or more specified > transfers up to the total number of IPv4 addresses of the transfers > included in the request, divided by the number of days (no less than 90) > since the earliest specified transfer included in the request was > completed, multiplied by 730. > > > > Comments: > > > > Timetable for implementation: Immediate > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From daveid at panix.com Wed Mar 22 11:52:27 2017 From: daveid at panix.com (David Huberman) Date: Wed, 22 Mar 2017 11:52:27 -0400 Subject: [arin-ppml] IETF BOF on Centralized Address Management Message-ID: <6CEA94D5-A3C4-4CE7-9D90-AE21E253FB77@panix.com> At the IETF next week in Chicago, a new CASM BOF will take place. Info on the BOF and the mailing list is at: https://www.ietf.org/mailman/listinfo/casm Sent from my iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Mar 24 00:53:32 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 24 Mar 2017 00:53:32 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201703240453.v2O4rWLv009926@rotala.raleigh.ibm.com> Total of 14 messages in the last 7 days. script run at: Fri Mar 24 00:53:27 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 35.71% | 5 | 30.38% | 47953 | info at arin.net 21.43% | 3 | 22.67% | 35793 | scottleibrand at gmail.com 14.29% | 2 | 27.59% | 43555 | jschiller at google.com 7.14% | 1 | 5.21% | 8220 | narten at us.ibm.com 7.14% | 1 | 5.02% | 7921 | jcurran at arin.net 7.14% | 1 | 4.90% | 7737 | job at ntt.net 7.14% | 1 | 4.24% | 6686 | daveid at panix.com --------+------+--------+----------+------------------------ 100.00% | 14 |100.00% | 157865 | Total From jcurran at arin.net Mon Mar 27 15:39:52 2017 From: jcurran at arin.net (John Curran) Date: Mon, 27 Mar 2017 19:39:52 +0000 Subject: [arin-ppml] Fwd: [ARIN-consult] Community Consultation on CKN23-ARIN Now Open References: Message-ID: Folks - We have initiated a community consultation on a possible restructuring of existing information in the ARIN registry ? this is to address the long-standing concern that some have expressed with the association of a ?No Contact Known? point-of-contact (POC) in some registry records that may have potentially valid Admin and Tech contact information. If you have hold a strong view on this matter, please see the attached consultation announcement and participate in the discussion on the arin-consult mailing list. Thanks! /John John Curran President and CEO ARIN === Begin forwarded message: From: ARIN > Subject: [ARIN-consult] Community Consultation on CKN23-ARIN Now Open Date: 22 March 2017 at 1:24:12 PM EDT To: > There are thousands of instances of the ARIN Point of Contact (POC) handle ?No, Contact Known? or CKN23-ARIN registered in the ARIN database, most of them associated with legacy resource records. ARIN would like the community to review the history of this situation and the proposed solution and provide us with their feedback. The creation and addition of this POC handle was due to a combination of factors. * In 2002, a database conversion project was done at ARIN that created a new database structure and added a new record type (Organization ID) as well as new POC types (Admin, Tech, Abuse and NOC). When an Org ID didn?t have a clear POC that had been recently updated or vetted by ARIN staff, the original resource POC remained on the resource record only and no POCs were added to the Org record at all. * In a later 2011 database conversion, reverse DNS delegation switched from per-net to per-zone. This created significant hijacking potential by allowing resource POCs to change their reverse delegation without first being verified by staff as legitimate. * Also in 2011, ARIN added a new business rule that required an Admin and a Tech POC on all Org records as a way of enhancing data quality. * Policy 2010-14 was implemented in 2011 and required Abuse POCs on all Org records. In order to maintain ARIN?s business rules, comply with policy 2010-14, and prevent hijackings, several actions were initiated by staff: * CKN23-ARIN was created to become the Admin and Tech POC on Orgs that lacked them * Resource POCs of legacy networks that had never been updated or validated by ARIN were moved to the Organization record as the Abuse POC * ARIN?s verification and vetting requirements were thus reinstated as the Abuse POC had to be vetted before making any changes to the record, and therefore could not hijack the resource by adding or changing the nameservers Over time, the above actions have created several issues: * It is easy for hijackers to identify and target records with CKN23 (no contact known) as the handle * POCs that were moved from resource tech to Org abuse are not happy about no longer having control of their resource record There are several different courses of action that ARIN could take to resolve the current situation. Option 1 Retain the current status and do nothing Option 2 Restore the resource POCs back to their original state on the resource record keeping in mind that this would open up the hijacking risk by giving the original resource POC control of the network without a verification process * Retain the Abuse POC on the Org record * Retain CKN23-ARIN as Org POC Option 3 - **Recommended option** Restore the resource POC back to their original state on the resource record. This will allow contacts historically associated with a resource record to more readily administer that record going forward. * Retain the Abuse POC on the Org * Replace CKN23-ARIN with a handle that better explains the record?s status (e.g. ?Legacy Record ? See Resource POC?) * Lock all resources associated with these legacy records who have had their resource POC restored. This would ensure that any changes made by the resource POC would first have to be reviewed by ARIN. We would like to thank the ARIN Services Working Group (WG) for their helpful review of the proposed change ? while the ARIN Services WG did not take a formal position in support of or in opposition of the proposed change, their review led to improvements in presentation of the options We are seeking community feedback on this proposed change (Option #3) to the ARIN Registry database. This consultation will remain open for 60 days - Please provide comments to arin-consult at arin.net. Discussion on arin-consult at arin.net will close on 22 May 2017. If you have any questions, please contact us at info at arin.net. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Mar 29 13:30:34 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 29 Mar 2017 10:30:34 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-2: Removal of Community Networks In-Reply-To: References: <58D1645E.4070101@arin.net> <42A28206-426D-4777-B7E5-F2463AE69145@gmail.com> Message-ID: <83338FBB-43F0-4728-9D3B-C1DECC655757@delong.com> > On Mar 21, 2017, at 12:07 , Jason Schiller wrote: > > I would offer a friendly amendment to Scott's request to open the > question up more generally... (we should not confuse if a policy > is being used, with if it is needed). > > Can "Community Networks" please chime into this thread > and explain one (or all) of the following: > > 1. Why are you (or other communities networks in general) > having or had trouble getting resources? This section was put in place to attempt to provide a mechanism by which community networks could gain access to IPv6 resources for the following reasons: 1. Encourage the use of IPv6 by community networks. 2. Provide an avenue by which the board could provide a reduced fee structure for community networks. (The board has, so far, elected not to do so) 3. Lower the barrier to qualification for relatively small blocks of IPv6 address space for operators of community networks. At the time the policy was introduced into the NRPM, the barrier to entry for a community network (which would be treated as an ISP) was a minimum commitment of $2,500 per year (IIRC, possibly even $5,000). Many community networks struggle to fund pizza for a monthly meeting. Several representatives of community networks, myself included, approached the board and were told that ?The board would need a definition of community networks in policy before it could provide any fee relief to such organizations.? The policy half was put in place and then the board declined to provide any of the requested fee relief. Since then, several changes (reductions) in fees have occurred. Today, fees are likely no longer a significant barrier to community networks use of this policy. However, that is a very recent event and I would like to see us give community networks some time to determine whether this is a useful avenue or not. Further, since this is an IPv6-only policy, it may well be that most community networks still don?t perceive it as practical to implement an IPv6 based network and so aren?t ready to take advantage of the policy yet, preferring instead to focus on whatever mechanism they are using to deal with IPv4. > 2. Is the current policy is sufficient for you > (and other community networks like you) > to get space without sections 2.11 and 6.5.9? From the perspective of the community networks I?ve been actively involved in, it?s a mixed bag. There are still advantages to preserving these sections in some instances. > 3. Do you (and others like you) believe they should > qualify under "Community Networks" but do not because > the definition is overly narrow? > [explain how we might extend the definition to cover you] From the perspective of the community networks I?ve been actively involved in, policy was not the problem, cost was the problem. The policy as is is helpful, but was not helpful enough. Recent general changes to the fee structure would now make taking advantage of the policy economically viable to some of these networks. > 4. Did you get space under a different policy, > but still believe you would have been better served > if you were able to fit under the "Communities Networks" > definition? From the perspective of the community networks I?ve been actively involved in, no. Economics being the primary barrier, no other policy would work, either. Yes, we would have been better served under the community networks definition _IF_ such service had been economically viable, but that was not the case until recent changes. > Please note if you think you should be considered a community network, > and why. (e.g. I am Your Neighborhood Net. We should be considered a > community network because we offer "free" WiFi to our community. We > hold monthly meetings that cost $10 / person, but half of that covers the > price of the pizza, the rest is a donation for our ISP fees and replacement > equipment. Occasionally, a community member will buy and donate an > access point so they can get better coverage, or speed. Neither > Your Neighborhood Net, nor people associated with it make any money) All of the community networks I?ve been involved in had no cost to attend their monthly meetings, provided free wifi to some service community, depended on donations from local ISPs or other businesses (service donations) for connectivity, and if there was pizza at the meeting, it was funded by everyone chipping in for the pizza. The equipment was generally donated and/or purchased with donations from individual organizers/volunteers involved in the community network. Space and power for the equipment was donated by individuals, companies, and in some cases, civic entities (water districts, police, EMA, etc.). Many of these networks were/are operated by Amateur Radio operators and often had some connection and/or intent to provide services for ARES/RACES and/or local emergency management authorities. > Please ask any community networks you know to chime in on this thread! Though I am no longer directly actively involved in any of these networks, I hope that the above historical and current information is useful to the discussion. Owen From owen at delong.com Wed Mar 29 13:33:44 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 29 Mar 2017 10:33:44 -0700 Subject: [arin-ppml] [ARIN-consult] Community Consultation on CKN23-ARIN Now Open In-Reply-To: References: Message-ID: I support recommended option 3. Owen > On Mar 27, 2017, at 12:39 , John Curran wrote: > > Folks - > > We have initiated a community consultation on a possible restructuring of existing > information in the ARIN registry ? this is to address the long-standing concern that > some have expressed with the association of a ?No Contact Known? point-of-contact > (POC) in some registry records that may have potentially valid Admin and Tech > contact information. > > If you have hold a strong view on this matter, please see the attached consultation > announcement and participate in the discussion on the arin-consult mailing list. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > === > >> Begin forwarded message: >> >> From: ARIN > >> Subject: [ARIN-consult] Community Consultation on CKN23-ARIN Now Open >> Date: 22 March 2017 at 1:24:12 PM EDT >> To: > >> >> There are thousands of instances of the ARIN Point of Contact (POC) >> handle ?No, Contact Known? or CKN23-ARIN registered in the ARIN >> database, most of them associated with legacy resource records. ARIN >> would like the community to review the history of this situation and the >> proposed solution and provide us with their feedback. >> >> The creation and addition of this POC handle was due to a combination of >> factors. >> >> * In 2002, a database conversion project was done at ARIN that >> created a new database structure and added a new record type >> (Organization ID) as well as new POC types (Admin, Tech, Abuse and NOC). >> When an Org ID didn?t have a clear POC that had been recently updated or >> vetted by ARIN staff, the original resource POC remained on the resource >> record only and no POCs were added to the Org record at all. >> * In a later 2011 database conversion, reverse DNS delegation >> switched from per-net to per-zone. This created significant hijacking >> potential by allowing resource POCs to change their reverse delegation >> without first being verified by staff as legitimate. >> * Also in 2011, ARIN added a new business rule that required an Admin >> and a Tech POC on all Org records as a way of enhancing data quality. >> * Policy 2010-14 was implemented in 2011 and required Abuse POCs on >> all Org records. >> >> In order to maintain ARIN?s business rules, comply with policy 2010-14, >> and prevent hijackings, several actions were initiated by staff: >> >> * CKN23-ARIN was created to become the Admin and Tech POC on Orgs >> that lacked them >> * Resource POCs of legacy networks that had never been updated or >> validated by ARIN were moved to the Organization record as the Abuse POC >> * ARIN?s verification and vetting requirements were thus reinstated >> as the Abuse POC had to be vetted before making any changes to the >> record, and therefore could not hijack the resource by adding or >> changing the nameservers >> >> Over time, the above actions have created several issues: >> >> * It is easy for hijackers to identify and target records with CKN23 >> (no contact known) as the handle >> * POCs that were moved from resource tech to Org abuse are not happy >> about no longer having control of their resource record >> >> There are several different courses of action that ARIN could take to >> resolve the current situation. >> >> Option 1 >> >> Retain the current status and do nothing >> >> Option 2 >> >> Restore the resource POCs back to their original state on the >> resource record keeping in mind that this would open up the hijacking >> risk by giving the original resource POC control of the network without >> a verification process >> * Retain the Abuse POC on the Org record >> * Retain CKN23-ARIN as Org POC >> >> Option 3 - **Recommended option** >> >> Restore the resource POC back to their original state on the >> resource record. This will allow contacts historically associated with >> a resource record to more readily administer that record going forward. >> * Retain the Abuse POC on the Org >> * Replace CKN23-ARIN with a handle that better explains the record?s >> status (e.g. ?Legacy Record ? See Resource POC?) >> * Lock all resources associated with these legacy records who have >> had their resource POC restored. This would ensure that any changes made >> by the resource POC would first have to be reviewed by ARIN. >> >> We would like to thank the ARIN Services Working Group (WG) for their >> helpful review of the proposed change ? while the ARIN Services WG did >> not take a formal position in support of or in opposition of the >> proposed change, their review led to improvements in presentation of the >> options >> >> We are seeking community feedback on this proposed change (Option #3) to >> the ARIN Registry database. >> >> This consultation will remain open for 60 days - Please provide comments >> to arin-consult at arin.net . >> >> Discussion on arin-consult at arin.net will close on 22 May 2017. >> >> If you have any questions, please contact us at info at arin.net . >> >> Regards, >> >> John Curran >> President and CEO >> American Registry for Internet Numbers (ARIN) >> >> _______________________________________________ >> ARIN-Consult >> You are receiving this message because you are subscribed to the ARIN Consult Mailing >> List (ARIN-consult at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services >> Help Desk at info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Wed Mar 29 14:46:01 2017 From: bjones at vt.edu (Brian Jones) Date: Wed, 29 Mar 2017 18:46:01 +0000 Subject: [arin-ppml] [ARIN-consult] Community Consultation on CKN23-ARIN Now Open In-Reply-To: References: Message-ID: I support Option 3. -- Brian On Wed, Mar 29, 2017 at 1:34 PM Owen DeLong wrote: I support recommended option 3. Owen On Mar 27, 2017, at 12:39 , John Curran wrote: Folks - We have initiated a community consultation on a possible restructuring of existing information in the ARIN registry ? this is to address the long-standing concern that some have expressed with the association of a ?No Contact Known? point-of-contact (POC) in some registry records that may have potentially valid Admin and Tech contact information. If you have hold a strong view on this matter, please see the attached consultation announcement and participate in the discussion on the arin-consult mailing list. Thanks! /John John Curran President and CEO ARIN === Begin forwarded message: *From: *ARIN *Subject: **[ARIN-consult] Community Consultation on CKN23-ARIN Now Open* *Date: *22 March 2017 at 1:24:12 PM EDT *To: * There are thousands of instances of the ARIN Point of Contact (POC) handle ?No, Contact Known? or CKN23-ARIN registered in the ARIN database, most of them associated with legacy resource records. ARIN would like the community to review the history of this situation and the proposed solution and provide us with their feedback. The creation and addition of this POC handle was due to a combination of factors. * In 2002, a database conversion project was done at ARIN that created a new database structure and added a new record type (Organization ID) as well as new POC types (Admin, Tech, Abuse and NOC). When an Org ID didn?t have a clear POC that had been recently updated or vetted by ARIN staff, the original resource POC remained on the resource record only and no POCs were added to the Org record at all. * In a later 2011 database conversion, reverse DNS delegation switched from per-net to per-zone. This created significant hijacking potential by allowing resource POCs to change their reverse delegation without first being verified by staff as legitimate. * Also in 2011, ARIN added a new business rule that required an Admin and a Tech POC on all Org records as a way of enhancing data quality. * Policy 2010-14 was implemented in 2011 and required Abuse POCs on all Org records. In order to maintain ARIN?s business rules, comply with policy 2010-14, and prevent hijackings, several actions were initiated by staff: * CKN23-ARIN was created to become the Admin and Tech POC on Orgs that lacked them * Resource POCs of legacy networks that had never been updated or validated by ARIN were moved to the Organization record as the Abuse POC * ARIN?s verification and vetting requirements were thus reinstated as the Abuse POC had to be vetted before making any changes to the record, and therefore could not hijack the resource by adding or changing the nameservers Over time, the above actions have created several issues: * It is easy for hijackers to identify and target records with CKN23 (no contact known) as the handle * POCs that were moved from resource tech to Org abuse are not happy about no longer having control of their resource record There are several different courses of action that ARIN could take to resolve the current situation. Option 1 Retain the current status and do nothing Option 2 Restore the resource POCs back to their original state on the resource record keeping in mind that this would open up the hijacking risk by giving the original resource POC control of the network without a verification process * Retain the Abuse POC on the Org record * Retain CKN23-ARIN as Org POC Option 3 - **Recommended option** Restore the resource POC back to their original state on the resource record. This will allow contacts historically associated with a resource record to more readily administer that record going forward. * Retain the Abuse POC on the Org * Replace CKN23-ARIN with a handle that better explains the record?s status (e.g. ?Legacy Record ? See Resource POC?) * Lock all resources associated with these legacy records who have had their resource POC restored. This would ensure that any changes made by the resource POC would first have to be reviewed by ARIN. We would like to thank the ARIN Services Working Group (WG) for their helpful review of the proposed change ? while the ARIN Services WG did not take a formal position in support of or in opposition of the proposed change, their review led to improvements in presentation of the options We are seeking community feedback on this proposed change (Option #3) to the ARIN Registry database. This consultation will remain open for 60 days - Please provide comments to arin-consult at arin.net. Discussion on arin-consult at arin.net will close on 22 May 2017. If you have any questions, please contact us at info at arin.net. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage 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 calderon.alfredo at gmail.com Thu Mar 30 08:28:10 2017 From: calderon.alfredo at gmail.com (Alfredo Calderon) Date: Thu, 30 Mar 2017 08:28:10 -0400 Subject: [arin-ppml] Fwd: [ARIN-consult] Community Consultation on CKN23-ARIN Now Open In-Reply-To: References: Message-ID: I support option # 3. It allows for a better management and evaluation procedure to filter records. [image: photo] *Alfredo Calderon* eLearning Consultant calderon.alfredo at gmail.com | http://aprendizajedistancia.blogspot.com | Skype: Alfredo_1212 <#> | wiseintro.co/alfredocalderon Get a signature like this: Click here! On Mon, Mar 27, 2017 at 3:39 PM, John Curran wrote: > Folks - > > We have initiated a community consultation on a possible restructuring > of existing > information in the ARIN registry ? this is to address the > long-standing concern that > some have expressed with the association of a ?No Contact Known? > point-of-contact > (POC) in some registry records that may have potentially valid Admin > and Tech > contact information. > > If you have hold a strong view on this matter, please see the attached > consultation > announcement and participate in the discussion on the arin-consult > mailing list. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > === > > Begin forwarded message: > > *From: *ARIN > *Subject: **[ARIN-consult] Community Consultation on CKN23-ARIN Now Open* > *Date: *22 March 2017 at 1:24:12 PM EDT > *To: * > > There are thousands of instances of the ARIN Point of Contact (POC) > handle ?No, Contact Known? or CKN23-ARIN registered in the ARIN > database, most of them associated with legacy resource records. ARIN > would like the community to review the history of this situation and the > proposed solution and provide us with their feedback. > > The creation and addition of this POC handle was due to a combination of > factors. > > * In 2002, a database conversion project was done at ARIN that > created a new database structure and added a new record type > (Organization ID) as well as new POC types (Admin, Tech, Abuse and NOC). > When an Org ID didn?t have a clear POC that had been recently updated or > vetted by ARIN staff, the original resource POC remained on the resource > record only and no POCs were added to the Org record at all. > * In a later 2011 database conversion, reverse DNS delegation > switched from per-net to per-zone. This created significant hijacking > potential by allowing resource POCs to change their reverse delegation > without first being verified by staff as legitimate. > * Also in 2011, ARIN added a new business rule that required an Admin > and a Tech POC on all Org records as a way of enhancing data quality. > * Policy 2010-14 was implemented in 2011 and required Abuse POCs on > all Org records. > > In order to maintain ARIN?s business rules, comply with policy 2010-14, > and prevent hijackings, several actions were initiated by staff: > > * CKN23-ARIN was created to become the Admin and Tech POC on Orgs > that lacked them > * Resource POCs of legacy networks that had never been updated or > validated by ARIN were moved to the Organization record as the Abuse POC > * ARIN?s verification and vetting requirements were thus reinstated > as the Abuse POC had to be vetted before making any changes to the > record, and therefore could not hijack the resource by adding or > changing the nameservers > > Over time, the above actions have created several issues: > > * It is easy for hijackers to identify and target records with CKN23 > (no contact known) as the handle > * POCs that were moved from resource tech to Org abuse are not happy > about no longer having control of their resource record > > There are several different courses of action that ARIN could take to > resolve the current situation. > > Option 1 > > Retain the current status and do nothing > > Option 2 > > Restore the resource POCs back to their original state on the > resource record keeping in mind that this would open up the hijacking > risk by giving the original resource POC control of the network without > a verification process > * Retain the Abuse POC on the Org record > * Retain CKN23-ARIN as Org POC > > Option 3 - **Recommended option** > > Restore the resource POC back to their original state on the > resource record. This will allow contacts historically associated with > a resource record to more readily administer that record going forward. > * Retain the Abuse POC on the Org > * Replace CKN23-ARIN with a handle that better explains the record?s > status (e.g. ?Legacy Record ? See Resource POC?) > * Lock all resources associated with these legacy records who have > had their resource POC restored. This would ensure that any changes made > by the resource POC would first have to be reviewed by ARIN. > > We would like to thank the ARIN Services Working Group (WG) for their > helpful review of the proposed change ? while the ARIN Services WG did > not take a formal position in support of or in opposition of the > proposed change, their review led to improvements in presentation of the > options > > We are seeking community feedback on this proposed change (Option #3) to > the ARIN Registry database. > > This consultation will remain open for 60 days - Please provide comments > to arin-consult at arin.net. > > Discussion on arin-consult at arin.net will close on 22 May 2017. > > If you have any questions, please contact us at info at arin.net. > > Regards, > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN > Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the > ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Mar 31 00:53:27 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 31 Mar 2017 00:53:27 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201703310453.v2V4rR7T023493@rotala.raleigh.ibm.com> Total of 6 messages in the last 7 days. script run at: Fri Mar 31 00:53:22 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 33.33% | 2 | 27.12% | 35586 | owen at delong.com 16.67% | 1 | 23.41% | 30720 | calderon.alfredo at gmail.com 16.67% | 1 | 21.78% | 28583 | bjones at vt.edu 16.67% | 1 | 21.24% | 27872 | jcurran at arin.net 16.67% | 1 | 6.45% | 8461 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 6 |100.00% | 131222 | Total