[arin-ppml] Counsel identifications of ARIN legal obligations (was: Re: Response to the ARIN counsel's assessment of 2014-1 (Out of region use))

[Milton L Mueller]

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: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150413/4e20a28a/attachment.htm>