[arin-ppml] Draft Policy ARIN-2013-4: RIR Principles

[John Curran]

On May 31, 2013, at 10:21 AM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>> wrote:
To that end, would it be unreasonable to ask for something different in the staff assessment?

Certainly a standard staff assessment should be done, but could staff also publish
a separate assessment, of each of the snippets of the draft policy that would
impact ARIN operations, how it would impact ARIN operations, and if there are other
events (text) that have superseded this text.

The community will then have:

1. the original principle
2. the history about the departure
3. the now current policy
4. how that might be changed if we reassert the principle in RFC 2050

The community can the first decide if the current policy / ARIN practice should remain

Assuming it should remain, the community should judge if this is:
A: Consistant with the original principle - should have no ARIN policy impact
B: The original principle is still true, but need to be modified to support current policy
C: Inconsistent with the original principle, but the original principle still holds true,
      current NRPM text should change, but resulting ARIN policy should be the same
D: Inconsistent with the original principle, but the original principle still holds true,
      current ARIN policy should change
E: Inconsistent with the original principle, but the original principle still holds true,
      current ARIN policy is an artifact of other events but should not change
F: Inconsistent with the original principle, and the community has concluded that it
      should depart from this original principle, as it is no longer valid.

For example wrt the text:
"IP addresses are valid as long as the criteria continues to be met"
the community may decide that:
- Yes this is a general principle that is still true
- No we don't think it should mean ARIN should start reclaiming legacy space
   that is under 80% utilized.
- No we don't think this should challenge the current RSA
- Yes we need some clarifying text asserting this
Conclusion ARIN AC (working with the community should work on text asserting this)

For example wrt 0.1.1 text:

"Assignment of Internet number resources is based on documented operational need.
Utilization rate of address space will be a key factor in number resource assignment.
To this end, registrants should have documented justified need available for each assignment.
Organizations will be assigned resources based on immediate utilization plus expected utilization."

The community might decide that:
- Yes this is a general principle that is still true, IPs should be given on a needs basis
- No we don't think ARIN should start giving out less IPv6 addresses, or make it harder to get
- Yes this does conflict with IPv6 allocation / assignment policy which is currently not based on need
- The conflicting IPv6 allocation / assignment policy should still be used by ARIN
- The community concludes IPv6 allocation / assignment policy should have always be based on need
- The community should work to modify the NRPM to
   1. Make IPv6 allocation / assignment policy based on need
   2. point out the balance between aggregation and efficient utilization much more favors the former
   3. ensure the needs based policy still results in the same allocation / assignment size


If we proceed in this fashion, we can identify
- the non-controversial (non-ARIN policy changing) text,
- the community can deal with each piece of text that might change ARIN policy, and decide at a high
level to what extent the particular policy should impact ARIN policy
- decide what sort of changes is needed to what (this draft, other NRPM text, RSA, ARIN policy, etc)
- begin crafting those changes

My apologies to staff for the added work, but if done well, this will truly be something to be proud of.

Jason -

   We work for you (the collective "you" being the entire community) and as such
   are happy to do any additional work which will help the community in consideration
   of draft policies.  We normally would note any conflicts with existing practices
   during staff and legal review (once requested by the AC) if it is not clear from
   the policy text that the intent is to change those practices as well at adoption.

   I will note that performing this sort of assessment may identify some clearly
   impacting aspects of the proposed text with existing registry practices, but not
   as many as you might expect, as the inherent conflict between the various
   proposed principles means that they can only be considered as a whole and
   not "snippet by snippet" as you suggest.

   Your example is a perfect illustration of this, in that you suggest that we might cite
   the existing IPv6 allocation/assignment policy as impacted by proposed principle
   "0.1.1. Documented Justified Need", but that is not possible because the policy is
   set by the community is based on the balance between justified need and the need
   for aggregation (i.e. proposed principle "0.2. Hierarchical Aggregation")...  To the
   extent that the balance is not optimum, that is ultimately for the community to
   decide that and not the ARIN staff.

   Phrases in the proposed principles such as "Internet number resources are valid as
   long as the criteria continues to be met", "All Internet number resource requests are
   subject to audit and verification by any means deemed appropriate by the regional
   registry", and "The party trying to obtain the resources must meet the same criteria
   as if they were requesting resources directly from the IR" (among others) will indeed
   be highlighted in any staff and legal review due to conflicts with existing ARIN registry
   operational practices, but it is up to the community to decide if, and to what extent,
   existing policy does not align with balance inherent to these proposed principles.

FYI,
/John

John Curran
President and CEO
ARIN


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130531/45b66295/attachment.htm>