[arin-ppml] 2011-1: reciprocity NOT required

[Owen DeLong]

On Oct 26, 2011, at 8:23 AM, William Herrin wrote:

> On Wed, Oct 26, 2011 at 9:48 AM, John Curran <jcurran at arin.net> wrote:
>> On Oct 26, 2011, at 1:36 PM, William Herrin wrote:
>>> Actually, I'm not sure about that last sentence. We've all been
>>> assuming that reciprocity is expected, but rereading draft 2011-1 I
>>> find no explicit reciprocity requirement. As 2011-1 is understood by
>>> ARIN, does an RIR which does not permit its addresses to be
>>> transferred out-region but does apply a needs basis of unknown
>>> stricture to transfer recipients qualify to receive addresses under
>>> 2011-1?
>> 
>> The RIR must have a compatible, needs-based transfer policy
>> which allows them to approved the request to transfer to the
>> recipient; there is no reciprocity requirement in 2011-1.
> 
> Neat! So under 2011-1 as drafted, APNIC registrants, under APNIC's
> nearly completed needs-based allocation policy, may accept addresses
> sold by ARIN-region registrants even as APNIC's participants merrily
> debate whether and how to permit APNIC region registrants to sell
> addresses to ARIN region organizations.
> 

> And correct me if I'm wrong, but APNIC uses country-level
> sub-registries very differently than ARIN. So, even if APNIC up top
> eventually adopts a reciprocal policy, it may be mooted by the
> country-level policies.
> 
You are wrong...

Your understanding of how APNIC NIRs operate is not correct.
The NIRs are not allowed to set independent addressing policies.
They are primarily a voting block  and a language interface arrangement.
They are a local front-end to the APNIC request process.


> Congratulations Scott, you've reached the public policy big time now.
> You nearly created another not-really "free trade" agreement with
> China.
> 

Unfair characterization based on the incorrect assumption contained
above. Perhaps you would do well to go through the APNIC policy
documents and have a quick read prior to posting broad assumptions
about what their policies say or do. I am not sure whether APNICs
current policy would implement reciprocity or not. I will, however,
ask APNIC staff for guidance on this aspect. I'm inclined to believe
that it would, actually, but, rather than speculate, I'll post again when
I have an authoritative answer.

> 
> I will now say "I told you so" in two respects:
> 
Premature at best.

> 1. This is why we send new text through parts two and three of the PDP
> instead of rushing them to last call in part 4. The vetting of this
> brand new text for draft 2011-1 has been inadequate and I doubt we've
> yet reached the bottom of the ways in which it abjectly fails to
> protect ARIN-region registrants in need of addresses.
> 

Continuing to harp on this point doesn't make it any more legitimate
than it was at the start. This is a relatively lightweight modification to
the existing proposal to bring it in line with the NRPM and incorporate
the feedback received from the community. At this point, yes, I believe
it needs more modification and another last call. I do not believe it
needs to go all the way back to step 2.

> 2. Asking the board to act as an experts group which certifies the
> compatibility of another region's policy, as I proposed both for this
> version of the text and for prior ones, would have avoided this
> problem and many others. ARIN staff does not have the Board's
> latitude; they must go by exactly what the policy says even if it
> obviously missed a beat.
> 

ARIN staff is able to implement policy in virtually any way that the
board instructs them to interpret or implement it. Absent input from
the board, of course they will go with the literal meaning and resolve
ambiguities as best they can in line with the CEO's interpretation
of "the right thing". That is all that can be expected of any organization.

In reality, the current policy will result in the CEO making such
determinations and I am quite sure that he will have board guidance
in the process (whether he wants it or not).

I really don't see how what you proposed would, in fact, change
anything other than to codify additional overhead in the process
which is most likely unnecessary.

Owen