[arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3

[Owen DeLong]

On May 27, 2011, at 7:15 AM, Mike Burns wrote:

> Hi Bill,
>  
> It's still not clear to me.
> Referencing "values" of an RFC is not terribly clarifying when attempting to match transfer needs requirements which already are out of sync with RFC2050's 1 year window.
>  

Where do you find a 1 year window in RFC 2050?

> And anyway, I say that requiring a needs test is *NOT* consistent with the values expressed here in RFC2050:

You are mistaken.

>  
> 4.  Operational Guidelines For Registries
> 
>    1.  Regional Registries provide registration services as its
>        primary function.
>  
> By requiring a needs test for inter-RIR transfers, we run the risk of driving these transfers off the books in contravention of our PRIMARY function as stewards.

By failing to require a needs test, we would open the door to transfers that are in gross violation of our PRIMARY
functions as stewards.

>  
> Just so we all understand.
> APNIC has a great need, and probably less underutilized addresses in its market to supply that need.
> A good chunk of available space is likely to be found in the legacy pools which are overrepresented in our region.
> The majority of this legacy space is not under any RSA with any RIR.
>  

So?

> You can route legacy space from inside Asia.

Yes.

>  
> A likely action that will occur is the purchases of address blocks from legacy holders which will be routed in Asia by network operators there, but ARIN will not be notified and Whois will not be updated.

Then they risk ARIN noticing that the blocks are no longer in use by the registrant, and proceeding as I have
repeatedly described to you. Further, they'd have to come to the US to get a ruling against ARIN on the matter
when ARIN issues the space to someone else if there isn't some other within-policy solution available.

Frankly, I'm not seeing this as necessarily a bad thing. Certainly the few instances of this which might occur
and disruption effects limited to two parties:
	The party that hijacked the space contrary to policy
and	The party that received the space from ARIN under RSA legitimately, but, when ARIN had no cleaner
	space to give and was apprised of the situation by ARIN prior to receiving the space.

Is vastly superior to the disruption to all parties that I see likely from removing needs basis.

>  
> I have said that I think we are moving into a future with more, rather than less, conflict over IPv4 address control. This is only to be expected, as the availability of free pool addresses has always provided a replacement option for any addresses in conflict. In addition, the underlying monetary value of address control, once understood, provides ample motive to drive conflict.

Yes. All the more reason that transfer records need to reflect good stewardship and that we need
to continue to administer the address space and recognize transfers within the policy framework
set by the community. All the more reason to preserve a needs basis for allowing people to take
address space out of the community pool and use it for their own purposes.

>  
> In an age of conflict, the accuracy of Whois will be related to the level of trust afforded to it. The absence of a strong trust authority could open the doors to a private registry.

I would think that if we preserve the integrity of our policies and administer whois according to
those policies with integrity, it would only serve to increase the level of trust. If we start recognizing
anything that looks like a transfer because we guess that the parties involved are probably the
ones that should be involved and they say so, I can imagine only a few better ways to devalue
the trust placed in the database.

>  
> Suppose there is conflict between private organizations over address control.  Then add to that conflict between RIRs over which registry is the authoritative. What is to stop a real international trust authority, say Lloyds of London, from using its trust to establish a pricey but generally recognized registry?

Here you once again go careening off the rails.. There is no conflict between the RIRs over which registry is authoritative. They have all come
to agreements on the matter.

As to Lloyds, they're welcome to try to do that now, but, the question is what would make ISPs listen to them?

>  
> Or even worse, what if the door is opened to the ITU to claim the RIR system was failing in a post-exhaust era, and seek to create its own registry system, or otherwise take control?

I think if we start eating our responsibilities for breakfast after sacrificing them on the altar of greed, this is virtually assured.

>  
> Once again, I make the point that a market in IPv4 addresses, such as envisaged in 8.3 or in the APNIC transfer policy, meets the stewardship goal of conservation through natural market forces.
> If we ladle on an extra helping of steward meddling, we are taking action in contravention of our primary duty to maintain a viable and trusted registry.

8.3 does, yes. The APNIC policy, IMHO, does not because it allows those without need to obtain addresses for
purposes contrary to the best interests and wishes of the community.

This is not about making qualitative judgment about needs. There is no comparison of worthiness of a need.
Merely the evaluation of whether need exists or not and to what extent. This is a perfectly valid criteria to apply
and to continue to apply.

>  
> So I would support the proposal if the requirement was simply that both RIRs approve, leaving off the "signal" sent by the needs language, which signal reads like a shot across the bow to me.

Yes, but, this is because you are in general in favor of eliminating needs basis. I think we all get that, but,
I think as long as the community chooses to preserve needs basis within the region, this phrase is critical
and vital to preserve that intent in this policy.

You may read it however you want. I doubt that the APNIC staff will consider it a shot across the bow,
but, I'm sure that some of the community members in APNIC will oppose it. I will point out that if that
is the case, they are welcome to express that opposition here if they care to.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110527/382be406/attachment.htm>