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

[Alexander, Daniel]

David,

I think you are missing my point. All the differences you mention below
whether a resource is under LRSA, reclaimable, fees, etc. are all
differences in the agreements that ARIN has with the resource holder as to
the services offered. These points are separate from what the ones and
zeros translate to.

Even Scott's language contains "A legacy resource is an IPv4 address or
Autonomous System Number...." which tries to define a special class of IP
resources. ARIN policy defines different types of users and different
conditions by which services are offered. It does not define address
resources. It may sound like I'm splitting hairs, but I think it is a big
one when you try and put it in the definitions section of the policy
manual.

ARIN was given administration over the IP resources as they were defined
by the IETF and delegated by IANA. If you want to refer to what people are
calling "legacy resources" as the ARIN registration that someone is
holding without contract, that is one thing. If you are saying that
special rights are granted to the series of ones and zeros that were
assigned prior to the formation of ARIN, it is a different discussion.

Also, I never suggested the advantages of silence or a lack of distinction
that you mention below. I'm not sure where you got that from my comments.

-Dan


On 6/18/12 4:15 PM, "David Farmer" <farmer at umn.edu> wrote:

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