[arin-ppml] Policy Proposal 2008-2: IPv4Transfer Policy Proposal -Revised

Kevin Kargel kkargel at polartel.com
Thu Sep 18 14:26:58 EDT 2008 

But....  If we are not going to follow through, if we are not going to
police the rule..  Then what point is there to the rule?  

The answer is just to state that "physical addresses for all registrant
parties for all registrations, requests and/or transfers must be in the
'ARIN Service Area' " then define the ARIN service area..  Then it is
simple..  No policing, no impotent rules.



> -----Original Message-----
> From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] 
> Sent: Thursday, September 18, 2008 1:19 PM
> To: Kevin Kargel; PPML PPML
> Subject: RE: [arin-ppml] Policy Proposal 2008-2: IPv4Transfer 
> Policy Proposal -Revised
> 
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net
> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> > Sent: Thursday, September 18, 2008 2:01 PM
> > To: PPML PPML
> > Subject: Re: [arin-ppml] Policy Proposal 2008-2: 
> IPv4Transfer Policy 
> > Proposal -Revised
> > 
> > Ah, so if Mitsuyama Corp in Japan wants an ARIN IP block they just 
> > need to get a mailing address in the US for the transfer 
> process, give 
> > the US corporation a bunch of money, get posession of the IP's, and 
> > abandon the CONUS mailing address..  Then they are operating within 
> > the policy and everything is ok..
> 
> Yes.  This is the current situation.  It doesn't come up, 
> because the integers in North American taste just the same as 
> the integers in the Asia Pacific region.
> 
> However, ARIN should not facilitate transfers from 
> extra-regional organizations, because ARIN doesn't have 
> authority over those numbers.
> 
> > It doesn't look like we are solving anything..  Just making another 
> > red tape loop..
> 
> The fact that a barrier is imperfect does not mean it should 
> not be built.  
> 
> First decide if a barrier is desirable.  The build the 
> appropriate barrier.  In this case, ARIN serves the ARIN 
> region, so except where desired, policy should not provide 
> for allocations outside the region.
> 
> Not a Board product.  IMHO, YMMV, IANAL, PEBCAK, TANSTAAFL, 
> floss regularly, tip your waitstaff, wear sunscreen, void 
> where prohibited.
> 
> Lee
> 
> 
> 
> > > -----Original Message-----
> > > From: Owen DeLong [mailto:owen at delong.com]
> > > Sent: Thursday, September 18, 2008 12:50 PM
> > > To: Kevin Kargel
> > > Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > Transfer Policy
> > > Proposal -Revised
> > > 
> > > 
> > > On Sep 18, 2008, at 10:39 AM, Kevin Kargel wrote:
> > > 
> > > > By "space" do you mean IP space or geo-space?
> > > >
> > > IP Space.
> > > 
> > > > In either case I still think the best solution is just 
> to forward 
> > > > requests from outside of "ARIN space" to the appropriate
> > registry..
> > > >
> > > The problem comes when you have an ORG that is within the
> > ARIN service
> > > Region trying to transfer ARIN registered space to an ORG that is 
> > > outside of the ARIN service region or vice versa.
> > > 
> > > The best thing is, IMHO, to clarify that ARIN policy only covers 
> > > transfers of IP Resources administered by ARIN between 
> two parties 
> > > within the ARIN service region.
> > > 
> > > Owen
> > > 
> > > >> -----Original Message-----
> > > >> From: Owen DeLong [mailto:owen at delong.com]
> > > >> Sent: Thursday, September 18, 2008 11:37 AM
> > > >> To: Kevin Kargel
> > > >> Cc: arin-ppml at arin.net
> > > >> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > > Transfer Policy
> > > >> Proposal -Revised
> > > >>
> > > >> Not so much.  The different registries have different transfer 
> > > >> policies (if they have any at all).  I think the best
> > thing is to
> > > >> make sure that ARIN policy applies to space which is
> > > administered by
> > > >> ARIN and leave it at that.
> > > >>
> > > >> Owen
> > > >>
> > > >> On Sep 18, 2008, at 7:58 AM, Kevin Kargel wrote:
> > > >>
> > > >>> I think this is more of an operational issue than a
> > policy issue.
> > > >>> Wouldn't it be better to work out a referral agreement with
> > > >> the other
> > > >>> registries where you refer requests to the proper registrar
> > > >> and they
> > > >>> refer requests to ARIN?  I don't know how you would do this
> > > >> other than
> > > >>> based on registration address, and there would be nothing
> > > >> preventing
> > > >>> the Tanzania hosting company from registering their
> > > network with a
> > > >>> Canadian address..
> > > >>>
> > > >>> Much the same situation exists with maritime ship
> > > >> registrations..  I
> > > >>> don't really see how to avoid or manage the issue.
> > > >>>
> > > >>> To restate my earlier posit..  Let's not make rules we
> > > >> can't enforce.
> > > >>>
> > > >>>
> > > >>>> -----Original Message-----
> > > >>>> From: Scott Leibrand [mailto:sleibrand at internap.com]
> > > >>>> Sent: Thursday, September 18, 2008 9:15 AM
> > > >>>> To: Kevin Kargel
> > > >>>> Cc: arin-ppml at arin.net
> > > >>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > > >> Transfer Policy
> > > >>>> Proposal -Revised
> > > >>>>
> > > >>>> It doesn't say it must be used in North America.  It says
> > > >> it must be
> > > >>>> *registered* for use there.  That means it must be
> > > registered with
> > > >>>> ARIN.
> > > >>>>
> > > >>>> This is not (intended to be) a new restriction: we're just
> > > >> trying to
> > > >>>> avoid having people come to us with LACNIC, AFRINIC, RIPE,
> > > >> or APNIC
> > > >>>> space and asking ARIN to transfer it.
> > > >>>>
> > > >>>> As I mentioned before, suggestions for improved wording
> > > >> are welcome.
> > > >>>>
> > > >>>> -Scott
> > > >>>>
> > > >>>> Kevin Kargel wrote:
> > > >>>>> I did not know that there was any way to control geographic
> > > >>>> use area..
> > > >>>>> So far as I know there is no way I can tell my router to
> > > >>>> deny from Tanzania..
> > > >>>>> (sorry Tanzania, I don't hate you, I just had to pick
> > > somebody)..
> > > >>>>>
> > > >>>>> Is there some BGP trick I don't know about that
> > > prevents me from
> > > >>>>> advertising an out of area network?
> > > >>>>>
> > > >>>>> If it cannot be policed then it shouldn't be in the
> > > >>>> verbage.  Nothing
> > > >>>>> will erode authority quicker than making rules you
> > > cannot enforce.
> > > >>>>>
> > > >>>>>
> > > >>>>>> -----Original Message-----
> > > >>>>>> From: arin-ppml-bounces at arin.net 
> > > >>>>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of
> > Scott Leibrand
> > > >>>>>> Sent: Thursday, September 18, 2008 8:55 AM
> > > >>>>>> To: michael.dillon at bt.com
> > > >>>>>> Cc: arin-ppml at arin.net
> > > >>>>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > > >>>> Transfer Policy
> > > >>>>>> Proposal -Revised
> > > >>>>>>
> > > >>>>>> michael.dillon at bt.com wrote:
> > > >>>>>>>> * The IPv4 block must currently be registered for use
> > > >>>>>> within the ARIN
> > > >>>>>>>> service area.
> > > >>>>>>> What does this mean?
> > > >>>>>> The intent there is that it simply has to be ARIN space.
> > > >>>>>> We're open to suggestions for improved wording.
> > > >>>>>>
> > > >>>>>>> Since when does ARIN restrict the use of IP address blocks
> > > >>>>>> to specific
> > > >>>>>>> geographical regions? Does the ARIN restriction apply only
> > > >>>>>> to use as a
> > > >>>>>>> source address, or also in the destination address field?
> > > >>>>>>>
> > > >>>>>>> To which organization should one apply if one want to
> > > >> receive IP
> > > >>>>>>> address blocks which can be used globally without
> > geographic
> > > >>>>>>> restrictions?
> > > >>>>>> I don't believe IANA has any intent to distribute
> > > >> address space to
> > > >>>>>> ISPs or end users that can be used globally without
> > geographic
> > > >>>>>> restrictions.  In the current system, addresses are
> > > >> allocated from
> > > >>>>>> the registry in the region in which they are primarily
> > > >> to be used,
> > > >>>>>> and we aren't trying to upset that apple cart just yet.
> > > >>>>>>
> > > >>>>>> -Scott
> > > >>>>>>
> > > >>>>>> _______________________________________________
> > > >>>>>> 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.
> > > >>>>
> > > >>> _______________________________________________
> > > >>> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080918/68641f60/attachment.bin>

More information about the ARIN-PPML mailing list