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

Tue May 24 23:38:32 EDT 2011

The risk of including the requirement of agreement by the RIRs is that it
leaves transfers to their whim.

We could rephrase it in some way to presume that that transfer will go
through, but that either party reserves the right to reject the transfer out
or in.

Frank

From: Owen DeLong [mailto:owen at delong.com] 
Sent: Tuesday, May 24, 2011 1:18 AM
To: frnkblk at iname.com
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3

There may be some other policy or legal reason that either RIR may wish to
block the

transfer and I want to give staff the ability to address unforeseen
circumstances in a

complicated and shifting environment that could change without input through
our

PDP by doing the closest they can come to "the right thing" based on sound
judgment

rather than being ratholed by our policy which cannot possibly adapt fast
enough.

Owen

On May 23, 2011, at 10:00 PM, Frank Bulk wrote:

Can you explain why?  It's not that ARIN-2011-1 binds the non-ARIN RIR to
receive the netblock.

Frank

From: Owen DeLong [mailto:owen at delong.com] 
Sent: Monday, May 23, 2011 11:56 PM
To: frnkblk at iname.com
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3

I prefer to preserve the safety valve of requiring agreement from both RIRs.

Owen

On May 23, 2011, at 8:53 PM, Frank Bulk wrote:

Why don't we change the second point to:

+ to another RIR, for transfer to a specified recipient in that RIR's
service

region, if the request meets both RIRS' transfer policies.

Frank

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Scott Leibrand
Sent: Monday, May 23, 2011 5:17 PM
To: Mike Burns
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3

On Mon, May 23, 2011 at 3:00 PM, Mike Burns <mike at nationwideinc.com> wrote:

Hi Scott,

In the context of this proposal, may I ask what would happen if APNIC
accepted a transfer of ARIN legacy addresses and updated their Whois, even
if ARIN refused the transfer?

I suppose what would matter in that case is who IANA pointed to.  To date,
we haven't seen cases where two different RIRs were both claiming authority
for the same address block, and I don't expect to see that, as all of the
RIRs are committed to operating within the "RIR system".

(Because the language of the proposal pointedly excludes APNIC, if their
current policy remains in place.)

I know that ARIN could revoke and reissue.

How is inter-RIR conflict resolved, is there a process in place for conflict
resolution?

Yes, I believe there is, but I don't know the details.  I presume it would
be a largely consensual process within the ASO/NRO/IANA framework (perhaps
within the NRO EC?).

Do the RIRs generally have compatible needs-based transfer policies, I mean
I know APNIC doesn't, but do the other RIRs have the same 3-month window,
for example?

Is a difference in the needs window enough to prevent a transfer?

If so, do we need to consider other RIRs  and the impact on inter-RIR
transfers when we consider proposals to change the needs window?

What if RIPE joins APNIC with a requirement like a /24 maximum, is that
something that makes the needs requirements incompatible?

I don't consider any such differences in timeframes, size minimums/maximums,
etc. to be incompatibilities in the context of 2011-1.  But ARIN has said
that, as things stand today, the lack of explicit needs basis in APNIC's
transfer policy would make it incompatible with 2011-1's requirement for
"compatible, needs-based transfer policies".  I hope we can come to an
agreement with the APNIC community on language or interpretation that would
be compatible with both regions' needs and preferences, but 2011-1 as I see
it is just the first step in that direction: setting up a framework that
would allow inter-RIR transfers once such incompatibilities are resolved
somehow (or with other RIRs where such incompatibilities may not exist).

I guess I am asking for a more detailed definition of the word "compatible"
in your proposed language.

Maybe that language is extraneous, as you are already requiring both RIRs to
agree?

Operationally, the two are quite related, in that ARIN will not agree unless
they assess the other RIR's transfer policy to be compatible.  But the "RIRs
agree" language is also there as a safety valve to explicitly allow an RIR
to not agree to a transfer if it has reason to believe that the transfer
would violate policy or law.

-Scott  (speaking only for myself, as usual)

----- Original Message -----

From: Scott Leibrand <mailto:scottleibrand at gmail.com> 

To: Owen DeLong <mailto:owen at delong.com> 

Cc: ARIN-PPML List <mailto:arin-ppml at arin.net> 

Sent: Monday, May 23, 2011 5:21 PM

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

On Mon, May 23, 2011 at 2:05 PM, Owen DeLong <owen at delong.com> wrote:

I could support this, but, I have a couple of lingering concerns.

I think that the last sentence dictates too much in the case of a transfer
to another region and should only apply to transfers within the ARIN region.

Yeah, I was wondering about that myself.  Possible slight revision inline
below...

I would like to see us relocate the

single aggregate clause to make it binding on the actual community intent
and if we're

going to turn 2011-1 into a policy to modify 8.3 anyway, we should
incorporate that

change.

I would like to see another proposal to do this (and to be discussed as a
counterpoint to ARIN-prop-144 in Philadelphia). 

On May 23, 2011, at 15:54, Scott Leibrand <scottleibrand at gmail.com> wrote:

In light of the discomfort a number of community and AC members feel with
the original 2011-1 text, I thought I'd make an attempt at integrating it
into the framework of NRPM 8.3, to see if the result would be tighter and
less ambiguous.  Here's what I came up with:

8.3. Transfers to Specified Recipients

In addition to transfers under section 8.2, IPv4 number resources may be
released to ARIN by the authorized resource holder, in whole or in part, for
transfer:

*	to a specified organizational recipient within the ARIN region, or 
*	to another RIR, for transfer to a specified organizational recipient
in that RIR's service region, if the two RIRs agree and maintain compatible,
needs-based transfer policies.

Such transferred number resources may only be received under RSA by
organizations that can demonstrate the need for such resources, as a single
aggregate, in the exact amount which they can justify under current ARIN
policies.  

How about "Such number resources may only be received under RSA by
organizations that can demonstrate the need for such resources, as a single
aggregate, in the exact amount which they can justify under current ARIN, or
recipient RIR, policies." ?

Or, feel free to suggest text...

-Scott

For reference, existing policy reads:
8.3. Transfers to Specified Recipients

In addition to transfers under section 8.2, IPv4 number resources within the
ARIN region may be released to ARIN by the authorized resource holder, in
whole or in part, for transfer to another specified organizational
recipient. Such transferred number resources may only be received under RSA
by organizations that are within the ARIN region and can demonstrate the
need for such resources, as a single aggregate, in the exact amount which
they can justify under current ARIN policies.

And original 2011-1 text reads:

Any RIR's resource registrant may transfer IPv4 addresses to the resource
registrant of another RIR as long as the two RIRs agree and maintain
compatible, needs-based transfer policies that exercise Internet stewardship
consistent with the values expressed in RFC2050.

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

  _____  

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

=

= 

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