[arin-ppml] Should inter-regional transfers be part of 8.3? Was: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
Owen DeLong
owen at delong.com
Thu Oct 20 22:01:18 EDT 2011
Sent from my iPad
On Oct 20, 2011, at 11:47 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> Thanks, Bill, for summarizing your suggested changes.
>
> Does anyone in the community have input on Bill's item #1 (whether 2011-1 should be part of 8.3, or separated out as 8.4)?
>
> Further comments inline...
>
> On Thu, Oct 20, 2011 at 12:58 PM, William Herrin <bill at herrin.us> wrote:
> On Thu, Oct 20, 2011 at 3:04 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> > But I was hoping you (and anyone else with ideas) could provide actual
> > constructive feedback on how the text could be improved. If such
> > suggestions are being provided here on list, we can discuss whether they are
> > potential improvements we should incorporate.
>
> Hi Scott,
>
> 1. Pull it out of section 8.3 and put it in its own section 8.4. At no
> time in the process do I recall the community express a desire to
> tamper with section 8.3 as part of the inter-region transfer process.
> While such integration may become desirable in the future it is, IMHO,
> not desirable now. We should implement, learn from and tune the
> inter-region policy long before considering whether or how to
> integrate it with the in-region transfer policy.
>
> I personally disagree, but I think it's a valid point, and would be happy to adjust the text accordingly if the community agrees that we should do so.
I don't care one way or the other on this one. I think worrying about it amounts to getting wrapped around the axle on process rather than focusing on whether the policy actually reflects the intent of the community. The placement of the wording is much less relevant than the actual effect the words have.
I'm fine with moving it to 8.4. I'm fine with leaving it in 8.3. However, what I don't want to do is make a silly positioning change and have to repeat last call without any substantive change to the meaning of the policy.
>
>
> 2. Earlier drafts required potential recipients to meet the
> eligibility criteria set by BOTH regions. While this increases the
> hassle factor associated with transferring addresses in or out of the
> region, I believe it provides a valuable safeguard for this, our first
> attempt at inter-region transfers. If, over time, we find that it's
> all hassle for no benefit, we can remove it.
>
> When that was put in place prior to the APNIC Busan meeting, I agree it was a valuable safeguard. But now that all the RIRs' transfer policies are needs-based, I believe this would just be an extra hassle with no real benefit. In addition, part of APNIC's reason for re-adding needs basis to their transfer policy was to avoid having to justify needs to ARIN. So in addition to being unnecessary, I believe a requirement to have ARIN do such a needs justification on out-of-region transfer recipients is harmful to the spirit of inter-RIR cooperation.
>
> It's also worth noting that this topic was discussed in Philly, and my sense of the room was that there was a consensus for the destination RIR doing the needs assessment.
>
Yes and no. I think that the current text contains adequate safeguards, but, I will point out that APNIC needs based policy is in last call, it is not yet fully ratified, let alone implemented. I hope that this proposal is sufficiently clear that ARIN staff will not agree to transfers with APNIC until such time as APNIC has completed the implementation of their needs-based policy.
I also think that we should remain aware that other RIRs could change their policies at any time independent of ours. That is why we chose to keep the terms "compatible needs-based" and "agreement of both RIRs" in the policy. I believe those provide safeguards and allow staff discretion to reject transfers that should not occur.
>
> 3. Who determines that ARIN and another RIR "share compatible,
> needs-based policies?" Unless we set out explicit criteria, this is an
> open-ended policy-level question which should be decided by
> policy-level people, i.e. the Board. NOT by staff. I offered this
> criticism on the earlier drafts as well and I'm disappointed to see it
> hasn't been addressed.
>
> We discussed this. John can elaborate, but the gist was that an RIR with a transfer policy that requires that a transfer recipient justify need to their RIR would be a compatible transfer policy. By contrast, a transfer policy where the transfer recipient simply must attest that they have need would not be compatible. I believe that is exactly what the community wants here, so I don't see this as an issue.
>
Yes, I actually agree. As much as I find this whole transfer thing distasteful and would prefer that it was practical to simply require organizations no longer using space to return it, that's not the reality we are faced with.
While I understand your desire to have these decisions made at the board and not the staff level, the reality is that in this case, staff can consult the board on a case-by-case basis if needed if we provide them a policy with sufficient latitude and I trust the board (and John) not to let staff get too far out into the weeds with their discretion. They have a pretty good track record. OTOH, if we were to make a rigid policy here, it could be very difficult for staff to adapt to quickly changing situations and might even complicate the board making a determination on a specific case as well.
I'm sure we'll spend significant resources continuing to fine tune section 8 over the next several policy cycles. For the time being, I think that this represents a significant step in the right direction.
>
> I have some other nitpicks, but without first correcting these large
> issues, I'm with Marty: good try but you failed to capture the
> community's intent. The newly written draft would benefit from another
> cycle of discussion, modification and presentation so that it can move
> forward with consensus on the actual policy language.
>
Thanks, Bill... That's good and useful feedback. I hope others in the community will let us know if they agree with you or if they feel that this policy as is (or with additional changes and another last call) should move forward without waiting for another policy cycle.
Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111021/3fffbc9b/attachment.htm>
More information about the ARIN-PPML
mailing list