[arin-ppml] Suggested update to PP 157

[David Farmer]

On 11/11/11 17:31 CST, Martin Hannigan wrote:
> Policy statement:  Number resources within the ARIN region may be
> released to ARIN by an authorized resource holder for transfer to a
> specified recipient who qualifies for resources under current ARIN
> policy.
>
> Rationale:
>
> The original text was overly complex and imprecise. The modified
> language has been reduced to be clear with respect to allowing
> specified transfers of "number resources". The definition of "number
> resources" is any IPv4 address or addresses, IPV6 address or addresses
> or a 2 byte or 4 byte ASN individually or collectively.
>
> The edits that I'm suggesting match almost verbatim comments and
> suggestions from the staff C/U.

While I still can't support this text as written, more on that in a bit. 
  This is much cleaner text, and deals with the editorial issues I had 
with the original version, except I have a new one now;

A suggestion from the lessons I'm taking out of the 2011-1 debacle; The 
title of this policy proposal is "Section 8.3 Simplification", note that 
wasn't included with this email, and I had to go look.  I believe this 
intends to completely replace section 8.3.  So, then lets either add the 
NRPM section number and title into the policy text or clearly state that 
this will completely replace NRPM section 8.3 in the rationale.  Maybe 
even go for triple overkill and have it in the title, the policy text, 
and the rationale. :)  Going only from the email you just sent, the fact 
that text was to replace Section 8.3 wasn't abundantly clear.  I was 
able to figure it out, but you get my point.

Now to policy issues;

I support adding designated transfers for ASNs, to the currently allowed 
IPv4 resources, for a whole host of reasons that have been discussed. 
However, before I can support designated transfers for IPv6 resources 
there are a whole number of technical issues that would need to be 
discussed and successfully resolved.  Like; What would be the effect on 
sparse allocation?  We would do next nibble boundary of which 
allocation?  If I have a /32 currently, can I receive a /32, only a /28 
that ARIN would round me up to, or anything between?

I'm not saying these issues can't be resolved; but that I can't support 
designated transfers for IPv6 without resolving them first.  I imagine 
we could keep 8.3 as simple as you propose and maybe deal with some of 
these issues in the details of the IPv6 policy sections.

If what the community wants in the short run is ASNs to be transferable, 
I support that and think that is fairly easy.  Heck, the current ASN 
policy is only about three paragraphs. However, IPv6 designated 
transfers are going to need to be thought through.  I think that can be 
done, if the community wants, but it will take work, probably more than 
a little bit too.

My personal suggestion is to limit designated transfers to IPv4 and ASNs 
for now and come back and deal with designated transfers for IPv6 later. 
  Something tells me we have other fish to fry over the next year or two.

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================