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

[Owen DeLong]

On Jun 5, 2012, at 5:32 PM, David Farmer wrote:

> 
> 
> On 6/5/12 17:02 CDT, Kevin Kargel wrote:
>> 
>> I strongly feel that addresses brought under *RSA should no longer be
>> considered "Legacy".  To my way of thinking an active Legacy resource
>> implies it is supported but not regulated by an agreement, and any version
>> of RSA brings with it regulation by agreement.
> 
> So, what does legacy mean (the English word)?
> 
> Legacy
> 1. Law . a gift of property, especially personal property, as money, by will; a bequest.
> 2. anything handed down from the past, as from an ancestor or predecessor: the legacy of ancient Rome.
> 3. an applicant to or student at a school that was attended by his or her parent.
> 4. Obsolete . the office, function, or commission of a legate.
> adjective
> 5. of or pertaining to old or outdated computer hardware, software, or data that, while still functional, does not work well with up-to-date systems.
> 
> #2 seem most the most appropriate to the situation, although #1, #5 are interesting side notes.
> 

I think when discussing legacy registrations, #5 is actually most appropriate, though #4 would also apply to some extent.

> This seem to most directly speak to the relationship between ARIN and the resource registration, the registration was "handed down" to ARIN from its predecessor registries (Postel's notebook :), SRI, InterNIC, Etc...) by the US Gov (through NFS with the assent of several other fed agencies and oversight bodies).  When ARIN was created there wasn't any change in the relationship between the resource holder and the resource.  That relationship was established when the assignment was made.  Also, if the resource holder still exists and is using the resource, then I contend, the relationship between the resource and resource holder has never changed and never will change.

I can see this argument as well.

I don't quite buy "and never will change." That is far too broad a prediction. There are many ways in which that can change.

However, I don't really believe that the relevant question here is the relationship between the resource recipient and the resource, but, rather is about the relationship between the resource recipient and the original registry and the extent to which the obligations and agreements of that predecessor registry are binding on ARIN and the resource recipient.

In the case of resources covered under any LRSA, the relevant relationship(s) to this discussion are well defined, documented and subject to contract between ARIN and the resource recipient. Therefore, those resources are not, in fact, legacy.

There are two principle classes of non-legacy resources. Those covered under RSA to which all ARIN policies and future policies apply uniformly and those covered under LRSA which, in recognition of the murky nature of the questionably defined rights and obligations around their previous status are granted special exemptions from certain limited sections of ARIN policy.

It has never been established that legacy resources cannot be revoked or reclaimed by ARIN or that legacy recipients use of said resources are not subject to ARIN policies. It is important in evaluating this to recognize that the resources themselves are not at issue and are not what is subject to transfer, possession, etc. What is, instead, at issue is the registrations of those resources. I have not seen anything to clearly indicate that ARIN is obliged to continue providing any services or registrations whatsoever to legacy recipients. I believe that ARIN has a moral obligation to do so, even if not a legal one. (Bear with me on the morality of a soulless corporation for the time being).

However, that does not mean that I believe ARIN has an obligation to treat those resources differently from any other resource allocation or assignment. I believe that ARIN does so only because and to the extent that it is better for the community and less expensive for ARIN to
do so than to pursue alternative courses of action with regard to said registrations.


> I'll add, there was nothing special about the "hand down" to ARIN, it was just the latest in a long long line of them.  And who knows, it very well may not the the last.  However, please lets not go through that again anytime soon. :)
> 
> Kevin, to your point; A contract clarifying the relationship between the resource holder and ARIN, neither changes the relationship between the resource holder and the resource nor ARIN and the resource registration, it only simply clarifies the relationship between ARIN and the resource holder, that is it. The registration was still "handed down" to ARIN.
> 
> Now if a resource holder seeks to transfer the resource, then that would change the relationship between both the resource and the resource holder and the resource registration and ARIN.  The registration is no longer "handed down" to ARIN but a new registration with ARIN, and the term legacy would seem to no longer seem to apply.

Correct. Anything transferred no longer enjoys legacy status.

> So, what about those other definitions;  #1 is interesting as it speaks to property but again the bequest seems to be to ARIN from it predecessor registries.  I don't see any change between the relationship of resource holder and the resource.  The resource holder isn't making a bequest, and if they were, of what to whom?  #5 would be an interesting usage, but would seem to apply to all IPv4 addresses. :)

While obsolescence applies to all IPv4 addresses at this point (or in the near future, depending on your perspective), it does not apply to all IPv4 registrations. Many IPv4 registrations were carried out under the modern process and have clear status delineated by contract. Registrations which are continuing to function in spite of being no longer aligned with the current process for resource registration are, in fact, very much what legacy IPv4 registrations represent.

> So I would have to say a legacy address or resource: is a resource that the registration of which ARIN inherited and for which the registration has not been changed. It is probably useful to add a few additional details (like IPv4 and ASNs, the date ARIN was created, who ARIN inherited them from, etc...) but that is mostly icing on the cake, the cake is "ARIN inherited the registration, and registration hasn't been changed"

It is possible to update the registration without changing the legacy status of the registration. POC changes, changes of address, and other routine maintenance of the registration by registered POCs while maintaining the resource with the same organization are and should be allowed without changing the status of the registration or requiring the addition of an RSA. This is in the interest of the community in terms of keeping the registration database up to date and accurate.

> There is another definition that might be useful "legacy resource holder" in this case the term legacy now seems to refer to the transitive relationship of the resource holder to the resource and the resource registration to ARIN, therefore speaking to the relationship of ARIN and the resource holder.
> 
> Finally, I don't see where or how the term legacy creates any unique property of the resource itself, it only seems to be a property of the relationship between ARIN and the resource registration and possibly transitively to the relationship between the resource holder and ARIN.

Exactly. Which means that there are no policy implications, per se, to it's status as a legacy registration which, to my thinking, seems to render the definition being placed in the NRPM moot.

Owen