From narten at us.ibm.com Fri Apr 3 00:53:02 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 03 Apr 2015 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201504030453.t334r3xU024122@rotala.raleigh.ibm.com> Total of 1 messages in the last 7 days. script run at: Fri Apr 3 00:53:02 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 6542 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 6542 | Total From info at arin.net Thu Apr 9 11:38:34 2015 From: info at arin.net (ARIN) Date: Thu, 09 Apr 2015 11:38:34 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-1: Out of Region Use - updated legal assessment In-Reply-To: <549AE7FF.6090108@arin.net> References: <549AE7FF.6090108@arin.net> Message-ID: <55269CFA.6030105@arin.net> ARIN has updated the legal assessment for policy 2014-1 Out of Region Use. The updated legal assessment is included in the Draft Policy text below and can be found at: https://www.arin.net/policy/proposals/2014_1.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Recommended Draft Policy ARIN-2014-1 Out of Region Use Date: 24 December 2014 AC's assessment of conformance with the Principles of Internet Number Resource Policy: This proposal enables fair and impartial number resource administration by clearing up a significant ambiguity in policy and practice. This proposal is technically sound, as no technical issues are raised by permitting a single network operator to use resources from one RIR in any region. This proposal is supported by the community. Permitting out of region use allows operators with facilities spanning more than one region to obtain resources in the most direct and convenient way, and to utilize their numbers more flexibly and efficiently. The concerns of law enforcement and staff raised by the first staff and legal assessment have been mitigated by the latest amendments. Problem statement: Current policy neither clearly forbids nor clearly permits out or region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has explored several options to restrict or otherwise limit out of region use. None of these options have gained consensus within the community. The next logical option is a proposal that clearly permits out of region use while addressing some of the concerns expressed about unlimited openness to out of region use. Policy statement: Create new Section X: ARIN registered resources may be used outside the ARIN service region. Out of region use of IPv4, IPv6, or ASNs are valid justification for additional number resources if the applicant is currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively. The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR?s service region, the officer of the applicant must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to request a listing of all the applicant's number holdings in the region(s) of proposed use, but this should happen only when there are significant reasons to suspect duplicate requests. Comments: a. Timetable for implementation: Immediate b. Anything else Current policy is ambiguous on the issue of out of region use of ARIN registered resources. The only guidance on the issue in current policy is Section 2.2, which defines the the role of RIRs as ?to manage and distribute public Internet address space within their respective regions.? Some in the community believe this means out of region use should be prevented or restricted, while others believe this is only intended to focus efforts within the region and not define where resources may be used. Previous policy proposals have explored restricting or otherwise limiting out of region use, but none have gained consensus within the ARIN community. Several standards for restricting out of region use were explored, but all of them were perceived as interfering with the legitimate operations of multi- or trans-regional networks. The requirement to have a minimal level of resources deployed in the region (/44 for IPv6, /22 for IPv4, 1 ASN) is an attempt to respond to law enforcement and some community concerns. An absolute threshold ensures that those applying for ARIN resources are actually operating in the region and not simply a shell company, but it avoids the known pitfalls of trying to use percentages of the organization's overall holdings to do that. The use of officer attestation and the possibility of an audit is an attempt to prevent duplicate requests without requiring burdensome reporting requirements. In summary, this proposal ensures that trans-regional organizations or service providers operating within the ARIN region may receive all the resources they need from ARIN if they wish to do so. This change is particularly important for IPv6. Requiring organizations get IPv6 resources from multiple RIRs will result in additional unique non-aggregatable prefixes within the IPv6 route table. ##### ARIN STAFF ASSESSMENT Date of Revised Assessment: 15 January 2015 1. Summary (Staff Understanding) This policy would allow out of region use of ARIN issued resources as long as the requesting organization is presently an ARIN registry customer and currently using the equivalent of a /22 IPv4 block, or a /44 IPv6 block, or an ASN on infrastructure physically located within the ARIN region. An officer attestation would be required to verify that the resource request is not a duplicate of one made to another RIR. 2. Comments A. ARIN Staff Comments There are registrants in the ARIN region, such as end-users, who are not necessarily ARIN members. The policy text has been updated to omit references to ?Member?, and is understood to refer to organizations with an existing customer relationship & agreement with ARIN. Current ARIN policy requires organizations to show a justified need for resources to be used specifically within the ARIN region in order to receive number resources from ARIN. If the draft policy were adopted, ARIN number resources could be requested for use in another region. When processing resource requests for use in another region under this policy, ARIN staff would include any address space registered through another RIR and currently used (or available to be used) within that region in its evaluation of the organization?s justified need based on current ARIN policy. This policy adds a new requirement that staff review utilization outside of the ARIN region, which will require additional time, and could delay the review and processing of requests of this type as well as other request types that ARIN currently handles. This policy would be placed in the NRPM as "2.17 Out of Region Use". [The following is an updated legal assessment of 2014-1] B. ARIN General Counsel - Legal Assessment 19 March 2015 Counsel has significant and material legal concerns about this policy. Counsel recognizes and supports the issuance of resources to entities in the ARIN region that need number resources that will be used in both this region and in the remainder of the world. ARIN currently issues resources for these needs based on a needs based allocation methodology. However, this proposed policy removes the requirement that there be any meaningful need for those resources in the ARIN service region, and allows all of the need to be outside the ARIN service region. This creates new legal challenges for ARIN which are identified below: First, ARIN is governed by ICANN ICP-2, which calls for establishment of a single RIR to serve each region. It further notes that multiple RIRs serving in single region is likely to lead to difficulty for co-ordination and co-operation between the RIRs as well as confusion for the community within the region. The implication of that governance structure is that each RIR can and should serve its service region. This policy would allow entities with no real connection to the ARIN's service region to obtain, for example, increasingly scarce IPv4 resources from ARIN and related registry services. This policy would result in ARIN effectively providing registry services to other regions, and thus appears on its face to be inconsistent with ICP-2. ARIN has obligations to follow the global policy in ICP2, or seek changes in it. Second, if the policy were adopted, ARIN could arguably become subject to the jurisdiction and laws passed by governments outside our service region. This may lead to ARIN being a litigant in courts of nations outside its service region and subject to their requirements and judgments. ARIN will need to accept greater legal expenditures and risks, as well as potentially larger costs in order to take this greater scope into consideration in ARIN's registry activities on an ongoing basis. Third, the policy fails to recognize that ARIN is not likely to able to perform the function contemplated in the policy with certain countries, and related public or private entities. See as examples under US law: Cuba, Iran and North Korea. The policy could benefit from a specific carve out that ARIN may meet its obligations under the laws of governments in its service region, even if such requests would otherwise comply with ARIN policy. For those who assert that this requirement to conform to law is implicit and does not need to be stated in policy, it is important the community is under notice of this limit. This issue has not been an issue for ARIN prior to this proposed policy. Fourth, ARIN may be subject to significantly greater political oversight by national governments in its service region that will wish to evaluate why ARIN alone of the 5 RIRs is assuming a duty to service all of the world's community. It may be argued by governments in ARIN's region that this is a potential breach of ARIN?s fiduciary obligations to its own region, and to examine whether it is consistent with ARIN?s non-profit status and other corporate documents. Fifth and finally, counsel is concerned that the policy will lead to an increase in fraudulent applications from out of region requestors, and issuance of resources to those who fraudulently file, since ARIN is not as well positioned to successfully discover such fraud by out of region requestors. [Legal Assessment in the staff assessment dated 15 January 2015] B. ARIN General Counsel - Legal Assessment [15 January 2015] Counsel supports the issuance of resources to entities in the ARIN region that need number resources that will be used in this region and in the remainder of the world. ARIN currently issues resources for these needs based on a needs based allocation methodology. This proposed revised policy now requires that there be /22 of deployed IPv4 resources in the ARIN service region, and once that installation exists it allows all of the recipients? needs outside the ARIN service region to be met by ARIN. The requirement of a meaningful physical presence of the recipient in the service region was absent from the prior version, and is an improvement. (The draft policy does not explicitly spell out that the recipient must have an actual physical presence, as well as a corporate legal entity, in the ARIN region, but implies the requirement indirectly by stating that the requester must presently be using resources in the ARIN region and thus already comply with ARIN?s existing requirements. The single remaining aspect that continues to create legal and policy concern is that the policy as written and interpreted calls for ARIN to allocate resources solely for use out of the ARIN service region. By definition, those resources should be obtained from the RIR(s) in the service region(s) where the need exists. Counsel would strongly prefer that the policy require that there be a requirement that some of the resources being allocated be needed in the ARIN region. Such a modest limit would be consistent with ICP-2; it would be consistent with ARIN's stewardship responsibility to allocate the waning pool of IPv4 number resources, and will still meet the needs of ARIN based multinational entities who need resources across the globe. This draft policy is inconsistent with ICP2. ARIN is governed by ICANN ICP-2, which calls for establishment of a single RIR to serve each region. ICP2 further notes that multiple RIRs serving in a single region is likely to lead to difficulty for co-ordination and co-operation between the RIRs as well as confusion for the community within the region. The implication of that governance structure is that each RIR can and should serve primarily its service region. Adoption of this policy will result in ARIN effectively providing significant registry services to ARIN qualified recipients in other RIR regions, and such a change should not be undertaken lightly but instead only after the framework provided in ICP-2 is updated (based on global discussion and consent) - to proceed otherwise would undermines ICP-2 and encourages parties to set aside its principles in an uncoordinated manner, risking in the very "confusion for the community" that ICP-2 helps deter at present. ARIN cannot perform business functions contemplated in the policy with certain countries, and related public or private entities, such as relationships to Cuba, Iran and North Korea under U.S. law. This has not historically been an issue for ARIN prior to this proposed policy. It may be necessary to require ARIN?s implementation of this policy to require a certification that none of the resources will be deployed contrary to U.S., Canada or Caribbean nations law in this respect. If the draft policy is adopted and ARIN provides resources to qualifying entities for use outside of the region, it is essential that the present requirement for dispute resolution via arbitration at a location in ARIN?s service region as currently required in the RSA be maintained to assist in reducing the risk of ARIN becoming subject to the venue, jurisdiction and laws of legal forums outside the ARIN service region. 3. Resource Impact This policy would have significant resource impact from an implementation aspect. It is estimated that implementation would occur within 5-6 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: Updated guidelines and internal procedures Staff training Additional time to review resource requests for out of region use as out of region utilization would now need to be included in the analysis of these requests Engineering efforts to handle out of region business rules may be substantial. 4. Policy Statement Proposal/Draft Policy Text Assessed Draft Policy ARIN-2014-1 Out of Region Use Create new Section X: ARIN registered resources may be used outside the ARIN service region. Out of region use of IPv4, IPv6, or ASNs are valid justification for additional number resources if the applicant is currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively. The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR?s service region, the officer of the applicant must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to request a listing of all the applicant's number holdings in the region(s) of proposed use, but this should happen only when there are significant reasons to suspect duplicate requests. On 12/24/14 11:21 AM, ARIN wrote: > Recommended Draft Policy ARIN-2014-1 > Out of Region Use > > On 18 December 2014 the ARIN Advisory Council (AC) recommended > ARIN-2014-1 for adoption, making it a Recommended Draft Policy. > > ARIN-2014-1 is below and can be found at: > https://www.arin.net/policy/proposals/2014_1.html > > You are encouraged to discuss Draft Policy 2014-1 on the PPML prior to > the upcoming ARIN Public Policy Consultation at NANOG 63 in San Antonio > in February 2015. Both the discussion on the list and at the meeting > will be used by the ARIN Advisory Council to determine the community > consensus for adopting this as policy. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Recommended Draft Policy ARIN-2014-1 > Out of Region Use > > Date: 24 December 2014 > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > This proposal enables fair and impartial number resource administration > by clearing up a significant ambiguity in policy and practice. This > proposal is technically sound, as no technical issues are raised by > permitting a single network operator to use resources from one RIR in > any region. This proposal is supported by the community. Permitting out > of region use allows operators with facilities spanning more than one > region to obtain resources in the most direct and convenient way, and to > utilize their numbers more flexibly and efficiently. The concerns of law > enforcement and staff raised by the first staff and legal assessment > have been mitigated by the latest amendments. > > Problem statement: > > Current policy neither clearly forbids nor clearly permits out or region > use of ARIN registered resources. This has created confusion and > controversy within the ARIN community for some time. Earlier work on > this issue has explored several options to restrict or otherwise limit > out of region use. None of these options have gained consensus within > the community. The next logical option is a proposal that clearly > permits out of region use while addressing some of the concerns > expressed about unlimited openness to out of region use. > > Policy statement: > > Create new Section X: > > ARIN registered resources may be used outside the ARIN service region. > Out of region use of IPv4, IPv6, or ASNs are valid justification for > additional number resources if the applicant is currently using at least > the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN > service region, respectively. > > The services and facilities used to justify the need for ARIN resources > that will be used out of region cannot also be used to justify resource > requests from another RIR. When a request for resources from ARIN is > justified by need located within another RIR?s service region, the > officer of the applicant must attest that the same services and > facilities have not been used as the basis for a resource request in the > other region(s). ARIN reserves the right to request a listing of all the > applicant's number holdings in the region(s) of proposed use, but this > should happen only when there are significant reasons to suspect > duplicate requests. > > Comments: > > a. Timetable for implementation: Immediate > > b. Anything else > > Current policy is ambiguous on the issue of out of region use of ARIN > registered resources. The only guidance on the issue in current policy > is Section 2.2, which defines the the role of RIRs as ?to manage and > distribute public Internet address space within their respective > regions.? Some in the community believe this means out of region use > should be prevented or restricted, while others believe this is only > intended to focus efforts within the region and not define where > resources may be used. > > Previous policy proposals have explored restricting or otherwise > limiting out of region use, but none have gained consensus within the > ARIN community. Several standards for restricting out of region use were > explored, but all of them were perceived as interfering with the > legitimate operations of multi- or trans-regional networks. > > The requirement to have a minimal level of resources deployed in the > region (/44 for IPv6, /22 for IPv4, 1 ASN) is an attempt to respond to > law enforcement and some community concerns. An absolute threshold > ensures that those applying for ARIN resources are actually operating in > the region and not simply a shell company, but it avoids the known > pitfalls of trying to use percentages of the organization's overall > holdings to do that. The use of officer attestation and the possibility > of an audit is an attempt to prevent duplicate requests without > requiring burdensome reporting requirements. > > In summary, this proposal ensures that trans-regional organizations or > service providers operating within the ARIN region may receive all the > resources they need from ARIN if they wish to do so. This change is > particularly important for IPv6. Requiring organizations get IPv6 > resources from multiple RIRs will result in additional unique > non-aggregatable prefixes within the IPv6 route table. > > ##### > > ARIN STAFF ASSESSMENT > > Date of Assessment: 22 October 2014 to 13 November 2014 > 2014-1 ?Out of Region Use? > > 1. Summary (Staff Understanding) > > This policy would allow out of region use of ARIN issued resources as > long as the requesting organization is an ARIN member in good standing > and currently using at least a /22, or a /44, or 1 ASN within the ARIN > region. > > 2. Comments > > A. ARIN Staff Comments > > There are registrants in the ARIN region, such as end-users, who are not > necessarily ARIN members. As written, this policy would not be available > to an organization that is not currently a member of ARIN, due to the > use of "ARIN member in good standing" in the policy text. Unless the > intention is specifically to require ARIN membership, the policy text > should simply reference "a registrant currently using at least the > equivalent of a /22 of IPv4, or a /44 of IPv6 in the region." > > Staff would apply ARIN policy to all out of region requests to include > asking for utilization details of resources registered in another RIR?s > database if the ARIN resources are being requested for use in that region. > > This policy adds a new requirement that staff review utilization outside > of the ARIN region, which will require additional time, and could delay > the review and processing of requests of this type as well as other > request types that ARIN currently handles. > > B. ARIN General Counsel - Legal Assessment > > This policy has been improved from counsel's perspective since the last > version was reviewed at ARIN 34 in Baltimore. > > Counsel recognizes and supports the issuance of resources to entities in > the ARIN region that need number resources that will be used in both > this region and in the remainder of the world. ARIN currently issues > resources for these needs based on a needs based allocation methodology. > This proposed revised policy now requires that there be /22 of deployed > resources in the ARIN service region, and once that installation exists > it allows all of the recipients' needs outside the ARIN service region > to be met by ARIN. This is a substantial improvement from a legal > perspective as it requires a "meaningful" or "material" physical > presence of the recipient in the service region that was absent from the > prior version. This meets a core objective answering my prior concern > about the lack of such a requirement. > > This policy still represents a type of exception to ICP2, despite the > helpful added requirement of the recipients /22 presence in region. ARIN > is governed by ICANN ICP-2, which calls for establishment of a single > RIR to serve each region. ICP2 further notes that multiple RIRs serving > in a single region is likely to lead to difficulty for co-ordination and > co-operation between the RIRs as well as confusion for the community > within the region. The implication of that governance structure is that > each RIR can and should serve its service region. This revised policy > still allows entities with /22 technological connections to the ARIN's > service region to obtain increasingly scarce IPv4 resources from ARIN > and related registry services for needs outside the ARIN regions. This > policy still will result in ARIN effectively providing significant > registry services to ARIN qualified recipients operating in other RIR > regions. > > If the draft policy is adopted and ARIN provides resources to qualifying > entities for use outside of the region, it is essential that the present > requirement for dispute resolution via arbitration at a location in > ARIN's service region as currently required in the RSA be maintained to > assist in reducing the risk of ARIN becoming subject to the venue, > jurisdiction and laws of legal forums outside the ARIN service region. > > ARIN cannot perform business functions contemplated in the policy with > certain countries, and related public or private entities, such as > relationships to Cuba, Iran and North Korea under U.S. law. This has not > historically been an issue for ARIN prior to this proposed policy. The > new requirement to spell out that the recipient must maintain an actual > physical presence, as well as a corporate legal entity in the ARIN > region, reduces, but does not entirely eliminate this concern. It may be > necessary to require ARIN's implementation of this policy to require a > certification that none of the resources will be deployed contrary to > U.S., Canada or Caribbean nations law in this respect. > > 3. Resource Impact > > This policy would have significant resource impact from an > implementation aspect. It is estimated that implementation would occur > within 5-6 months after ratification by the ARIN Board of Trustees. The > following would be needed in order to implement: > > Updated guidelines and internal procedures > > Staff training > > Engineering efforts to handle out of region business rules may be > substantial. > > 4. Proposal/Draft Policy Text Assessed > Draft Policy ARIN-2014-1 Out of Region Use > Date: 21 October 2014 > Problem statement: > Current policy neither clearly forbids nor clearly permits out or region > use of ARIN registered resources. This has created confusion and > controversy within the ARIN community for some time. Earlier work on > this issue has explored several options to restrict or otherwise limit > out of region use. None of these options have gained consensus within > the community. The next logical option is a proposal that clearly > permits out of region use while addressing some of the concerns > expressed about unlimited openness to out of region use. > > Policy statement: > Create new Section X: > ARIN registered resources may be used outside the ARIN service region. > Out of region use of IPv4, IPv6, or ASNs are valid justification for > additional number resources if the applicant is an ARIN member in good > standing and is currently using at least the equivalent of a /22 of > IPv4, or a /44 of IPv6, or 1 ASN within the ARIN service region, > respectively. > The services and facilities used to justify the need for ARIN resources > that will be used out of region cannot also be used to justify resource > requests from another RIR. When a request for resources from ARIN is > justified by need located within another RIR?s service region, an > officer of the applicant must attest that the same services and > facilities have not been used as the basis for a resource request in the > other region(s). ARIN reserves the right to request a listing of all the > applicant's number holdings in the region(s) of proposed use, but this > should happen only when there are significant reasons to suspect > duplicate requests. > > Comments: > a. Timetable for implementation: Immediate > b. Anything else > Current policy is ambiguous on the issue of out of region use of ARIN > registered resources. The only guidance on the issue in current policy > is Section 2.2, which defines the the role of RIRs as ?to manage and > distribute public Internet address space within their respective > regions.? Some in the community believe this means out of region use > should be prevented or restricted, while others believe this is only > intended to focus efforts within the region and not define where > resources may be used. > Previous policy proposals have explored restricting or otherwise > limiting out of region use, but none have gained consensus within the > ARIN community. Several standards for restricting out of region use were > explored, but all of them were perceived as interfering with the > legitimate operations of multi- or trans-regional networks. > The requirement to have a minimal level of resources deployed in the > region (/44 for IPv6, /22 for IPv4, 1 ASN) is an attempt to respond to > law enforcement and some community concerns. An absolute threshold > ensures that those applying for ARIN resources are actually operating in > the region and not simply a shell company, but it avoids the known > pitfalls of trying to use percentages of the organization's overall > holdings to do that. The use of officer attestation and the possibility > of an audit is an attempt to prevent duplicate requests without > requiring burdensome reporting requirements. > In summary, this proposal ensures that trans-regional organizations or > service providers operating within the ARIN region may receive all the > resources they need from ARIN if they wish to do so. This change is > particularly important for IPv6. Requiring organizations get IPv6 > resources from multiple RIRs will result in additional unique > non-aggregatable prefixes within the IPv6 route table. From narten at us.ibm.com Fri Apr 10 00:53:03 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 10 Apr 2015 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201504100453.t3A4r3ko024901@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri Apr 10 00:53:02 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 84.26% | 34378 | info at arin.net 50.00% | 1 | 15.74% | 6421 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 40799 | Total From mueller at syr.edu Sun Apr 12 16:53:27 2015 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 12 Apr 2015 20:53:27 +0000 Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) Message-ID: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> At ARIN 35 we will be discussing the fate of a proposal to formally allow out of region use of number resources. Attendees can review the text of the policy alongside a staff and legal assessment of it here: https://www.arin.net/policy/proposals/2014_1.html The following is my response to the legal assessment of the proposed out of region use policy by ARIN's Counsel. It is clear that Counsel opposes this policy but I am not sure we are getting an unbiased assessment of its true implications. In the spirit of open dialogue about policies that are supposed to be developed bottom up by the community, I offer this rejoinder: Counsel states: "ARIN is governed by ICANN ICP-2, which calls for establishment of a single RIR to serve each region." Regional exclusivity is one of the more interesting and far-ranging issues raised by 2014-1. We need to have a clear and honest discussion of it. Counsel is claiming that ICP-2 requires all usage of numbers to be bound to exclusive RIR service regions But this claim has no basis in either ICP-2 itself nor in operational practice. - The title of ICP-2 is "Criteria for Establishment of New Regional Internet Registries;" in other words it is about the establishment of NEW RIRs, not about the general model of number governance - Even assuming that service regions shouldn't overlap, ICP-2 does not articulate or establish a policy regarding use of number resources outside of a RIR's service region. - ICP-2 is not a law, and thus raises no legal issues; - ICP-2 is not even a global policy, as its development and adoption by the ICANN board antedates the global policy development process - It is routine for LIRs with transnational operations to rely on one RIR for most of their address resources rather than joining multiple registries in each of the service regions. Far from leading to "difficulty for co-ordination and co-operation" and "confusion for the community within the region," such practices make coordination easier and reduce confusion and overhead. In this regard, let me quote a Feb 25, 2015 statement on PPML by Tony Hain: "Back up and figure out what problem is being solved. The primary reason RIR's became possessive about their territory was "absurd protection of their precious IPv4 allocations". Rewind to the pre-RIR timeframe, and allocations were global, and use was global. The RIRs were brought in to simplify the process, not fragment it. ... Are we trying to protect the RIR's claimed autonomy over geography, or simplify the process of distribution for a global resource? If it is the latter as it started out to be, the definition of "out of region" is off-planet. If it is the former, why do people continue to fight against NIR's? If you want absolute autonomy, you need somebody capable of protecting your defined geography, and that usually becomes police or military. Make up your collective mind about your stated objective and make policy fit that. As far as I know the stated objective is to facilitate allocations of a global resource, so trying to restrict what the recipient does with it would appear to be out of scope." As Hain suggests, the regional nature of RIRs was intended to facilitate resource distribution, not fragment it; the real reason for assertions of territorial exclusivity is IPv4 scarcity and uneven runout among the RIRs. But 2014-1 probably will not be implemented until ARIN's free pool is gone. Counsel asserts: "This policy would allow entities with no real connection to the ARIN's service region to obtain, for example, increasingly scarce IPv4 resources" "No real connection" = a major exaggeration. The current policy requires recipients of ARIN resources to be organizations with an existing customer relationship & agreement with ARIN and be "currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively." Some connection to the ARIN region is required. Counsel asserts: "...if the policy were adopted, ARIN could arguably become subject to the jurisdiction and laws passed by governments outside our service region. This may lead to ARIN being a litigant in courts of nations outside its service region and subject to their requirements and judgments. ARIN will need to accept greater legal expenditures and risks, as well as potentially larger costs in order to take this greater scope into consideration in ARIN's registry activities on an ongoing basis." Questionable. As long as ARIN permits its number resources to be used outside of the region, as it currently does, the same risk exists regardless of whether 2014-1 passes or not. Note that even ARIN's Counsel states that he supports allowing network operators headquartered in ARIN's region to make use of ARIN-registered resources out of the North American region. Such cases would pose the same jurisdictional risks, if indeed those risks are significant. Thus it is unclear how 2014-1 changes anything in this regard. Note also that a RIPE policy in place for the past 2 and a half years has not led to any such problems. RIPE-NCC is currently allocating /22s from the 185.0.0.0/8 block without needs assessment and have given out hundreds since 2012. The receipant of the /22 is required to become a RIPE NCC member, but the recipient can be based anywhere. Over a dozen US companies not based in the RIPE region have availed themselves of this policy. Here are a few examples, with links to the Whois: US 185.46.120.0 01/31/2014 IHNetworks, LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-ILI4-RIPE&type=organisation US 185.47.84.0 02/10/2014 KVH Industries, Inc https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-KII1-RIPE&type=organisation US 185.51.4.0 03/20/2014 Latisys-Denver, LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-LL159-RIPE&type=organisation US 185.52.0.0 03/27/2014 RamNode LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-RL171-RIPE&type=organisation US 185.52.136.0 04/01/2014 Peak Web LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-PWL4-RIPE&type=organisation I believe in evidence-based policy. In many respects, RIPE-NCC is permitting out of region membership and out of region use. Can Counsel identify any of the purported problems taking place because of RIPE's openness to members from other regions? Has RIPE been a litigant in the US or has a national government threatened it with "political oversight" because of these actions? Counsel asserts: "[T]he policy fails to recognize that ARIN is not likely to able to perform the function contemplated in the policy with certain countries," such as Cuba, Iran and North Korea. ARIN is barred from doing business with those countries with or without this policy. Any applicant for resources from those countries could simply be denied. Counsel asserts: "ARIN may be subject to significantly greater political oversight by national governments in its service region that will wish to evaluate why ARIN alone of the 5 RIRs is assuming a duty to service all of the world's community. It may be argued by governments in ARIN's region that this is a potential breach of ARIN's fiduciary obligations to its own region, and to examine whether it is consistent with ARIN's non-profit status and other corporate documents." Incomplete, factually wrong in part, and speculative. It is incomplete because Counsel provides no legal reason why allowing out of region use would threaten ARIN's nonprofit status. Factually wrong because ARIN is not alone - note the RIPE-NCC case above. The argument about government reaction is speculative and non-legal. Essentially the claim is that governments (not the number resource-using community) won't like this policy and will punish ARIN for passing it by asserting some unspecified kind of "political oversight." Based on context I can think of only one government that would be in a position to assert "political oversight" over ARIN, and that is the U.S. government. Yet the US is firmly committed to private sector-led, multistakeholder internet governance. There is no legislation proposing to regulate ARIN on the horizon and no major private sector stakeholder lobbying group demanding it. I think, therefore, that Counsel has it exactly backwards: if we reject this policy solely because of fear of the US government, ARIN and its board will be breaching their fiduciary obligations to pass number resource policies that are fair and impartial, technically sound, and supported by the community. Counsel asserts: "the policy will lead to an increase in fraudulent applications from out of region requestors, and issuance of resources to those who fraudulently file, since ARIN is not as well positioned to successfully discover such fraud by out of region requestors." This is a legitimate concern. But I see no reason why staff cannot deny resources to entities that cannot produce adequate evidence for their claims. Other tweaks to be policy could be conceived that might address this issue, bearing in mind that two previous attempts to define thresholds were not acceptable to the community. Further, the incentive for most fraudulent applications comes from IPv4 scarcity, which has a very limited time horizon. Conclusion The choice is clear: are IP numbers a global resource to be allocated and assigned on the basis of technical efficiency, or are RIRs here to fragment the number distribution process into mutually exclusive territories? Will this policy be adopted or not based on its merit and community support, or on vague threats about governmental repercussions? I look forward to seeing you at ARIN 35 to further air these issues. Milton L Mueller ARIN Advisory Council member but speaking only for myself Laura J. and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/ Internet Governance Project http://internetgovernance.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Huberman at microsoft.com Sun Apr 12 18:48:16 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Sun, 12 Apr 2015 22:48:16 +0000 Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) In-Reply-To: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> References: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> Message-ID: I would like to quote just one section of Milton's post. >Counsel asserts: > "the policy will lead to an increase in fraudulent applications from out of > region requestors, and issuance of resources to those who fraudulently > file, since ARIN is not as well positioned to successfully discover such fraud > by out of region requestors." > This is a legitimate concern. But I see no reason why staff cannot deny > resources to entities that cannot produce adequate evidence for their claims. > Other tweaks to be policy could be conceived that might address this issue, > bearing in mind that two previous attempts to define thresholds were not > acceptable to the community. Further, the incentive for most fraudulent > applications comes from IPv4 scarcity, which has a very limited time horizon. Historically, there have been bad actors who have successfully obtained substantial IPv4 space from ARIN without having any customers or significant equipment in the region. A common method is to set up a routing infrastructure inside the ARIN region, and backhaul the traffic to the customers who all reside and operate in a region which has no IPv4 space available. And in my opinion, it is this type of scenario which Counsel is referring to. The counter-argument to this concern is to hold off enacting 2014-1 until ARIN exhaustion. And I haven't heard a counter-counter-argument. If 2014-1 were not enacted until IPv4 was out of play, and the only resources that ARIN would be giving out are IPv6 blocks and AS numbers, then I fail to see why the fraud concern is valid. If I'm mistaken, I'd like to know how so. Regards, David David R Huberman Principal, Global IP Addressing Microsoft Corporation From Daniel_Alexander at Cable.Comcast.com Sun Apr 12 19:30:31 2015 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Sun, 12 Apr 2015 23:30:31 +0000 Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) In-Reply-To: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> References: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> Message-ID: Milton, Everything you state below is your opinion, just as what counsel states is an opinion. As is my opinion that your reply approaches the line of personal attacks, which is a specifically prohibited activity on this list. As the Shepherd of this proposal it is good to call out the other side of an argument, but whether one side is wrong is not your call to make. It has also been pointed out that it is not appropriate to reference particular companies since you cannot speak authoritatively for them, or the details they operate under. Let's have a better conversation on Tuesday when this proposal is discussed at the meeting. Dan Alexander AC Chair From: Milton L Mueller > Date: Sunday, April 12, 2015 at 1:53 PM To: "arin-ppml at arin.net" > Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) At ARIN 35 we will be discussing the fate of a proposal to formally allow out of region use of number resources. Attendees can review the text of the policy alongside a staff and legal assessment of it here: https://www.arin.net/policy/proposals/2014_1.html The following is my response to the legal assessment of the proposed out of region use policy by ARIN's Counsel. It is clear that Counsel opposes this policy but I am not sure we are getting an unbiased assessment of its true implications. In the spirit of open dialogue about policies that are supposed to be developed bottom up by the community, I offer this rejoinder: Counsel states: "ARIN is governed by ICANN ICP-2, which calls for establishment of a single RIR to serve each region." Regional exclusivity is one of the more interesting and far-ranging issues raised by 2014-1. We need to have a clear and honest discussion of it. Counsel is claiming that ICP-2 requires all usage of numbers to be bound to exclusive RIR service regions But this claim has no basis in either ICP-2 itself nor in operational practice. - The title of ICP-2 is "Criteria for Establishment of New Regional Internet Registries;" in other words it is about the establishment of NEW RIRs, not about the general model of number governance - Even assuming that service regions shouldn?t overlap, ICP-2 does not articulate or establish a policy regarding use of number resources outside of a RIR?s service region. - ICP-2 is not a law, and thus raises no legal issues; - ICP-2 is not even a global policy, as its development and adoption by the ICANN board antedates the global policy development process - It is routine for LIRs with transnational operations to rely on one RIR for most of their address resources rather than joining multiple registries in each of the service regions. Far from leading to "difficulty for co-ordination and co-operation" and "confusion for the community within the region," such practices make coordination easier and reduce confusion and overhead. In this regard, let me quote a Feb 25, 2015 statement on PPML by Tony Hain: "Back up and figure out what problem is being solved. The primary reason RIR's became possessive about their territory was "absurd protection of their precious IPv4 allocations". Rewind to the pre-RIR timeframe, and allocations were global, and use was global. The RIRs were brought in to simplify the process, not fragment it. ... Are we trying to protect the RIR's claimed autonomy over geography, or simplify the process of distribution for a global resource? If it is the latter as it started out to be, the definition of "out of region" is off-planet. If it is the former, why do people continue to fight against NIR's? If you want absolute autonomy, you need somebody capable of protecting your defined geography, and that usually becomes police or military. Make up your collective mind about your stated objective and make policy fit that. As far as I know the stated objective is to facilitate allocations of a global resource, so trying to restrict what the recipient does with it would appear to be out of scope." As Hain suggests, the regional nature of RIRs was intended to facilitate resource distribution, not fragment it; the real reason for assertions of territorial exclusivity is IPv4 scarcity and uneven runout among the RIRs. But 2014-1 probably will not be implemented until ARIN's free pool is gone. Counsel asserts: "This policy would allow entities with no real connection to the ARIN's service region to obtain, for example, increasingly scarce IPv4 resources" ?No real connection? = a major exaggeration. The current policy requires recipients of ARIN resources to be organizations with an existing customer relationship & agreement with ARIN and be "currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively." Some connection to the ARIN region is required. Counsel asserts: "...if the policy were adopted, ARIN could arguably become subject to the jurisdiction and laws passed by governments outside our service region. This may lead to ARIN being a litigant in courts of nations outside its service region and subject to their requirements and judgments. ARIN will need to accept greater legal expenditures and risks, as well as potentially larger costs in order to take this greater scope into consideration in ARIN's registry activities on an ongoing basis." Questionable. As long as ARIN permits its number resources to be used outside of the region, as it currently does, the same risk exists regardless of whether 2014-1 passes or not. Note that even ARIN?s Counsel states that he supports allowing network operators headquartered in ARIN's region to make use of ARIN-registered resources out of the North American region. Such cases would pose the same jurisdictional risks, if indeed those risks are significant. Thus it is unclear how 2014-1 changes anything in this regard. Note also that a RIPE policy in place for the past 2 and a half years has not led to any such problems. RIPE-NCC is currently allocating /22s from the 185.0.0.0/8 block without needs assessment and have given out hundreds since 2012. The receipant of the /22 is required to become a RIPE NCC member, but the recipient can be based anywhere. Over a dozen US companies not based in the RIPE region have availed themselves of this policy. Here are a few examples, with links to the Whois: US 185.46.120.0 01/31/2014 IHNetworks, LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-ILI4-RIPE&type=organisation US 185.47.84.0 02/10/2014 KVH Industries, Inc https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-KII1-RIPE&type=organisation US 185.51.4.0 03/20/2014 Latisys-Denver, LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-LL159-RIPE&type=organisation US 185.52.0.0 03/27/2014 RamNode LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-RL171-RIPE&type=organisation US 185.52.136.0 04/01/2014 Peak Web LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-PWL4-RIPE&type=organisation I believe in evidence-based policy. In many respects, RIPE-NCC is permitting out of region membership and out of region use. Can Counsel identify any of the purported problems taking place because of RIPE?s openness to members from other regions? Has RIPE been a litigant in the US or has a national government threatened it with "political oversight" because of these actions? Counsel asserts: "[T]he policy fails to recognize that ARIN is not likely to able to perform the function contemplated in the policy with certain countries," such as Cuba, Iran and North Korea. ARIN is barred from doing business with those countries with or without this policy. Any applicant for resources from those countries could simply be denied. Counsel asserts: "ARIN may be subject to significantly greater political oversight by national governments in its service region that will wish to evaluate why ARIN alone of the 5 RIRs is assuming a duty to service all of the world's community. It may be argued by governments in ARIN's region that this is a potential breach of ARIN's fiduciary obligations to its own region, and to examine whether it is consistent with ARIN's non-profit status and other corporate documents." Incomplete, factually wrong in part, and speculative. It is incomplete because Counsel provides no legal reason why allowing out of region use would threaten ARIN's nonprofit status. Factually wrong because ARIN is not alone - note the RIPE-NCC case above. The argument about government reaction is speculative and non-legal. Essentially the claim is that governments (not the number resource-using community) won't like this policy and will punish ARIN for passing it by asserting some unspecified kind of "political oversight." Based on context I can think of only one government that would be in a position to assert "political oversight" over ARIN, and that is the U.S. government. Yet the US is firmly committed to private sector-led, multistakeholder internet governance. There is no legislation proposing to regulate ARIN on the horizon and no major private sector stakeholder lobbying group demanding it. I think, therefore, that Counsel has it exactly backwards: if we reject this policy solely because of fear of the US government, ARIN and its board will be breaching their fiduciary obligations to pass number resource policies that are fair and impartial, technically sound, and supported by the community. Counsel asserts: "the policy will lead to an increase in fraudulent applications from out of region requestors, and issuance of resources to those who fraudulently file, since ARIN is not as well positioned to successfully discover such fraud by out of region requestors." This is a legitimate concern. But I see no reason why staff cannot deny resources to entities that cannot produce adequate evidence for their claims. Other tweaks to be policy could be conceived that might address this issue, bearing in mind that two previous attempts to define thresholds were not acceptable to the community. Further, the incentive for most fraudulent applications comes from IPv4 scarcity, which has a very limited time horizon. Conclusion The choice is clear: are IP numbers a global resource to be allocated and assigned on the basis of technical efficiency, or are RIRs here to fragment the number distribution process into mutually exclusive territories? Will this policy be adopted or not based on its merit and community support, or on vague threats about governmental repercussions? I look forward to seeing you at ARIN 35 to further air these issues. Milton L Mueller ARIN Advisory Council member but speaking only for myself Laura J. and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/ Internet Governance Project http://internetgovernance.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sun Apr 12 19:53:30 2015 From: jcurran at arin.net (John Curran) Date: Sun, 12 Apr 2015 23:53:30 +0000 Subject: [arin-ppml] Counsel identifications of ARIN legal obligations (was: Re: Response to the ARIN counsel's assessment of 2014-1 (Out of region use)) In-Reply-To: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> References: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> Message-ID: <88E71CC8-0BBF-403B-8709-61E59092BD81@corp.arin.net> On Apr 12, 2015, at 1:53 PM, Milton L Mueller > wrote: ... Counsel states: "ARIN is governed by ICANN ICP-2, which calls for establishment of a single RIR to serve each region." Regional exclusivity is one of the more interesting and far-ranging issues raised by 2014-1. We need to have a clear and honest discussion of it. Indeed. Counsel is claiming that ICP-2 requires all usage of numbers to be bound to exclusive RIR service regions Milton - Please provide reference for your statement above; I am unaware of any statement by ARIN's Counsel that "ICP-2 requires all usage of numbers to be bound to exclusive RIR service regions? i.e. it would appear that you are ascribing statements to ARIN Counsel that were not actually made (and ddespite the rather laudable goal of clear and honest discussion.) For reference, the full paragraph regarding ICP-2 from the staff and legal assessment follows - First, ARIN is governed by ICANN ICP-2, which calls for establishment of a single RIR to serve each region. It further notes that multiple RIRs serving in single region is likely to lead to difficulty for co-ordination and co-operation between the RIRs as well as confusion for the community within the region. The implication of that governance structure is that each RIR can and should serve its service region. This policy would allow entities with no real connection to the ARIN's service region to obtain, for example, increasingly scarce IPv4 resources from ARIN and related registry services. This policy would result in ARIN effectively providing registry services to other regions, and thus appears on its face to be inconsistent with ICP-2. ARIN has obligations to follow the global policy in ICP2, or seek changes in it. The paragraphs notes that providing resources which are for use entirely out of region may be inconsistent with ICP-2; it makes no statement that _all usage_ of ARIN-issued resources are bound to the service region. Note that organizations that receive numbers resources presently from ARIN often do make some use of them in other regions. The statement in the staff and legal assessment is with regarding to issuing number resources to a party where it is clear that they are solely for use outside the ARIN service region, i.e. this is not a case of incidental use, or someone repurposing an address block, but instead ARIN knowingly providing registry services and resources to other region. But this claim has no basis in either ICP-2 itself nor in operational practice. ... - Even assuming that service regions shouldn?t overlap, ICP-2 does not articulate or establish a policy regarding use of number resources outside of a RIR?s service region. You are correct - ICP-2 does not articulate any policy regarding _use_ of number resources outside of a RIR?s service region, however, ICP-2 does identify issues that can result from RIRs operating in the same region and thus supports the actual statements which are within the staff and legal assessment. i.e. to the effect that adoption of 2014-1 draft policy would result in ARIN effectively providing registry services to other regions, it would appears on its face to be inconsistent with the intent and language of ICP-2, as follows below - "Each region should be served by a single RIR, established under one management and in one location. The establishment of multiple RIRs in one region is likely to lead to: ? fragmentation of address space allocated to the region; ? difficulty for co-ordination and co-operation between the RIRs; ? confusion for the community within the region.? Now it is possible that ICP-2 is rather dated and could use to be refreshed to look forward to the future which there is not significant new address allocations being made every day and where inter-RIR transfers already pose similar issues; however, that is probably a much larger discussion and ICP-2 stands as-is in the meantime. - ICP-2 is not a law, and thus raises no legal issues; ARIN?s compliance with its agreements to other parties can result in legal issues for ARIN, and ARIN has an agreement with ICANN (ASO MOU) which directly incorporates and references ICP-2. - ICP-2 is not even a global policy, as its development and adoption by the ICANN board antedates the global policy development process ICP-2 is identified in the ASO MOU as containing "agreed requirements and policies? It would be helpful to understand if you feel that there is no or nominal risk to the ARIN community to setting aside the principles contained in ICP-2; if that is the case, then it might be best to simply state that as your position. The guidance from ARIN Counsel that we have obligations with respect to ICP-2 is quite clear, but that doesn?t preclude the possiblity that there be nominal actual consequence (w.r.t. our relation with ICANN) from doing otherwise. Thank you, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Mon Apr 13 01:15:15 2015 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 13 Apr 2015 05:15:15 +0000 Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) In-Reply-To: References: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> Message-ID: <4711134efc4a4f40941a2884726a7572@EX13-MBX-13.ad.syr.edu> Dan: I would have to challenge you to show me specific language that constitutes a "personal attack." I don't think you can. I don't think the conversation can get much better than the contribution I made. It was well-researched, well reasoned, and more than an opinion. If you don't agree with it, let's hear some real argumentation or facts. Huberman's response is a good example of where the conversation is going based on what I said. I encourage you to join the conversation in a constructive way. --MM From: Alexander, Daniel [mailto:Daniel_Alexander at Cable.Comcast.com] Sent: Sunday, April 12, 2015 7:31 PM To: Milton L Mueller; arin-ppml at arin.net Subject: Re: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) Milton, Everything you state below is your opinion, just as what counsel states is an opinion. As is my opinion that your reply approaches the line of personal attacks, which is a specifically prohibited activity on this list. As the Shepherd of this proposal it is good to call out the other side of an argument, but whether one side is wrong is not your call to make. It has also been pointed out that it is not appropriate to reference particular companies since you cannot speak authoritatively for them, or the details they operate under. Let's have a better conversation on Tuesday when this proposal is discussed at the meeting. Dan Alexander AC Chair From: Milton L Mueller > Date: Sunday, April 12, 2015 at 1:53 PM To: "arin-ppml at arin.net" > Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) At ARIN 35 we will be discussing the fate of a proposal to formally allow out of region use of number resources. Attendees can review the text of the policy alongside a staff and legal assessment of it here: https://www.arin.net/policy/proposals/2014_1.html The following is my response to the legal assessment of the proposed out of region use policy by ARIN's Counsel. It is clear that Counsel opposes this policy but I am not sure we are getting an unbiased assessment of its true implications. In the spirit of open dialogue about policies that are supposed to be developed bottom up by the community, I offer this rejoinder: Counsel states: "ARIN is governed by ICANN ICP-2, which calls for establishment of a single RIR to serve each region." Regional exclusivity is one of the more interesting and far-ranging issues raised by 2014-1. We need to have a clear and honest discussion of it. Counsel is claiming that ICP-2 requires all usage of numbers to be bound to exclusive RIR service regions But this claim has no basis in either ICP-2 itself nor in operational practice. - The title of ICP-2 is "Criteria for Establishment of New Regional Internet Registries;" in other words it is about the establishment of NEW RIRs, not about the general model of number governance - Even assuming that service regions shouldn't overlap, ICP-2 does not articulate or establish a policy regarding use of number resources outside of a RIR's service region. - ICP-2 is not a law, and thus raises no legal issues; - ICP-2 is not even a global policy, as its development and adoption by the ICANN board antedates the global policy development process - It is routine for LIRs with transnational operations to rely on one RIR for most of their address resources rather than joining multiple registries in each of the service regions. Far from leading to "difficulty for co-ordination and co-operation" and "confusion for the community within the region," such practices make coordination easier and reduce confusion and overhead. In this regard, let me quote a Feb 25, 2015 statement on PPML by Tony Hain: "Back up and figure out what problem is being solved. The primary reason RIR's became possessive about their territory was "absurd protection of their precious IPv4 allocations". Rewind to the pre-RIR timeframe, and allocations were global, and use was global. The RIRs were brought in to simplify the process, not fragment it. ... Are we trying to protect the RIR's claimed autonomy over geography, or simplify the process of distribution for a global resource? If it is the latter as it started out to be, the definition of "out of region" is off-planet. If it is the former, why do people continue to fight against NIR's? If you want absolute autonomy, you need somebody capable of protecting your defined geography, and that usually becomes police or military. Make up your collective mind about your stated objective and make policy fit that. As far as I know the stated objective is to facilitate allocations of a global resource, so trying to restrict what the recipient does with it would appear to be out of scope." As Hain suggests, the regional nature of RIRs was intended to facilitate resource distribution, not fragment it; the real reason for assertions of territorial exclusivity is IPv4 scarcity and uneven runout among the RIRs. But 2014-1 probably will not be implemented until ARIN's free pool is gone. Counsel asserts: "This policy would allow entities with no real connection to the ARIN's service region to obtain, for example, increasingly scarce IPv4 resources" "No real connection" = a major exaggeration. The current policy requires recipients of ARIN resources to be organizations with an existing customer relationship & agreement with ARIN and be "currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively." Some connection to the ARIN region is required. Counsel asserts: "...if the policy were adopted, ARIN could arguably become subject to the jurisdiction and laws passed by governments outside our service region. This may lead to ARIN being a litigant in courts of nations outside its service region and subject to their requirements and judgments. ARIN will need to accept greater legal expenditures and risks, as well as potentially larger costs in order to take this greater scope into consideration in ARIN's registry activities on an ongoing basis." Questionable. As long as ARIN permits its number resources to be used outside of the region, as it currently does, the same risk exists regardless of whether 2014-1 passes or not. Note that even ARIN's Counsel states that he supports allowing network operators headquartered in ARIN's region to make use of ARIN-registered resources out of the North American region. Such cases would pose the same jurisdictional risks, if indeed those risks are significant. Thus it is unclear how 2014-1 changes anything in this regard. Note also that a RIPE policy in place for the past 2 and a half years has not led to any such problems. RIPE-NCC is currently allocating /22s from the 185.0.0.0/8 block without needs assessment and have given out hundreds since 2012. The receipant of the /22 is required to become a RIPE NCC member, but the recipient can be based anywhere. Over a dozen US companies not based in the RIPE region have availed themselves of this policy. Here are a few examples, with links to the Whois: US 185.46.120.0 01/31/2014 IHNetworks, LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-ILI4-RIPE&type=organisation US 185.47.84.0 02/10/2014 KVH Industries, Inc https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-KII1-RIPE&type=organisation US 185.51.4.0 03/20/2014 Latisys-Denver, LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-LL159-RIPE&type=organisation US 185.52.0.0 03/27/2014 RamNode LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-RL171-RIPE&type=organisation US 185.52.136.0 04/01/2014 Peak Web LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-PWL4-RIPE&type=organisation I believe in evidence-based policy. In many respects, RIPE-NCC is permitting out of region membership and out of region use. Can Counsel identify any of the purported problems taking place because of RIPE's openness to members from other regions? Has RIPE been a litigant in the US or has a national government threatened it with "political oversight" because of these actions? Counsel asserts: "[T]he policy fails to recognize that ARIN is not likely to able to perform the function contemplated in the policy with certain countries," such as Cuba, Iran and North Korea. ARIN is barred from doing business with those countries with or without this policy. Any applicant for resources from those countries could simply be denied. Counsel asserts: "ARIN may be subject to significantly greater political oversight by national governments in its service region that will wish to evaluate why ARIN alone of the 5 RIRs is assuming a duty to service all of the world's community. It may be argued by governments in ARIN's region that this is a potential breach of ARIN's fiduciary obligations to its own region, and to examine whether it is consistent with ARIN's non-profit status and other corporate documents." Incomplete, factually wrong in part, and speculative. It is incomplete because Counsel provides no legal reason why allowing out of region use would threaten ARIN's nonprofit status. Factually wrong because ARIN is not alone - note the RIPE-NCC case above. The argument about government reaction is speculative and non-legal. Essentially the claim is that governments (not the number resource-using community) won't like this policy and will punish ARIN for passing it by asserting some unspecified kind of "political oversight." Based on context I can think of only one government that would be in a position to assert "political oversight" over ARIN, and that is the U.S. government. Yet the US is firmly committed to private sector-led, multistakeholder internet governance. There is no legislation proposing to regulate ARIN on the horizon and no major private sector stakeholder lobbying group demanding it. I think, therefore, that Counsel has it exactly backwards: if we reject this policy solely because of fear of the US government, ARIN and its board will be breaching their fiduciary obligations to pass number resource policies that are fair and impartial, technically sound, and supported by the community. Counsel asserts: "the policy will lead to an increase in fraudulent applications from out of region requestors, and issuance of resources to those who fraudulently file, since ARIN is not as well positioned to successfully discover such fraud by out of region requestors." This is a legitimate concern. But I see no reason why staff cannot deny resources to entities that cannot produce adequate evidence for their claims. Other tweaks to be policy could be conceived that might address this issue, bearing in mind that two previous attempts to define thresholds were not acceptable to the community. Further, the incentive for most fraudulent applications comes from IPv4 scarcity, which has a very limited time horizon. Conclusion The choice is clear: are IP numbers a global resource to be allocated and assigned on the basis of technical efficiency, or are RIRs here to fragment the number distribution process into mutually exclusive territories? Will this policy be adopted or not based on its merit and community support, or on vague threats about governmental repercussions? I look forward to seeing you at ARIN 35 to further air these issues. Milton L Mueller ARIN Advisory Council member but speaking only for myself Laura J. and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/ Internet Governance Project http://internetgovernance.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Mon Apr 13 01:52:38 2015 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 13 Apr 2015 05:52:38 +0000 Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) In-Reply-To: References: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> Message-ID: > -----Original Message----- > Historically, there have been bad actors who have successfully obtained > substantial IPv4 space from ARIN without having any customers or significant > equipment in the region. A common method is to set up a routing > infrastructure inside the ARIN region, and backhaul the traffic to the > customers who all reside and operate in a region which has no IPv4 space > available. > > And in my opinion, it is this type of scenario which Counsel is referring to. > > The counter-argument to this concern is to hold off enacting 2014-1 until > ARIN exhaustion. And I haven't heard a counter-counter-argument. If 2014-1 > were not enacted until IPv4 was out of play, and the only resources that > ARIN would be giving out are IPv6 blocks and AS numbers, then I fail to see > why the fraud concern is valid. If I'm mistaken, I'd like to know how so. Thanks, David. I agree with your assessment. I think IPv4 scarcity is indeed the reason why ARIN is becoming so territorial and provides the incentive for fraud (even, as you note, without 2014-1). Setting the enactment date to correspond to some clear measure of "runout" could be a good step forward. From mueller at syr.edu Mon Apr 13 02:01:57 2015 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 13 Apr 2015 06:01:57 +0000 Subject: [arin-ppml] Counsel identifications of ARIN legal obligations (was: Re: Response to the ARIN counsel's assessment of 2014-1 (Out of region use)) In-Reply-To: <88E71CC8-0BBF-403B-8709-61E59092BD81@corp.arin.net> References: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> <88E71CC8-0BBF-403B-8709-61E59092BD81@corp.arin.net> Message-ID: <7cc562fbad0f47e599068daa6d8533c7@EX13-MBX-13.ad.syr.edu> Thanks, John, for engaging on the substantive issues. I welcome your response as part of the needed dialogue. Counsel is claiming that ICP-2 requires all usage of numbers to be bound to exclusive RIR service regions Milton - Please provide reference for your statement above; MM: When Counsel says ?This policy would result in ARIN effectively providing registry services to other regions? and ?each RIR should serve its region? I don?t think it is unreasonable to interpret that as meaning that all number services should be obtained from the RIR where the numbers will be used. This policy would allow entities with no real connection to the ARIN's service region to obtain, for example, increasingly scarce IPv4 resources from ARIN and related registry services. MM: My response showed that this was a false claim, and it is interesting that you did not challenge this. The paragraphs notes that providing resources which are for use entirely out of region may be inconsistent with ICP-2; it makes no statement that _all usage_ of ARIN-issued resources are bound to the service region. Note that organizations that receive numbers resources presently from ARIN often do make some use of them in other regions. MM: Does this mean that both you and the Counsel are not claiming that all usage of numbers must be bound to the service region? I hope so. Please explain why this is not inconsistent with Counsel?s interpretation of ICP-2. The statement in the staff and legal assessment is with regarding to issuing number resources to a party where it is clear that they are solely for use outside the ARIN service region, i.e. this is not a case of incidental use, or someone repurposing an address block, but instead ARIN knowingly providing registry services and resources to other region. MM: As you should know, the policy requires some presence in the region. It is designed to aid organizations that want one-stop shopping. You are correct - ICP-2 does not articulate any policy regarding _use_ of number resources outside of a RIR?s service region, MM: Good, I am glad we can agree on that. however, ICP-2 does identify issues that can result from RIRs operating in the same region and thus supports the actual statements which are within the staff and legal assessment. i.e. to the effect that adoption of 2014-1 draft policy would result in ARIN effectively providing registry services to other regions, it would appears on its face to be inconsistent with the intent and language of ICP-2, as follows below - MM: Both you and counsel keep ignoring the requirement for some kind of presence and established relationship with ARIN. Please re-read the staff assessment, which says: ?There are registrants in the ARIN region, such as end-users, who are not necessarily ARIN members. The policy text has been updated to omit references to ?Member?, and is understood to refer to organizations with an existing customer relationship & agreement with ARIN.? MM: As for this: "Each region should be served by a single RIR, established under one management and in one location. The establishment of multiple RIRs in one region is likely to lead to: ? fragmentation of address space allocated to the region; ? difficulty for co-ordination and co-operation between the RIRs; ? confusion for the community within the region.? MM: Remember, ICP-2 was written to deal with the establishment of new RIRs. I would agree that creating a new RIR that serves, say, Kansas and Nebraska and giving it a distinct set of number blocks to distribute would fragment the distribution of address space. But that Is not what this policy (2014-1) is proposing. ICP-2 is basically not the right standard to use in assessing this policy. You and Counsel have seized on it in an attempt to find an argument for regional exclusivity, but it is not the right instrument. If you want a global policy that says RIRs must confine address distribution to entities mainly in their region, go create one. It doesn?t exist yet. Now it is possible that ICP-2 is rather dated and could use to be refreshed to look forward to the future which there is not significant new address allocations being made every day and where inter-RIR transfers already pose similar issues; however, that is probably a much larger discussion and ICP-2 stands as-is in the meantime. As I said, ICP-2 does not say anything definitive about the issue we are debating in 2014-1. Please stop using it for that purpose. - ICP-2 is not a law, and thus raises no legal issues; ARIN?s compliance with its agreements to other parties can result in legal issues for ARIN, and ARIN has an agreement with ICANN (ASO MOU) which directly incorporates and references ICP-2. MM: OK, so we?ve agreed that you will stop calling it a global policy. But as I said, ICP-2 does not bear on the issues raised by 2014-1 It would be helpful to understand if you feel that there is no or nominal risk to the ARIN community to setting aside the principles contained in ICP-2; if that is the case, then it MM: You misunderstand my position, which is that ICP-2 does not establish any principles regarding out of region use policies of existing RIRs. ICP-2 establishes criteria for the establishment of new RIRs. Is it your position that 2014-1 is establishing a new RIR? Here is what I have concluded from our exchange: ? Neither you nor the Counsel are claiming that all usage of numbers must be bound to the service region ? You are not refuting or contesting my claim that the legal assessment mistakenly asserted that the policy would allow entities with ?no real connection? to the ARIN region to use it as a registry. ? We have agreed that ICP-2 is not a global policy, but you do consider it binding as part of the ASO MoU ? You still think ICP-2 is relevant to 2014-1, and I don?t. Fair summary? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinb at thewire.ca Mon Apr 13 02:06:00 2015 From: kevinb at thewire.ca (Kevin Blumberg) Date: Mon, 13 Apr 2015 06:06:00 +0000 Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) In-Reply-To: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> References: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> Message-ID: <7E7773B523E82C478734E793E58F69E78DAF76A3@SBS2011.thewireinc.local> Milton, All of the example net blocks that used in your examples below appear to be routed to equipment in the RIPE region. I would prefer that the RIPE porition is clarified as my understanding is that the IP allocations are to be used inside of the region. On the RIPE website the following FAQ seems to contradicte your statements Yes, you can become a member of RIPE NCC. However, keep in mind that the Internet number resources need be announced within the RIPE NCC's service region. I don't believe that your description of how allocations are handled in the RIPE region are accurate. Possible asking RIPE staff would be appropriate at this time. From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller Sent: April 12, 2015 4:53 PM To: arin-ppml at arin.net Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) At ARIN 35 we will be discussing the fate of a proposal to formally allow out of region use of number resources. Attendees can review the text of the policy alongside a staff and legal assessment of it here: https://www.arin.net/policy/proposals/2014_1.html The following is my response to the legal assessment of the proposed out of region use policy by ARIN's Counsel. It is clear that Counsel opposes this policy but I am not sure we are getting an unbiased assessment of its true implications. In the spirit of open dialogue about policies that are supposed to be developed bottom up by the community, I offer this rejoinder: Counsel states: "ARIN is governed by ICANN ICP-2, which calls for establishment of a single RIR to serve each region." Regional exclusivity is one of the more interesting and far-ranging issues raised by 2014-1. We need to have a clear and honest discussion of it. Counsel is claiming that ICP-2 requires all usage of numbers to be bound to exclusive RIR service regions But this claim has no basis in either ICP-2 itself nor in operational practice. - The title of ICP-2 is "Criteria for Establishment of New Regional Internet Registries;" in other words it is about the establishment of NEW RIRs, not about the general model of number governance - Even assuming that service regions shouldn't overlap, ICP-2 does not articulate or establish a policy regarding use of number resources outside of a RIR's service region. - ICP-2 is not a law, and thus raises no legal issues; - ICP-2 is not even a global policy, as its development and adoption by the ICANN board antedates the global policy development process - It is routine for LIRs with transnational operations to rely on one RIR for most of their address resources rather than joining multiple registries in each of the service regions. Far from leading to "difficulty for co-ordination and co-operation" and "confusion for the community within the region," such practices make coordination easier and reduce confusion and overhead. In this regard, let me quote a Feb 25, 2015 statement on PPML by Tony Hain: "Back up and figure out what problem is being solved. The primary reason RIR's became possessive about their territory was "absurd protection of their precious IPv4 allocations". Rewind to the pre-RIR timeframe, and allocations were global, and use was global. The RIRs were brought in to simplify the process, not fragment it. ... Are we trying to protect the RIR's claimed autonomy over geography, or simplify the process of distribution for a global resource? If it is the latter as it started out to be, the definition of "out of region" is off-planet. If it is the former, why do people continue to fight against NIR's? If you want absolute autonomy, you need somebody capable of protecting your defined geography, and that usually becomes police or military. Make up your collective mind about your stated objective and make policy fit that. As far as I know the stated objective is to facilitate allocations of a global resource, so trying to restrict what the recipient does with it would appear to be out of scope." As Hain suggests, the regional nature of RIRs was intended to facilitate resource distribution, not fragment it; the real reason for assertions of territorial exclusivity is IPv4 scarcity and uneven runout among the RIRs. But 2014-1 probably will not be implemented until ARIN's free pool is gone. Counsel asserts: "This policy would allow entities with no real connection to the ARIN's service region to obtain, for example, increasingly scarce IPv4 resources" "No real connection" = a major exaggeration. The current policy requires recipients of ARIN resources to be organizations with an existing customer relationship & agreement with ARIN and be "currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively." Some connection to the ARIN region is required. Counsel asserts: "...if the policy were adopted, ARIN could arguably become subject to the jurisdiction and laws passed by governments outside our service region. This may lead to ARIN being a litigant in courts of nations outside its service region and subject to their requirements and judgments. ARIN will need to accept greater legal expenditures and risks, as well as potentially larger costs in order to take this greater scope into consideration in ARIN's registry activities on an ongoing basis." Questionable. As long as ARIN permits its number resources to be used outside of the region, as it currently does, the same risk exists regardless of whether 2014-1 passes or not. Note that even ARIN's Counsel states that he supports allowing network operators headquartered in ARIN's region to make use of ARIN-registered resources out of the North American region. Such cases would pose the same jurisdictional risks, if indeed those risks are significant. Thus it is unclear how 2014-1 changes anything in this regard. Note also that a RIPE policy in place for the past 2 and a half years has not led to any such problems. RIPE-NCC is currently allocating /22s from the 185.0.0.0/8 block without needs assessment and have given out hundreds since 2012. The receipant of the /22 is required to become a RIPE NCC member, but the recipient can be based anywhere. Over a dozen US companies not based in the RIPE region have availed themselves of this policy. Here are a few examples, with links to the Whois: US 185.46.120.0 01/31/2014 IHNetworks, LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-ILI4-RIPE&type=organisation US 185.47.84.0 02/10/2014 KVH Industries, Inc https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-KII1-RIPE&type=organisation US 185.51.4.0 03/20/2014 Latisys-Denver, LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-LL159-RIPE&type=organisation US 185.52.0.0 03/27/2014 RamNode LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-RL171-RIPE&type=organisation US 185.52.136.0 04/01/2014 Peak Web LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-PWL4-RIPE&type=organisation I believe in evidence-based policy. In many respects, RIPE-NCC is permitting out of region membership and out of region use. Can Counsel identify any of the purported problems taking place because of RIPE's openness to members from other regions? Has RIPE been a litigant in the US or has a national government threatened it with "political oversight" because of these actions? Counsel asserts: "[T]he policy fails to recognize that ARIN is not likely to able to perform the function contemplated in the policy with certain countries," such as Cuba, Iran and North Korea. ARIN is barred from doing business with those countries with or without this policy. Any applicant for resources from those countries could simply be denied. Counsel asserts: "ARIN may be subject to significantly greater political oversight by national governments in its service region that will wish to evaluate why ARIN alone of the 5 RIRs is assuming a duty to service all of the world's community. It may be argued by governments in ARIN's region that this is a potential breach of ARIN's fiduciary obligations to its own region, and to examine whether it is consistent with ARIN's non-profit status and other corporate documents." Incomplete, factually wrong in part, and speculative. It is incomplete because Counsel provides no legal reason why allowing out of region use would threaten ARIN's nonprofit status. Factually wrong because ARIN is not alone - note the RIPE-NCC case above. The argument about government reaction is speculative and non-legal. Essentially the claim is that governments (not the number resource-using community) won't like this policy and will punish ARIN for passing it by asserting some unspecified kind of "political oversight." Based on context I can think of only one government that would be in a position to assert "political oversight" over ARIN, and that is the U.S. government. Yet the US is firmly committed to private sector-led, multistakeholder internet governance. There is no legislation proposing to regulate ARIN on the horizon and no major private sector stakeholder lobbying group demanding it. I think, therefore, that Counsel has it exactly backwards: if we reject this policy solely because of fear of the US government, ARIN and its board will be breaching their fiduciary obligations to pass number resource policies that are fair and impartial, technically sound, and supported by the community. Counsel asserts: "the policy will lead to an increase in fraudulent applications from out of region requestors, and issuance of resources to those who fraudulently file, since ARIN is not as well positioned to successfully discover such fraud by out of region requestors." This is a legitimate concern. But I see no reason why staff cannot deny resources to entities that cannot produce adequate evidence for their claims. Other tweaks to be policy could be conceived that might address this issue, bearing in mind that two previous attempts to define thresholds were not acceptable to the community. Further, the incentive for most fraudulent applications comes from IPv4 scarcity, which has a very limited time horizon. Conclusion The choice is clear: are IP numbers a global resource to be allocated and assigned on the basis of technical efficiency, or are RIRs here to fragment the number distribution process into mutually exclusive territories? Will this policy be adopted or not based on its merit and community support, or on vague threats about governmental repercussions? I look forward to seeing you at ARIN 35 to further air these issues. Milton L Mueller ARIN Advisory Council member but speaking only for myself Laura J. and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/ Internet Governance Project http://internetgovernance.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinb at thewire.ca Mon Apr 13 02:07:56 2015 From: kevinb at thewire.ca (Kevin Blumberg) Date: Mon, 13 Apr 2015 06:07:56 +0000 Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) References: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> Message-ID: <7E7773B523E82C478734E793E58F69E78DAF7745@SBS2011.thewireinc.local> I managed to hit the send button before completion. The link to the faq is https://www.ripe.net/lir-services/member-support/info/faqs/faq-joining Thanks, Kevin Blumberg From: Kevin Blumberg Sent: April 13, 2015 2:06 AM To: 'Milton L Mueller'; arin-ppml at arin.net Subject: RE: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) Milton, All of the example net blocks that used in your examples below appear to be routed to equipment in the RIPE region. I would prefer that the RIPE porition is clarified as my understanding is that the IP allocations are to be used inside of the region. On the RIPE website the following FAQ seems to contradicte your statements Yes, you can become a member of RIPE NCC. However, keep in mind that the Internet number resources need be announced within the RIPE NCC's service region. I don't believe that your description of how allocations are handled in the RIPE region are accurate. Possible asking RIPE staff would be appropriate at this time. From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller Sent: April 12, 2015 4:53 PM To: arin-ppml at arin.net Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) At ARIN 35 we will be discussing the fate of a proposal to formally allow out of region use of number resources. Attendees can review the text of the policy alongside a staff and legal assessment of it here: https://www.arin.net/policy/proposals/2014_1.html The following is my response to the legal assessment of the proposed out of region use policy by ARIN's Counsel. It is clear that Counsel opposes this policy but I am not sure we are getting an unbiased assessment of its true implications. In the spirit of open dialogue about policies that are supposed to be developed bottom up by the community, I offer this rejoinder: Counsel states: "ARIN is governed by ICANN ICP-2, which calls for establishment of a single RIR to serve each region." Regional exclusivity is one of the more interesting and far-ranging issues raised by 2014-1. We need to have a clear and honest discussion of it. Counsel is claiming that ICP-2 requires all usage of numbers to be bound to exclusive RIR service regions But this claim has no basis in either ICP-2 itself nor in operational practice. - The title of ICP-2 is "Criteria for Establishment of New Regional Internet Registries;" in other words it is about the establishment of NEW RIRs, not about the general model of number governance - Even assuming that service regions shouldn't overlap, ICP-2 does not articulate or establish a policy regarding use of number resources outside of a RIR's service region. - ICP-2 is not a law, and thus raises no legal issues; - ICP-2 is not even a global policy, as its development and adoption by the ICANN board antedates the global policy development process - It is routine for LIRs with transnational operations to rely on one RIR for most of their address resources rather than joining multiple registries in each of the service regions. Far from leading to "difficulty for co-ordination and co-operation" and "confusion for the community within the region," such practices make coordination easier and reduce confusion and overhead. In this regard, let me quote a Feb 25, 2015 statement on PPML by Tony Hain: "Back up and figure out what problem is being solved. The primary reason RIR's became possessive about their territory was "absurd protection of their precious IPv4 allocations". Rewind to the pre-RIR timeframe, and allocations were global, and use was global. The RIRs were brought in to simplify the process, not fragment it. ... Are we trying to protect the RIR's claimed autonomy over geography, or simplify the process of distribution for a global resource? If it is the latter as it started out to be, the definition of "out of region" is off-planet. If it is the former, why do people continue to fight against NIR's? If you want absolute autonomy, you need somebody capable of protecting your defined geography, and that usually becomes police or military. Make up your collective mind about your stated objective and make policy fit that. As far as I know the stated objective is to facilitate allocations of a global resource, so trying to restrict what the recipient does with it would appear to be out of scope." As Hain suggests, the regional nature of RIRs was intended to facilitate resource distribution, not fragment it; the real reason for assertions of territorial exclusivity is IPv4 scarcity and uneven runout among the RIRs. But 2014-1 probably will not be implemented until ARIN's free pool is gone. Counsel asserts: "This policy would allow entities with no real connection to the ARIN's service region to obtain, for example, increasingly scarce IPv4 resources" "No real connection" = a major exaggeration. The current policy requires recipients of ARIN resources to be organizations with an existing customer relationship & agreement with ARIN and be "currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively." Some connection to the ARIN region is required. Counsel asserts: "...if the policy were adopted, ARIN could arguably become subject to the jurisdiction and laws passed by governments outside our service region. This may lead to ARIN being a litigant in courts of nations outside its service region and subject to their requirements and judgments. ARIN will need to accept greater legal expenditures and risks, as well as potentially larger costs in order to take this greater scope into consideration in ARIN's registry activities on an ongoing basis." Questionable. As long as ARIN permits its number resources to be used outside of the region, as it currently does, the same risk exists regardless of whether 2014-1 passes or not. Note that even ARIN's Counsel states that he supports allowing network operators headquartered in ARIN's region to make use of ARIN-registered resources out of the North American region. Such cases would pose the same jurisdictional risks, if indeed those risks are significant. Thus it is unclear how 2014-1 changes anything in this regard. Note also that a RIPE policy in place for the past 2 and a half years has not led to any such problems. RIPE-NCC is currently allocating /22s from the 185.0.0.0/8 block without needs assessment and have given out hundreds since 2012. The receipant of the /22 is required to become a RIPE NCC member, but the recipient can be based anywhere. Over a dozen US companies not based in the RIPE region have availed themselves of this policy. Here are a few examples, with links to the Whois: US 185.46.120.0 01/31/2014 IHNetworks, LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-ILI4-RIPE&type=organisation US 185.47.84.0 02/10/2014 KVH Industries, Inc https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-KII1-RIPE&type=organisation US 185.51.4.0 03/20/2014 Latisys-Denver, LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-LL159-RIPE&type=organisation US 185.52.0.0 03/27/2014 RamNode LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-RL171-RIPE&type=organisation US 185.52.136.0 04/01/2014 Peak Web LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-PWL4-RIPE&type=organisation I believe in evidence-based policy. In many respects, RIPE-NCC is permitting out of region membership and out of region use. Can Counsel identify any of the purported problems taking place because of RIPE's openness to members from other regions? Has RIPE been a litigant in the US or has a national government threatened it with "political oversight" because of these actions? Counsel asserts: "[T]he policy fails to recognize that ARIN is not likely to able to perform the function contemplated in the policy with certain countries," such as Cuba, Iran and North Korea. ARIN is barred from doing business with those countries with or without this policy. Any applicant for resources from those countries could simply be denied. Counsel asserts: "ARIN may be subject to significantly greater political oversight by national governments in its service region that will wish to evaluate why ARIN alone of the 5 RIRs is assuming a duty to service all of the world's community. It may be argued by governments in ARIN's region that this is a potential breach of ARIN's fiduciary obligations to its own region, and to examine whether it is consistent with ARIN's non-profit status and other corporate documents." Incomplete, factually wrong in part, and speculative. It is incomplete because Counsel provides no legal reason why allowing out of region use would threaten ARIN's nonprofit status. Factually wrong because ARIN is not alone - note the RIPE-NCC case above. The argument about government reaction is speculative and non-legal. Essentially the claim is that governments (not the number resource-using community) won't like this policy and will punish ARIN for passing it by asserting some unspecified kind of "political oversight." Based on context I can think of only one government that would be in a position to assert "political oversight" over ARIN, and that is the U.S. government. Yet the US is firmly committed to private sector-led, multistakeholder internet governance. There is no legislation proposing to regulate ARIN on the horizon and no major private sector stakeholder lobbying group demanding it. I think, therefore, that Counsel has it exactly backwards: if we reject this policy solely because of fear of the US government, ARIN and its board will be breaching their fiduciary obligations to pass number resource policies that are fair and impartial, technically sound, and supported by the community. Counsel asserts: "the policy will lead to an increase in fraudulent applications from out of region requestors, and issuance of resources to those who fraudulently file, since ARIN is not as well positioned to successfully discover such fraud by out of region requestors." This is a legitimate concern. But I see no reason why staff cannot deny resources to entities that cannot produce adequate evidence for their claims. Other tweaks to be policy could be conceived that might address this issue, bearing in mind that two previous attempts to define thresholds were not acceptable to the community. Further, the incentive for most fraudulent applications comes from IPv4 scarcity, which has a very limited time horizon. Conclusion The choice is clear: are IP numbers a global resource to be allocated and assigned on the basis of technical efficiency, or are RIRs here to fragment the number distribution process into mutually exclusive territories? Will this policy be adopted or not based on its merit and community support, or on vague threats about governmental repercussions? I look forward to seeing you at ARIN 35 to further air these issues. Milton L Mueller ARIN Advisory Council member but speaking only for myself Laura J. and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/ Internet Governance Project http://internetgovernance.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From lear at cisco.com Mon Apr 13 03:02:39 2015 From: lear at cisco.com (Eliot Lear) Date: Mon, 13 Apr 2015 09:02:39 +0200 Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) In-Reply-To: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> References: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> Message-ID: <552B6A0F.60109@cisco.com> Hi Milton and others, I don't generally comment on these sorts of things, and so please excuse me if this comment is untimely. I have a single comment about your response to counsel. On 4/12/15 10:53 PM, Milton L Mueller wrote: > > Counsel asserts: > > "...if the policy were adopted, ARIN could arguably become subject to > the jurisdiction and laws passed by governments outside our service > region. This may lead to ARIN being a litigant in courts of nations > outside its service region and subject to their requirements and > judgments. ARIN will need to accept greater legal expenditures and > risks, as well as potentially larger costs in order to take this > greater scope into consideration in ARIN's registry activities on an > ongoing basis." > > > > Questionable. As long as ARIN permits its number resources to be used > outside of the region, as it currently does, the same risk exists > regardless of whether 2014-1 passes or not. Note that even ARIN?s > Counsel states that he supports allowing network operators > headquartered in ARIN's region to make use of ARIN-registered > resources out of the North American region. Such cases would pose the > same jurisdictional risks, if indeed those risks are significant. Thus > it is unclear how 2014-1 changes anything in this regard. Note also > that a RIPE policy in place for the past 2 and a half years has not > led to any such problems. > If I understand what counsel is claiming, it is in a way a contrapositive inference. That is- because ARIN does not assign resources to applicants who do not have a presence within its region, there is no logical basis for assertion of jurisdiction beyond that region. That is- the RIR system acts as a sort of legal and political circuit breaker so that governments do not overreach, and this proposal would remove that isolation. In the "What Could Possibly Go Wrong" department, there are two general classes of things going wrong: 1. ARIN applies local jurisdiction rules for the country of the applicant, in which case ARIN policies risk becoming potentially conflicting country-specific policies; or 2. ARIN ignores any such jurisdictional mandate. Further thoughts on this case follow. It seems to me that there are three risks of actions a country could take if ARIN did not apply their rules : * A country bans its citizens from transacting with ARIN. * A country bans origination of announcement of ARIN-assigned blocks within its borders. * A country either attempts a comprehensive control of the infrastructure through multilateral agreements with other countries, or simply joins in existing efforts to do so. Today the risk is bound to countries within a region. It is the third case that would do the most harm to the Internet, as has been demonstrated in previous attempts. The way RIRs have addressed the third case has been to engage with governments in region to discuss their concerns. Since you cite them in your email, I'll mention that RIPE, for instance, has an extremely effective and useful government roundtable. To do so at a worldwide level leads to ICANN-like structures. While those structures may be necessary for ICANN, I would hope we could avoid them here. To your point that there is no evidence to counsel's claim, I agree with you that the best policy is made through practical experience (a'la "rough consensus and running code"). That has to be balanced with what could happen if you get it wrong the first time. This brings to the fore whether the problem is sufficiently important to take on those risks. I have no opinion at this time as to that balance, nor do I have a feel for the level of risk we are talking about. RIPE's experience thus far seems to indicate it's pretty low, as you point out, but that may be because they have excellent relationships with governments in region. Warm regards, Eliot Lear -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 481 bytes Desc: OpenPGP digital signature URL: From jcurran at arin.net Mon Apr 13 09:15:41 2015 From: jcurran at arin.net (John Curran) Date: Mon, 13 Apr 2015 13:15:41 +0000 Subject: [arin-ppml] Counsel identifications of ARIN legal obligations (was: Re: Response to the ARIN counsel's assessment of 2014-1 (Out of region use)) In-Reply-To: <7cc562fbad0f47e599068daa6d8533c7@EX13-MBX-13.ad.syr.edu> References: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> <88E71CC8-0BBF-403B-8709-61E59092BD81@corp.arin.net> <7cc562fbad0f47e599068daa6d8533c7@EX13-MBX-13.ad.syr.edu> Message-ID: <4A97BEA6-5E75-4288-BBEF-89A723C8E1E0@arin.net> On Apr 12, 2015, at 11:01 PM, Milton L Mueller > wrote: Counsel is claiming that ICP-2 requires all usage of numbers to be bound to exclusive RIR service regions Milton - Please provide reference for your statement above; MM: When Counsel says ?This policy would result in ARIN effectively providing registry services to other regions? and ?each RIR should serve its region? I don?t think it is unreasonable to interpret that as meaning that all number services should be obtained from the RIR where the numbers will be used. Milton - ?ICP-2 requires all usage of numbers to be bound to exclusive RIR service regions? is what you attribute to Counsel, and it is very different issue than "ARIN effectively providing registry services to other regions? - two completely different concepts. One is regarding how a recipient may make use of their assigned address space whereas the other deals with an RIR's behavior. You conflate this two distinct concepts to arrive at a claim which was not made in the staff & legal report, nor does the constraint how parties use their address blocks appear in ICP-2. MM: Does this mean that both you and the Counsel are not claiming that all usage of numbers must be bound to the service region? I hope so. Please explain why this is not inconsistent with Counsel?s interpretation of ICP-2. Again, how a party makes use of assigned space is not directly within ARIN?s control once resources are issued, whereas ARIN having policies which issue space knowingly for use entirely within another region is completely within ARIN?s control and raises a valid question about commitment to the principles in ICP-2. MM: As you should know, the policy requires some presence in the region. It is designed to aid organizations that want one-stop shopping. It does indeed require some presence in our region, but draft policy 2014-1 would specifically have ARIN issue number resources entirely for use in another region. MM: Both you and counsel keep ignoring the requirement for some kind of presence and established relationship with ARIN. ? The required presence and established relationship with ARIN only affects who may apply, it does not change the fact that the draft policy, if adopted, would have ARIN issue numbers resources entirely for use in another region. It is ARIN knowing issuing resources entirely for use within another region which raises the question about consistency with the intent and language of ICP-2. MM: As for this: "Each region should be served by a single RIR, established under one management and in one location. The establishment of multiple RIRs in one region is likely to lead to: ? fragmentation of address space allocated to the region; ? difficulty for co-ordination and co-operation between the RIRs; ? confusion for the community within the region.? MM: Remember, ICP-2 was written to deal with the establishment of new RIRs. I would agree that creating a new RIR that serves, say, Kansas and Nebraska and giving it a distinct set of number blocks to distribute would fragment the distribution of address space. But that Is not what this policy (2014-1) is proposing. ICP-2 is basically not the right standard to use in assessing this policy. You and Counsel have seized on it in an attempt to find an argument for regional exclusivity, but it is not the right instrument. If you want a global policy that says RIRs must confine address distribution to entities mainly in their region, go create one. It doesn?t exist yet. Actually, the relevant portion of ICP-2 shown above is quite clear regarding intent for the servicing of regions by RIRs. You might not like what it says, or wish that it said something else, but it is an agreed policy to which ARIN is a party. It is not clear if setting aside the requirements therein will have consequences to ARIN?s ability to perform its mission, but it is plain that issuing space for use entirely within another region is a departure from the intent of the policy. As I said, ICP-2 does not say anything definitive about the issue we are debating in 2014-1. Please stop using it for that purpose. I understand your position, but do disagree as noted above. MM: You misunderstand my position, which is that ICP-2 does not establish any principles regarding out of region use policies of existing RIRs ?use? is about what an applicant does with their number resources. It is unclear if ICP-2 was ever intend to effect or constrain how recipients actually used resources received from any RIR. ?service region? is about where an RIR issues number resources, and it is quite clear that ICP-2 is intends that 'Each region should be served by a single RIR?. 2014-1 would have ARIN issue space knowingly and entirely within another region - whether that?s a good thing or a bad thing is something for the community to consider, but it would be contrary to intent to language and intent of ICP-2. Here is what I have concluded from our exchange: ? Neither you nor the Counsel are claiming that all usage of numbers must be bound to the service region Milton - it is you who incorrectly stated that "Counsel is claiming that ICP-2 requires all usage of numbers to be bound to exclusive RIR service regions?, i.e. a statement which is not reflected in actual staff and legal assessment for 2014-1 nor in ARIN?s practices. ICP-2 has no requirements about how parties use their number resources; it has requirements only about how RIR?s operate. When asked to provide a reference supporting your claim of Counsel?s position, you were unable to provide any. This is not surprising, since the actual staff and legal assessment simply notes that providing resources which are for use entirely out of region may be inconsistent with ICP-2; it makes no statement at all regarding usage of ARIN-issued resources being bound to the service region. I cannot tell if you are still unable to distinguish the difference between policy that affects what and how ARIN does its mission versus your incorrect statement attributed to Counsel that ARIN somehow constrains how recipients make use of their assigned number blocks, one can hope reading this response will help in that regard. ? You are not refuting or contesting my claim that the legal assessment mistakenly asserted that the policy would allow entities with ?no real connection? to the ARIN region to use it as a registry. There is much in your initial message and followup that I did not respond to - please do not consider that any form of endorsement or acceptance of your assertions therein. I only responded with respect to your ICP-2 remarks due to the false claim of statements made by Counsel. ? We have agreed that ICP-2 is not a global policy, but you do consider it binding as part of the ASO MoU ? You still think ICP-2 is relevant to 2014-1, and I don?t. Fair summary? And with regards to your acknowledging your creation of claims by Counsel that were in fact not made? Did you come to any conclusions in that regard, and do intend at some point to correct your remarks? ARIN today issues number resources to parties that are sometimes used by parties outside the ARIN service region. ARIN does not issue resources based on demand out of region, but a global enterprise can take number resources today and use them anywhere, and 2014-1 is not necessary to enable that. What 2014-1 would allow is for an organization with a minimal level of resources in region to request and obtain number resources from ARIN entirely based on demand and for use outside of the ARIN region. This would have ARIN effectively providing registry services to another region, which plainly does not confirm with the language and intent of ICP-2. The implications, if any, to ARIN?s ability to perform its mission that may result by proceeding contrary to ICP-2 are unclear at this time. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Mon Apr 13 10:43:25 2015 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 13 Apr 2015 14:43:25 +0000 Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) In-Reply-To: <7E7773B523E82C478734E793E58F69E78DAF76A3@SBS2011.thewireinc.local> References: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> <7E7773B523E82C478734E793E58F69E78DAF76A3@SBS2011.thewireinc.local> Message-ID: So is "being announced" in the region the same as "being used" within the region? What implications does this have for 2014-1? I think RIPE-NCC does maintain a kind of nominal adherence to service regional, but a lot of the American companies applying for these resources are requesting and using them based on local or global need, not specifically European need. IT would be good to see RIPEclarify. --MM From: Kevin Blumberg [mailto:kevinb at thewire.ca] Sent: Monday, April 13, 2015 2:06 AM To: Milton L Mueller; arin-ppml at arin.net Subject: RE: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) Milton, All of the example net blocks that used in your examples below appear to be routed to equipment in the RIPE region. I would prefer that the RIPE porition is clarified as my understanding is that the IP allocations are to be used inside of the region. On the RIPE website the following FAQ seems to contradicte your statements Yes, you can become a member of RIPE NCC. However, keep in mind that the Internet number resources need be announced within the RIPE NCC's service region. I don't believe that your description of how allocations are handled in the RIPE region are accurate. Possible asking RIPE staff would be appropriate at this time. From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller Sent: April 12, 2015 4:53 PM To: arin-ppml at arin.net Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) At ARIN 35 we will be discussing the fate of a proposal to formally allow out of region use of number resources. Attendees can review the text of the policy alongside a staff and legal assessment of it here: https://www.arin.net/policy/proposals/2014_1.html The following is my response to the legal assessment of the proposed out of region use policy by ARIN's Counsel. It is clear that Counsel opposes this policy but I am not sure we are getting an unbiased assessment of its true implications. In the spirit of open dialogue about policies that are supposed to be developed bottom up by the community, I offer this rejoinder: Counsel states: "ARIN is governed by ICANN ICP-2, which calls for establishment of a single RIR to serve each region." Regional exclusivity is one of the more interesting and far-ranging issues raised by 2014-1. We need to have a clear and honest discussion of it. Counsel is claiming that ICP-2 requires all usage of numbers to be bound to exclusive RIR service regions But this claim has no basis in either ICP-2 itself nor in operational practice. - The title of ICP-2 is "Criteria for Establishment of New Regional Internet Registries;" in other words it is about the establishment of NEW RIRs, not about the general model of number governance - Even assuming that service regions shouldn't overlap, ICP-2 does not articulate or establish a policy regarding use of number resources outside of a RIR's service region. - ICP-2 is not a law, and thus raises no legal issues; - ICP-2 is not even a global policy, as its development and adoption by the ICANN board antedates the global policy development process - It is routine for LIRs with transnational operations to rely on one RIR for most of their address resources rather than joining multiple registries in each of the service regions. Far from leading to "difficulty for co-ordination and co-operation" and "confusion for the community within the region," such practices make coordination easier and reduce confusion and overhead. In this regard, let me quote a Feb 25, 2015 statement on PPML by Tony Hain: "Back up and figure out what problem is being solved. The primary reason RIR's became possessive about their territory was "absurd protection of their precious IPv4 allocations". Rewind to the pre-RIR timeframe, and allocations were global, and use was global. The RIRs were brought in to simplify the process, not fragment it. ... Are we trying to protect the RIR's claimed autonomy over geography, or simplify the process of distribution for a global resource? If it is the latter as it started out to be, the definition of "out of region" is off-planet. If it is the former, why do people continue to fight against NIR's? If you want absolute autonomy, you need somebody capable of protecting your defined geography, and that usually becomes police or military. Make up your collective mind about your stated objective and make policy fit that. As far as I know the stated objective is to facilitate allocations of a global resource, so trying to restrict what the recipient does with it would appear to be out of scope." As Hain suggests, the regional nature of RIRs was intended to facilitate resource distribution, not fragment it; the real reason for assertions of territorial exclusivity is IPv4 scarcity and uneven runout among the RIRs. But 2014-1 probably will not be implemented until ARIN's free pool is gone. Counsel asserts: "This policy would allow entities with no real connection to the ARIN's service region to obtain, for example, increasingly scarce IPv4 resources" "No real connection" = a major exaggeration. The current policy requires recipients of ARIN resources to be organizations with an existing customer relationship & agreement with ARIN and be "currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively." Some connection to the ARIN region is required. Counsel asserts: "...if the policy were adopted, ARIN could arguably become subject to the jurisdiction and laws passed by governments outside our service region. This may lead to ARIN being a litigant in courts of nations outside its service region and subject to their requirements and judgments. ARIN will need to accept greater legal expenditures and risks, as well as potentially larger costs in order to take this greater scope into consideration in ARIN's registry activities on an ongoing basis." Questionable. As long as ARIN permits its number resources to be used outside of the region, as it currently does, the same risk exists regardless of whether 2014-1 passes or not. Note that even ARIN's Counsel states that he supports allowing network operators headquartered in ARIN's region to make use of ARIN-registered resources out of the North American region. Such cases would pose the same jurisdictional risks, if indeed those risks are significant. Thus it is unclear how 2014-1 changes anything in this regard. Note also that a RIPE policy in place for the past 2 and a half years has not led to any such problems. RIPE-NCC is currently allocating /22s from the 185.0.0.0/8 block without needs assessment and have given out hundreds since 2012. The receipant of the /22 is required to become a RIPE NCC member, but the recipient can be based anywhere. Over a dozen US companies not based in the RIPE region have availed themselves of this policy. Here are a few examples, with links to the Whois: US 185.46.120.0 01/31/2014 IHNetworks, LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-ILI4-RIPE&type=organisation US 185.47.84.0 02/10/2014 KVH Industries, Inc https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-KII1-RIPE&type=organisation US 185.51.4.0 03/20/2014 Latisys-Denver, LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-LL159-RIPE&type=organisation US 185.52.0.0 03/27/2014 RamNode LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-RL171-RIPE&type=organisation US 185.52.136.0 04/01/2014 Peak Web LLC https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-PWL4-RIPE&type=organisation I believe in evidence-based policy. In many respects, RIPE-NCC is permitting out of region membership and out of region use. Can Counsel identify any of the purported problems taking place because of RIPE's openness to members from other regions? Has RIPE been a litigant in the US or has a national government threatened it with "political oversight" because of these actions? Counsel asserts: "[T]he policy fails to recognize that ARIN is not likely to able to perform the function contemplated in the policy with certain countries," such as Cuba, Iran and North Korea. ARIN is barred from doing business with those countries with or without this policy. Any applicant for resources from those countries could simply be denied. Counsel asserts: "ARIN may be subject to significantly greater political oversight by national governments in its service region that will wish to evaluate why ARIN alone of the 5 RIRs is assuming a duty to service all of the world's community. It may be argued by governments in ARIN's region that this is a potential breach of ARIN's fiduciary obligations to its own region, and to examine whether it is consistent with ARIN's non-profit status and other corporate documents." Incomplete, factually wrong in part, and speculative. It is incomplete because Counsel provides no legal reason why allowing out of region use would threaten ARIN's nonprofit status. Factually wrong because ARIN is not alone - note the RIPE-NCC case above. The argument about government reaction is speculative and non-legal. Essentially the claim is that governments (not the number resource-using community) won't like this policy and will punish ARIN for passing it by asserting some unspecified kind of "political oversight." Based on context I can think of only one government that would be in a position to assert "political oversight" over ARIN, and that is the U.S. government. Yet the US is firmly committed to private sector-led, multistakeholder internet governance. There is no legislation proposing to regulate ARIN on the horizon and no major private sector stakeholder lobbying group demanding it. I think, therefore, that Counsel has it exactly backwards: if we reject this policy solely because of fear of the US government, ARIN and its board will be breaching their fiduciary obligations to pass number resource policies that are fair and impartial, technically sound, and supported by the community. Counsel asserts: "the policy will lead to an increase in fraudulent applications from out of region requestors, and issuance of resources to those who fraudulently file, since ARIN is not as well positioned to successfully discover such fraud by out of region requestors." This is a legitimate concern. But I see no reason why staff cannot deny resources to entities that cannot produce adequate evidence for their claims. Other tweaks to be policy could be conceived that might address this issue, bearing in mind that two previous attempts to define thresholds were not acceptable to the community. Further, the incentive for most fraudulent applications comes from IPv4 scarcity, which has a very limited time horizon. Conclusion The choice is clear: are IP numbers a global resource to be allocated and assigned on the basis of technical efficiency, or are RIRs here to fragment the number distribution process into mutually exclusive territories? Will this policy be adopted or not based on its merit and community support, or on vague threats about governmental repercussions? I look forward to seeing you at ARIN 35 to further air these issues. Milton L Mueller ARIN Advisory Council member but speaking only for myself Laura J. and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/ Internet Governance Project http://internetgovernance.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Mon Apr 13 10:45:03 2015 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 13 Apr 2015 14:45:03 +0000 Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) In-Reply-To: <552B6A0F.60109@cisco.com> References: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> <552B6A0F.60109@cisco.com> Message-ID: <484c4d14e7db446892b6a2c76f09232f@EX13-MBX-13.ad.syr.edu> If I understand what counsel is claiming, it is in a way a contrapositive inference. That is- because ARIN does not assign resources to applicants who do not have a presence within its region, there is no logical basis for assertion of jurisdiction beyond that region. MM: I thought we had already disposed of the false claim that 2014-1 does not require a presence in the region. Would you are to reframe this argument in a way that is relevant to 2014-1? I just don?t understand it -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Huberman at microsoft.com Mon Apr 13 14:11:22 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Mon, 13 Apr 2015 18:11:22 +0000 Subject: [arin-ppml] Policy idea: POC Validation Message-ID: Hello, Richard Jimmerson's Policy Experience Report indicated that 50% of the phone calls that RSD receives are about POC validation, and that they receive many angry emails and calls from POCs who are only associated with indirect resource registration records. In response, I offer the following change to the NRPM : Existing 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. I propose we make the first sentence read: "During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database that is associated with an active directly registered number resource." Thoughts? David David R Huberman Principal, Global IP Addressing Microsoft Corporation From David.Huberman at microsoft.com Mon Apr 13 14:30:03 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Mon, 13 Apr 2015 18:30:03 +0000 Subject: [arin-ppml] Policy to remove 25% in 30 days language Message-ID: I am planning on submitting the following policy template to ARIN in the coming days. I'd like feedback please. Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0 1.Policy Proposal Name: Remove 30 day utilization requirement in end-user IPv4 policy 4.Problem Statement: End-user policy is intended to provide end-users with a one year supply of IP addresses. Qualification for a one-year supply requires the network operator to utilize at least 25% of the requested addresses within 30 days. This text is unrealistic and should be remove. First, it often takes longer than 30 days to stage equipment and start actually using the addresses. Second, growth is often not that regimented; the forecast is to use X addresses over the course of a year, not to use 25% of X within 30 days. Third, this policy text applies to additional address space requests. It is incompatible with the requirements of other additional address space request justification which indicates that 80% utilization of existing space is sufficient to justify new space. If a block is at 80%, then often (almost always?) the remaining 80% will be used over the next 30 days and longer. Therefore the operator cannot honestly state they will use 25% of the ADDITIONAL space within 30 days of receiving it; they're still trying to use their older block efficiently. Fourth, in the face of ARIN exhaustion, some ISPs are starting to not give out /24 (or larger) blocks. So the justification for the 25% rule that previously existed (and in fact, applied for many years) is no longer germane. 5.Policy statement: Remove the 25% utilization criteria bullet point from NRPM 4.3.3. 6.Comments: a.Timetable for implementation: Immediate b.Anything else END OF TEMPLATE Thank you, David David R Huberman Principal, Global IP Addressing Microsoft Corporation From scottleibrand at gmail.com Mon Apr 13 14:57:50 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 13 Apr 2015 11:57:50 -0700 Subject: [arin-ppml] Policy to remove 25% in 30 days language In-Reply-To: References: Message-ID: I think this is a good approach. I also think we also need to recognize in the problem statement that, by the time any new policy is adopted, almost everyone qualifying for space under NRPM 4 will be getting it via transfer. And in a world where addresses are being obtained on the transfer market, strict constraints on how quickly addresses must be used probably make less sense than they did when most addresses were obtained via the free pool. -Scott On Mon, Apr 13, 2015 at 11:30 AM, David Huberman < David.Huberman at microsoft.com> wrote: > I am planning on submitting the following policy template to ARIN in the > coming days. I'd like feedback please. > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0 > 1.Policy Proposal Name: Remove 30 day utilization requirement in end-user > IPv4 policy > > 4.Problem Statement: End-user policy is intended to provide end-users > with a one year supply of IP addresses. Qualification for a one-year > supply requires the network operator to utilize at least 25% of the > requested addresses within 30 days. This text is unrealistic and should be > remove. > > First, it often takes longer than 30 days to stage equipment and start > actually using the addresses. > Second, growth is often not that regimented; the forecast is to use X > addresses over the course of a year, not to use 25% of X within 30 days. > Third, this policy text applies to additional address space requests. It > is incompatible with the requirements of other additional address space > request justification which indicates that 80% utilization of existing > space is sufficient to justify new space. If a block is at 80%, then often > (almost always?) the remaining 80% will be used over the next 30 days and > longer. Therefore the operator cannot honestly state they will use 25% of > the ADDITIONAL space within 30 days of receiving it; they're still trying > to use their older block efficiently. > Fourth, in the face of ARIN exhaustion, some ISPs are starting to not give > out /24 (or larger) blocks. So the justification for the 25% rule that > previously existed (and in fact, applied for many years) is no longer > germane. > > 5.Policy statement: Remove the 25% utilization criteria bullet point from > NRPM 4.3.3. > 6.Comments: > a.Timetable for implementation: Immediate > b.Anything else > > END OF TEMPLATE > > Thank you, > David > > David R Huberman > Principal, Global IP Addressing > Microsoft Corporation > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 tedm at ipinc.net Mon Apr 13 15:11:49 2015 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 13 Apr 2015 12:11:49 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: <552C14F5.9040705@ipinc.net> As one of the initiators of this policy I must state that none of us who worked on this ever assumed the POC Validation Policy would be the END of the process. The idea was that when a POC was marked invalid, that ARIN would institute an investigation into the number resources held by the invalid POC and if they did locate the actual holder, they would give that holder 30 days to supply valid POC contact info for whois that would replace the bogus invalid contact info. If the holder wasn't forthcoming, ARIN will delete the POC. Resources that have no POC's justifying their existence are then freed up for reassignment. If ARIN is not doing this, then it is completely understandable that you would be getting large numbers of phone calls from people annoyed that their email addresses are still in whois. So, ARIN can start doing this and thereby make the people happy who are complaining, and at the same time, freeing up resources that are held by stale or bogus POC data. You said "indirect resource registration records" What exactly is that? In my opinion, ANY POC that is in whois that is associated in any way with an organization or individual who has IP addresses, and is being used as justification for holding resources, must remain in the validation list. It seems quite obvious and apparent that POCs that ARIN has judged to be invalid, and is in the process of investigating, would be calling and complaining. In general people who are doing things they shouldn't be doing, don't like to be investigated would certainly would complain. That can be solved easily by deleting their records and thereby freeing up resources. Then you don't contact them again and the community gets back the IP addressing they have held. Does not a POC that is being contacted by ARIN have the right to have their information deleted? If they are calling in and complaining that their records are in there, they obviously want them removed. So, ARIN can remove them and stop bothering them. You need to define the difference between "indirect resource registration records" and "associated with an active directly registered number resource" before anyone can really make a judgement on this policy proposal change. It just seems very simple to me. If they are a POC they are there because their existence is justifying some IP address holding in some way, there is some connection. If their POC is no longer justifying an IP address holding and there is no connection whatsoever to an IP address holding, then take their POC out and doing so will automatically quit contacting them. Ted On 4/13/2015 11:11 AM, David Huberman wrote: > Hello, > > Richard Jimmerson's Policy Experience Report indicated that 50% of the phone calls that RSD receives are about POC validation, and that they receive many angry emails and calls from POCs who are only associated with indirect resource registration records. In response, I offer the following change to the NRPM : > > > Existing 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. > > > I propose we make the first sentence read: > > "During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database that is associated with an active directly registered number resource." > > Thoughts? > David > > David R Huberman > Principal, Global IP Addressing > Microsoft Corporation > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Mon Apr 13 15:32:21 2015 From: bill at herrin.us (William Herrin) Date: Mon, 13 Apr 2015 15:32:21 -0400 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: On Mon, Apr 13, 2015 at 2:11 PM, David Huberman wrote: > many angry emails and calls from POCs who are only associated with indirect resource registration records. > > During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database. > > "During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database that is associated with an active directly registered number resource." Hi David, How do we verify that an ISP is reporting truthful information about its downstream assignments? Regards, Bill herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From David.Huberman at microsoft.com Mon Apr 13 16:23:08 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Mon, 13 Apr 2015 20:23:08 +0000 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: <552C14F5.9040705@ipinc.net> References: <552C14F5.9040705@ipinc.net> Message-ID: Hi Ted, Thanks for the reply. By "indirect resource registration records", I meant reassignment records. ISP has a /17. They reassign a /28 to a customer, and decide to put customer POC information on it. That POC only exists because of the /28 - it isn't a POC for any directly registered allocation, assignment, or AS number. These are the POCs who are complaining en masse to ARIN after receiving POC Validation communications. My reasoning for removing POC validation for these types of POCs is that ISPs have the option to not register POCs at all -- they can choose "REASSIGN SIMPLE" as a path for registering SWIP information, and that doesn't have any POC info. Secondly, I'm not convinced there's a significant value in up-to-date POC information for reassigned numbers. In the end, the ISP (the direct registrant) is the party responsible for the IP addresses and use. (And in 90%+ of cases, the ISP is responsible for routing in the DFZ, too. For the cases where a reassigned block is announced by the customer, there's a customer ASN easily found in the routing tables, and that contact information is more germane than a SWIP record.) I hope that's clearer. David David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Monday, April 13, 2015 12:12 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy idea: POC Validation > > > As one of the initiators of this policy I must state that none of us who worked > on this ever assumed the POC Validation Policy would be the END of the > process. > > The idea was that when a POC was marked invalid, that ARIN would institute > an investigation into the number resources held by the invalid POC and if > they did locate the actual holder, they would give that holder 30 days to > supply valid POC contact info for whois that would replace the bogus invalid > contact info. > > If the holder wasn't forthcoming, ARIN will delete the POC. Resources that > have no POC's justifying their existence are then freed up for reassignment. > > If ARIN is not doing this, then it is completely understandable that you would > be getting large numbers of phone calls from people annoyed that their > email addresses are still in whois. > > So, ARIN can start doing this and thereby make the people happy who are > complaining, and at the same time, freeing up resources that are held by > stale or bogus POC data. > > You said "indirect resource registration records" > > What exactly is that? > > In my opinion, ANY POC that is in whois that is associated in any way with an > organization or individual who has IP addresses, and is being used as > justification for holding resources, must remain in the validation list. > > It seems quite obvious and apparent that POCs that ARIN has judged to be > invalid, and is in the process of investigating, would be calling and > complaining. In general people who are doing things they shouldn't be > doing, don't like to be investigated would certainly would complain. > That can be solved easily by deleting their records and thereby freeing up > resources. Then you don't contact them again and the community gets back > the IP addressing they have held. > > Does not a POC that is being contacted by ARIN have the right to have their > information deleted? If they are calling in and complaining that their records > are in there, they obviously want them removed. So, ARIN can remove them > and stop bothering them. > > You need to define the difference between "indirect resource registration > records" and "associated with an active directly registered number resource" > before anyone can really make a judgement on this policy proposal change. > > It just seems very simple to me. If they are a POC they are there because > their existence is justifying some IP address holding in some way, there is > some connection. If their POC is no longer justifying an IP address holding > and there is no connection whatsoever to an IP address holding, then take > their POC out and doing so will automatically quit contacting them. > > Ted > > On 4/13/2015 11:11 AM, David Huberman wrote: > > Hello, > > > > Richard Jimmerson's Policy Experience Report indicated that 50% of the > phone calls that RSD receives are about POC validation, and that they receive > many angry emails and calls from POCs who are only associated with indirect > resource registration records. In response, I offer the following change to the > NRPM : > > > > > > Existing 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. > > > > > > I propose we make the first sentence read: > > > > "During ARIN's annual Whois POC validation, an email will be sent to every > POC in the Whois database that is associated with an active directly > registered number resource." > > > > Thoughts? > > David > > > > David R Huberman > > Principal, Global IP Addressing > > Microsoft Corporation > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From David.Huberman at microsoft.com Mon Apr 13 16:29:30 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Mon, 13 Apr 2015 20:29:30 +0000 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: Hello Bill, > How do we verify that an ISP is reporting truthful information about its > downstream assignments? ARIN has asked questions about the ISP->customer relationship regularly as part of the additional allocation process - it's a mandatory step for all additional resource requests. That is supposed to verify the relationship of the ISP and the customer, and show justification for the size of the assignment made to the customer. But to my knowledge it's never drilled down to the POC level. In my proposal, I'm only trying to rectify an operational problem ARIN is having with the very broad scope of the POC Validation item in NRPM. It may be that the POC Validation text and purpose needs to be clarified in NRPM, so that ARIN is taking other steps the community wants. But under existing policy and practice, I believe POC validation for POCs only in Whois as a result of SWIPs is unnecessary and unproductive. Just my opinion, David David R Huberman Principal, Global IP Addressing Microsoft Corporation From michael at linuxmagic.com Mon Apr 13 16:31:51 2015 From: michael at linuxmagic.com (Michael Peddemors) Date: Mon, 13 Apr 2015 13:31:51 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: <552C27B7.4000908@linuxmagic.com> On 15-04-13 12:32 PM, William Herrin wrote: > On Mon, Apr 13, 2015 at 2:11 PM, David Huberman > wrote: >> many angry emails and calls from POCs who are only associated with indirect resource registration records. >> >> During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database. >> >> "During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database that is associated with an active directly registered number resource." > > Hi David, > > How do we verify that an ISP is reporting truthful information about > its downstream assignments? > > Regards, > Bill herrin > > Yes, I would like to know about that as well. We have reported companies with questionable 'assignment' information, or questionable usage, or poor compliance with SWIP/rWhois policies, which hasn't seemed to affect them getting new IP Space.. And the idea of "REASSIGN SIMPLE" is really non-sense.. Again, use of a public resource, IMHO should have correct public information. And it isn't onerous for any one to do this, and makes it harder for ARIN and others to see if the usage is 'fictional'. Again, this seems to be a problem with enforcement.. now and in the future, I object to simply 'removing' stale data, or any changes in the policy to that effect, when we need to improve accuracy. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From owen at delong.com Mon Apr 13 16:29:48 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Apr 2015 13:29:48 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: <552C14F5.9040705@ipinc.net> Message-ID: <192F24E7-123E-451B-BCB3-FE9D5CCB55C7@delong.com> David, I don?t see the angry phone call as the problem. I see it as a symptom. The problem is the incorrect registrations. I want us to find out about those incorrect registrations and resolve them. I certainly don?t want to simply remove the symptom (angry phone call) by masking the problem (incorrect registration). Owen > On Apr 13, 2015, at 1:23 PM, David Huberman wrote: > > Hi Ted, > > Thanks for the reply. > > By "indirect resource registration records", I meant reassignment records. ISP has a /17. They reassign a /28 to a customer, and decide to put customer POC information on it. That POC only exists because of the /28 - it isn't a POC for any directly registered allocation, assignment, or AS number. These are the POCs who are complaining en masse to ARIN after receiving POC Validation communications. My reasoning for removing POC validation for these types of POCs is that ISPs have the option to not register POCs at all -- they can choose "REASSIGN SIMPLE" as a path for registering SWIP information, and that doesn't have any POC info. Secondly, I'm not convinced there's a significant value in up-to-date POC information for reassigned numbers. In the end, the ISP (the direct registrant) is the party responsible for the IP addresses and use. (And in 90%+ of cases, the ISP is responsible for routing in the DFZ, too. For the cases where a reassigned block is announced by th > e customer, there's a customer ASN easily found in the routing tables, and that contact information is more germane than a SWIP record.) > > I hope that's clearer. > > David > > David R Huberman > Principal, Global IP Addressing > Microsoft Corporation > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Ted Mittelstaedt >> Sent: Monday, April 13, 2015 12:12 PM >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Policy idea: POC Validation >> >> >> As one of the initiators of this policy I must state that none of us who worked >> on this ever assumed the POC Validation Policy would be the END of the >> process. >> >> The idea was that when a POC was marked invalid, that ARIN would institute >> an investigation into the number resources held by the invalid POC and if >> they did locate the actual holder, they would give that holder 30 days to >> supply valid POC contact info for whois that would replace the bogus invalid >> contact info. >> >> If the holder wasn't forthcoming, ARIN will delete the POC. Resources that >> have no POC's justifying their existence are then freed up for reassignment. >> >> If ARIN is not doing this, then it is completely understandable that you would >> be getting large numbers of phone calls from people annoyed that their >> email addresses are still in whois. >> >> So, ARIN can start doing this and thereby make the people happy who are >> complaining, and at the same time, freeing up resources that are held by >> stale or bogus POC data. >> >> You said "indirect resource registration records" >> >> What exactly is that? >> >> In my opinion, ANY POC that is in whois that is associated in any way with an >> organization or individual who has IP addresses, and is being used as >> justification for holding resources, must remain in the validation list. >> >> It seems quite obvious and apparent that POCs that ARIN has judged to be >> invalid, and is in the process of investigating, would be calling and >> complaining. In general people who are doing things they shouldn't be >> doing, don't like to be investigated would certainly would complain. >> That can be solved easily by deleting their records and thereby freeing up >> resources. Then you don't contact them again and the community gets back >> the IP addressing they have held. >> >> Does not a POC that is being contacted by ARIN have the right to have their >> information deleted? If they are calling in and complaining that their records >> are in there, they obviously want them removed. So, ARIN can remove them >> and stop bothering them. >> >> You need to define the difference between "indirect resource registration >> records" and "associated with an active directly registered number resource" >> before anyone can really make a judgement on this policy proposal change. >> >> It just seems very simple to me. If they are a POC they are there because >> their existence is justifying some IP address holding in some way, there is >> some connection. If their POC is no longer justifying an IP address holding >> and there is no connection whatsoever to an IP address holding, then take >> their POC out and doing so will automatically quit contacting them. >> >> Ted >> >> On 4/13/2015 11:11 AM, David Huberman wrote: >>> Hello, >>> >>> Richard Jimmerson's Policy Experience Report indicated that 50% of the >> phone calls that RSD receives are about POC validation, and that they receive >> many angry emails and calls from POCs who are only associated with indirect >> resource registration records. In response, I offer the following change to the >> NRPM : >>> >>> >>> Existing 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. >>> >>> >>> I propose we make the first sentence read: >>> >>> "During ARIN's annual Whois POC validation, an email will be sent to every >> POC in the Whois database that is associated with an active directly >> registered number resource." >>> >>> Thoughts? >>> David >>> >>> David R Huberman >>> Principal, Global IP Addressing >>> Microsoft Corporation >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the ARIN >>> Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From David.Huberman at microsoft.com Mon Apr 13 16:36:35 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Mon, 13 Apr 2015 20:36:35 +0000 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: <192F24E7-123E-451B-BCB3-FE9D5CCB55C7@delong.com> References: <552C14F5.9040705@ipinc.net> <192F24E7-123E-451B-BCB3-FE9D5CCB55C7@delong.com> Message-ID: Hi Owen, I can give you a great example that's timely. My company ordered some circuits from ISP X recently. ISP X has a policy that they only do REASSIGN DETAIL. They registered the reassignments with POC data that points to a network engineer who ordered the circuit. It's the way their system works. The engineer emailed me very angry that her information was in ARIN Whois - and in fact, in Whois many times with multiple iterations of her POC -- POC1, POC2, POC3, POC4, POC5, etc all with the same information pointing to her. It even included her direct phone number, which happened to be her mobile phone, and she was upset about that. Luckily for her, she knew who ARIN was, she knew who the hostmaster was in our company (me!), and I knew how to get it fixed. BTW, in order to get it fixed, I chose to do what I thought was the right thing: I asked ARIN to "consolidate" the reassignment records into my main OrgID. ARIN *would not do it* without the explicit written permission of ISP X. (Luckily for us, ISP X consented.) Hope that helps, David David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, April 13, 2015 1:30 PM > To: David Huberman > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy idea: POC Validation > > David, > > I don?t see the angry phone call as the problem. I see it as a symptom. > > The problem is the incorrect registrations. I want us to find out about those > incorrect registrations and resolve them. I certainly don?t want to simply > remove the symptom (angry phone call) by masking the problem (incorrect > registration). > > Owen > > > On Apr 13, 2015, at 1:23 PM, David Huberman > wrote: > > > > Hi Ted, > > > > Thanks for the reply. > > > > By "indirect resource registration records", I meant reassignment records. > ISP has a /17. They reassign a /28 to a customer, and decide to put customer > POC information on it. That POC only exists because of the /28 - it isn't a POC > for any directly registered allocation, assignment, or AS number. These are > the POCs who are complaining en masse to ARIN after receiving POC > Validation communications. My reasoning for removing POC validation for > these types of POCs is that ISPs have the option to not register POCs at all -- > they can choose "REASSIGN SIMPLE" as a path for registering SWIP > information, and that doesn't have any POC info. Secondly, I'm not convinced > there's a significant value in up-to-date POC information for reassigned > numbers. In the end, the ISP (the direct registrant) is the party responsible > for the IP addresses and use. (And in 90%+ of cases, the ISP is responsible > for routing in the DFZ, too. For the cases where a reassigned block is > announced by th > > e customer, there's a customer ASN easily found in the routing tables, > > and that contact information is more germane than a SWIP record.) > > > > I hope that's clearer. > > > > David > > > > David R Huberman > > Principal, Global IP Addressing > > Microsoft Corporation > > > >> -----Original Message----- > >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > >> On Behalf Of Ted Mittelstaedt > >> Sent: Monday, April 13, 2015 12:12 PM > >> To: arin-ppml at arin.net > >> Subject: Re: [arin-ppml] Policy idea: POC Validation > >> > >> > >> As one of the initiators of this policy I must state that none of us > >> who worked on this ever assumed the POC Validation Policy would be > >> the END of the process. > >> > >> The idea was that when a POC was marked invalid, that ARIN would > >> institute an investigation into the number resources held by the > >> invalid POC and if they did locate the actual holder, they would give > >> that holder 30 days to supply valid POC contact info for whois that > >> would replace the bogus invalid contact info. > >> > >> If the holder wasn't forthcoming, ARIN will delete the POC. > >> Resources that have no POC's justifying their existence are then freed up > for reassignment. > >> > >> If ARIN is not doing this, then it is completely understandable that > >> you would be getting large numbers of phone calls from people annoyed > >> that their email addresses are still in whois. > >> > >> So, ARIN can start doing this and thereby make the people happy who > >> are complaining, and at the same time, freeing up resources that are > >> held by stale or bogus POC data. > >> > >> You said "indirect resource registration records" > >> > >> What exactly is that? > >> > >> In my opinion, ANY POC that is in whois that is associated in any way > >> with an organization or individual who has IP addresses, and is being > >> used as justification for holding resources, must remain in the validation > list. > >> > >> It seems quite obvious and apparent that POCs that ARIN has judged to > >> be invalid, and is in the process of investigating, would be calling > >> and complaining. In general people who are doing things they > >> shouldn't be doing, don't like to be investigated would certainly would > complain. > >> That can be solved easily by deleting their records and thereby > >> freeing up resources. Then you don't contact them again and the > >> community gets back the IP addressing they have held. > >> > >> Does not a POC that is being contacted by ARIN have the right to have > >> their information deleted? If they are calling in and complaining > >> that their records are in there, they obviously want them removed. > >> So, ARIN can remove them and stop bothering them. > >> > >> You need to define the difference between "indirect resource > >> registration records" and "associated with an active directly registered > number resource" > >> before anyone can really make a judgement on this policy proposal > change. > >> > >> It just seems very simple to me. If they are a POC they are there > >> because their existence is justifying some IP address holding in some > >> way, there is some connection. If their POC is no longer justifying > >> an IP address holding and there is no connection whatsoever to an IP > >> address holding, then take their POC out and doing so will automatically > quit contacting them. > >> > >> Ted > >> > >> On 4/13/2015 11:11 AM, David Huberman wrote: > >>> Hello, > >>> > >>> Richard Jimmerson's Policy Experience Report indicated that 50% of > >>> the > >> phone calls that RSD receives are about POC validation, and that they > >> receive many angry emails and calls from POCs who are only associated > >> with indirect resource registration records. In response, I offer the > >> following change to the NRPM : > >>> > >>> > >>> Existing 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. > >>> > >>> > >>> I propose we make the first sentence read: > >>> > >>> "During ARIN's annual Whois POC validation, an email will be sent to > >>> every > >> POC in the Whois database that is associated with an active directly > >> registered number resource." > >>> > >>> Thoughts? > >>> David > >>> > >>> David R Huberman > >>> Principal, Global IP Addressing > >>> Microsoft Corporation > >>> > >>> _______________________________________________ > >>> PPML > >>> You are receiving this message because you are subscribed to the > >>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >>> Unsubscribe or manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>> Please contact info at arin.net if you experience any issues. > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to the ARIN > >> Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. From michael at linuxmagic.com Mon Apr 13 16:47:14 2015 From: michael at linuxmagic.com (Michael Peddemors) Date: Mon, 13 Apr 2015 13:47:14 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: <552C14F5.9040705@ipinc.net> <192F24E7-123E-451B-BCB3-FE9D5CCB55C7@delong.com> Message-ID: <552C2B52.9020608@linuxmagic.com> On 15-04-13 01:36 PM, David Huberman wrote: > Hi Owen, > > I can give you a great example that's timely. My company ordered some circuits from ISP X recently. ISP X has a policy that they only do REASSIGN DETAIL. They registered the reassignments with POC data that points to a network engineer who ordered the circuit. It's the way their system works. > > The engineer emailed me very angry that her information was in ARIN Whois - and in fact, in Whois many times with multiple iterations of her POC -- POC1, POC2, POC3, POC4, POC5, etc all with the same information pointing to her. It even included her direct phone number, which happened to be her mobile phone, and she was upset about that. > > Luckily for her, she knew who ARIN was, she knew who the hostmaster was in our company (me!), and I knew how to get it fixed. > > BTW, in order to get it fixed, I chose to do what I thought was the right thing: I asked ARIN to "consolidate" the reassignment records into my main OrgID. ARIN *would not do it* without the explicit written permission of ISP X. (Luckily for us, ISP X consented.) > > Hope that helps, > David > > David R Huberman > Principal, Global IP Addressing > Microsoft Corporation This is another example of the problem being at ISP X, where they should be requiring accurate information on circuits for 'rwhois' or SWIP, and not just the information of the engineer making the order. Maybe an email 'alert' with Best Practices and Policies should be considered by ARIN, and again, this is related to mandating ARIN with a greater role in enforcement, rather than simply saying that if the current policies aren't working, drop the policy.. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From tedm at ipinc.net Mon Apr 13 17:30:42 2015 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 13 Apr 2015 14:30:42 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: <552C14F5.9040705@ipinc.net> <192F24E7-123E-451B-BCB3-FE9D5CCB55C7@delong.com> Message-ID: <552C3582.206@ipinc.net> There's 2 broken things in this example: 1) ISP X doing a REASSIGN DETAIL swip record with just any old information they happened to pull out of their rears. In this case, the contact info of the unsuspecting network engineer. ARIN can't make policy to correct that. The fact is that she should have lit up ISP X as well as you. Presumably, you and her learned from that and presumably ISP X also learned from that. Maybe in the future you tell ISP X you won't be buying anymore circuits until they get enlightened in this area? That often is very effective, you know. This is an ISP X <--> customer relation SNAFU and they could have just as easily SWIPed it with the company accountant's contact info because that's where the bill was supposed to go. If I go to the DMV and register my cat as a driver then get pulled over, do I have grounds to scream at the DMV for being dumb enough to give a drivers license to a cat? When it was my foolishness that did it? The DMV can't fix this anymore than ARIN can. 2) Multiple unconsolidated POCs. This happened once more because ISP X didn't properly file the SWIP using an existing POC ID. However, I do believe that it IS REASONABLE for ARIN to consolidate POCs that have the identical contact info. If "some random guy on the Internet" brings it to ARIN's attention that there are 5 JOHN SMITH POCs in whois that have the identical email address, telephone number, and address then I think ARIN should consolidate them without going through the rigamarole of asking permission. It doesn't matter who notices them - obviously they are the same person. That would cut down on the multiple emails to a POC I guess the way I look at it is that not verifying SWIP POCs just degrades the quality of the whois database, and makes it useless for fixing network problems or tracking wrongdoing. We cannot always count on the direct ISP even responding properly. That ISP may respond to ARIN because ARIN has a lever to pound on them if they don't, but why would they respond to anyone else on the Internet who is emailing them about a problem they are having with a subscriber? My experience is they generally don't. I can tell you that Law Enforcement has gotten very good at issuing subpoenas to networks to get the names of IP address holders, so it isn't like the true criminal can really hide. But, there's a big grey area of antisocial behavior that isn't criminal but is very objectionable, and providing some accountability tends to keep that down to a dull roar. I know it loads extra work on you guys but it seems to me that providing a directory of who has IP in use, even if they are a customer of some larger ISP who is "responsible" for the IP, is a core function of a Registrar and I think we need to really discuss this thoroughly. Is there any way ARIN can fix any of this through internal operations changes? Maybe tell every caller who calls in on this kind of problem to submit it via email or something? Ted On 4/13/2015 1:36 PM, David Huberman wrote: > Hi Owen, > > I can give you a great example that's timely. My company ordered > some circuits from ISP X recently. ISP X has a policy that they only > do REASSIGN DETAIL. They registered the reassignments with POC data > that points to a network engineer who ordered the circuit. It's the > way their system works. > > The engineer emailed me very angry that her information was in ARIN > Whois - and in fact, in Whois many times with multiple iterations of > her POC -- POC1, POC2, POC3, POC4, POC5, etc all with the same > information pointing to her. It even included her direct phone > number, which happened to be her mobile phone, and she was upset > about that. > > Luckily for her, she knew who ARIN was, she knew who the hostmaster > was in our company (me!), and I knew how to get it fixed. > > BTW, in order to get it fixed, I chose to do what I thought was the > right thing: I asked ARIN to "consolidate" the reassignment records > into my main OrgID. ARIN *would not do it* without the explicit > written permission of ISP X. (Luckily for us, ISP X consented.) > > Hope that helps, David > > David R Huberman Principal, Global IP Addressing Microsoft > Corporation > >> -----Original Message----- From: Owen DeLong >> [mailto:owen at delong.com] Sent: Monday, April 13, 2015 1:30 PM To: >> David Huberman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] >> Policy idea: POC Validation >> >> David, >> >> I don?t see the angry phone call as the problem. I see it as a >> symptom. >> >> The problem is the incorrect registrations. I want us to find out >> about those incorrect registrations and resolve them. I certainly >> don?t want to simply remove the symptom (angry phone call) by >> masking the problem (incorrect registration). >> >> Owen >> >>> On Apr 13, 2015, at 1:23 PM, David Huberman >> wrote: >>> >>> Hi Ted, >>> >>> Thanks for the reply. >>> >>> By "indirect resource registration records", I meant reassignment >>> records. >> ISP has a /17. They reassign a /28 to a customer, and decide to >> put customer POC information on it. That POC only exists because >> of the /28 - it isn't a POC for any directly registered allocation, >> assignment, or AS number. These are the POCs who are complaining >> en masse to ARIN after receiving POC Validation communications. My >> reasoning for removing POC validation for these types of POCs is >> that ISPs have the option to not register POCs at all -- they can >> choose "REASSIGN SIMPLE" as a path for registering SWIP >> information, and that doesn't have any POC info. Secondly, I'm not >> convinced there's a significant value in up-to-date POC information >> for reassigned numbers. In the end, the ISP (the direct >> registrant) is the party responsible for the IP addresses and use. >> (And in 90%+ of cases, the ISP is responsible for routing in the >> DFZ, too. For the cases where a reassigned block is announced by >> th >>> e customer, there's a customer ASN easily found in the routing >>> tables, and that contact information is more germane than a SWIP >>> record.) >>> >>> I hope that's clearer. >>> >>> David >>> >>> David R Huberman Principal, Global IP Addressing Microsoft >>> Corporation >>> >>>> -----Original Message----- From: arin-ppml-bounces at arin.net >>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted >>>> Mittelstaedt Sent: Monday, April 13, 2015 12:12 PM To: >>>> arin-ppml at arin.net Subject: Re: [arin-ppml] Policy idea: POC >>>> Validation >>>> >>>> >>>> As one of the initiators of this policy I must state that none >>>> of us who worked on this ever assumed the POC Validation Policy >>>> would be the END of the process. >>>> >>>> The idea was that when a POC was marked invalid, that ARIN >>>> would institute an investigation into the number resources held >>>> by the invalid POC and if they did locate the actual holder, >>>> they would give that holder 30 days to supply valid POC contact >>>> info for whois that would replace the bogus invalid contact >>>> info. >>>> >>>> If the holder wasn't forthcoming, ARIN will delete the POC. >>>> Resources that have no POC's justifying their existence are >>>> then freed up >> for reassignment. >>>> >>>> If ARIN is not doing this, then it is completely understandable >>>> that you would be getting large numbers of phone calls from >>>> people annoyed that their email addresses are still in whois. >>>> >>>> So, ARIN can start doing this and thereby make the people happy >>>> who are complaining, and at the same time, freeing up resources >>>> that are held by stale or bogus POC data. >>>> >>>> You said "indirect resource registration records" >>>> >>>> What exactly is that? >>>> >>>> In my opinion, ANY POC that is in whois that is associated in >>>> any way with an organization or individual who has IP >>>> addresses, and is being used as justification for holding >>>> resources, must remain in the validation >> list. >>>> >>>> It seems quite obvious and apparent that POCs that ARIN has >>>> judged to be invalid, and is in the process of investigating, >>>> would be calling and complaining. In general people who are >>>> doing things they shouldn't be doing, don't like to be >>>> investigated would certainly would >> complain. >>>> That can be solved easily by deleting their records and >>>> thereby freeing up resources. Then you don't contact them >>>> again and the community gets back the IP addressing they have >>>> held. >>>> >>>> Does not a POC that is being contacted by ARIN have the right >>>> to have their information deleted? If they are calling in and >>>> complaining that their records are in there, they obviously >>>> want them removed. So, ARIN can remove them and stop bothering >>>> them. >>>> >>>> You need to define the difference between "indirect resource >>>> registration records" and "associated with an active directly >>>> registered >> number resource" >>>> before anyone can really make a judgement on this policy >>>> proposal >> change. >>>> >>>> It just seems very simple to me. If they are a POC they are >>>> there because their existence is justifying some IP address >>>> holding in some way, there is some connection. If their POC is >>>> no longer justifying an IP address holding and there is no >>>> connection whatsoever to an IP address holding, then take their >>>> POC out and doing so will automatically >> quit contacting them. >>>> >>>> Ted >>>> >>>> On 4/13/2015 11:11 AM, David Huberman wrote: >>>>> Hello, >>>>> >>>>> Richard Jimmerson's Policy Experience Report indicated that >>>>> 50% of the >>>> phone calls that RSD receives are about POC validation, and >>>> that they receive many angry emails and calls from POCs who are >>>> only associated with indirect resource registration records. In >>>> response, I offer the following change to the NRPM : >>>>> >>>>> >>>>> Existing 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. >>>>> >>>>> >>>>> I propose we make the first sentence read: >>>>> >>>>> "During ARIN's annual Whois POC validation, an email will be >>>>> sent to every >>>> POC in the Whois database that is associated with an active >>>> directly registered number resource." >>>>> >>>>> Thoughts? David >>>>> >>>>> David R Huberman Principal, Global IP Addressing Microsoft >>>>> Corporation >>>>> >>>>> _______________________________________________ PPML You are >>>>> receiving this message because you are subscribed to the ARIN >>>>> Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe >>>>> or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml Please >>>>> contact info at arin.net if you experience any issues. >>>> _______________________________________________ PPML You are >>>> receiving this message because you are subscribed to the ARIN >>>> Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or >>>> manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml Please contact >>>> info at arin.net if you experience any issues. >>> _______________________________________________ PPML You are >>> receiving this message because you are subscribed to the ARIN >>> Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or >>> manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml Please contact >>> info at arin.net if you experience any issues. > > _______________________________________________ PPML You are > receiving this message because you are subscribed to the ARIN Public > Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your > mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml Please contact > info at arin.net if you experience any issues. From hannigan at gmail.com Mon Apr 13 17:31:18 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 13 Apr 2015 14:31:18 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: Did ARIN/you consider a consultation instead and simply adding a NACK button to the confirmation and reassigning the block back to the ISP in question or re designate to the online account owner? Maybe some of that needs policy. Maybe not. You mentioned at the mic that the POC assignments are random and most of the time the provisioning people aren't even aware. True for almost every POC I have. One of the problems that this creates is addressing law enforcement and abuse requests. .02 Best, -M< On Mon, Apr 13, 2015 at 11:11 AM, David Huberman < David.Huberman at microsoft.com> wrote: > Hello, > > Richard Jimmerson's Policy Experience Report indicated that 50% of the > phone calls that RSD receives are about POC validation, and that they > receive many angry emails and calls from POCs who are only associated with > indirect resource registration records. In response, I offer the following > change to the NRPM : > > > Existing 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. > > > I propose we make the first sentence read: > > "During ARIN's annual Whois POC validation, an email will be sent to every > POC in the Whois database that is associated with an active directly > registered number resource." > > Thoughts? > David > > David R Huberman > Principal, Global IP Addressing > Microsoft Corporation > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 lee at dilkie.com Mon Apr 13 17:47:33 2015 From: lee at dilkie.com (Lee Dilkie) Date: Mon, 13 Apr 2015 17:47:33 -0400 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: <552C3582.206@ipinc.net> References: <552C14F5.9040705@ipinc.net> <192F24E7-123E-451B-BCB3-FE9D5CCB55C7@delong.com> <552C3582.206@ipinc.net> Message-ID: <552C3975.6070805@dilkie.com> On 4/13/2015 5:30 PM, Ted Mittelstaedt wrote: > If I go to the DMV and register my cat as a driver then get pulled over, > do I have grounds to scream at the DMV for being dumb enough to give a > drivers license to a cat? When it was my foolishness that did it? > The DMV can't fix this anymore than ARIN can. surely your cat would fail to pass the drivers examination. -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Huberman at microsoft.com Mon Apr 13 17:37:44 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Mon, 13 Apr 2015 21:37:44 +0000 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: Hello Marty, > Did ARIN/you consider a consultation instead and simply adding a NACK button > to the confirmation and reassigning the block back to the ISP in question or > re-designate to the? online account owner? Maybe some of that needs policy. > Maybe not. [I didn't consider a consultation. Richard had said at the mic during his presentation that it required a policy change, or I thought that's what I heard.] I think your solution would be a good option. Can other ISPs who SWIP comment on this option? Would you be ok with your SWIPs being erased when your customers press a button or contact ARIN and demand to be removed? Alternatively, we could also consider a middle ground -- anyone who presses NACK or complains, the POC on the reassignment reverts to the parent Org POCs (the ISP's POC info). David David R Huberman Principal, Global IP Addressing Microsoft Corporation From jay at impulse.net Mon Apr 13 17:52:31 2015 From: jay at impulse.net (Jay Hennigan) Date: Mon, 13 Apr 2015 14:52:31 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: <192F24E7-123E-451B-BCB3-FE9D5CCB55C7@delong.com> References: <552C14F5.9040705@ipinc.net> <192F24E7-123E-451B-BCB3-FE9D5CCB55C7@delong.com> Message-ID: <552C3A9F.10900@impulse.net> On 4/13/15 1:29 PM, Owen DeLong wrote: > David, > > I don?t see the angry phone call as the problem. I see it as a symptom. > > The problem is the incorrect registrations. I want us to find out about those incorrect registrations and resolve them. I certainly don?t want to simply remove the symptom (angry phone call) by masking the problem (incorrect registration). They aren't necessarily incorrect registrations, they're redundant registrations never requested by the POC. I've been on the receiving end of this for several years. Here's one issue as I've observed it. We're a regional ISP, and from time to time will have a customer out of our service area with a need for direct Internet access. We contract with several major providers for this, and one of them is Centurylink. CenturyLink has some form of (presumably automated) process where they process our order and submit my contact information from their order to ARIN, consisting of my email address, phone number, etc. but with the street address of our end-user customer. For each of these, ARIN generates a separate unique POC record and then sends annual POC validation requests. Of course, until I get these annual requests, I have no idea that the POC records even exist. ARIN apparently expects me to, for each and every one of these, jump through several flaming hoops on their website to obtain a login, then validate each and every one of them separately. For anyone who hasn't done so, and this should be a requirement for anyone in ARIN's web coding group, go to the ARIN page and try to set up authentication for an existing POC for yourself that you didn't know existed. It isn't exactly fun, nor quick, nor intuitive. I haven't needed to resort to angry phone calls, but have generally been able to resolve this by email. Ignore the auto-response that suggests you do this yourself on the ARIN website, unless you like pain. -- Jay Hennigan | CCIE #7880 | jay at impulse.net | www.impulse.net Voice +1.805.884.6323 | Fax +1.805.880.1523 | WB6RDV Chief Network Architect | Impulse Advanced Communications From andrea at ripe.net Mon Apr 13 18:16:46 2015 From: andrea at ripe.net (Andrea Cima) Date: Tue, 14 Apr 2015 00:16:46 +0200 Subject: [arin-ppml] Response to the ARIN counsel's assessment of 2014-1 (Out of region use) In-Reply-To: References: <985a52bc845a4ff8882f3866e5d1de08@EX13-MBX-13.ad.syr.edu> <7E7773B523E82C478734E793E58F69E78DAF76A3@SBS2011.thewireinc.local> Message-ID: <552C404E.2090009@ripe.net> Hi Milton, RIPE NCC membership is open without conditions to everyone. However in order to receive Internet number resources the member must have a need in the RIPE NCC service region: the network that will be using the resources must have an active element located in the region. The RIPE NCC has more than 200 member organisations which are not incorporated in the RIPE NCC services region, but do need resources for use within the region, as confirmed during their membership application process. I hope this clarifies Regards, Andrea Cima RIPE NCC On 13/4/15 16:43, Milton L Mueller wrote: > So is ?being announced? in the region the same as ?being used? within > the region? What implications does this have for 2014-1? > > I think RIPE-NCC does maintain a kind of nominal adherence to service > regional, but a lot of the American companies applying for these > resources are requesting and using them based on local or global need, > not specifically European need. IT would be good to see RIPEclarify. > > > > --MM > > > > *From:* Kevin Blumberg [mailto:kevinb at thewire.ca] > *Sent:* Monday, April 13, 2015 2:06 AM > *To:* Milton L Mueller; arin-ppml at arin.net > *Subject:* RE: [arin-ppml] Response to the ARIN counsel's assessment of > 2014-1 (Out of region use) > > > > Milton, > > > > All of the example net blocks that used in your examples below appear > to be routed to equipment in the RIPE region. > > > > I would prefer that the RIPE porition is clarified as my understanding > is that the IP allocations are to be used inside of the region. > > > > On the RIPE website the following FAQ seems to contradicte your statements > > > > > > Yes, you can become a member of RIPE NCC. However, keep in mind that the > Internet number resources need be announced within the RIPE NCC?s > service region > . > > > > I don?t believe that your description of how allocations are handled in > the RIPE region are accurate. Possible asking RIPE staff would be > appropriate at this time. > > > > > > > > *From:* arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *Milton L Mueller > *Sent:* April 12, 2015 4:53 PM > *To:* arin-ppml at arin.net > *Subject:* [arin-ppml] Response to the ARIN counsel's assessment of > 2014-1 (Out of region use) > > > > At ARIN 35 we will be discussing the fate of a proposal to formally > allow out of region use of number resources. Attendees can review the > text of the policy alongside a staff and legal assessment of it here: > > https://www.arin.net/policy/proposals/2014_1.html > > > > The following is my response to the legal assessment of the proposed out > of region use policy by ARIN's Counsel. It is clear that Counsel opposes > this policy but I am not sure we are getting an unbiased assessment of > its true implications. In the spirit of open dialogue about policies > that are supposed to be developed bottom up by the community, I offer > this rejoinder: > > > > Counsel states: > > "ARIN is governed by ICANN ICP-2, which calls for establishment of a > single RIR to serve each region." > > > > Regional exclusivity is one of the more interesting and far-ranging > issues raised by 2014-1. We need to have a clear and honest discussion > of it. Counsel is claiming that ICP-2 requires all usage of numbers to > be bound to exclusive RIR service regions But this claim has no basis in > either ICP-2 itself nor in operational practice. > > - The title of ICP-2 is "Criteria for Establishment of New Regional > Internet Registries;" in other words it is about the establishment of > NEW RIRs, not about the general model of number governance > > - Even assuming that service regions shouldn?t overlap, ICP-2 does not > articulate or establish a policy regarding use of number resources > outside of a RIR?s service region. > > - ICP-2 is not a law, and thus raises no legal issues; > > - ICP-2 is not even a global policy, as its development and adoption by > the ICANN board antedates the global policy development process > > - It is routine for LIRs with transnational operations to rely on one > RIR for most of their address resources rather than joining multiple > registries in each of the service regions. Far from leading to > "difficulty for co-ordination and co-operation" and "confusion for the > community within the region," such practices make coordination easier > and reduce confusion and overhead. > > > > In this regard, let me quote a Feb 25, 2015 statement on PPML by Tony Hain: > > > > "Back up and figure out what problem is being solved. The primary > reason RIR's became possessive about their territory was "absurd > protection of their precious IPv4 allocations". Rewind to the pre-RIR > timeframe, and allocations were global, and use was global. The RIRs > were brought in to simplify the process, not fragment it. ... Are we > trying to protect the RIR's claimed autonomy over geography, or simplify > the process of distribution for a global resource? If it is the latter > as it started out to be, the definition of "out of region" is > off-planet. If it is the former, why do people continue to fight against > NIR's? If you want absolute autonomy, you need somebody capable of > protecting your defined geography, and that usually becomes police or > military. Make up your collective mind about your stated objective and > make policy fit that. As far as I know the stated objective is to > facilitate allocations of a global resource, so trying to restrict what > the recipient does with it would appear to be out of scope." > > > > As Hain suggests, the regional nature of RIRs was intended to facilitate > resource distribution, not fragment it; the real reason for assertions > of territorial exclusivity is IPv4 scarcity and uneven runout among the > RIRs. But 2014-1 probably will not be implemented until ARIN's free pool > is gone. > > > > Counsel asserts: > > "This policy would allow entities with no real connection to the ARIN's > service region to obtain, for example, increasingly scarce IPv4 resources" > > > > ?No real connection? = a major exaggeration. The current policy requires > recipients of ARIN resources to be organizations with an existing > customer relationship & agreement with ARIN and be "currently using at > least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the > ARIN service region, respectively." Some connection to the ARIN region > is required. > > > > Counsel asserts: > > "...if the policy were adopted, ARIN could arguably become subject to > the jurisdiction and laws passed by governments outside our service > region. This may lead to ARIN being a litigant in courts of nations > outside its service region and subject to their requirements and > judgments. ARIN will need to accept greater legal expenditures and > risks, as well as potentially larger costs in order to take this greater > scope into consideration in ARIN's registry activities on an ongoing basis." > > > > Questionable. As long as ARIN permits its number resources to be used > outside of the region, as it currently does, the same risk exists > regardless of whether 2014-1 passes or not. Note that even ARIN?s > Counsel states that he supports allowing network operators headquartered > in ARIN's region to make use of ARIN-registered resources out of the > North American region. Such cases would pose the same jurisdictional > risks, if indeed those risks are significant. Thus it is unclear how > 2014-1 changes anything in this regard. Note also that a RIPE policy in > place for the past 2 and a half years has not led to any such problems. > > > > RIPE-NCC is currently allocating /22s from the 185.0.0.0/8 block without > needs assessment and have given out hundreds since 2012. The receipant > of the /22 is required to become a RIPE NCC member, but the recipient > can be based anywhere. Over a dozen US companies not based in the RIPE > region have availed themselves of this policy. Here are a few examples, > with links to the Whois: > > > > US 185.46.120.0 01/31/2014 IHNetworks, LLC > https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-ILI4-RIPE&type=organisation > > > US 185.47.84.0 02/10/2014 KVH Industries, Inc > https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-KII1-RIPE&type=organisation > > > US 185.51.4.0 03/20/2014 Latisys-Denver, LLC > https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-LL159-RIPE&type=organisation > > > US 185.52.0.0 03/27/2014 RamNode LLC > https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-RL171-RIPE&type=organisation > > > US 185.52.136.0 04/01/2014 Peak Web LLC > https://apps.db.ripe.net/search/lookup.html?source=ripe&key=ORG-PWL4-RIPE&type=organisation > > > > > I believe in evidence-based policy. In many respects, RIPE-NCC is > permitting out of region membership and out of region use. Can Counsel > identify any of the purported problems taking place because of RIPE?s > openness to members from other regions? Has RIPE been a litigant in the > US or has a national government threatened it with "political oversight" > because of these actions? > > > > Counsel asserts: > > "[T]he policy fails to recognize that ARIN is not likely to able to > perform the function contemplated in the policy with certain countries," > such as Cuba, Iran and North Korea. > > > > ARIN is barred from doing business with those countries with or without > this policy. Any applicant for resources from those countries could > simply be denied. > > > > Counsel asserts: > > > > "ARIN may be subject to significantly greater political oversight by > national governments in its service region that will wish to evaluate > why ARIN alone of the 5 RIRs is assuming a duty to service all of the > world's community. It may be argued by governments in ARIN's region that > this is a potential breach of ARIN's fiduciary obligations to its own > region, and to examine whether it is consistent with ARIN's non-profit > status and other corporate documents." > > > > Incomplete, factually wrong in part, and speculative. It is incomplete > because Counsel provides no legal reason why allowing out of region use > would threaten ARIN's nonprofit status. Factually wrong because ARIN is > not alone - note the RIPE-NCC case above. The argument about government > reaction is speculative and non-legal. Essentially the claim is that > governments (not the number resource-using community) won't like this > policy and will punish ARIN for passing it by asserting some unspecified > kind of "political oversight." Based on context I can think of only one > government that would be in a position to assert "political oversight" > over ARIN, and that is the U.S. government. Yet the US is firmly > committed to private sector-led, multistakeholder internet governance. > There is no legislation proposing to regulate ARIN on the horizon and no > major private sector stakeholder lobbying group demanding it. > > > > I think, therefore, that Counsel has it exactly backwards: if we reject > this policy solely because of fear of the US government, ARIN and its > board will be breaching their fiduciary obligations to pass number > resource policies that are fair and impartial, technically sound, and > supported by the community. > > > > Counsel asserts: > > > > "the policy will lead to an increase in fraudulent applications from out > of region requestors, and issuance of resources to those who > fraudulently file, since ARIN is not as well positioned to successfully > discover such fraud by out of region requestors." > > > > This is a legitimate concern. But I see no reason why staff cannot deny > resources to entities that cannot produce adequate evidence for their > claims. Other tweaks to be policy could be conceived that might address > this issue, bearing in mind that two previous attempts to define > thresholds were not acceptable to the community. Further, the incentive > for most fraudulent applications comes from IPv4 scarcity, which has a > very limited time horizon. > > > > Conclusion > > The choice is clear: are IP numbers a global resource to be allocated > and assigned on the basis of technical efficiency, or are RIRs here to > fragment the number distribution process into mutually exclusive > territories? Will this policy be adopted or not based on its merit and > community support, or on vague threats about governmental repercussions? > I look forward to seeing you at ARIN 35 to further air these issues. > > > > Milton L Mueller > > ARIN Advisory Council member but speaking only for myself > > Laura J. and L. Douglas Meredith Professor > > Syracuse University School of Information Studies > > http://faculty.ischool.syr.edu/mueller/ > > Internet Governance Project > > http://internetgovernance.org > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From owen at delong.com Mon Apr 13 18:36:59 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Apr 2015 15:36:59 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: <552C3A9F.10900@impulse.net> References: <552C14F5.9040705@ipinc.net> <192F24E7-123E-451B-BCB3-FE9D5CCB55C7@delong.com> <552C3A9F.10900@impulse.net> Message-ID: <5A5A4ECB-388E-47E0-9502-A3F5C1443996@delong.com> ARIN isn?t creating those separate POCs? They are created by CenturyLink or whoever in the ARIN database. I would suggest asking CenturyLink or your other providers to use a consistent contact or find another way to deal with those registrations. You can actually associate all of those contacts with the same ARIN online login, no hoops required. Yes, you have to validate each one individually, but in my experience so far, that has consisted of clicking on a URL in the POC validation email and moving on. Owen > On Apr 13, 2015, at 2:52 PM, Jay Hennigan wrote: > > On 4/13/15 1:29 PM, Owen DeLong wrote: >> David, >> >> I don?t see the angry phone call as the problem. I see it as a symptom. >> >> The problem is the incorrect registrations. I want us to find out about those incorrect registrations and resolve them. I certainly don?t want to simply remove the symptom (angry phone call) by masking the problem (incorrect registration). > > They aren't necessarily incorrect registrations, they're redundant registrations never requested by the POC. I've been on the receiving end of this for several years. Here's one issue as I've observed it. > > We're a regional ISP, and from time to time will have a customer out of our service area with a need for direct Internet access. We contract with several major providers for this, and one of them is Centurylink. > > CenturyLink has some form of (presumably automated) process where they process our order and submit my contact information from their order to ARIN, consisting of my email address, phone number, etc. but with the street address of our end-user customer. > > For each of these, ARIN generates a separate unique POC record and then sends annual POC validation requests. Of course, until I get these annual requests, I have no idea that the POC records even exist. > > ARIN apparently expects me to, for each and every one of these, jump through several flaming hoops on their website to obtain a login, then validate each and every one of them separately. > > For anyone who hasn't done so, and this should be a requirement for anyone in ARIN's web coding group, go to the ARIN page and try to set up authentication for an existing POC for yourself that you didn't know existed. It isn't exactly fun, nor quick, nor intuitive. > > I haven't needed to resort to angry phone calls, but have generally been able to resolve this by email. Ignore the auto-response that suggests you do this yourself on the ARIN website, unless you like pain. > > -- > Jay Hennigan | CCIE #7880 | jay at impulse.net | www.impulse.net > Voice +1.805.884.6323 | Fax +1.805.880.1523 | WB6RDV > Chief Network Architect | Impulse Advanced Communications > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mueller at syr.edu Mon Apr 13 18:49:40 2015 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 13 Apr 2015 22:49:40 +0000 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: > -----Original Message----- > existing policy and practice, I believe POC validation for POCs only in Whois > as a result of SWIPs is unnecessary and unproductive. I agree with this and believe that it is also a source of confusion and irritation to the people who receive them. From michael at linuxmagic.com Mon Apr 13 20:08:40 2015 From: michael at linuxmagic.com (Michael Peddemors) Date: Mon, 13 Apr 2015 17:08:40 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: <552C3582.206@ipinc.net> References: <552C14F5.9040705@ipinc.net> <192F24E7-123E-451B-BCB3-FE9D5CCB55C7@delong.com> <552C3582.206@ipinc.net> Message-ID: <552C5A88.4050307@linuxmagic.com> On 15-04-13 02:30 PM, Ted Mittelstaedt wrote: > I know it loads extra work on you guys but it seems to me that providing > a directory of who has IP in use, even if they are a customer of > some larger ISP who is "responsible" for the IP, is a core function of > a Registrar and I think we need to really discuss this thoroughly. Here, here.. And I know the voices of law enforcement have also been pushing for this.. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From michael at linuxmagic.com Mon Apr 13 20:51:15 2015 From: michael at linuxmagic.com (Michael Peddemors) Date: Mon, 13 Apr 2015 17:51:15 -0700 Subject: [arin-ppml] Should mention, someone on this list has a virus.. Message-ID: <552C6483.2010604@linuxmagic.com> Just got interesting spam with Subject: of "Re: [arin-ppml] Policy idea: POC Validation" in my spam folder.. Return-Path: Received: from server1.love2nsa.com (HELO server1.love2nsa.com) (107.170.162.27) From: Carrie Flores (Porn spam, fake-ht-tp://meetnsagirl.com/carrie-profile/) Oh, speaking of 'rwhois' and SWIP.. NetRange: 107.170.0.0 - 107.170.255.255 CIDR: 107.170.0.0/16 NetName: DIGITALOCEAN-8 NetHandle: NET-107-170-0-0-1 Parent: NET107 (NET-107-0-0-0-0) NetType: Direct Allocation OriginAS: AS14061, AS62567, AS46652 Organization: Digital Ocean, Inc. (DO-13) RegDate: 2013-12-30 Updated: 2013-12-30 Comment: http://www.digitalocean.com Comment: Simple Cloud Hosting Ref: http://whois.arin.net/rest/net/NET-107-170-0-0-1 OrgName: Digital Ocean, Inc. Wonder who that IP was assigned to (and for how long ;) -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From mysidia at gmail.com Mon Apr 13 21:07:14 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 13 Apr 2015 20:07:14 -0500 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: <552C14F5.9040705@ipinc.net> Message-ID: On Mon, Apr 13, 2015 at 3:23 PM, David Huberman wrote: > Hi Ted, > Thanks for the reply. >complaining en masse to ARIN after receiving POC Validation communications. My reasoning for removing >POC validation for these types of POCs is that ISPs have the option to not register POCs at all -- they can >choose "REASSIGN SIMPLE" as a path for registering SWIP information, and that doesn't have any POC info. If they don't register a POC, then the upstream record needs to have a POC. They also only offer Reassign Simple for REASSIGNMENTS. The REALLOCATION forms require full POCs. - If they do put the information in Whois, then it MUST be accurate, and ARIN should take steps to help verify that the e-mail addresses at least work. POCs for the indirect records still ought to be verified with the same rigor. However, - The POC verification requests should not say to call ARIN RSD. If ARIN is getting too many calls; it's probable b/c of the fact the e-mail they have been using just says to call ARIN if there are any problems. Instead, there should be "self help" options for common issues clearly explained in POC verification messages. The option to call ARIN should not be the first thing advertised. - The annual POC verification e-mail messages should be designed to minimize any confusion. They should avoid using abbreviations such as "WHOIS POC". There should be more explanation of what the message is about, and not just "That there is a POC verification policy". - Just as there is a link to "confirm" the POC record is good, there should be another prominent link near the top to say "This POC record is bad, and stop contacting me" - If the POC says their record is bad, And they don't go back and cancel that (in case of accidental clicking), then their information should be removed from WHOIS pending review. - If No valid POCs remain for a resource, and it's an allocation or assignment that requires a POC, then the resource should be reviewed for deletion/revokation and/or notification to whomever allocated it that they are required to provide correct contact info for the reallocation. -- -JH From michael at linuxmagic.com Mon Apr 13 21:20:51 2015 From: michael at linuxmagic.com (Michael Peddemors) Date: Mon, 13 Apr 2015 18:20:51 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: <552C14F5.9040705@ipinc.net> Message-ID: <552C6B73.5040609@linuxmagic.com> On 15-04-13 06:07 PM, Jimmy Hess wrote: > - Just as there is a link to "confirm" the POC record is good, there > should be another > prominent link near the top to say "This POC record is bad, and > stop contacting me" > > - If the POC says their record is bad, And they don't go back and cancel that > (in case of accidental clicking), then their information should > be removed from WHOIS pending review. Actually, this should then be escalated to whomever their upstream is, with a warning about bad POC's. Also notice lately that some of the hosting providers are allowing 'automated' sign-ups, where any forged information also is automated to post to the 'rwhois' server, or SWIP. The upstream provider should be notified of such an issue as soon as possible, and if they aren't dealing with the situation, then the upstream provider is in non-compliance with policy, as I see it. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From info at arin.net Tue Apr 14 11:06:15 2015 From: info at arin.net (ARIN) Date: Tue, 14 Apr 2015 11:06:15 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-1: Out of Region Use - updated legal assessment In-Reply-To: <549AE7FF.6090108@arin.net> References: <549AE7FF.6090108@arin.net> Message-ID: <552D2CE7.8060702@arin.net> There was a request to repost the updated legal assessment of 2014-1 which is going to be discussed here at ARIN 35 this morning. The updated legal assessment is included in the Draft Policy text below and can be found at: https://www.arin.net/policy/proposals/2014_1.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Recommended Draft Policy ARIN-2014-1 Out of Region Use Date: 24 December 2014 AC's assessment of conformance with the Principles of Internet Number Resource Policy: This proposal enables fair and impartial number resource administration by clearing up a significant ambiguity in policy and practice. This proposal is technically sound, as no technical issues are raised by permitting a single network operator to use resources from one RIR in any region. This proposal is supported by the community. Permitting out of region use allows operators with facilities spanning more than one region to obtain resources in the most direct and convenient way, and to utilize their numbers more flexibly and efficiently. The concerns of law enforcement and staff raised by the first staff and legal assessment have been mitigated by the latest amendments. Problem statement: Current policy neither clearly forbids nor clearly permits out or region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has explored several options to restrict or otherwise limit out of region use. None of these options have gained consensus within the community. The next logical option is a proposal that clearly permits out of region use while addressing some of the concerns expressed about unlimited openness to out of region use. Policy statement: Create new Section X: ARIN registered resources may be used outside the ARIN service region. Out of region use of IPv4, IPv6, or ASNs are valid justification for additional number resources if the applicant is currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively. The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR??s service region, the officer of the applicant must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to request a listing of all the applicant's number holdings in the region(s) of proposed use, but this should happen only when there are significant reasons to suspect duplicate requests. Comments: a. Timetable for implementation: Immediate b. Anything else Current policy is ambiguous on the issue of out of region use of ARIN registered resources. The only guidance on the issue in current policy is Section 2.2, which defines the the role of RIRs as ??to manage and distribute public Internet address space within their respective regions.?? Some in the community believe this means out of region use should be prevented or restricted, while others believe this is only intended to focus efforts within the region and not define where resources may be used. Previous policy proposals have explored restricting or otherwise limiting out of region use, but none have gained consensus within the ARIN community. Several standards for restricting out of region use were explored, but all of them were perceived as interfering with the legitimate operations of multi- or trans-regional networks. The requirement to have a minimal level of resources deployed in the region (/44 for IPv6, /22 for IPv4, 1 ASN) is an attempt to respond to law enforcement and some community concerns. An absolute threshold ensures that those applying for ARIN resources are actually operating in the region and not simply a shell company, but it avoids the known pitfalls of trying to use percentages of the organization's overall holdings to do that. The use of officer attestation and the possibility of an audit is an attempt to prevent duplicate requests without requiring burdensome reporting requirements. In summary, this proposal ensures that trans-regional organizations or service providers operating within the ARIN region may receive all the resources they need from ARIN if they wish to do so. This change is particularly important for IPv6. Requiring organizations get IPv6 resources from multiple RIRs will result in additional unique non-aggregatable prefixes within the IPv6 route table. ##### ARIN STAFF ASSESSMENT Date of Revised Assessment: 15 January 2015 1. Summary (Staff Understanding) This policy would allow out of region use of ARIN issued resources as long as the requesting organization is presently an ARIN registry customer and currently using the equivalent of a /22 IPv4 block, or a /44 IPv6 block, or an ASN on infrastructure physically located within the ARIN region. An officer attestation would be required to verify that the resource request is not a duplicate of one made to another RIR. 2. Comments A. ARIN Staff Comments There are registrants in the ARIN region, such as end-users, who are not necessarily ARIN members. The policy text has been updated to omit references to ??Member??, and is understood to refer to organizations with an existing customer relationship & agreement with ARIN. Current ARIN policy requires organizations to show a justified need for resources to be used specifically within the ARIN region in order to receive number resources from ARIN. If the draft policy were adopted, ARIN number resources could be requested for use in another region. When processing resource requests for use in another region under this policy, ARIN staff would include any address space registered through another RIR and currently used (or available to be used) within that region in its evaluation of the organization??s justified need based on current ARIN policy. This policy adds a new requirement that staff review utilization outside of the ARIN region, which will require additional time, and could delay the review and processing of requests of this type as well as other request types that ARIN currently handles. This policy would be placed in the NRPM as "2.17 Out of Region Use". [The following is an updated legal assessment of 2014-1] B. ARIN General Counsel - Legal Assessment 19 March 2015 Counsel has significant and material legal concerns about this policy. Counsel recognizes and supports the issuance of resources to entities in the ARIN region that need number resources that will be used in both this region and in the remainder of the world. ARIN currently issues resources for these needs based on a needs based allocation methodology. However, this proposed policy removes the requirement that there be any meaningful need for those resources in the ARIN service region, and allows all of the need to be outside the ARIN service region. This creates new legal challenges for ARIN which are identified below: First, ARIN is governed by ICANN ICP-2, which calls for establishment of a single RIR to serve each region. It further notes that multiple RIRs serving in single region is likely to lead to difficulty for co-ordination and co-operation between the RIRs as well as confusion for the community within the region. The implication of that governance structure is that each RIR can and should serve its service region. This policy would allow entities with no real connection to the ARIN's service region to obtain, for example, increasingly scarce IPv4 resources from ARIN and related registry services. This policy would result in ARIN effectively providing registry services to other regions, and thus appears on its face to be inconsistent with ICP-2. ARIN has obligations to follow the global policy in ICP2, or seek changes in it. Second, if the policy were adopted, ARIN could arguably become subject to the jurisdiction and laws passed by governments outside our service region. This may lead to ARIN being a litigant in courts of nations outside its service region and subject to their requirements and judgments. ARIN will need to accept greater legal expenditures and risks, as well as potentially larger costs in order to take this greater scope into consideration in ARIN's registry activities on an ongoing basis. Third, the policy fails to recognize that ARIN is not likely to able to perform the function contemplated in the policy with certain countries, and related public or private entities. See as examples under US law: Cuba, Iran and North Korea. The policy could benefit from a specific carve out that ARIN may meet its obligations under the laws of governments in its service region, even if such requests would otherwise comply with ARIN policy. For those who assert that this requirement to conform to law is implicit and does not need to be stated in policy, it is important the community is under notice of this limit. This issue has not been an issue for ARIN prior to this proposed policy. Fourth, ARIN may be subject to significantly greater political oversight by national governments in its service region that will wish to evaluate why ARIN alone of the 5 RIRs is assuming a duty to service all of the world's community. It may be argued by governments in ARIN's region that this is a potential breach of ARIN??s fiduciary obligations to its own region, and to examine whether it is consistent with ARIN??s non-profit status and other corporate documents. Fifth and finally, counsel is concerned that the policy will lead to an increase in fraudulent applications from out of region requestors, and issuance of resources to those who fraudulently file, since ARIN is not as well positioned to successfully discover such fraud by out of region requestors. [Legal Assessment in the staff assessment dated 15 January 2015] B. ARIN General Counsel - Legal Assessment [15 January 2015] Counsel supports the issuance of resources to entities in the ARIN region that need number resources that will be used in this region and in the remainder of the world. ARIN currently issues resources for these needs based on a needs based allocation methodology. This proposed revised policy now requires that there be /22 of deployed IPv4 resources in the ARIN service region, and once that installation exists it allows all of the recipients?? needs outside the ARIN service region to be met by ARIN. The requirement of a meaningful physical presence of the recipient in the service region was absent from the prior version, and is an improvement. (The draft policy does not explicitly spell out that the recipient must have an actual physical presence, as well as a corporate legal entity, in the ARIN region, but implies the requirement indirectly by stating that the requester must presently be using resources in the ARIN region and thus already comply with ARIN??s existing requirements. The single remaining aspect that continues to create legal and policy concern is that the policy as written and interpreted calls for ARIN to allocate resources solely for use out of the ARIN service region. By definition, those resources should be obtained from the RIR(s) in the service region(s) where the need exists. Counsel would strongly prefer that the policy require that there be a requirement that some of the resources being allocated be needed in the ARIN region. Such a modest limit would be consistent with ICP-2; it would be consistent with ARIN's stewardship responsibility to allocate the waning pool of IPv4 number resources, and will still meet the needs of ARIN based multinational entities who need resources across the globe. This draft policy is inconsistent with ICP2. ARIN is governed by ICANN ICP-2, which calls for establishment of a single RIR to serve each region. ICP2 further notes that multiple RIRs serving in a single region is likely to lead to difficulty for co-ordination and co-operation between the RIRs as well as confusion for the community within the region. The implication of that governance structure is that each RIR can and should serve primarily its service region. Adoption of this policy will result in ARIN effectively providing significant registry services to ARIN qualified recipients in other RIR regions, and such a change should not be undertaken lightly but instead only after the framework provided in ICP-2 is updated (based on global discussion and consent) - to proceed otherwise would undermines ICP-2 and encourages parties to set aside its principles in an uncoordinated manner, risking in the very "confusion for the community" that ICP-2 helps deter at present. ARIN cannot perform business functions contemplated in the policy with certain countries, and related public or private entities, such as relationships to Cuba, Iran and North Korea under U.S. law. This has not historically been an issue for ARIN prior to this proposed policy. It may be necessary to require ARIN??s implementation of this policy to require a certification that none of the resources will be deployed contrary to U.S., Canada or Caribbean nations law in this respect. If the draft policy is adopted and ARIN provides resources to qualifying entities for use outside of the region, it is essential that the present requirement for dispute resolution via arbitration at a location in ARIN??s service region as currently required in the RSA be maintained to assist in reducing the risk of ARIN becoming subject to the venue, jurisdiction and laws of legal forums outside the ARIN service region. 3. Resource Impact This policy would have significant resource impact from an implementation aspect. It is estimated that implementation would occur within 5-6 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: Updated guidelines and internal procedures Staff training Additional time to review resource requests for out of region use as out of region utilization would now need to be included in the analysis of these requests Engineering efforts to handle out of region business rules may be substantial. 4. Policy Statement Proposal/Draft Policy Text Assessed Draft Policy ARIN-2014-1 Out of Region Use Create new Section X: ARIN registered resources may be used outside the ARIN service region. Out of region use of IPv4, IPv6, or ASNs are valid justification for additional number resources if the applicant is currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively. The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR??s service region, the officer of the applicant must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to request a listing of all the applicant's number holdings in the region(s) of proposed use, but this should happen only when there are significant reasons to suspect duplicate requests. On 12/24/14 11:21 AM, ARIN wrote: > Recommended Draft Policy ARIN-2014-1 > Out of Region Use > > On 18 December 2014 the ARIN Advisory Council (AC) recommended > ARIN-2014-1 for adoption, making it a Recommended Draft Policy. > > ARIN-2014-1 is below and can be found at: > https://www.arin.net/policy/proposals/2014_1.html > > You are encouraged to discuss Draft Policy 2014-1 on the PPML prior to > the upcoming ARIN Public Policy Consultation at NANOG 63 in San Antonio > in February 2015. Both the discussion on the list and at the meeting > will be used by the ARIN Advisory Council to determine the community > consensus for adopting this as policy. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Recommended Draft Policy ARIN-2014-1 > Out of Region Use > > Date: 24 December 2014 > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > This proposal enables fair and impartial number resource administration > by clearing up a significant ambiguity in policy and practice. This > proposal is technically sound, as no technical issues are raised by > permitting a single network operator to use resources from one RIR in > any region. This proposal is supported by the community. Permitting out > of region use allows operators with facilities spanning more than one > region to obtain resources in the most direct and convenient way, and to > utilize their numbers more flexibly and efficiently. The concerns of law > enforcement and staff raised by the first staff and legal assessment > have been mitigated by the latest amendments. > > Problem statement: > > Current policy neither clearly forbids nor clearly permits out or region > use of ARIN registered resources. This has created confusion and > controversy within the ARIN community for some time. Earlier work on > this issue has explored several options to restrict or otherwise limit > out of region use. None of these options have gained consensus within > the community. The next logical option is a proposal that clearly > permits out of region use while addressing some of the concerns > expressed about unlimited openness to out of region use. > > Policy statement: > > Create new Section X: > > ARIN registered resources may be used outside the ARIN service region. > Out of region use of IPv4, IPv6, or ASNs are valid justification for > additional number resources if the applicant is currently using at least > the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN > service region, respectively. > > The services and facilities used to justify the need for ARIN resources > that will be used out of region cannot also be used to justify resource > requests from another RIR. When a request for resources from ARIN is > justified by need located within another RIR??s service region, the > officer of the applicant must attest that the same services and > facilities have not been used as the basis for a resource request in the > other region(s). ARIN reserves the right to request a listing of all the > applicant's number holdings in the region(s) of proposed use, but this > should happen only when there are significant reasons to suspect > duplicate requests. > > Comments: > > a. Timetable for implementation: Immediate > > b. Anything else > > Current policy is ambiguous on the issue of out of region use of ARIN > registered resources. The only guidance on the issue in current policy > is Section 2.2, which defines the the role of RIRs as ??to manage and > distribute public Internet address space within their respective > regions.?? Some in the community believe this means out of region use > should be prevented or restricted, while others believe this is only > intended to focus efforts within the region and not define where > resources may be used. > > Previous policy proposals have explored restricting or otherwise > limiting out of region use, but none have gained consensus within the > ARIN community. Several standards for restricting out of region use were > explored, but all of them were perceived as interfering with the > legitimate operations of multi- or trans-regional networks. > > The requirement to have a minimal level of resources deployed in the > region (/44 for IPv6, /22 for IPv4, 1 ASN) is an attempt to respond to > law enforcement and some community concerns. An absolute threshold > ensures that those applying for ARIN resources are actually operating in > the region and not simply a shell company, but it avoids the known > pitfalls of trying to use percentages of the organization's overall > holdings to do that. The use of officer attestation and the possibility > of an audit is an attempt to prevent duplicate requests without > requiring burdensome reporting requirements. > > In summary, this proposal ensures that trans-regional organizations or > service providers operating within the ARIN region may receive all the > resources they need from ARIN if they wish to do so. This change is > particularly important for IPv6. Requiring organizations get IPv6 > resources from multiple RIRs will result in additional unique > non-aggregatable prefixes within the IPv6 route table. > > ##### > > ARIN STAFF ASSESSMENT > > Date of Assessment: 22 October 2014 to 13 November 2014 > 2014-1 ??Out of Region Use?? > > 1. Summary (Staff Understanding) > > This policy would allow out of region use of ARIN issued resources as > long as the requesting organization is an ARIN member in good standing > and currently using at least a /22, or a /44, or 1 ASN within the ARIN > region. > > 2. Comments > > A. ARIN Staff Comments > > There are registrants in the ARIN region, such as end-users, who are not > necessarily ARIN members. As written, this policy would not be available > to an organization that is not currently a member of ARIN, due to the > use of "ARIN member in good standing" in the policy text. Unless the > intention is specifically to require ARIN membership, the policy text > should simply reference "a registrant currently using at least the > equivalent of a /22 of IPv4, or a /44 of IPv6 in the region." > > Staff would apply ARIN policy to all out of region requests to include > asking for utilization details of resources registered in another RIR??s > database if the ARIN resources are being requested for use in that region. > > This policy adds a new requirement that staff review utilization outside > of the ARIN region, which will require additional time, and could delay > the review and processing of requests of this type as well as other > request types that ARIN currently handles. > > B. ARIN General Counsel - Legal Assessment > > This policy has been improved from counsel's perspective since the last > version was reviewed at ARIN 34 in Baltimore. > > Counsel recognizes and supports the issuance of resources to entities in > the ARIN region that need number resources that will be used in both > this region and in the remainder of the world. ARIN currently issues > resources for these needs based on a needs based allocation methodology. > This proposed revised policy now requires that there be /22 of deployed > resources in the ARIN service region, and once that installation exists > it allows all of the recipients' needs outside the ARIN service region > to be met by ARIN. This is a substantial improvement from a legal > perspective as it requires a "meaningful" or "material" physical > presence of the recipient in the service region that was absent from the > prior version. This meets a core objective answering my prior concern > about the lack of such a requirement. > > This policy still represents a type of exception to ICP2, despite the > helpful added requirement of the recipients /22 presence in region. ARIN > is governed by ICANN ICP-2, which calls for establishment of a single > RIR to serve each region. ICP2 further notes that multiple RIRs serving > in a single region is likely to lead to difficulty for co-ordination and > co-operation between the RIRs as well as confusion for the community > within the region. The implication of that governance structure is that > each RIR can and should serve its service region. This revised policy > still allows entities with /22 technological connections to the ARIN's > service region to obtain increasingly scarce IPv4 resources from ARIN > and related registry services for needs outside the ARIN regions. This > policy still will result in ARIN effectively providing significant > registry services to ARIN qualified recipients operating in other RIR > regions. > > If the draft policy is adopted and ARIN provides resources to qualifying > entities for use outside of the region, it is essential that the present > requirement for dispute resolution via arbitration at a location in > ARIN's service region as currently required in the RSA be maintained to > assist in reducing the risk of ARIN becoming subject to the venue, > jurisdiction and laws of legal forums outside the ARIN service region. > > ARIN cannot perform business functions contemplated in the policy with > certain countries, and related public or private entities, such as > relationships to Cuba, Iran and North Korea under U.S. law. This has not > historically been an issue for ARIN prior to this proposed policy. The > new requirement to spell out that the recipient must maintain an actual > physical presence, as well as a corporate legal entity in the ARIN > region, reduces, but does not entirely eliminate this concern. It may be > necessary to require ARIN's implementation of this policy to require a > certification that none of the resources will be deployed contrary to > U.S., Canada or Caribbean nations law in this respect. > > 3. Resource Impact > > This policy would have significant resource impact from an > implementation aspect. It is estimated that implementation would occur > within 5-6 months after ratification by the ARIN Board of Trustees. The > following would be needed in order to implement: > > Updated guidelines and internal procedures > > Staff training > > Engineering efforts to handle out of region business rules may be > substantial. > > 4. Proposal/Draft Policy Text Assessed > Draft Policy ARIN-2014-1 Out of Region Use > Date: 21 October 2014 > Problem statement: > Current policy neither clearly forbids nor clearly permits out or region > use of ARIN registered resources. This has created confusion and > controversy within the ARIN community for some time. Earlier work on > this issue has explored several options to restrict or otherwise limit > out of region use. None of these options have gained consensus within > the community. The next logical option is a proposal that clearly > permits out of region use while addressing some of the concerns > expressed about unlimited openness to out of region use. > > Policy statement: > Create new Section X: > ARIN registered resources may be used outside the ARIN service region. > Out of region use of IPv4, IPv6, or ASNs are valid justification for > additional number resources if the applicant is an ARIN member in good > standing and is currently using at least the equivalent of a /22 of > IPv4, or a /44 of IPv6, or 1 ASN within the ARIN service region, > respectively. > The services and facilities used to justify the need for ARIN resources > that will be used out of region cannot also be used to justify resource > requests from another RIR. When a request for resources from ARIN is > justified by need located within another RIR??s service region, an > officer of the applicant must attest that the same services and > facilities have not been used as the basis for a resource request in the > other region(s). ARIN reserves the right to request a listing of all the > applicant's number holdings in the region(s) of proposed use, but this > should happen only when there are significant reasons to suspect > duplicate requests. > > Comments: > a. Timetable for implementation: Immediate > b. Anything else > Current policy is ambiguous on the issue of out of region use of ARIN > registered resources. The only guidance on the issue in current policy > is Section 2.2, which defines the the role of RIRs as ??to manage and > distribute public Internet address space within their respective > regions.?? Some in the community believe this means out of region use > should be prevented or restricted, while others believe this is only > intended to focus efforts within the region and not define where > resources may be used. > Previous policy proposals have explored restricting or otherwise > limiting out of region use, but none have gained consensus within the > ARIN community. Several standards for restricting out of region use were > explored, but all of them were perceived as interfering with the > legitimate operations of multi- or trans-regional networks. > The requirement to have a minimal level of resources deployed in the > region (/44 for IPv6, /22 for IPv4, 1 ASN) is an attempt to respond to > law enforcement and some community concerns. An absolute threshold > ensures that those applying for ARIN resources are actually operating in > the region and not simply a shell company, but it avoids the known > pitfalls of trying to use percentages of the organization's overall > holdings to do that. The use of officer attestation and the possibility > of an audit is an attempt to prevent duplicate requests without > requiring burdensome reporting requirements. > In summary, this proposal ensures that trans-regional organizations or > service providers operating within the ARIN region may receive all the > resources they need from ARIN if they wish to do so. This change is > particularly important for IPv6. Requiring organizations get IPv6 > resources from multiple RIRs will result in additional unique > non-aggregatable prefixes within the IPv6 route table. From owen at delong.com Tue Apr 14 13:09:27 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Apr 2015 10:09:27 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: <552C14F5.9040705@ipinc.net> <192F24E7-123E-451B-BCB3-FE9D5CCB55C7@delong.com> Message-ID: <17508EAA-EE18-43E5-90B1-9C38F0B45D89@delong.com> Seems to me that the problem in this case is not ARIN, it is the way your particular service provider works. Choices include: 1. Work with your service provider to change their process. 2. Change service providers. What am I missing? Owen > On Apr 13, 2015, at 1:36 PM, David Huberman wrote: > > Hi Owen, > > I can give you a great example that's timely. My company ordered some circuits from ISP X recently. ISP X has a policy that they only do REASSIGN DETAIL. They registered the reassignments with POC data that points to a network engineer who ordered the circuit. It's the way their system works. > > The engineer emailed me very angry that her information was in ARIN Whois - and in fact, in Whois many times with multiple iterations of her POC -- POC1, POC2, POC3, POC4, POC5, etc all with the same information pointing to her. It even included her direct phone number, which happened to be her mobile phone, and she was upset about that. > > Luckily for her, she knew who ARIN was, she knew who the hostmaster was in our company (me!), and I knew how to get it fixed. > > BTW, in order to get it fixed, I chose to do what I thought was the right thing: I asked ARIN to "consolidate" the reassignment records into my main OrgID. ARIN *would not do it* without the explicit written permission of ISP X. (Luckily for us, ISP X consented.) > > Hope that helps, > David > > David R Huberman > Principal, Global IP Addressing > Microsoft Corporation > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Monday, April 13, 2015 1:30 PM >> To: David Huberman >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Policy idea: POC Validation >> >> David, >> >> I don?t see the angry phone call as the problem. I see it as a symptom. >> >> The problem is the incorrect registrations. I want us to find out about those >> incorrect registrations and resolve them. I certainly don?t want to simply >> remove the symptom (angry phone call) by masking the problem (incorrect >> registration). >> >> Owen >> >>> On Apr 13, 2015, at 1:23 PM, David Huberman >> wrote: >>> >>> Hi Ted, >>> >>> Thanks for the reply. >>> >>> By "indirect resource registration records", I meant reassignment records. >> ISP has a /17. They reassign a /28 to a customer, and decide to put customer >> POC information on it. That POC only exists because of the /28 - it isn't a POC >> for any directly registered allocation, assignment, or AS number. These are >> the POCs who are complaining en masse to ARIN after receiving POC >> Validation communications. My reasoning for removing POC validation for >> these types of POCs is that ISPs have the option to not register POCs at all -- >> they can choose "REASSIGN SIMPLE" as a path for registering SWIP >> information, and that doesn't have any POC info. Secondly, I'm not convinced >> there's a significant value in up-to-date POC information for reassigned >> numbers. In the end, the ISP (the direct registrant) is the party responsible >> for the IP addresses and use. (And in 90%+ of cases, the ISP is responsible >> for routing in the DFZ, too. For the cases where a reassigned block is >> announced by th >>> e customer, there's a customer ASN easily found in the routing tables, >>> and that contact information is more germane than a SWIP record.) >>> >>> I hope that's clearer. >>> >>> David >>> >>> David R Huberman >>> Principal, Global IP Addressing >>> Microsoft Corporation >>> >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>>> On Behalf Of Ted Mittelstaedt >>>> Sent: Monday, April 13, 2015 12:12 PM >>>> To: arin-ppml at arin.net >>>> Subject: Re: [arin-ppml] Policy idea: POC Validation >>>> >>>> >>>> As one of the initiators of this policy I must state that none of us >>>> who worked on this ever assumed the POC Validation Policy would be >>>> the END of the process. >>>> >>>> The idea was that when a POC was marked invalid, that ARIN would >>>> institute an investigation into the number resources held by the >>>> invalid POC and if they did locate the actual holder, they would give >>>> that holder 30 days to supply valid POC contact info for whois that >>>> would replace the bogus invalid contact info. >>>> >>>> If the holder wasn't forthcoming, ARIN will delete the POC. >>>> Resources that have no POC's justifying their existence are then freed up >> for reassignment. >>>> >>>> If ARIN is not doing this, then it is completely understandable that >>>> you would be getting large numbers of phone calls from people annoyed >>>> that their email addresses are still in whois. >>>> >>>> So, ARIN can start doing this and thereby make the people happy who >>>> are complaining, and at the same time, freeing up resources that are >>>> held by stale or bogus POC data. >>>> >>>> You said "indirect resource registration records" >>>> >>>> What exactly is that? >>>> >>>> In my opinion, ANY POC that is in whois that is associated in any way >>>> with an organization or individual who has IP addresses, and is being >>>> used as justification for holding resources, must remain in the validation >> list. >>>> >>>> It seems quite obvious and apparent that POCs that ARIN has judged to >>>> be invalid, and is in the process of investigating, would be calling >>>> and complaining. In general people who are doing things they >>>> shouldn't be doing, don't like to be investigated would certainly would >> complain. >>>> That can be solved easily by deleting their records and thereby >>>> freeing up resources. Then you don't contact them again and the >>>> community gets back the IP addressing they have held. >>>> >>>> Does not a POC that is being contacted by ARIN have the right to have >>>> their information deleted? If they are calling in and complaining >>>> that their records are in there, they obviously want them removed. >>>> So, ARIN can remove them and stop bothering them. >>>> >>>> You need to define the difference between "indirect resource >>>> registration records" and "associated with an active directly registered >> number resource" >>>> before anyone can really make a judgement on this policy proposal >> change. >>>> >>>> It just seems very simple to me. If they are a POC they are there >>>> because their existence is justifying some IP address holding in some >>>> way, there is some connection. If their POC is no longer justifying >>>> an IP address holding and there is no connection whatsoever to an IP >>>> address holding, then take their POC out and doing so will automatically >> quit contacting them. >>>> >>>> Ted >>>> >>>> On 4/13/2015 11:11 AM, David Huberman wrote: >>>>> Hello, >>>>> >>>>> Richard Jimmerson's Policy Experience Report indicated that 50% of >>>>> the >>>> phone calls that RSD receives are about POC validation, and that they >>>> receive many angry emails and calls from POCs who are only associated >>>> with indirect resource registration records. In response, I offer the >>>> following change to the NRPM : >>>>> >>>>> >>>>> Existing 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. >>>>> >>>>> >>>>> I propose we make the first sentence read: >>>>> >>>>> "During ARIN's annual Whois POC validation, an email will be sent to >>>>> every >>>> POC in the Whois database that is associated with an active directly >>>> registered number resource." >>>>> >>>>> Thoughts? >>>>> David >>>>> >>>>> David R Huberman >>>>> Principal, Global IP Addressing >>>>> Microsoft Corporation >>>>> >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to the >>>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to the ARIN >>>> Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the ARIN >>> Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. > From andrew.dul at quark.net Tue Apr 14 13:34:45 2015 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 14 Apr 2015 11:34:45 -0600 Subject: [arin-ppml] 2014-1 (Out of region use) Message-ID: <82f3fdd1705e8ae688637e105b514d69@quark.net> Here is a suggested addition to the draft policy's first paragraph in an attempt to alleviate some of the issues raised by the staff & legal assessment by increasing the nexus requirement slightly. Out of region use of IPv4, IPv6, or ASNs are valid justification for additional number resources if the applicant is currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively. At least 10% of the additional resource request or 20% of all an organization?s resources must be used in the ARIN service region. From bill at herrin.us Tue Apr 14 14:08:44 2015 From: bill at herrin.us (William Herrin) Date: Tue, 14 Apr 2015 14:08:44 -0400 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: On Mon, Apr 13, 2015 at 5:31 PM, Martin Hannigan wrote: > Did ARIN/you consider a consultation instead and simply adding a NACK button > to the confirmation and reassigning the block back to the ISP in question or > re designate to the online account owner? Hi Marty, That's a fantastic idea. But instead of deregistering the block (which would add chaos to the process for the right-org-wrong-POC case) do two things: 1. Feed the fact of the NACK back to the ISP with a message that the POC reports a registration mistake (requests contact for correction) and a gentle reminder that they are asked to publish accurate records as a condition of retaining allocations. Mistakes will be made. How will the folks who made the mistake find out if they don't get any feedback? 2. Use the data to build a stochastic model that separates routine bookkeeping error from orgs who are more on the negligence/fraud end of SWIP management. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jlewis at lewis.org Tue Apr 14 14:16:51 2015 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 14 Apr 2015 14:16:51 -0400 (EDT) Subject: [arin-ppml] 2014-1 (Out of region use) In-Reply-To: <82f3fdd1705e8ae688637e105b514d69@quark.net> References: <82f3fdd1705e8ae688637e105b514d69@quark.net> Message-ID: On Tue, 14 Apr 2015, Andrew Dul wrote: > Here is a suggested addition to the draft policy's first paragraph in an > attempt to alleviate some of the issues raised by the staff & legal > assessment by increasing the nexus requirement slightly. > > > Out of region use of IPv4, IPv6, or ASNs are valid justification for > additional number resources if the applicant is currently using at least the > equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service > region, respectively. At least 10% of the additional resource request or 20% > of all an organizations resources must be used in the ARIN service region. I wouldn't object to this (now that it's been tempered with the "or 20%..."), but I don't think this will be effective in preventing the sort of fraudulent or "RIR shopping" requests people seem to be worried about. As was just mentioned at the meeting, a major concern some seem to have with 2014-1 is a question of security: "How do we allow ARIN members to use ARIN space globally without restrictions, but prevent out of region organizations from becoming ARIN members for the purpose of acquiring ARIN resources to be used entirely outside the ARIN region?" I don't have a good answer for that question, but I do wonder if the question is relevant? As has previously been mentioned on PPML, an organization can setup a "dummy" network using as little as some in-region cloud computing resources to "fake out" the nexus requirement. What's to stop them from doing the same thing to hide that their request is for resources to be used out of region? If an org is going to commit fraud to obtain ARIN resources, I don't see that 2014-1 opening additional fraudulent routes to obtaining ARIN resources is the huge problem some seem to think it is. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bill at herrin.us Tue Apr 14 14:29:11 2015 From: bill at herrin.us (William Herrin) Date: Tue, 14 Apr 2015 14:29:11 -0400 Subject: [arin-ppml] 2014-1 (Out of region use) In-Reply-To: <82f3fdd1705e8ae688637e105b514d69@quark.net> References: <82f3fdd1705e8ae688637e105b514d69@quark.net> Message-ID: On Tue, Apr 14, 2015 at 1:34 PM, Andrew Dul wrote: > Out of region use of IPv4, IPv6, or ASNs are valid justification for > additional number resources if the applicant is currently using at least the > equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service > region, respectively. At least 10% of the additional resource request or > 20% of all an organization's resources must be used in the ARIN service > region. Hi Andrew, How would that alleviate the concerns raised in the March legal assessment? As I understood it, they boiled down to: 1. Permitted use of addresses outregion could subject ARIN to the legal jurisdiction in the myriad localities where the addresses are used. Dealing with that could be super expensive and could distract and draw resources away from ARIN's core function: managing addresses for use in-region. 2. ARIN is bound by ICP-2 which is at least nominally contrary to outregion use of ARIN-managed addresses. Changes or clarifications to ICP-2 would be desired in order to proceed with an explicit outregion policy more permissive than, "no." The _fraction_ of use in presumptively non-permitted ways doesn't seem to be at issue. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From scottleibrand at gmail.com Tue Apr 14 14:59:45 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 14 Apr 2015 11:59:45 -0700 Subject: [arin-ppml] "Don't ask" about Out of region use? Message-ID: During and after the 2014-1 (Out of region use) policy discussion, it was pointed out that perhaps the real issue we're trying to address here is not entirely a policy issue, but more of a staff practice issue. In particular, ARIN changed their practice a few years ago to start asking where an applicant intends to use the addresses they're requesting. The reason for changing practice was related to imminent runout and fraud concerns, and it's likely that those concerns will be much less relevant after free pool exhaustion. So perhaps it would be better / easier if we requested that ARIN, after IPv4 exhaustion, stop asking where applicants intend to use the address space they're requesting to receive? If we were to submit a request to that effect through the ACSP, would ARIN staff be able or willing to return to the previous staff practice? If ARIN staff were to do that, does the community feel that would address the problem we're trying to address here, and allow organizations to get IPv4 addresses via transfer to use wherever they need them in their global networks? -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Tue Apr 14 15:18:25 2015 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 14 Apr 2015 19:18:25 +0000 Subject: [arin-ppml] 2014-1 (Out of region use) In-Reply-To: References: <82f3fdd1705e8ae688637e105b514d69@quark.net> Message-ID: <3fdaecdd62f6435ea2122f868123ac83@EX13-MBX-13.ad.syr.edu> Bill > -----Original Message----- > > 1. Permitted use of addresses outregion could subject ARIN to the legal > jurisdiction in the myriad localities where the addresses are used. Dealing > with that could be super expensive and could distract and draw resources > away from ARIN's core function: managing addresses for use in-region. It's an invalid argument. Out of region usage _already_ occurs, and both staff (JC) and Counsel have said they don't oppose it if the entity has some nexus with our region. The 2014-1 policy includes a threshold for nexus. It is a change of degree not a change of kind. There is nothing in the policy, therefore, that would significantly change jurisdictional exposure. > > 2. ARIN is bound by ICP-2 which is at least nominally contrary to outregion > use of ARIN-managed addresses. Changes or clarifications to > ICP-2 would be desired in order to proceed with an explicit outregion policy > more permissive than, "no." As noted many times before, ICP-2 does not address the usage policies of existing RIRs, it is about creating new RIRs. And it basically just asserts that it would be confusing to create a new RIR that overlapped with existing service regions. From mueller at syr.edu Tue Apr 14 15:20:27 2015 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 14 Apr 2015 19:20:27 +0000 Subject: [arin-ppml] 2014-1 (Out of region use) In-Reply-To: References: <82f3fdd1705e8ae688637e105b514d69@quark.net> Message-ID: > -----Original Message----- > "How do we allow ARIN members to use ARIN space globally without > restrictions, but prevent out of region organizations from becoming ARIN > members for the purpose of acquiring ARIN resources to be used entirely > outside the ARIN region?" This issue is addressed by IPv4 runout and its replacement by a market. > resources to be used out of region? If an org is going to commit fraud to > obtain ARIN resources, I don't see that 2014-1 opening additional fraudulent > routes to obtaining ARIN resources is the huge problem some seem to think > it is. You're right. From jcurran at arin.net Tue Apr 14 16:53:48 2015 From: jcurran at arin.net (John Curran) Date: Tue, 14 Apr 2015 20:53:48 +0000 Subject: [arin-ppml] "Don't ask" about Out of region use? In-Reply-To: References: Message-ID: <6D8A2921-DE74-4BB8-8A9E-7861D2AED9F8@corp.arin.net> On Apr 14, 2015, at 11:59 AM, Scott Leibrand wrote: > > During and after the 2014-1 (Out of region use) policy discussion, it was pointed out that perhaps the real issue we're trying to address here is not entirely a policy issue, but more of a staff practice issue. In particular, ARIN changed their practice a few years ago to start asking where an applicant intends to use the addresses they're requesting. The reason for changing practice was related to imminent runout and fraud concerns, and it's likely that those concerns will be much less relevant after free pool exhaustion. > > So perhaps it would be better / easier if we requested that ARIN, after IPv4 exhaustion, stop asking where applicants intend to use the address space they're requesting to receive? > > If we were to submit a request to that effect through the ACSP, would ARIN staff be able or willing to return to the previous staff practice? Scott - It would be best community would provide clear policy regarding how it wants requests handled, as present policy is ambiguous regarding how to determine need when out-of-region demand is involved. /John John Curran President and CEO ARIN From David.Huberman at microsoft.com Tue Apr 14 17:34:13 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 14 Apr 2015 21:34:13 +0000 Subject: [arin-ppml] Equality in address space assignment Message-ID: RIPE and APNIC policy HAVE ALWAYS ALLOWED all first-time requestors to be an LIR and get address space directly from the registry. In fact, for more than a decade, that size was defaulted to a /20. It is smaller now (a /22 I believe). Then to get more space, you show you efficiently utilized what you have. At the mics at ARIN 35 just today, the large ISPs and Cablecos got up to the mic and said a policy which allows small networks to get a /24 just by asking for it is unfair. So I ask: How is RIPE and APNIC's policy unfair, but ARIN's policy of "you must be THIS large a network to participate" fair? What is the technical basis for not allowing small networks to get PI space? Decades of RIPE and APNIC policy didn't break the internet. David David R Huberman Principal, Global IP Addressing Microsoft Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Tue Apr 14 17:54:58 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 14 Apr 2015 14:54:58 -0700 Subject: [arin-ppml] Equality in address space assignment In-Reply-To: References: Message-ID: <53E65F85-01D6-4026-8D3F-38DF5318CD0D@matthew.at> > On Apr 14, 2015, at 2:34 PM, David Huberman wrote: > > ... > > What is the technical basis for not allowing small networks to get PI space? That's easy. The large networks would "technically" have leverage over their PA-addressed customers. Matthew Kaufman (Sent from my iPhone) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mysidia at gmail.com Tue Apr 14 19:23:32 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 14 Apr 2015 18:23:32 -0500 Subject: [arin-ppml] Equality in address space assignment In-Reply-To: References: Message-ID: On Tue, Apr 14, 2015 at 4:34 PM, David Huberman wrote: > How is RIPE and APNIC?s policy unfair, but ARIN?s policy of ?you must be > THIS large a network to participate? fair? > What is the technical basis for not allowing small networks to get PI space? It's unfair, because non first time requestors have to hold resources, And they have to show efficient utilization of existing resources. "All first time requestors can get a /24" is essentially saying.... "We don't care if you waste 253 IP addresses, because your network design only required a /29." Doesn't require a technical basis. It is undesirable for any networks to have PI space, as it grows the routing tables, but This is a good non-technical resource management choice. It makes sense to require small networks with no direct allocation yet to meet criteria to show that they have reached a size milestone of proven business and growth projections with sufficient confidence to show that the allocation of a /24 is needed, and absolutely necessary to meet short term or immediate needs. Consider that there are many more small networks than large ones. There are many very small networks which might have a proven case for 10 IP addresses and a claim to need 200 "soon". It makes no sense that they can get a /24 for ARIN, and then stop growing, and hold onto that entire /24 forever; As long as the small organization exists, the allocation of the /24 is an irrevocable choice, with no incentive for the small org. to renumber back to PA space and release unnecessary resources. On the other hand, if the small org obtains a /24 of PA space instead, or a /28 of PA space, Either less IP space will be wasted by the small network, Or the ISP holding the PA block can reclaim addresses at a later date. Furthermore, for the larger networks, there should be a small number of those, so there is less possible waste. It would also be much better for the public for these resources to go to an ISP as PA space, where the /24 could be divided up more fairly according to actual need; with fewer global routing table entries. Operators already managing large PA address space are also more likely to have mature organizational frameworks to ensure the right internal address management practices are in place to avoid wasting or unnecessarily utilizing scarce IPs. To the 50000 or so would-be first time requestors who might like a /24; if there was no previous resource requirement.... they might very well wind up wasting 75% of their allocation by only using 25% of the IPs. > Decades of RIPE and APNIC policy didn?t break the internet. Non Sequitur. Decades of ARIN policy didn't break the internet, either. > David -- -JH From SRyerse at eclipse-networks.com Tue Apr 14 21:53:43 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 15 Apr 2015 01:53:43 +0000 Subject: [arin-ppml] Equality in address space assignment In-Reply-To: References: Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12017A8CEA49@ENI-MAIL.eclipse-networks.com> You know I find it amazing that those big large ISPs and Cablecos who probably got very large blocks like Class A's and Class B's for free just by asking Network Solutions for them well before ARIN was formed, and who probably have large unused portions of those blocks under their control, would complain about a small org getting a measly /24 and not using it all. That kind of thinking is why ARIN's policies are so unfair to small Orgs. When a small Org with no IP resources applies for a small block and get denied, they not only get shut out of resources but they get shut out of participating in this Community and voting for AC & Board posts. The deck is stacked against us small guys and this needs to change. My Prop 2014-18 would have been the first very small step towards changing that but of course the bigger guys who have resources and can participate in this community keep the small guys out. My two cents!! Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jimmy Hess Sent: Tuesday, April 14, 2015 7:24 PM To: David Huberman Cc: ARIN PPML (ppml at arin.net) Subject: Re: [arin-ppml] Equality in address space assignment On Tue, Apr 14, 2015 at 4:34 PM, David Huberman wrote: > How is RIPE and APNIC?s policy unfair, but ARIN?s policy of ?you must > be THIS large a network to participate? fair? > What is the technical basis for not allowing small networks to get PI space? It's unfair, because non first time requestors have to hold resources, And they have to show efficient utilization of existing resources. "All first time requestors can get a /24" is essentially saying.... "We don't care if you waste 253 IP addresses, because your network design only required a /29." Doesn't require a technical basis. It is undesirable for any networks to have PI space, as it grows the routing tables, but This is a good non-technical resource management choice. It makes sense to require small networks with no direct allocation yet to meet criteria to show that they have reached a size milestone of proven business and growth projections with sufficient confidence to show that the allocation of a /24 is needed, and absolutely necessary to meet short term or immediate needs. Consider that there are many more small networks than large ones. There are many very small networks which might have a proven case for 10 IP addresses and a claim to need 200 "soon". It makes no sense that they can get a /24 for ARIN, and then stop growing, and hold onto that entire /24 forever; As long as the small organization exists, the allocation of the /24 is an irrevocable choice, with no incentive for the small org. to renumber back to PA space and release unnecessary resources. On the other hand, if the small org obtains a /24 of PA space instead, or a /28 of PA space, Either less IP space will be wasted by the small network, Or the ISP holding the PA block can reclaim addresses at a later date. Furthermore, for the larger networks, there should be a small number of those, so there is less possible waste. It would also be much better for the public for these resources to go to an ISP as PA space, where the /24 could be divided up more fairly according to actual need; with fewer global routing table entries. Operators already managing large PA address space are also more likely to have mature organizational frameworks to ensure the right internal address management practices are in place to avoid wasting or unnecessarily utilizing scarce IPs. To the 50000 or so would-be first time requestors who might like a /24; if there was no previous resource requirement.... they might very well wind up wasting 75% of their allocation by only using 25% of the IPs. > Decades of RIPE and APNIC policy didn?t break the internet. Non Sequitur. Decades of ARIN policy didn't break the internet, either. > David -- -JH _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From hannigan at gmail.com Wed Apr 15 02:46:01 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 14 Apr 2015 23:46:01 -0700 Subject: [arin-ppml] 2014-1 (Out of region use) In-Reply-To: <82f3fdd1705e8ae688637e105b514d69@quark.net> References: <82f3fdd1705e8ae688637e105b514d69@quark.net> Message-ID: This is getting wholly unproductive. Ratios are dead on the doir step. I tack up the assignment as anchor and its 100% utilized ratio wise. Already works this way as I hope I explained today. I suggest we finally dump this proposal. Instead, please start over (new) and focus on out of region "requestors". Not in region legitimate in region and innocent users. Best, Marty On Tuesday, April 14, 2015, Andrew Dul wrote: > Here is a suggested addition to the draft policy's first paragraph in an > attempt to alleviate some of the issues raised by the staff & legal > assessment by increasing the nexus requirement slightly. > > > Out of region use of IPv4, IPv6, or ASNs are valid justification for > additional number resources if the applicant is currently using at least > the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN > service region, respectively. At least 10% of the additional resource > request or 20% of all an organization's resources must be used in the ARIN > service region. > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 elvis at velea.eu Wed Apr 15 03:49:16 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Wed, 15 Apr 2015 00:49:16 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-1: Out of Region Use - updated legal assessment In-Reply-To: <552D2CE7.8060702@arin.net> References: <549AE7FF.6090108@arin.net> <552D2CE7.8060702@arin.net> Message-ID: <552E17FC.4010408@velea.eu> Hi, after carefully reading the proposed text and after the discussion we had yesterday, I support the proposal. I know I objected, initially, at the microphone during yesterday's session but now I understand that my objection was either based on previous versions of this proposal or on suggestions made by others that made me believe otherwise. I believe that there is no way for the ARIN Staff to actually verify where an IP address is used and not implementing such a proposal as policy means that companies will need to use misleading justification in order to request and obtain what they need. For example, companies will have to say that they will announce the aggregate from an ARIN AS even though the more specifics (and therefore the sites receiving the traffic) could most be out of region. Additionally, companies requesting addresses for a disconnected POP (out of region) may be refused while if they would say that the POP is part of a global infrastructure (with an aggregate announced from ARIN) they will probably get the requested space. Currently we are at .24 of a /8 available in the free pool and it makes no sense to continue to be strict or add more barriers in how companies decide to use the IP addresses allocated to them. Organizations that decide to be ARIN members (no matter what their reasoning is) as long as these organizations are dully incorporated and have a physical presence in ARIN should be allowed to use address space registered in the ARIN registry and database for all of their in (or out of) region needs. Lastly, I have been talking to various people during the breaks and I understand that it will be in the interest of those parties if they could have only one account (membership) to worry about and if they could aggregate all of their resources in that one account. Although, to be fair, I would not understand why someone would actually do that in ARIN because holding a RIPE NCC membership account comes with (maybe) a cheaper fee and freedom to request/receive/transfer anything (including the no needs based requirements). my 2 cents, Elvis On 14/04/15 08:06, ARIN wrote: > There was a request to repost the updated legal assessment of 2014-1 > which is going to be discussed here at ARIN 35 this morning. > > The updated legal assessment is included in the Draft Policy text > below and can be found at: > > https://www.arin.net/policy/proposals/2014_1.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Recommended Draft Policy ARIN-2014-1 > Out of Region Use > > Date: 24 December 2014 > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > This proposal enables fair and impartial number resource > administration by clearing up a significant ambiguity in policy and > practice. This proposal is technically sound, as no technical issues > are raised by permitting a single network operator to use resources > from one RIR in any region. This proposal is supported by the > community. Permitting out of region use allows operators with > facilities spanning more than one region to obtain resources in the > most direct and convenient way, and to utilize their numbers more > flexibly and efficiently. The concerns of law enforcement and staff > raised by the first staff and legal assessment have been mitigated by > the latest amendments. > > Problem statement: > > Current policy neither clearly forbids nor clearly permits out or > region use of ARIN registered resources. This has created confusion > and controversy within the ARIN community for some time. Earlier work > on this issue has explored several options to restrict or otherwise > limit out of region use. None of these options have gained consensus > within the community. The next logical option is a proposal that > clearly permits out of region use while addressing some of the > concerns expressed about unlimited openness to out of region use. > > Policy statement: > > Create new Section X: > > ARIN registered resources may be used outside the ARIN service region. > Out of region use of IPv4, IPv6, or ASNs are valid justification for > additional number resources if the applicant is currently using at > least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within > the ARIN service region, respectively. > > The services and facilities used to justify the need for ARIN > resources that will be used out of region cannot also be used to > justify resource requests from another RIR. When a request for > resources from ARIN is justified by need located within another RIR??s > service region, the officer of the applicant must attest that the same > services and facilities have not been used as the basis for a resource > request in the other region(s). ARIN reserves the right to request a > listing of all the applicant's number holdings in the region(s) of > proposed use, but this should happen only when there are significant > reasons to suspect duplicate requests. > > Comments: > > a. Timetable for implementation: Immediate > > b. Anything else > > Current policy is ambiguous on the issue of out of region use of ARIN > registered resources. The only guidance on the issue in current policy > is Section 2.2, which defines the the role of RIRs as ??to manage and > distribute public Internet address space within their respective > regions.?? Some in the community believe this means out of region use > should be prevented or restricted, while others believe this is only > intended to focus efforts within the region and not define where > resources may be used. > > Previous policy proposals have explored restricting or otherwise > limiting out of region use, but none have gained consensus within the > ARIN community. Several standards for restricting out of region use > were explored, but all of them were perceived as interfering with the > legitimate operations of multi- or trans-regional networks. > > The requirement to have a minimal level of resources deployed in the > region (/44 for IPv6, /22 for IPv4, 1 ASN) is an attempt to respond to > law enforcement and some community concerns. An absolute threshold > ensures that those applying for ARIN resources are actually operating > in the region and not simply a shell company, but it avoids the known > pitfalls of trying to use percentages of the organization's overall > holdings to do that. The use of officer attestation and the > possibility of an audit is an attempt to prevent duplicate requests > without requiring burdensome reporting requirements. > > In summary, this proposal ensures that trans-regional organizations or > service providers operating within the ARIN region may receive all the > resources they need from ARIN if they wish to do so. This change is > particularly important for IPv6. Requiring organizations get IPv6 > resources from multiple RIRs will result in additional unique > non-aggregatable prefixes within the IPv6 route table. > > ##### > > ARIN STAFF ASSESSMENT > > Date of Revised Assessment: 15 January 2015 > > 1. Summary (Staff Understanding) > > This policy would allow out of region use of ARIN issued resources as > long as the requesting organization is presently an ARIN registry > customer and currently using the equivalent of a /22 IPv4 block, or a > /44 IPv6 block, or an ASN on infrastructure physically located within > the ARIN region. An officer attestation would be required to verify > that the resource request is not a duplicate of one made to another RIR. > > 2. Comments > > A. ARIN Staff Comments > > There are registrants in the ARIN region, such as end-users, who are > not necessarily ARIN members. The policy text has been updated to omit > references to ??Member??, and is understood to refer to organizations > with an existing customer relationship & agreement with ARIN. > > Current ARIN policy requires organizations to show a justified need > for resources to be used specifically within the ARIN region in order > to receive number resources from ARIN. If the draft policy were > adopted, ARIN number resources could be requested for use in another > region. > > When processing resource requests for use in another region under this > policy, ARIN staff would include any address space registered through > another RIR and currently used (or available to be used) within that > region in its evaluation of the organization??s justified need based > on current ARIN policy. > > This policy adds a new requirement that staff review utilization > outside of the ARIN region, which will require additional time, and > could delay the review and processing of requests of this type as well > as other request types that ARIN currently handles. > > This policy would be placed in the NRPM as "2.17 Out of Region Use". > > [The following is an updated legal assessment of 2014-1] > > B. ARIN General Counsel - Legal Assessment > > 19 March 2015 > > Counsel has significant and material legal concerns about this policy. > Counsel recognizes and supports the issuance of resources to entities > in the ARIN region that need number resources that will be used in > both this region and in the remainder of the world. ARIN currently > issues resources for these needs based on a needs based allocation > methodology. > > However, this proposed policy removes the requirement that there be > any meaningful need for those resources in the ARIN service region, > and allows all of the need to be outside the ARIN service region. This > creates new legal challenges for ARIN which are identified below: > > First, ARIN is governed by ICANN ICP-2, which calls for establishment > of a single RIR to serve each region. It further notes that multiple > RIRs serving in single region is likely to lead to difficulty for > co-ordination and co-operation between the RIRs as well as confusion > for the community within the region. The implication of that > governance structure is that each RIR can and should serve its service > region. This policy would allow entities with no real connection to > the ARIN's service region to obtain, for example, increasingly scarce > IPv4 resources from ARIN and related registry services. This policy > would result in ARIN effectively providing registry services to other > regions, and thus appears on its face to be inconsistent with ICP-2. > ARIN has obligations to follow the global policy in ICP2, or seek > changes in it. > > Second, if the policy were adopted, ARIN could arguably become subject > to the jurisdiction and laws passed by governments outside our service > region. This may lead to ARIN being a litigant in courts of nations > outside its service region and subject to their requirements and > judgments. ARIN will need to accept greater legal expenditures and > risks, as well as potentially larger costs in order to take this > greater scope into consideration in ARIN's registry activities on an > ongoing basis. > > Third, the policy fails to recognize that ARIN is not likely to able > to perform the function contemplated in the policy with certain > countries, and related public or private entities. See as examples > under US law: Cuba, Iran and North Korea. The policy could benefit > from a specific carve out that ARIN may meet its obligations under the > laws of governments in its service region, even if such requests would > otherwise comply with ARIN policy. For those who assert that this > requirement to conform to law is implicit and does not need to be > stated in policy, it is important the community is under notice of > this limit. This issue has not been an issue for ARIN prior to this > proposed policy. > > Fourth, ARIN may be subject to significantly greater political > oversight by national governments in its service region that will wish > to evaluate why ARIN alone of the 5 RIRs is assuming a duty to service > all of the world's community. It may be argued by governments in > ARIN's region that this is a potential breach of ARIN??s fiduciary > obligations to its own region, and to examine whether it is consistent > with ARIN??s non-profit status and other corporate documents. > > Fifth and finally, counsel is concerned that the policy will lead to > an increase in fraudulent applications from out of region requestors, > and issuance of resources to those who fraudulently file, since ARIN > is not as well positioned to successfully discover such fraud by out > of region requestors. > > > [Legal Assessment in the staff assessment dated 15 January 2015] > > B. ARIN General Counsel - Legal Assessment > > [15 January 2015] > > Counsel supports the issuance of resources to entities in the ARIN > region that need number resources that will be used in this region and > in the remainder of the world. ARIN currently issues resources for > these needs based on a needs based allocation methodology. This > proposed revised policy now requires that there be /22 of deployed > IPv4 resources in the ARIN service region, and once that installation > exists it allows all of the recipients?? needs outside the ARIN > service region to be met by ARIN. The requirement of a meaningful > physical presence of the recipient in the service region was absent > from the prior version, and is an improvement. (The draft policy does > not explicitly spell out that the recipient must have an actual > physical presence, as well as a corporate legal entity, in the ARIN > region, but implies the requirement indirectly by stating that the > requester must presently be using resources in the ARIN region and > thus already comply with ARIN??s existing requirements. > > The single remaining aspect that continues to create legal and policy > concern is that the policy as written and interpreted calls for ARIN > to allocate resources solely for use out of the ARIN service region. > By definition, those resources should be obtained from the RIR(s) in > the service region(s) where the need exists. Counsel would strongly > prefer that the policy require that there be a requirement that some > of the resources being allocated be needed in the ARIN region. Such a > modest limit would be consistent with ICP-2; it would be consistent > with ARIN's stewardship responsibility to allocate the waning pool of > IPv4 number resources, and will still meet the needs of ARIN based > multinational entities who need resources across the globe. > > This draft policy is inconsistent with ICP2. ARIN is governed by ICANN > ICP-2, which calls for establishment of a single RIR to serve each > region. ICP2 further notes that multiple RIRs serving in a single > region is likely to lead to difficulty for co-ordination and > co-operation between the RIRs as well as confusion for the community > within the region. The implication of that governance structure is > that each RIR can and should serve primarily its service region. > Adoption of this policy will result in ARIN effectively providing > significant registry services to ARIN qualified recipients in other > RIR regions, and such a change should not be undertaken lightly but > instead only after the framework provided in ICP-2 is updated (based > on global discussion and consent) - to proceed otherwise would > undermines ICP-2 and encourages parties to set aside its principles in > an uncoordinated manner, risking in the very "confusion for the > community" that ICP-2 helps deter at present. > > ARIN cannot perform business functions contemplated in the policy with > certain countries, and related public or private entities, such as > relationships to Cuba, Iran and North Korea under U.S. law. This has > not historically been an issue for ARIN prior to this proposed policy. > It may be necessary to require ARIN??s implementation of this policy > to require a certification that none of the resources will be deployed > contrary to U.S., Canada or Caribbean nations law in this respect. If > the draft policy is adopted and ARIN provides resources to qualifying > entities for use outside of the region, it is essential that the > present requirement for dispute resolution via arbitration at a > location in ARIN??s service region as currently required in the RSA be > maintained to assist in reducing the risk of ARIN becoming subject to > the venue, jurisdiction and laws of legal forums outside the ARIN > service region. > > 3. Resource Impact > > This policy would have significant resource impact from an > implementation aspect. It is estimated that implementation would occur > within 5-6 months after ratification by the ARIN Board of Trustees. > The following would be needed in order to implement: > > Updated guidelines and internal procedures > > Staff training > > Additional time to review resource requests for out of region use as > out of region utilization would now need to be included in the > analysis of these requests > > Engineering efforts to handle out of region business rules may be > substantial. > > 4. Policy Statement > Proposal/Draft Policy Text Assessed > Draft Policy ARIN-2014-1 Out of Region Use > Create new Section X: > > ARIN registered resources may be used outside the ARIN service region. > Out of region use of IPv4, IPv6, or ASNs are valid justification for > additional number resources if the applicant is currently using at > least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within > the ARIN service region, respectively. > > The services and facilities used to justify the need for ARIN resources > that will be used out of region cannot also be used to justify resource > requests from another RIR. When a request for resources from ARIN is > justified by need located within another RIR??s service region, the > officer of the applicant must attest that the same services and > facilities have not been used as the basis for a resource request in > the other region(s). ARIN reserves the right to request a listing of > all the applicant's number holdings in the region(s) of proposed use, > but this should happen only when there are significant reasons to suspect > duplicate requests. > > > > > On 12/24/14 11:21 AM, ARIN wrote: >> Recommended Draft Policy ARIN-2014-1 >> Out of Region Use >> >> On 18 December 2014 the ARIN Advisory Council (AC) recommended >> ARIN-2014-1 for adoption, making it a Recommended Draft Policy. >> >> ARIN-2014-1 is below and can be found at: >> https://www.arin.net/policy/proposals/2014_1.html >> >> You are encouraged to discuss Draft Policy 2014-1 on the PPML prior to >> the upcoming ARIN Public Policy Consultation at NANOG 63 in San Antonio >> in February 2015. Both the discussion on the list and at the meeting >> will be used by the ARIN Advisory Council to determine the community >> consensus for adopting this as policy. >> >> The ARIN Policy Development Process can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Recommended Draft Policy ARIN-2014-1 >> Out of Region Use >> >> Date: 24 December 2014 >> >> AC's assessment of conformance with the Principles of Internet Number >> Resource Policy: >> >> This proposal enables fair and impartial number resource administration >> by clearing up a significant ambiguity in policy and practice. This >> proposal is technically sound, as no technical issues are raised by >> permitting a single network operator to use resources from one RIR in >> any region. This proposal is supported by the community. Permitting out >> of region use allows operators with facilities spanning more than one >> region to obtain resources in the most direct and convenient way, and to >> utilize their numbers more flexibly and efficiently. The concerns of law >> enforcement and staff raised by the first staff and legal assessment >> have been mitigated by the latest amendments. >> >> Problem statement: >> >> Current policy neither clearly forbids nor clearly permits out or region >> use of ARIN registered resources. This has created confusion and >> controversy within the ARIN community for some time. Earlier work on >> this issue has explored several options to restrict or otherwise limit >> out of region use. None of these options have gained consensus within >> the community. The next logical option is a proposal that clearly >> permits out of region use while addressing some of the concerns >> expressed about unlimited openness to out of region use. >> >> Policy statement: >> >> Create new Section X: >> >> ARIN registered resources may be used outside the ARIN service region. >> Out of region use of IPv4, IPv6, or ASNs are valid justification for >> additional number resources if the applicant is currently using at least >> the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN >> service region, respectively. >> >> The services and facilities used to justify the need for ARIN resources >> that will be used out of region cannot also be used to justify resource >> requests from another RIR. When a request for resources from ARIN is >> justified by need located within another RIR??s service region, the >> officer of the applicant must attest that the same services and >> facilities have not been used as the basis for a resource request in the >> other region(s). ARIN reserves the right to request a listing of all the >> applicant's number holdings in the region(s) of proposed use, but this >> should happen only when there are significant reasons to suspect >> duplicate requests. >> >> Comments: >> >> a. Timetable for implementation: Immediate >> >> b. Anything else >> >> Current policy is ambiguous on the issue of out of region use of ARIN >> registered resources. The only guidance on the issue in current policy >> is Section 2.2, which defines the the role of RIRs as ??to manage and >> distribute public Internet address space within their respective >> regions.?? Some in the community believe this means out of region use >> should be prevented or restricted, while others believe this is only >> intended to focus efforts within the region and not define where >> resources may be used. >> >> Previous policy proposals have explored restricting or otherwise >> limiting out of region use, but none have gained consensus within the >> ARIN community. Several standards for restricting out of region use were >> explored, but all of them were perceived as interfering with the >> legitimate operations of multi- or trans-regional networks. >> >> The requirement to have a minimal level of resources deployed in the >> region (/44 for IPv6, /22 for IPv4, 1 ASN) is an attempt to respond to >> law enforcement and some community concerns. An absolute threshold >> ensures that those applying for ARIN resources are actually operating in >> the region and not simply a shell company, but it avoids the known >> pitfalls of trying to use percentages of the organization's overall >> holdings to do that. The use of officer attestation and the possibility >> of an audit is an attempt to prevent duplicate requests without >> requiring burdensome reporting requirements. >> >> In summary, this proposal ensures that trans-regional organizations or >> service providers operating within the ARIN region may receive all the >> resources they need from ARIN if they wish to do so. This change is >> particularly important for IPv6. Requiring organizations get IPv6 >> resources from multiple RIRs will result in additional unique >> non-aggregatable prefixes within the IPv6 route table. >> >> ##### >> >> ARIN STAFF ASSESSMENT >> >> Date of Assessment: 22 October 2014 to 13 November 2014 >> 2014-1 ??Out of Region Use?? >> >> 1. Summary (Staff Understanding) >> >> This policy would allow out of region use of ARIN issued resources as >> long as the requesting organization is an ARIN member in good standing >> and currently using at least a /22, or a /44, or 1 ASN within the ARIN >> region. >> >> 2. Comments >> >> A. ARIN Staff Comments >> >> There are registrants in the ARIN region, such as end-users, who are not >> necessarily ARIN members. As written, this policy would not be available >> to an organization that is not currently a member of ARIN, due to the >> use of "ARIN member in good standing" in the policy text. Unless the >> intention is specifically to require ARIN membership, the policy text >> should simply reference "a registrant currently using at least the >> equivalent of a /22 of IPv4, or a /44 of IPv6 in the region." >> >> Staff would apply ARIN policy to all out of region requests to include >> asking for utilization details of resources registered in another RIR??s >> database if the ARIN resources are being requested for use in that >> region. >> >> This policy adds a new requirement that staff review utilization outside >> of the ARIN region, which will require additional time, and could delay >> the review and processing of requests of this type as well as other >> request types that ARIN currently handles. >> >> B. ARIN General Counsel - Legal Assessment >> >> This policy has been improved from counsel's perspective since the last >> version was reviewed at ARIN 34 in Baltimore. >> >> Counsel recognizes and supports the issuance of resources to entities in >> the ARIN region that need number resources that will be used in both >> this region and in the remainder of the world. ARIN currently issues >> resources for these needs based on a needs based allocation methodology. >> This proposed revised policy now requires that there be /22 of deployed >> resources in the ARIN service region, and once that installation exists >> it allows all of the recipients' needs outside the ARIN service region >> to be met by ARIN. This is a substantial improvement from a legal >> perspective as it requires a "meaningful" or "material" physical >> presence of the recipient in the service region that was absent from the >> prior version. This meets a core objective answering my prior concern >> about the lack of such a requirement. >> >> This policy still represents a type of exception to ICP2, despite the >> helpful added requirement of the recipients /22 presence in region. ARIN >> is governed by ICANN ICP-2, which calls for establishment of a single >> RIR to serve each region. ICP2 further notes that multiple RIRs serving >> in a single region is likely to lead to difficulty for co-ordination and >> co-operation between the RIRs as well as confusion for the community >> within the region. The implication of that governance structure is that >> each RIR can and should serve its service region. This revised policy >> still allows entities with /22 technological connections to the ARIN's >> service region to obtain increasingly scarce IPv4 resources from ARIN >> and related registry services for needs outside the ARIN regions. This >> policy still will result in ARIN effectively providing significant >> registry services to ARIN qualified recipients operating in other RIR >> regions. >> >> If the draft policy is adopted and ARIN provides resources to qualifying >> entities for use outside of the region, it is essential that the present >> requirement for dispute resolution via arbitration at a location in >> ARIN's service region as currently required in the RSA be maintained to >> assist in reducing the risk of ARIN becoming subject to the venue, >> jurisdiction and laws of legal forums outside the ARIN service region. >> >> ARIN cannot perform business functions contemplated in the policy with >> certain countries, and related public or private entities, such as >> relationships to Cuba, Iran and North Korea under U.S. law. This has not >> historically been an issue for ARIN prior to this proposed policy. The >> new requirement to spell out that the recipient must maintain an actual >> physical presence, as well as a corporate legal entity in the ARIN >> region, reduces, but does not entirely eliminate this concern. It may be >> necessary to require ARIN's implementation of this policy to require a >> certification that none of the resources will be deployed contrary to >> U.S., Canada or Caribbean nations law in this respect. >> >> 3. Resource Impact >> >> This policy would have significant resource impact from an >> implementation aspect. It is estimated that implementation would occur >> within 5-6 months after ratification by the ARIN Board of Trustees. The >> following would be needed in order to implement: >> >> Updated guidelines and internal procedures >> >> Staff training >> >> Engineering efforts to handle out of region business rules may be >> substantial. >> >> 4. Proposal/Draft Policy Text Assessed >> Draft Policy ARIN-2014-1 Out of Region Use >> Date: 21 October 2014 >> Problem statement: >> Current policy neither clearly forbids nor clearly permits out or region >> use of ARIN registered resources. This has created confusion and >> controversy within the ARIN community for some time. Earlier work on >> this issue has explored several options to restrict or otherwise limit >> out of region use. None of these options have gained consensus within >> the community. The next logical option is a proposal that clearly >> permits out of region use while addressing some of the concerns >> expressed about unlimited openness to out of region use. >> >> Policy statement: >> Create new Section X: >> ARIN registered resources may be used outside the ARIN service region. >> Out of region use of IPv4, IPv6, or ASNs are valid justification for >> additional number resources if the applicant is an ARIN member in good >> standing and is currently using at least the equivalent of a /22 of >> IPv4, or a /44 of IPv6, or 1 ASN within the ARIN service region, >> respectively. >> The services and facilities used to justify the need for ARIN resources >> that will be used out of region cannot also be used to justify resource >> requests from another RIR. When a request for resources from ARIN is >> justified by need located within another RIR??s service region, an >> officer of the applicant must attest that the same services and >> facilities have not been used as the basis for a resource request in the >> other region(s). ARIN reserves the right to request a listing of all the >> applicant's number holdings in the region(s) of proposed use, but this >> should happen only when there are significant reasons to suspect >> duplicate requests. >> >> Comments: >> a. Timetable for implementation: Immediate >> b. Anything else >> Current policy is ambiguous on the issue of out of region use of ARIN >> registered resources. The only guidance on the issue in current policy >> is Section 2.2, which defines the the role of RIRs as ??to manage and >> distribute public Internet address space within their respective >> regions.?? Some in the community believe this means out of region use >> should be prevented or restricted, while others believe this is only >> intended to focus efforts within the region and not define where >> resources may be used. >> Previous policy proposals have explored restricting or otherwise >> limiting out of region use, but none have gained consensus within the >> ARIN community. Several standards for restricting out of region use were >> explored, but all of them were perceived as interfering with the >> legitimate operations of multi- or trans-regional networks. >> The requirement to have a minimal level of resources deployed in the >> region (/44 for IPv6, /22 for IPv4, 1 ASN) is an attempt to respond to >> law enforcement and some community concerns. An absolute threshold >> ensures that those applying for ARIN resources are actually operating in >> the region and not simply a shell company, but it avoids the known >> pitfalls of trying to use percentages of the organization's overall >> holdings to do that. The use of officer attestation and the possibility >> of an audit is an attempt to prevent duplicate requests without >> requiring burdensome reporting requirements. >> In summary, this proposal ensures that trans-regional organizations or >> service providers operating within the ARIN region may receive all the >> resources they need from ARIN if they wish to do so. This change is >> particularly important for IPv6. Requiring organizations get IPv6 >> resources from multiple RIRs will result in additional unique >> non-aggregatable prefixes within the IPv6 route table. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From David.Huberman at microsoft.com Wed Apr 15 12:00:54 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Wed, 15 Apr 2015 16:00:54 +0000 Subject: [arin-ppml] Equality in address space assignment In-Reply-To: References: Message-ID: Jimmy, Thank you for the well thought out counter argument. I agree with a lot of what you say. You've outlined what I think is the primary thinking behind conservation-based allocation practices that ARIN policy has been based on for 18 years now. The problem I think I have is the results of those practices. 1) Lock-in by large providers 2) Conservation itself is a red herring, and has been for more than a decade. 80-90% of the addresses go to 10 companies. That leaves tens of thousands of networks using just 10-20% of the addresses. This math has been shown many times on PPML in the past. Routing table growth is no longer mathematically valid, in my opinion. We are just under 600,000 routes. There are only 40,000 ASes or so (right?) in a typical DFZ. Even a doubling of that would have no discernable effect on routing. If youre running a catalyst 5xxx, it's time to upgrade. Finally, I respect the RIPE and APNIC model of addressing: everyone plays on a level field to start with. You get a block, and try and grow your business/network. At ARIN, this "you must be THIS tall" inherently favors the large ISPs and cablecos who dominate ARIN policy making (and have since the beginning), which results in lock-in, etc etc. Just my opinion. My original post was made in frustration when large ISPs got to the mic at ARIN35 decrying that removing needs-basis for small transfers was unfair. Such hypocrisy (especially from those who already bought a /8!!!) is a sore topic for me. I will continue to fight for the little guy, borne of my 10 years working with them every day at ARIN. The big guys don't need the help. Thanks for listening, David David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: Jimmy Hess [mailto:mysidia at gmail.com] > Sent: Tuesday, April 14, 2015 4:24 PM > To: David Huberman > Cc: ARIN PPML (ppml at arin.net) > Subject: Re: [arin-ppml] Equality in address space assignment > > On Tue, Apr 14, 2015 at 4:34 PM, David Huberman > wrote: > > > How is RIPE and APNIC?s policy unfair, but ARIN?s policy of ?you must > > be THIS large a network to participate? fair? > > What is the technical basis for not allowing small networks to get PI space? > > It's unfair, because non first time requestors have to hold resources, And > they have to show efficient utilization of existing resources. > > "All first time requestors can get a /24" is essentially saying.... > > "We don't care if you waste 253 IP addresses, because your network design > only required a /29." > > > Doesn't require a technical basis. It is undesirable for any > networks to have PI > space, as it grows the routing tables, but > > This is a good non-technical resource management choice. It makes sense to > require small networks with no direct allocation yet to meet criteria to show > that they have reached a size milestone of proven business and growth > projections with > sufficient confidence to show that the allocation of a /24 is needed, > and absolutely necessary to meet short term or immediate needs. > > Consider that there are many more small networks than large ones. > There are many very small networks which might have a proven case for > 10 IP addresses and a claim to need 200 "soon". > > It makes no sense that they can get a /24 for ARIN, and then stop growing, > and hold onto > that entire /24 forever; As long as the small organization exists, > the allocation of the /24 > is an irrevocable choice, with no incentive for the small org. to renumber > back to PA space and release unnecessary resources. > > On the other hand, if the small org obtains a /24 of PA space instead, or a > /28 of PA space, Either less IP space will be wasted by the small network, > Or the ISP holding the PA block can reclaim addresses at a later date. > > Furthermore, for the larger networks, there should be a small number of > those, so there is less possible waste. > > It would also be much better for the public for these resources to go to an > ISP as PA space, where the /24 could be divided up more fairly according to > actual need; with fewer global routing table entries. > > Operators already managing large PA address space are also more likely to > have mature organizational frameworks to ensure the right internal address > management practices are in place to avoid wasting or unnecessarily utilizing > scarce IPs. > > To the 50000 or so would-be first time requestors who might like a /24; if > there was no previous resource requirement.... > they might very well wind up wasting 75% of their allocation by only using > 25% of the IPs. > > > > Decades of RIPE and APNIC policy didn?t break the internet. > > Non Sequitur. > Decades of ARIN policy didn't break the internet, either. > > > > David > -- > -JH From David.Huberman at microsoft.com Wed Apr 15 12:05:51 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Wed, 15 Apr 2015 16:05:51 +0000 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: <17508EAA-EE18-43E5-90B1-9C38F0B45D89@delong.com> References: <552C14F5.9040705@ipinc.net> <192F24E7-123E-451B-BCB3-FE9D5CCB55C7@delong.com> <17508EAA-EE18-43E5-90B1-9C38F0B45D89@delong.com> Message-ID: Hi Owen, I think the problem is the scale to which the scenario I outlined is common. It's in the tens of thousands of records (probably over 100,000 if I had to guess, based on my knowledge of ARIN's database size). So let's get data. ARIN STAFF: How many POCs are invalid that are only associated (directly or via the OrgID) with indirectly associated number registrations and with no number registrations at all? Thanks, David David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, April 14, 2015 10:09 AM > To: David Huberman > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy idea: POC Validation > > Seems to me that the problem in this case is not ARIN, it is the way your > particular service provider works. > > Choices include: > > 1. Work with your service provider to change their process. > 2. Change service providers. > > What am I missing? > > Owen > > > On Apr 13, 2015, at 1:36 PM, David Huberman > wrote: > > > > Hi Owen, > > > > I can give you a great example that's timely. My company ordered some > circuits from ISP X recently. ISP X has a policy that they only do REASSIGN > DETAIL. They registered the reassignments with POC data that points to a > network engineer who ordered the circuit. It's the way their system works. > > > > The engineer emailed me very angry that her information was in ARIN > Whois - and in fact, in Whois many times with multiple iterations of her POC - > - POC1, POC2, POC3, POC4, POC5, etc all with the same information pointing > to her. It even included her direct phone number, which happened to be > her mobile phone, and she was upset about that. > > > > Luckily for her, she knew who ARIN was, she knew who the hostmaster > was in our company (me!), and I knew how to get it fixed. > > > > BTW, in order to get it fixed, I chose to do what I thought was the right > thing: I asked ARIN to "consolidate" the reassignment records into my main > OrgID. ARIN *would not do it* without the explicit written permission of ISP > X. (Luckily for us, ISP X consented.) > > > > Hope that helps, > > David > > > > David R Huberman > > Principal, Global IP Addressing > > Microsoft Corporation > > > >> -----Original Message----- > >> From: Owen DeLong [mailto:owen at delong.com] > >> Sent: Monday, April 13, 2015 1:30 PM > >> To: David Huberman > >> Cc: arin-ppml at arin.net > >> Subject: Re: [arin-ppml] Policy idea: POC Validation > >> > >> David, > >> > >> I don?t see the angry phone call as the problem. I see it as a symptom. > >> > >> The problem is the incorrect registrations. I want us to find out > >> about those incorrect registrations and resolve them. I certainly > >> don?t want to simply remove the symptom (angry phone call) by masking > >> the problem (incorrect registration). > >> > >> Owen > >> > >>> On Apr 13, 2015, at 1:23 PM, David Huberman > >> wrote: > >>> > >>> Hi Ted, > >>> > >>> Thanks for the reply. > >>> > >>> By "indirect resource registration records", I meant reassignment > records. > >> ISP has a /17. They reassign a /28 to a customer, and decide to put > >> customer POC information on it. That POC only exists because of the /28 - > it isn't a POC > >> for any directly registered allocation, assignment, or AS number. These > are > >> the POCs who are complaining en masse to ARIN after receiving POC > >> Validation communications. My reasoning for removing POC validation > >> for these types of POCs is that ISPs have the option to not register > >> POCs at all -- they can choose "REASSIGN SIMPLE" as a path for > >> registering SWIP information, and that doesn't have any POC info. > >> Secondly, I'm not convinced there's a significant value in up-to-date > >> POC information for reassigned numbers. In the end, the ISP (the > >> direct registrant) is the party responsible for the IP addresses and > >> use. (And in 90%+ of cases, the ISP is responsible for routing in > >> the DFZ, too. For the cases where a reassigned block is announced by > >> th > >>> e customer, there's a customer ASN easily found in the routing > >>> tables, and that contact information is more germane than a SWIP > >>> record.) > >>> > >>> I hope that's clearer. > >>> > >>> David > >>> > >>> David R Huberman > >>> Principal, Global IP Addressing > >>> Microsoft Corporation > >>> > >>>> -----Original Message----- > >>>> From: arin-ppml-bounces at arin.net > >>>> [mailto:arin-ppml-bounces at arin.net] > >>>> On Behalf Of Ted Mittelstaedt > >>>> Sent: Monday, April 13, 2015 12:12 PM > >>>> To: arin-ppml at arin.net > >>>> Subject: Re: [arin-ppml] Policy idea: POC Validation > >>>> > >>>> > >>>> As one of the initiators of this policy I must state that none of > >>>> us who worked on this ever assumed the POC Validation Policy would > >>>> be the END of the process. > >>>> > >>>> The idea was that when a POC was marked invalid, that ARIN would > >>>> institute an investigation into the number resources held by the > >>>> invalid POC and if they did locate the actual holder, they would > >>>> give that holder 30 days to supply valid POC contact info for whois > >>>> that would replace the bogus invalid contact info. > >>>> > >>>> If the holder wasn't forthcoming, ARIN will delete the POC. > >>>> Resources that have no POC's justifying their existence are then > >>>> freed up > >> for reassignment. > >>>> > >>>> If ARIN is not doing this, then it is completely understandable > >>>> that you would be getting large numbers of phone calls from people > >>>> annoyed that their email addresses are still in whois. > >>>> > >>>> So, ARIN can start doing this and thereby make the people happy who > >>>> are complaining, and at the same time, freeing up resources that > >>>> are held by stale or bogus POC data. > >>>> > >>>> You said "indirect resource registration records" > >>>> > >>>> What exactly is that? > >>>> > >>>> In my opinion, ANY POC that is in whois that is associated in any > >>>> way with an organization or individual who has IP addresses, and is > >>>> being used as justification for holding resources, must remain in > >>>> the validation > >> list. > >>>> > >>>> It seems quite obvious and apparent that POCs that ARIN has judged > >>>> to be invalid, and is in the process of investigating, would be > >>>> calling and complaining. In general people who are doing things > >>>> they shouldn't be doing, don't like to be investigated would > >>>> certainly would > >> complain. > >>>> That can be solved easily by deleting their records and thereby > >>>> freeing up resources. Then you don't contact them again and the > >>>> community gets back the IP addressing they have held. > >>>> > >>>> Does not a POC that is being contacted by ARIN have the right to > >>>> have their information deleted? If they are calling in and > >>>> complaining that their records are in there, they obviously want them > removed. > >>>> So, ARIN can remove them and stop bothering them. > >>>> > >>>> You need to define the difference between "indirect resource > >>>> registration records" and "associated with an active directly > >>>> registered > >> number resource" > >>>> before anyone can really make a judgement on this policy proposal > >> change. > >>>> > >>>> It just seems very simple to me. If they are a POC they are there > >>>> because their existence is justifying some IP address holding in > >>>> some way, there is some connection. If their POC is no longer > >>>> justifying an IP address holding and there is no connection > >>>> whatsoever to an IP address holding, then take their POC out and > >>>> doing so will automatically > >> quit contacting them. > >>>> > >>>> Ted > >>>> > >>>> On 4/13/2015 11:11 AM, David Huberman wrote: > >>>>> Hello, > >>>>> > >>>>> Richard Jimmerson's Policy Experience Report indicated that 50% of > >>>>> the > >>>> phone calls that RSD receives are about POC validation, and that > >>>> they receive many angry emails and calls from POCs who are only > >>>> associated with indirect resource registration records. In > >>>> response, I offer the following change to the NRPM : > >>>>> > >>>>> > >>>>> Existing 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. > >>>>> > >>>>> > >>>>> I propose we make the first sentence read: > >>>>> > >>>>> "During ARIN's annual Whois POC validation, an email will be sent > >>>>> to every > >>>> POC in the Whois database that is associated with an active > >>>> directly registered number resource." > >>>>> > >>>>> Thoughts? > >>>>> David > >>>>> > >>>>> David R Huberman > >>>>> Principal, Global IP Addressing > >>>>> Microsoft Corporation > >>>>> > >>>>> _______________________________________________ > >>>>> PPML > >>>>> You are receiving this message because you are subscribed to the > >>>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >>>>> Unsubscribe or manage your mailing list subscription at: > >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>>>> Please contact info at arin.net if you experience any issues. > >>>> _______________________________________________ > >>>> PPML > >>>> You are receiving this message because you are subscribed to the > >>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >>>> Unsubscribe or manage your mailing list subscription at: > >>>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>>> Please contact info at arin.net if you experience any issues. > >>> _______________________________________________ > >>> PPML > >>> You are receiving this message because you are subscribed to the > >>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >>> Unsubscribe or manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>> Please contact info at arin.net if you experience any issues. > > From tedm at ipinc.net Wed Apr 15 12:22:39 2015 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 15 Apr 2015 09:22:39 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: <552E904F.7020909@ipinc.net> I like this solution a lot! It will, of course, result in the offending ISPs POCs being spammed to death by their own automated systems which auto-fill the SWIPs with information they seem to pull out of thin air. But sacrifices have to be made! Ted On 4/14/2015 11:08 AM, William Herrin wrote: > On Mon, Apr 13, 2015 at 5:31 PM, Martin Hannigan wrote: >> Did ARIN/you consider a consultation instead and simply adding a NACK button >> to the confirmation and reassigning the block back to the ISP in question or >> re designate to the online account owner? > > Hi Marty, > > That's a fantastic idea. But instead of deregistering the block (which > would add chaos to the process for the right-org-wrong-POC case) do > two things: > > 1. Feed the fact of the NACK back to the ISP with a message that the > POC reports a registration mistake (requests contact for correction) > and a gentle reminder that they are asked to publish accurate records > as a condition of retaining allocations. Mistakes will be made. How > will the folks who made the mistake find out if they don't get any > feedback? > > 2. Use the data to build a stochastic model that separates routine > bookkeeping error from orgs who are more on the negligence/fraud end > of SWIP management. > > Regards, > Bill Herrin > From tedm at ipinc.net Wed Apr 15 12:24:20 2015 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 15 Apr 2015 09:24:20 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: <552C14F5.9040705@ipinc.net> <192F24E7-123E-451B-BCB3-FE9D5CCB55C7@delong.com> <17508EAA-EE18-43E5-90B1-9C38F0B45D89@delong.com> Message-ID: <552E90B4.60808@ipinc.net> Your only going to see a fraction of 'em, David. For every 1 who calls in to complain there's 10 others that just ignore it. Ted On 4/15/2015 9:05 AM, David Huberman wrote: > Hi Owen, > > I think the problem is the scale to which the scenario I outlined is common. It's in the tens of thousands of records (probably over 100,000 if I had to guess, based on my knowledge of ARIN's database size). So let's get data. > > ARIN STAFF: How many POCs are invalid that are only associated (directly or via the OrgID) with indirectly associated number registrations and with no number registrations at all? > > Thanks, > David > > David R Huberman > Principal, Global IP Addressing > Microsoft Corporation > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Tuesday, April 14, 2015 10:09 AM >> To: David Huberman >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Policy idea: POC Validation >> >> Seems to me that the problem in this case is not ARIN, it is the way your >> particular service provider works. >> >> Choices include: >> >> 1. Work with your service provider to change their process. >> 2. Change service providers. >> >> What am I missing? >> >> Owen >> >>> On Apr 13, 2015, at 1:36 PM, David Huberman >> wrote: >>> >>> Hi Owen, >>> >>> I can give you a great example that's timely. My company ordered some >> circuits from ISP X recently. ISP X has a policy that they only do REASSIGN >> DETAIL. They registered the reassignments with POC data that points to a >> network engineer who ordered the circuit. It's the way their system works. >>> >>> The engineer emailed me very angry that her information was in ARIN >> Whois - and in fact, in Whois many times with multiple iterations of her POC - >> - POC1, POC2, POC3, POC4, POC5, etc all with the same information pointing >> to her. It even included her direct phone number, which happened to be >> her mobile phone, and she was upset about that. >>> >>> Luckily for her, she knew who ARIN was, she knew who the hostmaster >> was in our company (me!), and I knew how to get it fixed. >>> >>> BTW, in order to get it fixed, I chose to do what I thought was the right >> thing: I asked ARIN to "consolidate" the reassignment records into my main >> OrgID. ARIN *would not do it* without the explicit written permission of ISP >> X. (Luckily for us, ISP X consented.) >>> >>> Hope that helps, >>> David >>> >>> David R Huberman >>> Principal, Global IP Addressing >>> Microsoft Corporation >>> >>>> -----Original Message----- >>>> From: Owen DeLong [mailto:owen at delong.com] >>>> Sent: Monday, April 13, 2015 1:30 PM >>>> To: David Huberman >>>> Cc: arin-ppml at arin.net >>>> Subject: Re: [arin-ppml] Policy idea: POC Validation >>>> >>>> David, >>>> >>>> I don?t see the angry phone call as the problem. I see it as a symptom. >>>> >>>> The problem is the incorrect registrations. I want us to find out >>>> about those incorrect registrations and resolve them. I certainly >>>> don?t want to simply remove the symptom (angry phone call) by masking >>>> the problem (incorrect registration). >>>> >>>> Owen >>>> >>>>> On Apr 13, 2015, at 1:23 PM, David Huberman >>>> wrote: >>>>> >>>>> Hi Ted, >>>>> >>>>> Thanks for the reply. >>>>> >>>>> By "indirect resource registration records", I meant reassignment >> records. >>>> ISP has a /17. They reassign a /28 to a customer, and decide to put >>>> customer POC information on it. That POC only exists because of the /28 - >> it isn't a POC >>>> for any directly registered allocation, assignment, or AS number. These >> are >>>> the POCs who are complaining en masse to ARIN after receiving POC >>>> Validation communications. My reasoning for removing POC validation >>>> for these types of POCs is that ISPs have the option to not register >>>> POCs at all -- they can choose "REASSIGN SIMPLE" as a path for >>>> registering SWIP information, and that doesn't have any POC info. >>>> Secondly, I'm not convinced there's a significant value in up-to-date >>>> POC information for reassigned numbers. In the end, the ISP (the >>>> direct registrant) is the party responsible for the IP addresses and >>>> use. (And in 90%+ of cases, the ISP is responsible for routing in >>>> the DFZ, too. For the cases where a reassigned block is announced by >>>> th >>>>> e customer, there's a customer ASN easily found in the routing >>>>> tables, and that contact information is more germane than a SWIP >>>>> record.) >>>>> >>>>> I hope that's clearer. >>>>> >>>>> David >>>>> >>>>> David R Huberman >>>>> Principal, Global IP Addressing >>>>> Microsoft Corporation >>>>> >>>>>> -----Original Message----- >>>>>> From: arin-ppml-bounces at arin.net >>>>>> [mailto:arin-ppml-bounces at arin.net] >>>>>> On Behalf Of Ted Mittelstaedt >>>>>> Sent: Monday, April 13, 2015 12:12 PM >>>>>> To: arin-ppml at arin.net >>>>>> Subject: Re: [arin-ppml] Policy idea: POC Validation >>>>>> >>>>>> >>>>>> As one of the initiators of this policy I must state that none of >>>>>> us who worked on this ever assumed the POC Validation Policy would >>>>>> be the END of the process. >>>>>> >>>>>> The idea was that when a POC was marked invalid, that ARIN would >>>>>> institute an investigation into the number resources held by the >>>>>> invalid POC and if they did locate the actual holder, they would >>>>>> give that holder 30 days to supply valid POC contact info for whois >>>>>> that would replace the bogus invalid contact info. >>>>>> >>>>>> If the holder wasn't forthcoming, ARIN will delete the POC. >>>>>> Resources that have no POC's justifying their existence are then >>>>>> freed up >>>> for reassignment. >>>>>> >>>>>> If ARIN is not doing this, then it is completely understandable >>>>>> that you would be getting large numbers of phone calls from people >>>>>> annoyed that their email addresses are still in whois. >>>>>> >>>>>> So, ARIN can start doing this and thereby make the people happy who >>>>>> are complaining, and at the same time, freeing up resources that >>>>>> are held by stale or bogus POC data. >>>>>> >>>>>> You said "indirect resource registration records" >>>>>> >>>>>> What exactly is that? >>>>>> >>>>>> In my opinion, ANY POC that is in whois that is associated in any >>>>>> way with an organization or individual who has IP addresses, and is >>>>>> being used as justification for holding resources, must remain in >>>>>> the validation >>>> list. >>>>>> >>>>>> It seems quite obvious and apparent that POCs that ARIN has judged >>>>>> to be invalid, and is in the process of investigating, would be >>>>>> calling and complaining. In general people who are doing things >>>>>> they shouldn't be doing, don't like to be investigated would >>>>>> certainly would >>>> complain. >>>>>> That can be solved easily by deleting their records and thereby >>>>>> freeing up resources. Then you don't contact them again and the >>>>>> community gets back the IP addressing they have held. >>>>>> >>>>>> Does not a POC that is being contacted by ARIN have the right to >>>>>> have their information deleted? If they are calling in and >>>>>> complaining that their records are in there, they obviously want them >> removed. >>>>>> So, ARIN can remove them and stop bothering them. >>>>>> >>>>>> You need to define the difference between "indirect resource >>>>>> registration records" and "associated with an active directly >>>>>> registered >>>> number resource" >>>>>> before anyone can really make a judgement on this policy proposal >>>> change. >>>>>> >>>>>> It just seems very simple to me. If they are a POC they are there >>>>>> because their existence is justifying some IP address holding in >>>>>> some way, there is some connection. If their POC is no longer >>>>>> justifying an IP address holding and there is no connection >>>>>> whatsoever to an IP address holding, then take their POC out and >>>>>> doing so will automatically >>>> quit contacting them. >>>>>> >>>>>> Ted >>>>>> >>>>>> On 4/13/2015 11:11 AM, David Huberman wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Richard Jimmerson's Policy Experience Report indicated that 50% of >>>>>>> the >>>>>> phone calls that RSD receives are about POC validation, and that >>>>>> they receive many angry emails and calls from POCs who are only >>>>>> associated with indirect resource registration records. In >>>>>> response, I offer the following change to the NRPM : >>>>>>> >>>>>>> >>>>>>> Existing 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. >>>>>>> >>>>>>> >>>>>>> I propose we make the first sentence read: >>>>>>> >>>>>>> "During ARIN's annual Whois POC validation, an email will be sent >>>>>>> to every >>>>>> POC in the Whois database that is associated with an active >>>>>> directly registered number resource." >>>>>>> >>>>>>> Thoughts? >>>>>>> David >>>>>>> >>>>>>> David R Huberman >>>>>>> Principal, Global IP Addressing >>>>>>> Microsoft Corporation >>>>>>> >>>>>>> _______________________________________________ >>>>>>> PPML >>>>>>> You are receiving this message because you are subscribed to the >>>>>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>>>> Please contact info at arin.net if you experience any issues. >>>>>> _______________________________________________ >>>>>> PPML >>>>>> You are receiving this message because you are subscribed to the >>>>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>>> Please contact info at arin.net if you experience any issues. >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to the >>>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From micah at riseup.net Wed Apr 15 12:26:09 2015 From: micah at riseup.net (micah anderson) Date: Wed, 15 Apr 2015 12:26:09 -0400 Subject: [arin-ppml] Equality in address space assignment In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12017A8CEA49@ENI-MAIL.eclipse-networks.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12017A8CEA49@ENI-MAIL.eclipse-networks.com> Message-ID: <87fv81l5ni.fsf@muck.riseup.net> Steven Ryerse writes: > That kind of thinking is why ARIN's policies are so unfair to small > Orgs. When a small Org with no IP resources applies for a small block > and get denied, they not only get shut out of resources but they get > shut out of participating in this Community and voting for AC & Board > posts. Even if you manage as a small org to get a small block and get voting rights for AC & Board posts, most small organizations can't afford the resources to allocate someone to follow this list and the process, and so are effectively shut out, even when they have the ability to vote. As someone who is part of a small org, with a very small budget, who did manage to get a small block, and work with other small organizations who have nothing more than a /24, I speak from experience and from talking to those other organizations. All of them said they were subscribed to arin-ppml and then the firehose opened, and the list was put in a folder never to be opened again. In fact the only reason I am replying to this message is because my mail filter seems to have failed on how this list was CC'd, so it came to my inbox :) I think that the voting structure needs to be disentangled from the policy wrangling discussions, and a ultra-low volume list is used to send out a call for votes with all the relevant information for voting. I'm sure someone is going to say that this exists already, but if it does, I have no idea. >The deck is stacked against us small guys and this needs to > change. My Prop 2014-18 would have been the first very small step > towards changing that but of course the bigger guys who have resources > and can participate in this community keep the small guys out. My two > cents!! two cents means a lot from us small guys, where every penny counts. micah From bcornett at servlet.com Wed Apr 15 12:33:27 2015 From: bcornett at servlet.com (Bruce Cornett) Date: Wed, 15 Apr 2015 12:33:27 -0400 Subject: [arin-ppml] Equality in address space assignment In-Reply-To: References: Message-ID: <552E92D7.5050204@servlet.com> Agreed. On 04/15/2015 12:00 PM, David Huberman wrote: > Jimmy, > > Thank you for the well thought out counter argument. I agree with a lot of what you say. You've outlined what I think is the primary thinking behind conservation-based allocation practices that ARIN policy has been based on for 18 years now. > > The problem I think I have is the results of those practices. > 1) Lock-in by large providers > 2) Conservation itself is a red herring, and has been for more than a decade. 80-90% of the addresses go to 10 companies. That leaves tens of thousands of networks using just 10-20% of the addresses. This math has been shown many times on PPML in the past. > > Routing table growth is no longer mathematically valid, in my opinion. We are just under 600,000 routes. There are only 40,000 ASes or so (right?) in a typical DFZ. Even a doubling of that would have no discernable effect on routing. If youre running a catalyst 5xxx, it's time to upgrade. > > Finally, I respect the RIPE and APNIC model of addressing: everyone plays on a level field to start with. You get a block, and try and grow your business/network. At ARIN, this "you must be THIS tall" inherently favors the large ISPs and cablecos who dominate ARIN policy making (and have since the beginning), which results in lock-in, etc etc. > > Just my opinion. My original post was made in frustration when large ISPs got to the mic at ARIN35 decrying that removing needs-basis for small transfers was unfair. Such hypocrisy (especially from those who already bought a /8!!!) is a sore topic for me. I will continue to fight for the little guy, borne of my 10 years working with them every day at ARIN. The big guys don't need the help. > > Thanks for listening, > David > > David R Huberman > Principal, Global IP Addressing > Microsoft Corporation > >> -----Original Message----- >> From: Jimmy Hess [mailto:mysidia at gmail.com] >> Sent: Tuesday, April 14, 2015 4:24 PM >> To: David Huberman >> Cc: ARIN PPML (ppml at arin.net) >> Subject: Re: [arin-ppml] Equality in address space assignment >> >> On Tue, Apr 14, 2015 at 4:34 PM, David Huberman >> wrote: >> >>> How is RIPE and APNIC?s policy unfair, but ARIN?s policy of ?you must >>> be THIS large a network to participate? fair? >>> What is the technical basis for not allowing small networks to get PI space? >> >> It's unfair, because non first time requestors have to hold resources, And >> they have to show efficient utilization of existing resources. >> >> "All first time requestors can get a /24" is essentially saying.... >> >> "We don't care if you waste 253 IP addresses, because your network design >> only required a /29." >> >> >> Doesn't require a technical basis. It is undesirable for any >> networks to have PI >> space, as it grows the routing tables, but >> >> This is a good non-technical resource management choice. It makes sense to >> require small networks with no direct allocation yet to meet criteria to show >> that they have reached a size milestone of proven business and growth >> projections with >> sufficient confidence to show that the allocation of a /24 is needed, >> and absolutely necessary to meet short term or immediate needs. >> >> Consider that there are many more small networks than large ones. >> There are many very small networks which might have a proven case for >> 10 IP addresses and a claim to need 200 "soon". >> >> It makes no sense that they can get a /24 for ARIN, and then stop growing, >> and hold onto >> that entire /24 forever; As long as the small organization exists, >> the allocation of the /24 >> is an irrevocable choice, with no incentive for the small org. to renumber >> back to PA space and release unnecessary resources. >> >> On the other hand, if the small org obtains a /24 of PA space instead, or a >> /28 of PA space, Either less IP space will be wasted by the small network, >> Or the ISP holding the PA block can reclaim addresses at a later date. >> >> Furthermore, for the larger networks, there should be a small number of >> those, so there is less possible waste. >> >> It would also be much better for the public for these resources to go to an >> ISP as PA space, where the /24 could be divided up more fairly according to >> actual need; with fewer global routing table entries. >> >> Operators already managing large PA address space are also more likely to >> have mature organizational frameworks to ensure the right internal address >> management practices are in place to avoid wasting or unnecessarily utilizing >> scarce IPs. >> >> To the 50000 or so would-be first time requestors who might like a /24; if >> there was no previous resource requirement.... >> they might very well wind up wasting 75% of their allocation by only using >> 25% of the IPs. >> >> >>> Decades of RIPE and APNIC policy didn?t break the internet. >> >> Non Sequitur. >> Decades of ARIN policy didn't break the internet, either. >> >> >>> David >> -- >> -JH > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From rudi.daniel at gmail.com Wed Apr 15 12:44:33 2015 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Wed, 15 Apr 2015 12:44:33 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 118, Issue 19 In-Reply-To: References: Message-ID: Jimmy I would have to +1 David here; wholeheartedly Sir. RD On Apr 15, 2015 12:23 PM, wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Equality in address space assignment (David Huberman) > 2. Re: Policy idea: POC Validation (David Huberman) > 3. Re: Policy idea: POC Validation (Ted Mittelstaedt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 Apr 2015 16:00:54 +0000 > From: David Huberman > To: Jimmy Hess > Cc: "ARIN PPML \(ppml at arin.net\)" > Subject: Re: [arin-ppml] Equality in address space assignment > Message-ID: > < > DM2PR03MB398CF9A4E3D8DDC11B511ED9BE50 at DM2PR03MB398.namprd03.prod.outlook.com > > > > Content-Type: text/plain; charset="utf-8" > > Jimmy, > > Thank you for the well thought out counter argument. I agree with a lot > of what you say. You've outlined what I think is the primary thinking > behind conservation-based allocation practices that ARIN policy has been > based on for 18 years now. > > The problem I think I have is the results of those practices. > 1) Lock-in by large providers > 2) Conservation itself is a red herring, and has been for more than a > decade. 80-90% of the addresses go to 10 companies. That leaves tens of > thousands of networks using just 10-20% of the addresses. This math has > been shown many times on PPML in the past. > > Routing table growth is no longer mathematically valid, in my opinion. We > are just under 600,000 routes. There are only 40,000 ASes or so (right?) > in a typical DFZ. Even a doubling of that would have no discernable effect > on routing. If youre running a catalyst 5xxx, it's time to upgrade. > > Finally, I respect the RIPE and APNIC model of addressing: everyone plays > on a level field to start with. You get a block, and try and grow your > business/network. At ARIN, this "you must be THIS tall" inherently favors > the large ISPs and cablecos who dominate ARIN policy making (and have since > the beginning), which results in lock-in, etc etc. > > Just my opinion. My original post was made in frustration when large ISPs > got to the mic at ARIN35 decrying that removing needs-basis for small > transfers was unfair. Such hypocrisy (especially from those who already > bought a /8!!!) is a sore topic for me. I will continue to fight for the > little guy, borne of my 10 years working with them every day at ARIN. The > big guys don't need the help. > > Thanks for listening, > David > > David R Huberman > Principal, Global IP Addressing > Microsoft Corporation > > > -----Original Message----- > > From: Jimmy Hess [mailto:mysidia at gmail.com] > > Sent: Tuesday, April 14, 2015 4:24 PM > > To: David Huberman > > Cc: ARIN PPML (ppml at arin.net) > > Subject: Re: [arin-ppml] Equality in address space assignment > > > > On Tue, Apr 14, 2015 at 4:34 PM, David Huberman > > wrote: > > > > > How is RIPE and APNIC?s policy unfair, but ARIN?s policy of ?you must > > > be THIS large a network to participate? fair? > > > What is the technical basis for not allowing small networks to get PI > space? > > > > It's unfair, because non first time requestors have to hold resources, > And > > they have to show efficient utilization of existing resources. > > > > "All first time requestors can get a /24" is essentially saying.... > > > > "We don't care if you waste 253 IP addresses, because your network > design > > only required a /29." > > > > > > Doesn't require a technical basis. It is undesirable for any > > networks to have PI > > space, as it grows the routing tables, but > > > > This is a good non-technical resource management choice. It makes sense > to > > require small networks with no direct allocation yet to meet criteria to > show > > that they have reached a size milestone of proven business and growth > > projections with > > sufficient confidence to show that the allocation of a /24 is needed, > > and absolutely necessary to meet short term or immediate needs. > > > > Consider that there are many more small networks than large ones. > > There are many very small networks which might have a proven case for > > 10 IP addresses and a claim to need 200 "soon". > > > > It makes no sense that they can get a /24 for ARIN, and then stop > growing, > > and hold onto > > that entire /24 forever; As long as the small organization exists, > > the allocation of the /24 > > is an irrevocable choice, with no incentive for the small org. to > renumber > > back to PA space and release unnecessary resources. > > > > On the other hand, if the small org obtains a /24 of PA space > instead, or a > > /28 of PA space, Either less IP space will be wasted by the small > network, > > Or the ISP holding the PA block can reclaim addresses at a later > date. > > > > Furthermore, for the larger networks, there should be a small number of > > those, so there is less possible waste. > > > > It would also be much better for the public for these resources to go to > an > > ISP as PA space, where the /24 could be divided up more fairly according > to > > actual need; with fewer global routing table entries. > > > > Operators already managing large PA address space are also more likely > to > > have mature organizational frameworks to ensure the right internal > address > > management practices are in place to avoid wasting or unnecessarily > utilizing > > scarce IPs. > > > > To the 50000 or so would-be first time requestors who might like a > /24; if > > there was no previous resource requirement.... > > they might very well wind up wasting 75% of their allocation by only > using > > 25% of the IPs. > > > > > > > Decades of RIPE and APNIC policy didn?t break the internet. > > > > Non Sequitur. > > Decades of ARIN policy didn't break the internet, either. > > > > > > > David > > -- > > -JH > > ------------------------------ > > Message: 2 > Date: Wed, 15 Apr 2015 16:05:51 +0000 > From: David Huberman > To: Owen DeLong > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Policy idea: POC Validation > Message-ID: > < > DM2PR03MB398C0786D9D0BC519E878649BE50 at DM2PR03MB398.namprd03.prod.outlook.com > > > > Content-Type: text/plain; charset="utf-8" > > Hi Owen, > > I think the problem is the scale to which the scenario I outlined is > common. It's in the tens of thousands of records (probably over 100,000 if > I had to guess, based on my knowledge of ARIN's database size). So let's > get data. > > ARIN STAFF: How many POCs are invalid that are only associated (directly > or via the OrgID) with indirectly associated number registrations and with > no number registrations at all? > > Thanks, > David > > David R Huberman > Principal, Global IP Addressing > Microsoft Corporation > > > -----Original Message----- > > From: Owen DeLong [mailto:owen at delong.com] > > Sent: Tuesday, April 14, 2015 10:09 AM > > To: David Huberman > > Cc: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy idea: POC Validation > > > > Seems to me that the problem in this case is not ARIN, it is the way your > > particular service provider works. > > > > Choices include: > > > > 1. Work with your service provider to change their process. > > 2. Change service providers. > > > > What am I missing? > > > > Owen > > > > > On Apr 13, 2015, at 1:36 PM, David Huberman > > wrote: > > > > > > Hi Owen, > > > > > > I can give you a great example that's timely. My company ordered some > > circuits from ISP X recently. ISP X has a policy that they only do > REASSIGN > > DETAIL. They registered the reassignments with POC data that points to a > > network engineer who ordered the circuit. It's the way their system > works. > > > > > > The engineer emailed me very angry that her information was in ARIN > > Whois - and in fact, in Whois many times with multiple iterations of her > POC - > > - POC1, POC2, POC3, POC4, POC5, etc all with the same information > pointing > > to her. It even included her direct phone number, which happened to be > > her mobile phone, and she was upset about that. > > > > > > Luckily for her, she knew who ARIN was, she knew who the hostmaster > > was in our company (me!), and I knew how to get it fixed. > > > > > > BTW, in order to get it fixed, I chose to do what I thought was the > right > > thing: I asked ARIN to "consolidate" the reassignment records into my > main > > OrgID. ARIN *would not do it* without the explicit written permission > of ISP > > X. (Luckily for us, ISP X consented.) > > > > > > Hope that helps, > > > David > > > > > > David R Huberman > > > Principal, Global IP Addressing > > > Microsoft Corporation > > > > > >> -----Original Message----- > > >> From: Owen DeLong [mailto:owen at delong.com] > > >> Sent: Monday, April 13, 2015 1:30 PM > > >> To: David Huberman > > >> Cc: arin-ppml at arin.net > > >> Subject: Re: [arin-ppml] Policy idea: POC Validation > > >> > > >> David, > > >> > > >> I don?t see the angry phone call as the problem. I see it as a > symptom. > > >> > > >> The problem is the incorrect registrations. I want us to find out > > >> about those incorrect registrations and resolve them. I certainly > > >> don?t want to simply remove the symptom (angry phone call) by masking > > >> the problem (incorrect registration). > > >> > > >> Owen > > >> > > >>> On Apr 13, 2015, at 1:23 PM, David Huberman > > >> wrote: > > >>> > > >>> Hi Ted, > > >>> > > >>> Thanks for the reply. > > >>> > > >>> By "indirect resource registration records", I meant reassignment > > records. > > >> ISP has a /17. They reassign a /28 to a customer, and decide to put > > >> customer POC information on it. That POC only exists because of the > /28 - > > it isn't a POC > > >> for any directly registered allocation, assignment, or AS number. > These > > are > > >> the POCs who are complaining en masse to ARIN after receiving POC > > >> Validation communications. My reasoning for removing POC validation > > >> for these types of POCs is that ISPs have the option to not register > > >> POCs at all -- they can choose "REASSIGN SIMPLE" as a path for > > >> registering SWIP information, and that doesn't have any POC info. > > >> Secondly, I'm not convinced there's a significant value in up-to-date > > >> POC information for reassigned numbers. In the end, the ISP (the > > >> direct registrant) is the party responsible for the IP addresses and > > >> use. (And in 90%+ of cases, the ISP is responsible for routing in > > >> the DFZ, too. For the cases where a reassigned block is announced by > > >> th > > >>> e customer, there's a customer ASN easily found in the routing > > >>> tables, and that contact information is more germane than a SWIP > > >>> record.) > > >>> > > >>> I hope that's clearer. > > >>> > > >>> David > > >>> > > >>> David R Huberman > > >>> Principal, Global IP Addressing > > >>> Microsoft Corporation > > >>> > > >>>> -----Original Message----- > > >>>> From: arin-ppml-bounces at arin.net > > >>>> [mailto:arin-ppml-bounces at arin.net] > > >>>> On Behalf Of Ted Mittelstaedt > > >>>> Sent: Monday, April 13, 2015 12:12 PM > > >>>> To: arin-ppml at arin.net > > >>>> Subject: Re: [arin-ppml] Policy idea: POC Validation > > >>>> > > >>>> > > >>>> As one of the initiators of this policy I must state that none of > > >>>> us who worked on this ever assumed the POC Validation Policy would > > >>>> be the END of the process. > > >>>> > > >>>> The idea was that when a POC was marked invalid, that ARIN would > > >>>> institute an investigation into the number resources held by the > > >>>> invalid POC and if they did locate the actual holder, they would > > >>>> give that holder 30 days to supply valid POC contact info for whois > > >>>> that would replace the bogus invalid contact info. > > >>>> > > >>>> If the holder wasn't forthcoming, ARIN will delete the POC. > > >>>> Resources that have no POC's justifying their existence are then > > >>>> freed up > > >> for reassignment. > > >>>> > > >>>> If ARIN is not doing this, then it is completely understandable > > >>>> that you would be getting large numbers of phone calls from people > > >>>> annoyed that their email addresses are still in whois. > > >>>> > > >>>> So, ARIN can start doing this and thereby make the people happy who > > >>>> are complaining, and at the same time, freeing up resources that > > >>>> are held by stale or bogus POC data. > > >>>> > > >>>> You said "indirect resource registration records" > > >>>> > > >>>> What exactly is that? > > >>>> > > >>>> In my opinion, ANY POC that is in whois that is associated in any > > >>>> way with an organization or individual who has IP addresses, and is > > >>>> being used as justification for holding resources, must remain in > > >>>> the validation > > >> list. > > >>>> > > >>>> It seems quite obvious and apparent that POCs that ARIN has judged > > >>>> to be invalid, and is in the process of investigating, would be > > >>>> calling and complaining. In general people who are doing things > > >>>> they shouldn't be doing, don't like to be investigated would > > >>>> certainly would > > >> complain. > > >>>> That can be solved easily by deleting their records and thereby > > >>>> freeing up resources. Then you don't contact them again and the > > >>>> community gets back the IP addressing they have held. > > >>>> > > >>>> Does not a POC that is being contacted by ARIN have the right to > > >>>> have their information deleted? If they are calling in and > > >>>> complaining that their records are in there, they obviously want > them > > removed. > > >>>> So, ARIN can remove them and stop bothering them. > > >>>> > > >>>> You need to define the difference between "indirect resource > > >>>> registration records" and "associated with an active directly > > >>>> registered > > >> number resource" > > >>>> before anyone can really make a judgement on this policy proposal > > >> change. > > >>>> > > >>>> It just seems very simple to me. If they are a POC they are there > > >>>> because their existence is justifying some IP address holding in > > >>>> some way, there is some connection. If their POC is no longer > > >>>> justifying an IP address holding and there is no connection > > >>>> whatsoever to an IP address holding, then take their POC out and > > >>>> doing so will automatically > > >> quit contacting them. > > >>>> > > >>>> Ted > > >>>> > > >>>> On 4/13/2015 11:11 AM, David Huberman wrote: > > >>>>> Hello, > > >>>>> > > >>>>> Richard Jimmerson's Policy Experience Report indicated that 50% of > > >>>>> the > > >>>> phone calls that RSD receives are about POC validation, and that > > >>>> they receive many angry emails and calls from POCs who are only > > >>>> associated with indirect resource registration records. In > > >>>> response, I offer the following change to the NRPM : > > >>>>> > > >>>>> > > >>>>> Existing 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. > > >>>>> > > >>>>> > > >>>>> I propose we make the first sentence read: > > >>>>> > > >>>>> "During ARIN's annual Whois POC validation, an email will be sent > > >>>>> to every > > >>>> POC in the Whois database that is associated with an active > > >>>> directly registered number resource." > > >>>>> > > >>>>> Thoughts? > > >>>>> David > > >>>>> > > >>>>> David R Huberman > > >>>>> Principal, Global IP Addressing > > >>>>> Microsoft Corporation > > >>>>> > > >>>>> _______________________________________________ > > >>>>> PPML > > >>>>> You are receiving this message because you are subscribed to the > > >>>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > >>>>> Unsubscribe or manage your mailing list subscription at: > > >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml > > >>>>> Please contact info at arin.net if you experience any issues. > > >>>> _______________________________________________ > > >>>> PPML > > >>>> You are receiving this message because you are subscribed to the > > >>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > >>>> Unsubscribe or manage your mailing list subscription at: > > >>>> http://lists.arin.net/mailman/listinfo/arin-ppml > > >>>> Please contact info at arin.net if you experience any issues. > > >>> _______________________________________________ > > >>> PPML > > >>> You are receiving this message because you are subscribed to the > > >>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > >>> Unsubscribe or manage your mailing list subscription at: > > >>> http://lists.arin.net/mailman/listinfo/arin-ppml > > >>> Please contact info at arin.net if you experience any issues. > > > > > > ------------------------------ > > Message: 3 > Date: Wed, 15 Apr 2015 09:22:39 -0700 > From: Ted Mittelstaedt > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy idea: POC Validation > Message-ID: <552E904F.7020909 at ipinc.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > I like this solution a lot! It will, of course, result in the > offending ISPs POCs being spammed to death by their own automated > systems which auto-fill the SWIPs with information they seem to pull > out of thin air. > > But sacrifices have to be made! > > Ted > > On 4/14/2015 11:08 AM, William Herrin wrote: > > On Mon, Apr 13, 2015 at 5:31 PM, Martin Hannigan > wrote: > >> Did ARIN/you consider a consultation instead and simply adding a NACK > button > >> to the confirmation and reassigning the block back to the ISP in > question or > >> re designate to the online account owner? > > > > Hi Marty, > > > > That's a fantastic idea. But instead of deregistering the block (which > > would add chaos to the process for the right-org-wrong-POC case) do > > two things: > > > > 1. Feed the fact of the NACK back to the ISP with a message that the > > POC reports a registration mistake (requests contact for correction) > > and a gentle reminder that they are asked to publish accurate records > > as a condition of retaining allocations. Mistakes will be made. How > > will the folks who made the mistake find out if they don't get any > > feedback? > > > > 2. Use the data to build a stochastic model that separates routine > > bookkeeping error from orgs who are more on the negligence/fraud end > > of SWIP management. > > > > Regards, > > Bill Herrin > > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 118, Issue 19 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at tknow.com Wed Apr 15 13:05:17 2015 From: bill at tknow.com (Bill Buhler) Date: Wed, 15 Apr 2015 17:05:17 +0000 Subject: [arin-ppml] Equality in address space assignment In-Reply-To: References: Message-ID: <8e8bc33b57b040c1a35cff9504df0d15@TK-Ex13.ad.tknow.com> I have to agree with David +1 -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: Wednesday, April 15, 2015 10:01 AM To: Jimmy Hess Cc: ARIN PPML (ppml at arin.net) Subject: Re: [arin-ppml] Equality in address space assignment Jimmy, Thank you for the well thought out counter argument. I agree with a lot of what you say. You've outlined what I think is the primary thinking behind conservation-based allocation practices that ARIN policy has been based on for 18 years now. The problem I think I have is the results of those practices. 1) Lock-in by large providers 2) Conservation itself is a red herring, and has been for more than a decade. 80-90% of the addresses go to 10 companies. That leaves tens of thousands of networks using just 10-20% of the addresses. This math has been shown many times on PPML in the past. Routing table growth is no longer mathematically valid, in my opinion. We are just under 600,000 routes. There are only 40,000 ASes or so (right?) in a typical DFZ. Even a doubling of that would have no discernable effect on routing. If youre running a catalyst 5xxx, it's time to upgrade. Finally, I respect the RIPE and APNIC model of addressing: everyone plays on a level field to start with. You get a block, and try and grow your business/network. At ARIN, this "you must be THIS tall" inherently favors the large ISPs and cablecos who dominate ARIN policy making (and have since the beginning), which results in lock-in, etc etc. Just my opinion. My original post was made in frustration when large ISPs got to the mic at ARIN35 decrying that removing needs-basis for small transfers was unfair. Such hypocrisy (especially from those who already bought a /8!!!) is a sore topic for me. I will continue to fight for the little guy, borne of my 10 years working with them every day at ARIN. The big guys don't need the help. Thanks for listening, David David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: Jimmy Hess [mailto:mysidia at gmail.com] > Sent: Tuesday, April 14, 2015 4:24 PM > To: David Huberman > Cc: ARIN PPML (ppml at arin.net) > Subject: Re: [arin-ppml] Equality in address space assignment > > On Tue, Apr 14, 2015 at 4:34 PM, David Huberman > wrote: > > > How is RIPE and APNIC?s policy unfair, but ARIN?s policy of ?you > > must be THIS large a network to participate? fair? > > What is the technical basis for not allowing small networks to get PI space? > > It's unfair, because non first time requestors have to hold resources, > And they have to show efficient utilization of existing resources. > > "All first time requestors can get a /24" is essentially saying.... > > "We don't care if you waste 253 IP addresses, because your network > design only required a /29." > > > Doesn't require a technical basis. It is undesirable for any > networks to have PI > space, as it grows the routing tables, but > > This is a good non-technical resource management choice. It makes > sense to require small networks with no direct allocation yet to meet > criteria to show that they have reached a size milestone of proven > business and growth projections with > sufficient confidence to show that the allocation of a /24 is needed, > and absolutely necessary to meet short term or immediate needs. > > Consider that there are many more small networks than large ones. > There are many very small networks which might have a proven case for > 10 IP addresses and a claim to need 200 "soon". > > It makes no sense that they can get a /24 for ARIN, and then stop > growing, and hold onto > that entire /24 forever; As long as the small organization exists, > the allocation of the /24 > is an irrevocable choice, with no incentive for the small org. to renumber > back to PA space and release unnecessary resources. > > On the other hand, if the small org obtains a /24 of PA space > instead, or a > /28 of PA space, Either less IP space will be wasted by the small network, > Or the ISP holding the PA block can reclaim addresses at a later date. > > Furthermore, for the larger networks, there should be a small number > of those, so there is less possible waste. > > It would also be much better for the public for these resources to go > to an ISP as PA space, where the /24 could be divided up more fairly > according to actual need; with fewer global routing table entries. > > Operators already managing large PA address space are also more > likely to have mature organizational frameworks to ensure the right > internal address management practices are in place to avoid wasting > or unnecessarily utilizing scarce IPs. > > To the 50000 or so would-be first time requestors who might like a > /24; if there was no previous resource requirement.... > they might very well wind up wasting 75% of their allocation by only > using 25% of the IPs. > > > > Decades of RIPE and APNIC policy didn?t break the internet. > > Non Sequitur. > Decades of ARIN policy didn't break the internet, either. > > > > David > -- > -JH _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From mysidia at gmail.com Wed Apr 15 20:09:12 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 15 Apr 2015 19:09:12 -0500 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: On Tue, Apr 14, 2015 at 1:08 PM, William Herrin wrote: In addition to the 'annual NACK' I would suggest that there always be an *initial POC verification* that needs to be confirmed by clicking a link or going through the same process within a couple weeks of the POC initially being created, And also after any change of E-mail address. 1 Year later (during the next annual POC verification) should not be the first time that any e-mail address receives an annual POC validation request from ARIN. The introductory e-mail should remind the direct or indirect contact That they will receive an e-mail once per year that they need to confirm, etc. > That's a fantastic idea. But instead of deregistering the block (which > would add chaos to the process for the right-org-wrong-POC case) do > two things: > > 1. Feed the fact of the NACK back to the ISP with a message that the > POC reports a registration mistake (requests contact for correction) -- -JH From jschiller at google.com Wed Apr 15 20:28:29 2015 From: jschiller at google.com (Jason Schiller) Date: Wed, 15 Apr 2015 20:28:29 -0400 Subject: [arin-ppml] Equality in address space assignment In-Reply-To: References: Message-ID: On Tue, Apr 14, 2015 at 5:34 PM, David Huberman < David.Huberman at microsoft.com> wrote: > So I ask: > > How is RIPE and APNIC?s policy unfair, but ARIN?s policy of ?you must be > THIS large a network to participate? fair? > > > When you say "you must be THIS large a network to participate" you are talking about networks that are smaller than 61 hosts (plus a router, network address and broadcast address), and also don't have a plan to have a total of 123 hosts in one year. (the numbers go down a bit if you have a reason to need more subnets). I ask for all posters that reference this policy being unfair to small networks, to disclose if they have less than 61 hosts, or cannot meet a plan for 123 hosts. This bar was intended to prevent anyone who wanted their own address space from getting it and routing it, and contributing to the global routing table. Routing table size IS a real concern, even with current hardware. (and it is not just 572K IPv4 routes and the 24K IPv6 which cost between 1.9 and 2.2 times as much space, but also all of the internal routes that large networks are nice enough to aggregate for everyone, and the number of routes as a function of your architecture and peering locations) How much lower of a bar would you suggest? Striking the 61 hosts now and leaving a promise of 123 or more in a year's time? Would you want to lower it 29 hosts now or 13 hosts? ___Jason On Tue, Apr 14, 2015 at 5:34 PM, David Huberman < David.Huberman at microsoft.com> wrote: > RIPE and APNIC policy HAVE ALWAYS ALLOWED all first-time requestors to > be an LIR and get address space directly from the registry. In fact, for > more than a decade, that size was defaulted to a /20. It is smaller now (a > /22 I believe). Then to get more space, you show you efficiently utilized > what you have. > > > > At the mics at ARIN 35 just today, the large ISPs and Cablecos got up to > the mic and said a policy which allows small networks to get a /24 just by > asking for it is unfair. > > > > So I ask: > > How is RIPE and APNIC?s policy unfair, but ARIN?s policy of ?you must be > THIS large a network to participate? fair? > > > > What is the technical basis for not allowing small networks to get PI > space? > > > > Decades of RIPE and APNIC policy didn?t break the internet. > > > > David > > > > *David R Huberman* > Principal, Global IP Addressing > > Microsoft Corporation > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 athompso at athompso.net Wed Apr 15 20:51:14 2015 From: athompso at athompso.net (Adam Thompson) Date: Wed, 15 Apr 2015 19:51:14 -0500 Subject: [arin-ppml] Equality in address space assignment In-Reply-To: References: Message-ID: <552F0782.40700@athompso.net> There's a difference between "number of hosts" and "number of public IP addresses needed". I've had a number of clients in the 1k-10k IP hosts category who only needed a handful of, portable, public IPv4 addresses; everything else is internal use or NAT'd. The solution isn't too hard, you can artificially use up ~127 IP addresses pretty easily, and avoid (technically) lying to ARIN, but it's silly. But for companies that aren't willing to play games like that (and there are quite a few, surprisingly), yeah, the "you must be THIS tall" thing is a problem. The related issue is when connecting to an IX, you need an AS. To get an AS, you need PI. To get PI, you need XXX utilization of an *already-ISP-delegated non-portable* /24. So effectively, ARIN *also* shuts out smaller companies from connecting to local IXs like MBIX (where I'm on the board). Yes, it can be worked around, but it's another hoop you have to jump through, and, usually in my experience, I see companies simply lying to ARIN to get around it. (And, yes, I'm well aware of private ASNs - those are simply not allowed at most IXPs, including MBIX.) I've been complaining about this since I realized that multi-homing was no longer sufficient justification to get IPv4 PI, but AS USUAL most people here didn't care about the [V]SMBs. Or maybe I didn't communicate clearly, but certainly no-one suggested that. In fact, my comments effectively vanished into a black hole, as expected. *I HAVE LESS THAN 61 HOSTS*. Even including VMs and hosted customers. Even including all the subnets, I would have been fine with a /25 and I could even have made do with a /26. (Admittedly, I didn't know that at the time.) And I'm multi-homed, and connected to the local IX. The ONLY reason I needed PI space was to successfully advertise it using BGP to multiple providers over a mix of public and private peering. And despite being the smallest of small networks, my - redundant - routers can handle roughly 40+ copies of the full routing table right now. So when I see companies the size of MCI, Google, Comcast, etc. whining about router memory exhaustion? I bit the bullet and sized my gear for multi-homed, multi-carrier IPv4+IPv6 including a hefty margin (like, 500%) for growth. Yes, I'm only running one set of border routers, not 1000, but that - to me - is an merely argument against the gigantic networks the US - and this mailing list - is full of. The lower bar I'd suggest? Anything. No bar at all. Let IPv4 run out completely, and then, maybe, my local ISPs will finally start thinking about supporting IPv6. Rather pissed off with this conversation and everyone who thinks small networks don't exist or don't matter, -Adam Thompson On 2015-04-15 07:28 PM, Jason Schiller wrote: > On Tue, Apr 14, 2015 at 5:34 PM, David > Huberman >wrote: > > So I ask: > > How is RIPE and APNIC?s policy unfair, but ARIN?s policy of ?you > must be THIS large a network to participate? fair? > > > When you say "you must be THIS large a network to participate" you are > talking about networks that are smaller than 61 hosts (plus a router, > network address and broadcast address), and also don't have a plan to > have a total of 123 hosts in one year. > > (the numbers go down a bit if you have a reason to need more subnets). > > I ask for all posters that reference this policy being unfair to small > networks, to disclose if they have less than 61 hosts, or cannot meet > a plan for 123 hosts. > > This bar was intended to prevent anyone who wanted their own address > space from getting it and routing it, and contributing to the global > routing table. > > Routing table size IS a real concern, even with current hardware. > > (and it is not just 572K IPv4 routes and the 24K IPv6 which cost > between 1.9 and 2.2 times as much space, but also all of the internal > routes that large networks are nice enough to aggregate for everyone, > and the number of routes as a function of your architecture and > peering locations) > > How much lower of a bar would you suggest? > > Striking the 61 hosts now and leaving a promise of 123 or more in a > year's time? > > Would you want to lower it 29 hosts now or 13 hosts? > > > ___Jason > > On Tue, Apr 14, 2015 at 5:34 PM, David Huberman > > > wrote: > > RIPE and APNIC policy HAVE ALWAYS ALLOWED all first-time > requestors to be an LIR and get address space directly from the > registry. In fact, for more than a decade, that size was > defaulted to a /20. It is smaller now (a /22 I believe). Then > to get more space, you show you efficiently utilized what you have. > > At the mics at ARIN 35 just today, the large ISPs and Cablecos got > up to the mic and said a policy which allows small networks to get > a /24 just by asking for it is unfair. > > So I ask: > > How is RIPE and APNIC?s policy unfair, but ARIN?s policy of ?you > must be THIS large a network to participate? fair? > > What is the technical basis for not allowing small networks to get > PI space? > > Decades of RIPE and APNIC policy didn?t break the internet. > > David > > *David R Huberman* > Principal, Global IP Addressing > > Microsoft Corporation > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage 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. -- -Adam Thompson athompso at athompso.net +1 (204) 291-7950 - cell +1 (204) 489-6515 - fax -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Thu Apr 16 01:01:05 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 15 Apr 2015 22:01:05 -0700 Subject: [arin-ppml] Equality in address space assignment In-Reply-To: References: Message-ID: On Wed, Apr 15, 2015 at 5:28 PM, Jason Schiller wrote: > On Tue, Apr 14, 2015 at 5:34 PM, David Huberman < > David.Huberman at microsoft.com> wrote: > >> So I ask: >> >> How is RIPE and APNIC's policy unfair, but ARIN's policy of "you must be >> THIS large a network to participate" fair? >> >> >> > > When you say "you must be THIS large a network to participate" you are > talking about networks that are smaller than 61 hosts (plus a router, > network address and broadcast address), and also don't have a plan to have > a total of 123 hosts in one year. > > (the numbers go down a bit if you have a reason to need more subnets). > > I ask for all posters that reference this policy being unfair to small > networks, to disclose if they have less than 61 hosts, or cannot meet a > plan for 123 hosts. > In the six digits plus range. I can meet the plan. > > This bar was intended to prevent anyone who wanted their own address space > from getting it and routing it, and contributing to the global routing > table. > Do we have pointers to the list archive to support that? I'd be interesting to see who proposed it, who supported it and the discussion. The AC has archives all the way back, IIRC. [ clip] Would you want to lower it 29 hosts now or 13 hosts? I think zero would work. What is the RIPE and other regions experience? And multi homing is fast becoming a relic, along with policies like this. [ Reminder, we're out of v4 ] Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From drc at virtualized.org Thu Apr 16 02:25:47 2015 From: drc at virtualized.org (David Conrad) Date: Wed, 15 Apr 2015 23:25:47 -0700 Subject: [arin-ppml] Equality in address space assignment In-Reply-To: References: Message-ID: <0B2A8BCF-DC67-4CBA-B0F9-7A5083FF6E9F@virtualized.org> Martin, > On Apr 15, 2015, at 10:01 PM, Martin Hannigan wrote: > This bar was intended to prevent anyone who wanted their own address space from getting it and routing it, and contributing to the global routing table. > > Do we have pointers to the list archive to support that? I'd be interesting to see who proposed it, who supported it and the discussion. The AC has archives all the way back, IIRC. IIUC, "this bar" pre-dated the AC (and ARIN). I believe InterNIC had a policy that they would only allocate address space if you could demonstrate you had efficiently utilized the (/20?) address space that had been given to you by your upstream provider. I remember discussions with Kim in which she was quite concerned (with reason) that if InterNIC were to allocate to all comers, the routers of the day (mid-90's) would fall over, resulting in prefix-length filters and other general unpleasantness (e.g., annoying Sean Doran). RIPE-NCC and APNIC, having a relatively smaller customer base (the telcos believed OSI was the One True Future, so there were only those weird academic and entrepreneur types that were looking at this TCP/IP thing), didn't really worry about blowing up the routing tables, rather they were primarily interested in driving increased penetration of that TCP/IP thing. This historic interlude brought to you by a very nice http://www.freemanwinery.com/wine/overview/2011-Russian-River-Valley-Pinot-Noir :) Regards, -drc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From owen at delong.com Thu Apr 16 13:53:42 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Apr 2015 10:53:42 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: > On Apr 15, 2015, at 5:09 PM, Jimmy Hess wrote: > > On Tue, Apr 14, 2015 at 1:08 PM, William Herrin wrote: > > > In addition to the 'annual NACK' I would suggest that there always be an > *initial POC verification* that needs to be confirmed by clicking a > link or going > through the same process within a couple weeks of the POC initially being > created, And also after any change of E-mail address. I really like the idea of a requirement for an ACK by the POC on POC creation. That should at least create an incentive to stop these records from being created by ISPs which will significantly reduce the problem space. Owen From gary.buhrmaster at gmail.com Thu Apr 16 14:20:22 2015 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 16 Apr 2015 18:20:22 +0000 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: On Thu, Apr 16, 2015 at 5:53 PM, Owen DeLong wrote: ..... > I really like the idea of a requirement for an ACK by the POC on POC creation. > > That should at least create an incentive to stop these records from being created > by ISPs which will significantly reduce the problem space. I actually think it is not the creation that is the issue, it is the assignment to a role. There should be a "Do you accept this " ACK requirement for the assignment is complete. No ACK, no assignment. I do understand that this would imply some changes to the process (i.e. engineering resources). From owen at delong.com Thu Apr 16 20:17:55 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Apr 2015 17:17:55 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: > On Apr 16, 2015, at 11:20 AM, Gary Buhrmaster wrote: > > On Thu, Apr 16, 2015 at 5:53 PM, Owen DeLong wrote: > ..... >> I really like the idea of a requirement for an ACK by the POC on POC creation. >> >> That should at least create an incentive to stop these records from being created >> by ISPs which will significantly reduce the problem space. > > I actually think it is not the creation that is the issue, it is the > assignment to a role. > > There should be a "Do you accept this " ACK requirement > for the assignment is complete. No ACK, no assignment. > > I do understand that this would imply some changes to the > process (i.e. engineering resources). I think both would have value. The primary complaints being expressed are providers creating massive numbers of POC records for the same individual, so letting the individual know a new POC record is being created is desirable. I think there is also value to letting someone know when their POC is added to a record. Owen From mysidia at gmail.com Thu Apr 16 20:44:57 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 16 Apr 2015 19:44:57 -0500 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: > There should be a "Do you accept this " ACK requirement >for the assignment is complete. No ACK, no assignment. An alternative would be: 1* Opt-in confirmation for destination e-mail address on create POC record / change e-mail address, before the POC details other than the Handle name appear in Whois. 2* Within 24 hours of assignment to a role, a FYI Notification e-mail message to affected POCs. Containing the list of Organizations (or Network objects) they have been added to. With a link in the FYI notification to open a 'quick trouble report' page, where the POC can object to one or more of the role additions. This should avoid a major change to the process for detailed reassignments Or org/network modifies. This should avoid spamming contacts with multiple requests for confirmations, when a contact needs to be added to multiple individual objects. -- -Jimmy From narten at us.ibm.com Fri Apr 17 00:53:02 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 17 Apr 2015 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201504170453.t3H4r2hi025302@rotala.raleigh.ibm.com> Total of 70 messages in the last 7 days. script run at: Fri Apr 17 00:53:02 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 12.86% | 9 | 19.10% | 201324 | mueller at syr.edu 14.29% | 10 | 10.26% | 108174 | david.huberman at microsoft.com 4.29% | 3 | 8.10% | 85398 | jcurran at arin.net 7.14% | 5 | 4.75% | 50049 | owen at delong.com 2.86% | 2 | 7.64% | 80484 | kevinb at thewire.ca 5.71% | 4 | 4.74% | 49927 | tedm at ipinc.net 7.14% | 5 | 3.29% | 34700 | michael at linuxmagic.com 5.71% | 4 | 2.78% | 29321 | mysidia at gmail.com 4.29% | 3 | 3.12% | 32841 | hannigan at gmail.com 1.43% | 1 | 5.12% | 53960 | rudi.daniel at gmail.com 4.29% | 3 | 1.81% | 19070 | bill at herrin.us 1.43% | 1 | 3.70% | 39040 | elvis at velea.eu 1.43% | 1 | 3.49% | 36805 | daniel_alexander at cable.comcast.com 2.86% | 2 | 1.93% | 20374 | scottleibrand at gmail.com 1.43% | 1 | 3.27% | 34502 | info at arin.net 1.43% | 1 | 2.23% | 23532 | athompso at athompso.net 1.43% | 1 | 1.84% | 19422 | andrea at ripe.net 1.43% | 1 | 1.68% | 17691 | lear at cisco.com 1.43% | 1 | 1.62% | 17115 | jschiller at google.com 1.43% | 1 | 1.11% | 11703 | drc at virtualized.org 1.43% | 1 | 1.11% | 11668 | bill at tknow.com 1.43% | 1 | 0.99% | 10450 | bcornett at servlet.com 1.43% | 1 | 0.92% | 9711 | sryerse at eclipse-networks.com 1.43% | 1 | 0.76% | 7959 | matthew at matthew.at 1.43% | 1 | 0.73% | 7701 | micah at riseup.net 1.43% | 1 | 0.71% | 7468 | jay at impulse.net 1.43% | 1 | 0.71% | 7440 | lee at dilkie.com 1.43% | 1 | 0.67% | 7076 | jlewis at lewis.org 1.43% | 1 | 0.61% | 6481 | narten at us.ibm.com 1.43% | 1 | 0.61% | 6378 | andrew.dul at quark.net 1.43% | 1 | 0.59% | 6260 | gary.buhrmaster at gmail.com --------+------+--------+----------+------------------------ 100.00% | 70 |100.00% | 1054024 | Total From owen at delong.com Fri Apr 17 14:24:30 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Apr 2015 11:24:30 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: Message-ID: <794E954F-5A55-49FB-9669-44E1EB90A95D@delong.com> I would consider this a workable solution. (Assuming annual validation is retained) Owen > On Apr 16, 2015, at 5:44 PM, Jimmy Hess wrote: > >> There should be a "Do you accept this " ACK requirement >> for the assignment is complete. No ACK, no assignment. > > An alternative would be: > 1* Opt-in confirmation for destination e-mail address on create POC > record / change e-mail address, > before the POC details other than the Handle name appear in Whois. > > 2* Within 24 hours of assignment to a role, a FYI Notification > e-mail message to affected POCs. > Containing the list of Organizations (or Network objects) they have > been added to. > > With a link in the FYI notification to open a 'quick trouble report' > page, where > the POC can object to one or more of the role additions. > > > This should avoid a major change to the process for detailed reassignments Or > org/network modifies. > > This should avoid spamming contacts with multiple requests for confirmations, > when a contact needs to be added to multiple individual objects. > > > -- > -Jimmy From owen at delong.com Fri Apr 17 18:13:08 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Apr 2015 15:13:08 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: <794E954F-5A55-49FB-9669-44E1EB90A95D@delong.com> References: <794E954F-5A55-49FB-9669-44E1EB90A95D@delong.com> Message-ID: <6D74C0D1-B5D4-4B12-A31C-70FD45DC0DBD@delong.com> Another thought I had on POC creation emails? What if in addition to the NACK button, there was a ?Consolidate with? (need better name) button where I could express that this is a duplicate POC creation and that I would like it quashed in favor of my existing POC record. The button would require you to authenticate with ARIN on-line and then present a page showing the new POC and a drop-down of the POCs for which you are authorized administration. You could choose one of those and ARIN would then do (essentially) s///g in the database. IIRC, ARIN On-line already has this functionality if you go into manage your POCs, so I think implementation should be fairly minor. Thoughts? Owen > On Apr 17, 2015, at 11:24 AM, Owen DeLong wrote: > > I would consider this a workable solution. > > (Assuming annual validation is retained) > > Owen > >> On Apr 16, 2015, at 5:44 PM, Jimmy Hess wrote: >> >>> There should be a "Do you accept this " ACK requirement >>> for the assignment is complete. No ACK, no assignment. >> >> An alternative would be: >> 1* Opt-in confirmation for destination e-mail address on create POC >> record / change e-mail address, >> before the POC details other than the Handle name appear in Whois. >> >> 2* Within 24 hours of assignment to a role, a FYI Notification >> e-mail message to affected POCs. >> Containing the list of Organizations (or Network objects) they have >> been added to. >> >> With a link in the FYI notification to open a 'quick trouble report' >> page, where >> the POC can object to one or more of the role additions. >> >> >> This should avoid a major change to the process for detailed reassignments Or >> org/network modifies. >> >> This should avoid spamming contacts with multiple requests for confirmations, >> when a contact needs to be added to multiple individual objects. >> >> >> -- >> -Jimmy > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 hannigan at gmail.com Fri Apr 17 18:23:04 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 17 Apr 2015 18:23:04 -0400 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: <6D74C0D1-B5D4-4B12-A31C-70FD45DC0DBD@delong.com> References: <794E954F-5A55-49FB-9669-44E1EB90A95D@delong.com> <6D74C0D1-B5D4-4B12-A31C-70FD45DC0DBD@delong.com> Message-ID: If I could simply consolidate everything into the POC I want and not POCs made up by others, I'd be a happy camper. On Fri, Apr 17, 2015 at 6:13 PM, Owen DeLong wrote: > Another thought I had on POC creation emails... > > What if in addition to the NACK button, there was a "Consolidate with" > (need better name) button where I could express that this is a duplicate > POC creation and that I would like it quashed in favor of my existing POC > record. The button would require you to authenticate with ARIN on-line and > then present a page showing the new POC and a drop-down of the POCs for > which you are authorized administration. You could choose one of those and > ARIN would then do (essentially) s///g in the database. > > IIRC, ARIN On-line already has this functionality if you go into manage > your POCs, so I think implementation should be fairly minor. > > Thoughts? > > Owen > > > On Apr 17, 2015, at 11:24 AM, Owen DeLong wrote: > > > > I would consider this a workable solution. > > > > (Assuming annual validation is retained) > > > > Owen > > > >> On Apr 16, 2015, at 5:44 PM, Jimmy Hess wrote: > >> > >>> There should be a "Do you accept this " ACK requirement > >>> for the assignment is complete. No ACK, no assignment. > >> > >> An alternative would be: > >> 1* Opt-in confirmation for destination e-mail address on create POC > >> record / change e-mail address, > >> before the POC details other than the Handle name appear in Whois. > >> > >> 2* Within 24 hours of assignment to a role, a FYI Notification > >> e-mail message to affected POCs. > >> Containing the list of Organizations (or Network objects) they have > >> been added to. > >> > >> With a link in the FYI notification to open a 'quick trouble report' > >> page, where > >> the POC can object to one or more of the role additions. > >> > >> > >> This should avoid a major change to the process for detailed > reassignments Or > >> org/network modifies. > >> > >> This should avoid spamming contacts with multiple requests for > confirmations, > >> when a contact needs to be added to multiple individual objects. > >> > >> > >> -- > >> -Jimmy > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage 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 gary.buhrmaster at gmail.com Fri Apr 17 18:52:16 2015 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 17 Apr 2015 22:52:16 +0000 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: <794E954F-5A55-49FB-9669-44E1EB90A95D@delong.com> <6D74C0D1-B5D4-4B12-A31C-70FD45DC0DBD@delong.com> Message-ID: On Fri, Apr 17, 2015 at 10:23 PM, Martin Hannigan wrote: > > > If I could simply consolidate everything into the POC I want and not POCs > made up by others, I'd be a happy camper. +1 to making Marty happy. More to the point, I would agree that while there are legitimate reasons to having multiple POC records that end up going to the same individual, it should be the choice of the individual to decide how many they have to deal with, not others. Gary From farmer at umn.edu Fri Apr 17 18:47:26 2015 From: farmer at umn.edu (David Farmer) Date: Fri, 17 Apr 2015 17:47:26 -0500 Subject: [arin-ppml] ASN requirements (was: Equality in address space assignment) In-Reply-To: <552F0782.40700@athompso.net> References: <552F0782.40700@athompso.net> Message-ID: <55318D7E.9070006@umn.edu> You talk about ASN requirements, in my opinion this is a completely separate issue that I want to explore with you. On 4/15/15 19:51 , Adam Thompson wrote: ... > The related issue is when connecting to an IX, you need an AS. To get > an AS, you need PI. To get PI, you need XXX utilization of an > *already-ISP-delegated non-portable* /24. So effectively, ARIN *also* > shuts out smaller companies from connecting to local IXs like MBIX > (where I'm on the board). Yes, it can be worked around, but it's > another hoop you have to jump through, and, usually in my experience, I > see companies simply lying to ARIN to get around it. > > (And, yes, I'm well aware of private ASNs - those are simply not allowed > at most IXPs, including MBIX.) No where in the requirements to get an ASN does it state that you need PI, IPv4 or IPv6. https://www.arin.net/policy/nrpm.html#five It says you need "A unique routing policy (its policy differs from its border gateway peers)" or "A multihomed site". If you plan to connect to a IX you by definition are "A multihomed site". If you are having policy issues getting an ASN to participate in an IX I would like to understand and fix any such issues. Now if you are saying that you can't get an IPv4 address block to announce at the IX, that is the previous discussion, but it's not an ASN issue. Thanks -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From tedm at ipinc.net Sat Apr 18 19:46:54 2015 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sat, 18 Apr 2015 16:46:54 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: References: <794E954F-5A55-49FB-9669-44E1EB90A95D@delong.com> <6D74C0D1-B5D4-4B12-A31C-70FD45DC0DBD@delong.com> Message-ID: <5532ECEE.4020304@ipinc.net> +1 ARIN: Do we need a policy proposal for this? Ted On 4/17/2015 3:52 PM, Gary Buhrmaster wrote: > On Fri, Apr 17, 2015 at 10:23 PM, Martin Hannigan wrote: >> >> >> If I could simply consolidate everything into the POC I want and not POCs >> made up by others, I'd be a happy camper. > > +1 to making Marty happy. > > More to the point, I would agree that while there are > legitimate reasons to having multiple POC records > that end up going to the same individual, it should > be the choice of the individual to decide how many > they have to deal with, not others. > > Gary > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From woody at pch.net Sat Apr 18 20:01:25 2015 From: woody at pch.net (Bill Woodcock) Date: Sat, 18 Apr 2015 17:01:25 -0700 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: <5532ECEE.4020304@ipinc.net> References: <794E954F-5A55-49FB-9669-44E1EB90A95D@delong.com> <6D74C0D1-B5D4-4B12-A31C-70FD45DC0DBD@delong.com> <5532ECEE.4020304@ipinc.net> Message-ID: <1B24DD3E-470A-4320-A0ED-6FD3607FDEBC@pch.net> I certainly HOPE it doesn't require a policy proposal. It shouldn't. Nate, what's the quickest process to get this feature added? -Bill > On Apr 18, 2015, at 16:47, Ted Mittelstaedt wrote: > > +1 > > ARIN: > > Do we need a policy proposal for this? > > Ted > >> On 4/17/2015 3:52 PM, Gary Buhrmaster wrote: >>> On Fri, Apr 17, 2015 at 10:23 PM, Martin Hannigan wrote: >>> >>> >>> If I could simply consolidate everything into the POC I want and not POCs >>> made up by others, I'd be a happy camper. >> >> +1 to making Marty happy. >> >> More to the point, I would agree that while there are >> legitimate reasons to having multiple POC records >> that end up going to the same individual, it should >> be the choice of the individual to decide how many >> they have to deal with, not others. >> >> Gary >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mysidia at gmail.com Sat Apr 18 20:27:57 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 18 Apr 2015 19:27:57 -0500 Subject: [arin-ppml] Policy idea: POC Validation In-Reply-To: <1B24DD3E-470A-4320-A0ED-6FD3607FDEBC@pch.net> References: <794E954F-5A55-49FB-9669-44E1EB90A95D@delong.com> <6D74C0D1-B5D4-4B12-A31C-70FD45DC0DBD@delong.com> <5532ECEE.4020304@ipinc.net> <1B24DD3E-470A-4320-A0ED-6FD3607FDEBC@pch.net> Message-ID: On Sat, Apr 18, 2015 at 7:01 PM, Bill Woodcock wrote: > I certainly HOPE it doesn't require a policy proposal. It shouldn't. Nate, what's the quickest process to get this feature added? The exact procedures ARIN takes to manage POCs and POC e-mail addresses are out of the scope of policy... therefore: a policy proposal cannot change them, since these are decisions that have to be made by ARIN staff in regards to how to implement policy. However, it seems they ought to take reasonable steps such as confirming an e-mail address is valid, before it can be used, and not wait too long for POC validation.... confirming e-mail addresses by sending an initial message is common practice for most online services. My expectation would be that ARIN staff should see this discussion thread about POC validation; and consider the suggestions about changes to Annual POC verification e-mail content, the inclusion of a "Not Acknowledged" Option, that there be an immediate Annual POC verification required when a new POC is created, and POC information is not fully visible in Whois, until properly confirmed, And reallocations that require a POC will be considered invalid for justifying further resource assignments, if there are no confirmed POCs on that subdelegation. And that there be optionally batched e-mail notification to POCs on additions to new roles or records. With options to object or specify a different POC with the same e-mail address / consolidate POCs. > > -Bill -- -JH From narten at us.ibm.com Fri Apr 24 00:53:02 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 24 Apr 2015 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201504240453.t3O4r2L6009760@rotala.raleigh.ibm.com> Total of 9 messages in the last 7 days. script run at: Fri Apr 24 00:53:01 EDT 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 22.22% | 2 | 20.63% | 15073 | owen at delong.com 11.11% | 1 | 18.80% | 13731 | hannigan at gmail.com 11.11% | 1 | 11.87% | 8672 | farmer at umn.edu 11.11% | 1 | 11.18% | 8164 | narten at us.ibm.com 11.11% | 1 | 10.40% | 7594 | mysidia at gmail.com 11.11% | 1 | 9.44% | 6898 | woody at pch.net 11.11% | 1 | 8.84% | 6460 | gary.buhrmaster at gmail.com 11.11% | 1 | 8.84% | 6454 | tedm at ipinc.net --------+------+--------+----------+------------------------ 100.00% | 9 |100.00% | 73046 | Total From info at arin.net Mon Apr 27 12:05:41 2015 From: info at arin.net (ARIN) Date: Mon, 27 Apr 2015 12:05:41 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - April 2015 Message-ID: <553E5E55.1050901@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) met on 15 April 2015. The AC moved the following to last call (to be posted separately to last call): Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text Recommended Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 The AC abandoned the following: Recommended Draft Policy ARIN-2014-1: Out of Region Use Recommended Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers Recommended Draft Policy ARIN-2014-22: Removal of Minimum in Section 4.10 The AC provided the following statements: Regarding ARIN-2014-1: Out of Region Use: "After taking into careful consideration feedback from the ARIN community, both on PPML and at ARIN 35, the AC voted to abandon 2014-1. The AC's consensus is that more work is needed in clarifying and resolving issues in this area and that a new proposal is more likely to yield favorable results than continued efforts to tweak the existing proposal, which has morphed considerably from the original author's intent. To that end, there are AC members currently working to craft a new proposal in this problem space." Regarding ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers: "In its meeting on April 15th, 2015 following ARIN35, the ARIN advisory council voted to abandon Draft Policy 2014-14 due to lack of support in the community, as expressed in the Public Policy Meeting and on PPML." Regarding ARIN-2014-22: Removal of Minimum in Section 4.10: "The ARIN Advisory Council, based on input from the community, has voted to abandon ARIN 2014-22 Removal of Minimum in Section 4.10. The primary goal of Section 4.10 is to provide small blocks of IPv4 space to new entrants for IPv6. The removal of the minimum would have significantly reduced the number of blocks available. While blocks smaller than /24 are not widely routable today, the Advisory Council believes the change would be premature. As a first step to address routability concerns, the AC also recommends that ARIN take additional measures to increase awareness of the specific /10 netblock reserved for assignments under 4.10." == The AC is continuing to work on: Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments The AC found the revisions to the ARIN NRPM Section 5 (as posted to PPML on 24 February 2015) to be editorial in nature and recommended they be adopted by the ARIN Board of Trustees. The AC abandoned 2014-1, 2014-14 and 2014-22. Anyone dissatisfied with these decisions may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon Apr 27 12:05:57 2015 From: info at arin.net (ARIN) Date: Mon, 27 Apr 2015 12:05:57 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text Message-ID: <553E5E65.9070008@arin.net> The ARIN Advisory Council (AC) met on 15 April 2015 and decided to send the following to last call: Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 11 May 2015. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Recommended Draft Policy ARIN-2014-6 Remove Operational Reverse DNS Text (was: Remove 7.1) Date: 21 January 2014 AC's assessment of conformance with the Principles of Internet Number Resource Policy: 2014-6 enables fair and impartial number resource administration by removing technical statements that are not related to number policy from the NRPM. It is technically sound to remove operational practice from the NRPM; indeed this act serves as a forcing function for a best practices document that is both more detailed and more approachable than the policy statement that was removed. Discussion of the previous revision of 2014-6 centered around "why are you fixing this for IPv4 and not IPv6", and the most recent changes reflect that community feedback. There has not been notable opposition to the notion of removing operational language from the NRPM. Problem Statement: 7.1 attempts to assert rules on rDNS management at ARIN. It fails to do so because it only addresses in-addr.arpa (missing equally important rules in ip6.arpa). It's also not based on any RFC; it's an arbitrary decision made by ARIN technical staff. We should remove this text from policy, as it represents operational practice rather than ARIN number policy. In feedback received at public policy meetings and on the PPML mailing list, the Community expressed a desire for IPv4 and IPv6 policy on reverse DNS to be congruent (that is to say, it makes no sense to remove 7.1 without addressing 6.5.6 which is similarly operationally prescriptive) and bring this proposal forward again. Policy statement: Remove 7.1 Remove 6.5.6 Comments: a.Timetable for implementation: Immediate b.Anything else: 7.1. Maintaining IN-ADDRs All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain records for their respective customers. For blocks smaller than /16, and for the segment of larger blocks smaller than /16, ARIN can maintain IN-ADDRs. 6.5.6. Reverse lookup When an RIR delegates IPv6 address space to an organization, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organization should properly manage its reverse lookup zone. When making an address assignment, the organization must delegate to an assignee organization, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address. ##### ARIN STAFF & LEGAL ASSESSMENT Draft Policy ARIN-2014-6 Remove Operational Reverse DNS Text Date of Assessment: March 17, 2015 1. Summary (Staff Understanding) This proposal would remove 6.5.6 and 7.1, thus removing reverse DNS language from the NRPM. 2. Comments A. ARIN Staff Comments This change to NRPM will not change the DNS service that ARIN performs. This proposal can be implemented as written. ARIN registration services staff occasionally receives a telephone or email inquiry asking how reverse DNS services can be set up for a company. In the cases the company is a downstream customer of an ISP who has received a direct allocation from ARIN, staff explains this service can be set up for them by their service provider. On rare occasion, the company presses for a reference that states this is done by their ISP, and not ARIN. In those cases staff will refer them to the language currently in the NRPM. In the case the language is removed from NRPM, ARIN staff will create a resource for the ARIN public website that describes how ARIN's Reverse DNS services are provided; including who is able to establish Reverse DNS service for different types of registration records. B. ARIN General Counsel ??? Legal Assessment The policy does not create legal concerns. 3. Resource Impact This policy would have minimal impact from an implementation standpoint. It is estimated implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following tasks will be completed for implementation: Versioned change to NRPM Updated guidelines on ARIN website describing reverse DNS services (to act as general information resource and serve as new reference point for situation described in staff comments). Staff training 4. Proposal / Draft Policy Text Assessed Draft Policy ARIN-2014-6 Remove Operational Reverse DNS Text (was: Remove 7.1) Date: 21 January 2015 Problem Statement: 7.1 attempts to assert rules on rDNS management at ARIN. It fails to do so because it only addresses in-addr.arpa (missing equally important rules in ip6.arpa). It's also not based on any RFC; it's an arbitrary decision made by ARIN technical staff. We should remove this text from policy, as it represents operational practice rather than ARIN number policy. In feedback received at public policy meetings and on the PPML mailing list, the Community expressed a desire for IPv4 and IPv6 policy on reverse DNS to be congruent (that is to say, it makes no sense to remove 7.1 without addressing 6.5.6 which is similarly operationally prescriptive) and bring this proposal forward again. Policy statement: Remove 7.1 Remove 6.5.6 Comments: a.Timetable for implementation: Immediate b.Anything else: 7.1. Maintaining IN-ADDRs All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain records for their respective customers. For blocks smaller than /16, and for the segment of larger blocks smaller than /16, ARIN can maintain IN-ADDRs. 6.5.6. Reverse lookup When an RIR delegates IPv6 address space to an organization, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organization should properly manage its reverse lookup zone. When making an address assignment, the organization must delegate to an assignee organization, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address. From info at arin.net Mon Apr 27 12:06:10 2015 From: info at arin.net (ARIN) Date: Mon, 27 Apr 2015 12:06:10 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 Message-ID: <553E5E72.6060605@arin.net> The ARIN Advisory Council (AC) met on 15 April 2015 and decided to send the following to last call: Recommended Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 11 May 2015. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Recommended Draft Policy ARIN-2014-21 Modification to CI Pool Size per Section 4.4 Date: 25 November 2014 AC's assessment of conformance with the Principles of Internet Number Resource Policy: This proposal enables fair and impartial number resource administration by ensuring IPv4 resources are available for critical infrastructure and Internet Exchanges in particular after IPv4 resources are no longer readily available from the ARIN free pool. This benefits more than just the individual organizations receiving these resources; it benefits the entire Internet Community by contributing to the stability and scalability of the Internet as a whole. This proposal is technically sound and is supported by the community. Problem Statement: At the time that this section of policy was written, IXP growth in North America was stagnant. Efforts of late have increased significantly within the IXP standards and other communities to improve critical infrastructure in North America. This effort is paying dividends and we project that a /16 will not be enough to continue to improve global interconnect conditions and support needed IXP CI infrastructure. Policy statement: Change to text in section 4.4 Micro Allocations: Current text: ARIN will place an equivalent of a /16 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4. If at the end of the policy term there is unused address space remaining in this pool, ARIN staff is authorized to utilize this space in a manner consistent with community expectations. Proposed text to replace current text entirely: ARIN will place an equivalent of a /15 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4. Timetable for implementation: Immediate ##### ARIN STAFF ASSESSMENT Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 Date of Assessment: 14 January 2015 1. Summary (Staff Understanding) This policy changes one section of existing NRPM policy 4.4 to extend the current reservation size for critical infrastructure and exchange points from a /16 equivalent to a /15 equivalent. 2. Comments A. ARIN Staff Comments ??? For informational purposes: ??? A total of 35 /24s have been issued from the reserved /16 equivalent for CI and IXPs since the policy was amended and implemented on 20 March 2013, leaving 221 /24s available in this reserved block. ??? There are currently 381 free /24s remaining in the two /8 ranges used for CI and IXP micro-allocations. ??? This policy could be implemented as written. B. ARIN General Counsel - Legal Assessment This proposal does not create any material legal issue. 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: ?? Updated guidelines and internal procedures ?? Staff training 4. Proposal/Draft Policy Text Assessed Draft Policy ARIN-2014-21???Modification to CI Pool Size per Section 4.4 Date: 25 November 2014 Problem Statement: At the time that this section of policy was written, IXP growth in North America was stagnant. Efforts of late have increased significantly within the IXP standards and other communities to improve critical infrastructure in North America. This effort is paying dividends and we project that a /16 will not be enough to continue to improve global interconnect conditions and support needed IXP CI infrastructure. Policy statement: Change to text in section 4.4 Micro Allocations: Current text: ARIN will place an equivalent of a /16 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4. If at the end of the policy term there is unused address space remaining in this pool, ARIN staff is authorized to utilize this space in a manner consistent with community expectations. Proposed text to replace current text entirely: ARIN will place an equivalent of a /15 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4. From michael at linuxmagic.com Mon Apr 27 12:42:24 2015 From: michael at linuxmagic.com (Michael Peddemors) Date: Mon, 27 Apr 2015 09:42:24 -0700 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text In-Reply-To: <553E5E65.9070008@arin.net> References: <553E5E65.9070008@arin.net> Message-ID: <553E66F0.9040000@linuxmagic.com> Vote against.. In my opinion, the granting of a public IPv4 (or IPv6) address space SHOULD come alone with some responsibility, including 'rwhois/SWIP/routing/rDNS obligations'. I would rather have more work done by the community at large to reach consensus on those things, even IF ARIN has little enforcement mandate at this time, we should be able to reference it in discussions. I suggest abandoning "Recommended Draft Policy ARIN-2014-6" and work on better language. On 15-04-27 09:05 AM, ARIN wrote: > The ARIN Advisory Council (AC) met on 15 April 2015 and decided to > send the following to last call: > > Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS > Text > > Feedback is encouraged during the last call period. All comments should > be provided to the Public Policy Mailing List. This last call will > expire on 11 May 2015. After last call the AC will conduct their > last call review. > > The draft policy text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Recommended Draft Policy ARIN-2014-6 > Remove Operational Reverse DNS Text (was: Remove 7.1) > > Date: 21 January 2014 > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > 2014-6 enables fair and impartial number resource administration by > removing technical statements that are not related to number policy from > the NRPM. It is technically sound to remove operational practice from > the NRPM; indeed this act serves as a forcing function for a best > practices document that is both more detailed and more approachable than > the policy statement that was removed. Discussion of the previous > revision of 2014-6 centered around "why are you fixing this for IPv4 and > not IPv6", and the most recent changes reflect that community feedback. > There has not been notable opposition to the notion of removing > operational language from the NRPM. > > Problem Statement: > > 7.1 attempts to assert rules on rDNS management at ARIN. It fails to do > so because it only addresses in-addr.arpa (missing equally important > rules in ip6.arpa). It's also not based on any RFC; it's an arbitrary > decision made by ARIN technical staff. We should remove this text from > policy, as it represents operational practice rather than ARIN number > policy. > > In feedback received at public policy meetings and on the PPML mailing > list, the Community expressed a desire for IPv4 and IPv6 policy on > reverse DNS to be congruent (that is to say, it makes no sense to remove > 7.1 without addressing 6.5.6 which is similarly operationally > prescriptive) and bring this proposal forward again. > > Policy statement: > > Remove 7.1 > > Remove 6.5.6 > > Comments: > > a.Timetable for implementation: Immediate > > b.Anything else: > 7.1. Maintaining IN-ADDRs > > All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses > from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain > records for their respective customers. For blocks smaller than /16, and > for the segment of larger blocks smaller than /16, ARIN can maintain > IN-ADDRs. > > 6.5.6. Reverse lookup > > When an RIR delegates IPv6 address space to an organization, it also > delegates the responsibility to manage the reverse lookup zone that > corresponds to the allocated IPv6 address space. Each organization > should properly manage its reverse lookup zone. When making an address > assignment, the organization must delegate to an assignee organization, > upon request, the responsibility to manage the reverse lookup zone that > corresponds to the assigned address. > > ##### > > ARIN STAFF & LEGAL ASSESSMENT > > Draft Policy ARIN-2014-6 > Remove Operational Reverse DNS Text > > Date of Assessment: March 17, 2015 > > 1. Summary (Staff Understanding) > This proposal would remove 6.5.6 and 7.1, thus removing reverse DNS > language from the NRPM. > > 2. Comments > A. ARIN Staff Comments > This change to NRPM will not change the DNS service that ARIN performs. > This proposal can be implemented as written. > > ARIN registration services staff occasionally receives a telephone or > email inquiry asking how reverse DNS services can be set up for a > company. In the cases the company is a downstream customer of an ISP who > has received a direct allocation from ARIN, staff explains this service > can be set up for them by their service provider. On rare occasion, the > company presses for a reference that states this is done by their ISP, > and not ARIN. In those cases staff will refer them to the language > currently in the NRPM. > > In the case the language is removed from NRPM, ARIN staff will create a > resource for the ARIN public website that describes how ARIN's Reverse > DNS services are provided; including who is able to establish Reverse > DNS service for different types of registration records. > > B. ARIN General Counsel ??? Legal Assessment > The policy does not create legal concerns. > > 3. Resource Impact > This policy would have minimal impact from an implementation standpoint. > It is estimated implementation would occur within 3 months after > ratification by the ARIN Board of Trustees. The following tasks will be > completed for implementation: > Versioned change to NRPM > Updated guidelines on ARIN website describing reverse DNS services (to > act as general information resource and serve as new reference point for > situation described in staff comments). > Staff training > > 4. Proposal / Draft Policy Text Assessed > > Draft Policy ARIN-2014-6 > Remove Operational Reverse DNS Text (was: Remove 7.1) > > Date: 21 January 2015 > > Problem Statement: > > 7.1 attempts to assert rules on rDNS management at ARIN. It fails to do > so because it only addresses in-addr.arpa (missing equally important > rules in ip6.arpa). It's also not based on any RFC; it's an arbitrary > decision made by ARIN technical staff. We should remove this text from > policy, as it represents operational practice rather than ARIN number > policy. > > In feedback received at public policy meetings and on the PPML mailing > list, the Community expressed a desire for IPv4 and IPv6 policy on > reverse DNS to be congruent (that is to say, it makes no sense to remove > 7.1 without addressing 6.5.6 which is similarly operationally > prescriptive) and bring this proposal forward again. > > Policy statement: > > Remove 7.1 > > Remove 6.5.6 > > Comments: > > a.Timetable for implementation: Immediate > > b.Anything else: > > 7.1. Maintaining IN-ADDRs > > All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses > from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain > records for their respective customers. For blocks smaller than /16, and > for the segment of larger blocks smaller than /16, ARIN can maintain > IN-ADDRs. > > 6.5.6. Reverse lookup > > When an RIR delegates IPv6 address space to an organization, it also > delegates the responsibility to manage the reverse lookup zone that > corresponds to the allocated IPv6 address space. Each organization > should properly manage its reverse lookup zone. When making an address > assignment, the organization must delegate to an assignee organization, > upon request, the responsibility to manage the reverse lookup zone that > corresponds to the assigned address. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From info at arin.net Mon Apr 27 15:14:40 2015 From: info at arin.net (ARIN) Date: Mon, 27 Apr 2015 15:14:40 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 In-Reply-To: <553E5E72.6060605@arin.net> References: <553E5E72.6060605@arin.net> Message-ID: <553E8AA0.3080001@arin.net> The ARIN Advisory Council provided an updated assessment of 2014-21: "This proposal is technically sound, enables fair and impartial number resource administration by ensuring IPv4 resources are available for critical infrastructure and Internet exchanges in particular after IPv4 resources are no longer readily available from the ARIN free pool. This benefits more than just the individual organizations receiving these resources; it benefits the entire Internet community by contributing to the stability and scalability of the Internet as a whole. Although a portion of the community believes the current reservation is sufficient and that expanding it will unnecessarily impact those that would have otherwise received the resources, the majority of the community polled concluded the reservation is justified and supports the proposal." Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 4/27/15 12:06 PM, ARIN wrote: > The ARIN Advisory Council (AC) met on 15 April 2015 and decided to > send the following to last call: > > Recommended Draft Policy ARIN-2014-21: Modification to CI Pool Size > per Section 4.4 > > Feedback is encouraged during the last call period. All comments should > be provided to the Public Policy Mailing List. This last call will > expire on 11 May 2015. After last call the AC will conduct their > last call review. > > The draft policy text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Recommended Draft Policy ARIN-2014-21 > Modification to CI Pool Size per Section 4.4 > > Date: 25 November 2014 > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > This proposal enables fair and impartial number resource administration > by ensuring IPv4 resources are available for critical infrastructure and > Internet Exchanges in particular after IPv4 resources are no longer > readily available from the ARIN free pool. This benefits more than just > the individual organizations receiving these resources; it benefits the > entire Internet Community by contributing to the stability and > scalability of the Internet as a whole. This proposal is technically > sound and is supported by the community. > > Problem Statement: > > At the time that this section of policy was written, IXP growth in North > America was stagnant. Efforts of late have increased significantly > within the IXP standards and other communities to improve critical > infrastructure in North America. This effort is paying dividends and we > project that a /16 will not be enough to continue to improve global > interconnect conditions and support needed IXP CI infrastructure. > > Policy statement: > > Change to text in section 4.4 Micro Allocations: > > Current text: > > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. If at > the end of the policy term there is unused address space remaining in > this pool, ARIN staff is authorized to utilize this space in a manner > consistent with community expectations. > > Proposed text to replace current text entirely: > > ARIN will place an equivalent of a /15 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. > > Timetable for implementation: Immediate > > ##### > > ARIN STAFF ASSESSMENT > > Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 > Date of Assessment: 14 January 2015 > > 1. Summary (Staff Understanding) > > This policy changes one section of existing NRPM policy 4.4 to extend > the current reservation size for critical infrastructure and exchange > points from a /16 equivalent to a /15 equivalent. > > > 2. Comments > > A. ARIN Staff Comments > > ??? For informational purposes: > ??? A total of 35 /24s have been issued from the reserved /16 equivalent > for CI and IXPs since the policy was amended and implemented on 20 March > 2013, leaving 221 /24s available in this reserved block. > > ??? There are currently 381 free /24s remaining in the two /8 ranges > used for CI and IXP micro-allocations. > > ??? This policy could be implemented as written. > > > B. ARIN General Counsel - Legal Assessment > > This proposal does not create any material legal issue. > > 3. Resource Impact > > This policy would have minimal resource impact from an implementation > aspect. It is estimated that implementation would occur within 3 months > after ratification by the ARIN Board of Trustees. The following would be > needed in order to implement: > ?? Updated guidelines and internal procedures > ?? Staff training > > 4. Proposal/Draft Policy Text Assessed > Draft Policy ARIN-2014-21???Modification to CI Pool Size per Section 4.4 > Date: 25 November 2014 > Problem Statement: > At the time that this section of policy was written, IXP growth in North > America was stagnant. Efforts of late have increased significantly > within the IXP standards and other communities to improve critical > infrastructure in North America. This effort is paying dividends and we > project that a /16 will not be enough to continue to improve global > interconnect conditions and support needed IXP CI infrastructure. > Policy statement: > Change to text in section 4.4 Micro Allocations: > Current text: > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. If at > the end of the policy term there is unused address space remaining in > this pool, ARIN staff is authorized to utilize this space in a manner > consistent with community expectations. > Proposed text to replace current text entirely: > ARIN will place an equivalent of a /15 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4.