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

[Jason Schiller]

John,

Thank you for your careful consideration.

My intention certainly is not to undermine current NRPM policy or RSA text
or change RIR operations.  Ideally all of the things taken from RFC 2050 are
high level principles, and are still as true today as they were then.

It seems things may not be that simple.

First let me say this is not my effort, but rather our effort, where our is
both the
community, the AC, and ARIN staff.

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




On Fri, May 31, 2013 at 6:54 AM, John Curran <jcurran at arin.net> wrote:

>  On May 31, 2013, at 1:47 AM, Jason Schiller <jschiller at google.com>
>  wrote:
>
>  John,
>
>  Reading your respons brings to mind a general question.
>
>  You said "the most likely change that would be anticipated
> by insertation of that into ARIN policy would be ..."
>
>  In this and other cases the "that" is RFC-2050 text.
>
>  Shouldn't the text of RFC-2050 already impact ARIN policy?
>
>
>  At the time of publication more than 15 years ago, RFC 2050 was a
> baseline
> of operational guidelines for all of the regional registries, with each
> RIR free
> to establish any additional guidelines as appropriate.   Since that time,
> both
> individual RIRs have evolved, as well as the entire structure of the
> Internet
> Number Registry System.  This is one of the key reasons why it was felt
> that RFC2050 was long overdue to be refreshed, as many material issues
> have changed since that time (e.g. Jon Postel no longer available as IANA,
> formation of ICANN, introduction of additional RIRs, IPv6, etc.)  RFC 2050
> was operational guidelines from a single point in time, with it made clear
> that the policies followed by an RIR could be supplemented with additional
> policy and/or these global operational guidelines themselves could be
> amended by the IANA to reflect changing requirements.
>
>  The reality is that the entire system has so extensively changed that
> each
> RIR has its own adopted policy, has contractual relations with its members,
> and we have a formal process with ICANN for adoption of global policy.
>  There
> is quite a bit in RFC 2050 operational guidelines which has been preempted
> by these events, and hence the reason why the RFC2050bis effort has
> focused on primarily describing the Internet Number Registry System, and
> calling out those technical considerations from RFC 2050 which are inherent
> to use of the the Internet Protocol and should be considered in
> establishing
> registry policy.
>
>  I would say that the underlying concepts in RFC 2050 should indeed be
> considered when setting ARIN registry policy, but how exactly that is done,
> and how much weight is given to individual principles is very much up to
> this
> community.
>
>   (Assuming no translational issues, out of context, etc)
> why would the impact differ when the text is in RFC-2050,
> or in the NRPM?
>
>
>  See above.  ARIN must follow NRPM in operation of the registry, whereas
> RFC 2050 is a 15 year-old base set of operational guidelines and technical
> principles for consideration in establishing registry policy for
> this region.
>
>    (I'm not debating there is value in community being more clear
> in outlining its expectations and impact on operations. I think
> that point is true if this text is added to the NRPM and while this
> text remains in RFC-2050.
>
>
>  As there is language in RFC 2050 which is clearly obsoleted by events,
> it is necessary for the community to discuss and determine what aspects
> should be considered current and incorporated into ARIN registry policy.
>
>  We certainly can improve on the 2050 text, but I was trying to avoid
> any updates that may be controversial, and was more interesting in
> preserving the principles in 2050 in the first go around. )
>
>
>  A very admirable goal, but you are conflicted between the implied goals
> of "avoiding updates" versus "producing something which is both current
> and accurate."  I'm not sure that the latter is achievable without quite a
> bit of debate on what should be adopted.
>
>  Best wishes on your effort!
> /John
>
>  John Curran
> President and CEO
> ARIN
>
>
>
>


-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130531/0b23a79c/attachment.htm>