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

John Curran jcurran at arin.net
Wed Jun 6 01:09:36 EDT 2012

On Jun 5, 2012, at 9:18 PM, Lindsey, Marc wrote:

> John - I do recognize the difference between staff operational processes intended to implement policy and policy.  However, I disagree that my definition as proposed (including the second criteria) is not the proper subject matter for policy discussion.  

The legal format for return of address space that that ARIN considers 
sufficient is matter of risk management for the organization and 
ultimately the judgement of the Board upon hearing the recommendation
of staff and guidance of legal counsel. 

> It seems to me that legacy numbers should not lose their status as legacy numbers unless they are intentionally returned by the rightful holder to an RIR or another historic number authority to be re-allocated by an RIR or other number authority to another registrant under RSA (or equivalent).

You probably could have sufficed with simply "legacy numbers should 
not lose their status as legacy numbers unless they are intentionally 
returned."  I'm not certain that such return needs to be explicitly 
stated as to "an RIR or another historic number authority", and in 
particular do not believe that "to be re-allocated by another RIR 
.. to another registrant under RSA" should be present, as the future 
of the returned number space is not germane and may not even involve 
re-allocation to another registrant.

> I suspect further tweaking of the language may be required to capture the desirable "release/return" permutations and others may disagree with my premise, but this really is a policy question.

It is certain that the registrant actually return the address space, 
and to argue otherwise would be a significant policy matter for the 
community to discuss.  I do not believe anyone is arguing that point
and hence would recommend keeping in the proposed definition.

> I gather from your comments that you're concerned that requiring specific formalities (like a contract or written consent, which by the way, can be in electronic form) to perfect releases/returns of legacy numbers to ARIN (or another number authority) might render some prior returns/releases ineffective, and unsettle ARIN's authority to re-allocate those numbers.  

I am only concerned that the definition will become the measure by which
returns which have already been completed in the past will be judged and
that attempting to set criteria after the fact is inappropriate.  i.e. 
If 'Bob' yelled to Jon Postel, "Actually, No, I don't want x.y, can 
we make it j.l instead?", that may have been a perfectly appropriate 
return of resources at that time it was done.   By now, block x.y has
likely been issued to someone else and been in use for years, despite 
the email that states that it was issued to 'Bob' and absence of any
email to the contrary...

> Given the implications, I believe releases/returns of this sort should, as a matter of policy -- not just operational process, be supported by documentation validating the release/return. Without this, there is a risk that prior returns not properly documented will be challenged by the original registrant or its successors or assigns (whether or not my proposed definition is adopted). 

If the community wishes to develop a standard for this, it will be
utilized by ARIN for processing all returns once adopted.

> Yet adoption of my proposed definition by itself would not render prior returns ineffectual, and would not establish specific processes ARIN staff must employ to accept returns of legacy numbers to replenish the pool. Only future substantive policy changes, changes in staff operational processes, or court orders/decisions are likely to do that.  

Excellent to hear, and if that it is case, then please make the definition
simply "(2) the original legacy holder (or its legal successor or assign) 
did not return the IPv4 address block or Autonomous System Number."


John Curran
President and CEO

More information about the ARIN-PPML mailing list