[arin-ppml] ARIN-prop-172 Additional definition for NRPM Section 2 - Legacy Resources

David Farmer farmer at umn.edu
Mon Jun 18 16:15:12 EDT 2012



On 6/18/12 11:29 CDT, Alexander, Daniel wrote:
> Hello All,
>
> I know this proposal has been thoroughly discussed, so I'm not trying to
> pile onto comments already made. This note is simply to explain my
> reasoning as an AC member why I will be voting against this proposal as
> written.

As currently written I agree with you.  But I think Scott's suggested 
changes fixes most of my objections and I believe this proposal could 
lead to useful policy with those changes.

>>From my point of view, ARIN is responsible for providing registration
> services for the IP resources allocated to it, and inherited by the IANA
> function, as defined by the IETF. As a community driven organization, it
> is also responsible for adhering to the conditions by which the members
> decide those services should be provided.
>
> I feel this proposal attempts to define a class of IP resources separate
> from those that are defined by the IETF. If the definition were focused on
> the legacy registrations, I would be inclined to accept it onto the
> docket, but as it is written, I feel it is outside of the scope of ARIN
> policy. 2011-5 showed us something similar.
>
> We walk a fine line when we look at other concepts like critical
> infrastructure, or community networks. These concepts try and classify who
> may be requesting resources or how they are used, in order to define the
> conditions for providing registration services. Legacy holders of an IP
> resource are another classification, but the IP resources they use are
> ASN's or unicast IP space, just like all the others defined by the IETF.
>
> All of the definitions in section two of the NRPM focus on who and how the
> resources are used. None of them attempt to define a difference in the
> resources themselves. While it is a safe bet that there will be replies to
> this note saying there is no difference, I personally feel this proposal
> is out of scope of ARIN policy.

While I wish there were no distinctions between legacy and non-legacy 
resources, realistically I think there are at least a few practical 
distinctions.  As has been pointed out by several people in the 
discussion, the contract issue is a big distinction, and some feel that 
is only practical distinction. Also, at least partially because there is 
no contract, I feel there is another distinction, there is no mechanism 
in policy or contract to recover address space from defunct 
organizations with legacy resources, unless someone else commits 
resource fraud and start using them.   Resources covered under RSA or 
LRSA are recoverable after non-payment of fees, and if someone else pays 
the fees and uses the resources this is also clearly resource fraud. 
But there is no clear policy or contract under which ARIN can recover 
resources from an organization that no longer exists, prior to some 
fraud taking place.  Honestly, I think this is a big problem and seems 
clearly related to legacy resources and not other resources.

Others, incorrectly in my opinion, also believe that ARIN has no 
authority over legacy resources or that some or all ARIN policies 
doesn't apply to legacy resources.  Therefore, I believe it is important 
to define what legacy resources are and the limited differences they do 
have, and also solve the issue of recovery of legacy resources from 
defunct organizations.

ARIN policy being mostly silent on the issue of legacy resources avoids 
creating a distinction between types resources, which as you suggest has 
its advantages.  However, this silence also fosters the misconception 
that ARIN policies do not apply to legacy resources.  I know it is a 
catch 22.  I guess we could not define legacy resources and only use the 
term "resources assigned by a predecessor registry", but I think just 
defining legacy resources would be much clearer and easier to understand 
for most people.

> Regards,
> Dan Alexander
> AC Member

-- 
===============================================
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
===============================================





More information about the ARIN-PPML mailing list