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: