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?
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
