[arin-ppml] ARIN-prop-183 Section 8.4 Transfer enhancement

Martin Hannigan hannigan at gmail.com
Tue Oct 30 16:32:43 EDT 2012


On Tue, Oct 30, 2012 at 4:11 PM, David Farmer <farmer at umn.edu> wrote:
> Sorry about that last message it escaped.
>
>
> On 10/30/12 11:05 , Martin Hannigan wrote:
>
>> We saw that with regional ASN transfers that once you provided the
>> mechanism, it was utilized. We knew the demand was there since many
>> knew of the quite public secret that ASN's were traded on a regular
>> basis. I'm not sure how someone could assert that this wasn't also
>> happening internationally.
>
>
> I have no doubt, but the other RIR's need to decide to implement ASN
> Transfers for themselves, ARIN shouldn't and I don't think can force them to
> implement ASN transfers that is for those communities to decide.
>

That's not what is being proposed. Just because ARIN makes something
available does not mean that another region has to do anything. We
learned that with the first version of inter-rir transfer which was a
global policy that tried to implicitly set conditions that would
normally be under the other RIR's control. We still did it in this
regional version of inter-rir transfer and forced the others to
require need.

That skullduggery is already complete. This proposal simply allows for
ASN's to be more reliably documented. I'm not sure where it implies
that anyone has to do anything other than to do what they already do
except do it in the light instead of in the dark.

>
>> Section 5 of the APNIC inter-rir transfer might be interpreted to
>> accommodate this type of transfer as well as RIPE 2012-7 since it
>> doesn't differentiate a legacy "internet resource". I can't speak for
>> the policy proposers in the RIPE region and nor do I pretend to, but
>> in the latter case, it's possible that we don't need this proposal at
>> all since theoretically, the RIPE region proposal (if adopted) clearly
>> states the definition of a legacy resources as prior to the creation
>> of the RIPE NCC and does not differentiate between ASN's and IP
>> addresses. One might also assume that based on the language  you might
>> be able to bring your resource directly to the RIPE NCC, get their
>> services agreement which if adopted would be much more conducive to
>> retaining the value of a resource, and simply register the transfer
>> there.
>
>
> Both of these seem to be fairly specific in dealing with Resources that are
> already under the control of APNIC or RIPE as part of Early Registration
> Transfers (ERX).  Not general Inter-RIR transfers as envisioned by 8.4 of
> ARIN's NRPM or section 4 of APNIC's transfer policy.
>

I think we can agree to disagree. I would assume that is the case in
the APNIC region, but no so much in the RIPE region. It will be
interesting to see 2012-7 play out since it appears to have great and
constructive interest in the RIPE region.


>
>> Making it "easy" to utilize ARIN's process, even if it turns out to be
>> inferior to other regions, has value. It makes a transfer cheaper for
>> one thing and instills a level of trust on the part of a US based
>> transferee since familiarity with a legal system is part of that trust
>> mechanism. It also insures that the supply of ASN's is efficiently
>> used and that the all important registry is updated and as accurate as
>> possible. I thought the latter part was the important bit to be
>> honest.
>
>
> Section 8.4 is fairly specific that there needs to be a reciprocal policy at
> the other RIR, if you remember I argued against that, but that is ARIN's
> policy.
>

+1


> I'm willing to accept this on to the docket in order to not create a
> catch-22, and make it clear ARIN is willing to consider this of other RIRs
> are too.  However, I'm not sure significant effort should be put into it
> until at least ASN transfers have been proposed at another RIR.
>

Why bother working on policy if you aren't going to take it seriously?
That also implies that we don't take registry accuracy seriously FWIW.


Best,

-M<



More information about the ARIN-PPML mailing list