<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 12/23/2009 12:43 PM, Owen DeLong wrote:
<blockquote cite="mid:DE7B6192-F08C-4918-9612-95B7B47B0D89@delong.com"
type="cite">
<div>
<blockquote type="cite"><font class="Apple-style-span" color="#000000"><br>
</font><br>
<br>
Replacement text:<br>
<br>
1.1. Number resources not to be considered property<br>
<br>
It is contrary to the goals of this document and is not in the
interests of the Internet community as a whole for address space to be
considered freehold property.<br>
<br>
The policies in this document are based upon the understanding that
globally-unique number resources are licensed for use rather than
owned. Specifically, IP addresses and ASNs will be allocated and
assigned on a license basis, with licenses subject to renewal on a
periodic basis. The granting of a license is subject to specific
conditions applied at the start or renewal of the license, as definied
in the ARIN Registration Services Agreement.<br>
<br>
Note that when a license is renewed, the new license will be evaluated
under and governed by the applicable number resource policies in place
at the time of renewal, which may differ from the policy in place at
the time of the original allocation or assignment.<br>
<br>
</blockquote>
I do not like the use of the term license, and, I think Steve Ryan
would likely take issue with it as well.</div>
<div><br>
</div>
<div>Personally, I think that the first paragraph is sufficient. The
remaining two paragraphs simply restate</div>
<div>(badly) what is in the RSA and do not need to be part of the
NRPM.</div>
</blockquote>
<br>
I already deleted a couple extraneous paragraphs, and would be happy to
trim further, once we've gotten to the point of getting a Legal review
if not before. In any event, this is all in the existing NRPM already.<br>
<br>
<blockquote cite="mid:DE7B6192-F08C-4918-9612-95B7B47B0D89@delong.com"
type="cite">
<div>
<blockquote type="cite">ARIN is not concerned about which address
size an LIR/ISP actually assigns. Accordingly, ARIN will not request
the detailed information on IPv6 user networks as in IPv4, except for
the purpose of measuring utilization as defined in this document.<br>
<br>
</blockquote>
This paragraph should be deleted. ARIN is concerned if you want to
issue more than a /48 to an end site and should</div>
<div>be able to review such large assignments.</div>
</blockquote>
<br>
Ok. I like deleting unnecessary text. :-)<br>
<br>
<blockquote cite="mid:DE7B6192-F08C-4918-9612-95B7B47B0D89@delong.com"
type="cite">
<div>
<blockquote type="cite">6.2.3. Allocations and assignments from ARIN<br>
<br>
6.2.3.1 Goals<br>
To balance the goals of Aggregation, Conservation, Fairness, and
Minimized Overhead, ARIN normally makes allocations only in the
discrete sizes of /48, /40, /32, /28, or /24 or larger. Each
organization or discrete network may qualify for one allocation or
assignment of each size, and must pay fees according to ARIN's <a
href="<a moz-do-not-send="true"
href="https://www.arin.net/fees/fee_schedule.html">https://www.arin.net/fees/fee_schedule.html</a>">fee
schedule</a><br>
for each size assigned.<br>
<br>
</blockquote>
<div>The first "makes allocations" should either be "issues IPv6
addresses" or "makes allocations or assignments".</div>
The last "assigned" should either be "issued" or "assigned or
allocated".</div>
</blockquote>
<br>
Agreed.<br>
<br>
<blockquote cite="mid:DE7B6192-F08C-4918-9612-95B7B47B0D89@delong.com"
type="cite">
<div><br>
<blockquote type="cite">6.2.3.2 X-Small (/48)<br>
To qualify for a /48 allocation or assignment, an organization must:<br>
* Serve at least 500 hosts, if multihomed; or<br>
* Serve at least 1000 hosts; or<br>
* Demonstrate efficient utilization of all direct IPv4 assignments
and allocations, each of which must be covered by any current ARIN RSA;
or<br>
* Be a critical infrastructure provider of the Internet, including
public exchange points, core DNS service providers (e.g.
ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs
and IANA; or<br>
* Qualify for a Micro-allocations for Internal Infrastructure per
6.3.3.2.2.<br>
<br>
</blockquote>
I would rather see this in the ~100 host range, if multihomed. I'm
fine with 1000 hosts otherwise.</div>
<div><br>
</div>
<div>There should not be any IPv4 requirement for getting IPv6 space.
The efficient utilization of IPv4 resources as a determining</div>
<div>factor for getting IPv6 resources should be removed in my
opinion.</div>
</blockquote>
<br>
Note that this is an "or", so it's just another way to get space.
Removing it would repeal 2007-21, which I don't think should be done
until we're much further along in IPv6 deployment.<br>
<br>
<blockquote cite="mid:DE7B6192-F08C-4918-9612-95B7B47B0D89@delong.com"
type="cite">
<div><br>
</div>
<div>
<blockquote type="cite">6.2.3.2.1 Critical Infrastructure<br>
Organizations qualified as critical infrastructure providers may be
granted multiple /48 allocations in certain situations. Exchange point
allocations MUST be allocated from specific blocks reserved only for
this purpose. All other micro-allocations WILL be allocated out of
other blocks reserved for micro-allocation purposes. ARIN will make a
list of these blocks publicly available. Exchange point operators must
provide justification for the allocation, including: connection policy,
location, other participants (minimum of two total), ASN, and contact
information. ISPs and other organizations receiving these
micro-allocations will be charged under the ISP fee schedule, while
end-users will be charged under the fee schedule for end-users. This
policy does not preclude exchange point operators from requesting
address space under other policies.<br>
<br>
</blockquote>
Why create a separate pool for exchange point allocations?</div>
</blockquote>
<br>
Cause that's what existing policy does. I'd be OK with deleting this,
but didn't see a reason to.<br>
<br>
<blockquote cite="mid:DE7B6192-F08C-4918-9612-95B7B47B0D89@delong.com"
type="cite">
<div>
<blockquote type="cite">6.2.3.2.2 Micro-allocations for Internal
Infrastructure<br>
Organizations that currently hold IPv6 allocations may apply for a /48
micro-allocation for internal infrastructure. Applicant must provide
technical justification indicating why a separate non-routed block is
required. Justification must include why a sub-allocation of currently
held IP space cannot be utilized. Internal infrastructure allocations
must be allocated from specific blocks reserved only for this purpose.<br>
<br>
6.2.3.3 Small (/40)<br>
To qualify for a /40 allocation or assignment, an organization must
qualify for two or more /48s.<br>
<br>
</blockquote>
This is in direct conflict with the statement at the beginning that an
organization can only qualify for one block of each size. This problem
persists in your subsequent requirements to qualify for larger blocks
as well.</div>
</blockquote>
<br>
The idea here is that if you qualify for a /48, you get one. If you
qualify for more than one /48, you can't have a second, but you can
have a /40 instead. I'd welcome suggestions for better ways to say
that.<br>
<br>
<blockquote cite="mid:DE7B6192-F08C-4918-9612-95B7B47B0D89@delong.com"
type="cite">
<div>
<blockquote type="cite">6.3. Registration<br>
<br>
When an organization holding an IPv6 address allocation makes IPv6
address assignments, it must register assignment information in a
database, accessible by RIRs as appropriate (information registered by
ARIN may be replaced by a distributed database for registering address
management information in future). Information is registered in units
of assigned /56 networks. When more than a /56 is assigned to an
organization, the assigning organization is responsible for ensuring
that the address space is registered in an ARIN database.<br>
<br>
</blockquote>
This is a major departure from current whois policy and I do not think
that an overhaul of whois</div>
<div>should be packaged with a major change to IPv6 policy. Please
restore the current SWIP/rhwois</div>
<div>requirements for publishing the data.</div>
<div><br>
</div>
<div>I'm fine with registering IPv6 data in terms of /56s, but, what
about cases where customers are</div>
<div>issued /64s? There are 256 /64 customers in a single /56.</div>
</blockquote>
<br>
This isn't a departure, this is a copy and paste (with minor edits)
from existing policy (<a class="moz-txt-link-freetext" href="https://www.arin.net/policy/nrpm.html#six55">https://www.arin.net/policy/nrpm.html#six55</a>)<br>
<blockquote cite="mid:DE7B6192-F08C-4918-9612-95B7B47B0D89@delong.com"
type="cite">
<div><br>
</div>
<div>
<blockquote type="cite">IRs shall maintain systems and practices that
protect the security of personal and commercial information that is
used in request evaluation, but which is not required for public
registration.<br>
<br>
</blockquote>
I don't think this needs to be in the NRPM. I think that it is already
addressed in other areas.</div>
</blockquote>
<br>
It's in the current NRPM, but I'll be happy to remove it unless anyone
thinks it needs to stay. (Like much of NRPM section 6, the globally
coordinated policy restates a lot of policy from elsewhere, and some
operational practice stuff as well.)<br>
<br>
<blockquote cite="mid:DE7B6192-F08C-4918-9612-95B7B47B0D89@delong.com"
type="cite">
<div>
<blockquote type="cite">6.3.1. Residential Customer Privacy (2003-3)<br>
<br>
To maintain the privacy of their residential customers, an organization
with downstream residential customers may substitute that
organization's name for the customer's name, e.g. 'Private Customer -
XYZ Network', and the customer's street address may read 'Private
Residence'. Each private downstream residential reassignment must have
accurate upstream Abuse and Technical POCs visible on the WHOIS record
for that block.<br>
<br>
6.3.2. Reverse lookup<br>
<br>
When ARIN delegates IPv6 address space to an organization, it also
delegates the responsibility to manage the reverse lookup zone that
corresponds to the allocated IPv6 address space. Each organization
should properly manage its reverse lookup zone. When making an address
assignment, the organization must delegate to an assignee organization,
upon request, the responsibility to manage the reverse lookup zone that
corresponds to the assigned address.<br>
<font class="Apple-style-span" color="#000000"><font
class="Apple-style-span" color="#144fae"><br>
</font></font></blockquote>
I think this needs word-smithing, but, I'm at a loss to come up with
something better at the moment.</div>
</blockquote>
<br>
Well, this too is existing NRPM text, so we don't have to fix it right
now.<br>
<br>
Thanks for the feedback. I'd also like to hear anyone's general
thoughts on the proposal as a whole, if you've formed an opinion on it
yet.<br>
<br>
Thanks,<br>
Scott<br>
</body>
</html>