From jaymartin926 at gmail.com  Tue Apr  1 01:48:07 2014
From: jaymartin926 at gmail.com (Jay Martin)
Date: Mon, 31 Mar 2014 22:48:07 -0700
Subject: [arin-ppml] Subject: ARIN Draft Policy 2014-2 Improved 8.4
	Anti-Flip Language
Message-ID: <CALJtNObcjm08RmMRPscL+rnVOjxnF829bmcZcHGD=kUNy4RyPw@mail.gmail.com>

*Hello community, *




Message: 1

Date: Wed, 5 Mar 2014 21:17:58 +0000

From: David Huberman <David.Huberman at microsoft.com>

To: Bill Darte <billdarte at gmail.com>, "arin-ppml at arin.net"

<arin-ppml at arin.net>, Owen DeLong <owen at delong.com>

Subject: Re: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4

Anti-Flip Language

Message-ID:

<87b03e32ad2743559958047e94c94044 at DM2PR03MB398.namprd03.prod.outlook.com>


Content-Type: text/plain; charset="us-ascii"


As the author of this proposal, and having encountered the real-world
consequences of existing 8.4 anti-flip language, I support #3 as the
cleanest, simplest approach that best promotes Whois accuracy.



*Can you specify what have you encountered in the real world ? which
finally "inspire" you to write this proposal.  I think your company is so
selfish and what your cared is your own company.  Keep buying ip and
**pla**nning
to transfer them into Asia Pacific region; meanwhile drain out of the IPs
from the remained Arin pool. *



ARIN is a registry, not a regulator. Let's write policy that promotes
accuracy in Whois, please.



*As a member of the community,   i consider that you are a hypocrite.
Your so-call  caring about ARIN  accuracy in whois is just an excuse for
you to protect your company's benefit.   *


*Let me expose what your intention behind this proposal, i think the
community deserve the right to see your true face. *

*What you want to do is to help your own company to  easily transfer either
the purchased ip  or the old allocated ip from Arin into the Asia Pacific
region; meanwhile  your company is able to keep squeezing and draining  the
remained free pool of Arin. *


*Your support of #3 will make it easy for your company to transfer ip into
Asia Pacific,    which will create a "the needs of Arin IP badly" image in
the local  ARIN region.   Your purchased /13  from that bankruptcy is the
justification of your company's needs in Arin region. Now you want a policy
to help your company to transfer the "old" and " purchase" ip to Asia
Pacific( you must be a good liar at making your justification to be
approved by Arin), which will not affect your continuing application of big
chunk block from Arin.     *


*The system has already been established to take care of giant baby like
your company  and leave the smaller organisations without chance to have
their deserved ip and suffer.*


*Wake up the community.  Do you want this hypocrite to dry up the free
pool?*

*I am against this proposal, it will only open the doors for some  players
to drain up the free pool of ARIN quickly. *


*Jay*



David R Huberman

Microsoft Corporation

Senior IT/OPS Program Manager (GFS)

________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140331/6e5002ce/attachment.htm>

From billdarte at gmail.com  Tue Apr  1 10:35:29 2014
From: billdarte at gmail.com (Bill Darte)
Date: Tue, 1 Apr 2014 09:35:29 -0500
Subject: [arin-ppml] Subject: ARIN Draft Policy 2014-2 Improved 8.4
	Anti-Flip Language
In-Reply-To: <CALJtNObcjm08RmMRPscL+rnVOjxnF829bmcZcHGD=kUNy4RyPw@mail.gmail.com>
References: <CALJtNObcjm08RmMRPscL+rnVOjxnF829bmcZcHGD=kUNy4RyPw@mail.gmail.com>
Message-ID: <CAMApp36dtrtYWu6uJ-Fe2VnkrD7OQzNUeAp_PO5xSxNsvKW92A@mail.gmail.com>

Jay,

I appreciate that you have a view to express that is opposed to the Draft
Policy.  I understand that you may even be upset about it and that you
believe that the motivation is contrary to the community's interest. But I
think that your personalized attack on the author is unwarranted and
outside both the spirit of and stated Acceptable Use Policy for the PPML.

You may find the specific rules at
https://www.arin.net/participate/mailing_lists/aup.html

Bill Darte
AC Shepherd
ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip Language


On Tue, Apr 1, 2014 at 12:48 AM, Jay Martin <jaymartin926 at gmail.com> wrote:

>
> *Hello community, *
>
>
>
>
> Message: 1
>
> Date: Wed, 5 Mar 2014 21:17:58 +0000
>
> From: David Huberman <David.Huberman at microsoft.com>
>
> To: Bill Darte <billdarte at gmail.com>, "arin-ppml at arin.net"
>
> <arin-ppml at arin.net>, Owen DeLong <owen at delong.com>
>
> Subject: Re: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4
>
> Anti-Flip Language
>
> Message-ID:
>
> <87b03e32ad2743559958047e94c94044 at DM2PR03MB398.namprd03.prod.outlook.com>
>
>
> Content-Type: text/plain; charset="us-ascii"
>
>
> As the author of this proposal, and having encountered the real-world
> consequences of existing 8.4 anti-flip language, I support #3 as the
> cleanest, simplest approach that best promotes Whois accuracy.
>
>
>
> *Can you specify what have you encountered in the real world ? which
> finally "inspire" you to write this proposal.  I think your company is so
> selfish and what your cared is your own company.  Keep buying ip and *
> *pla**nning to transfer them into Asia Pacific region; meanwhile drain
> out of the IPs from the remained Arin pool. *
>
>
>
> ARIN is a registry, not a regulator. Let's write policy that promotes
> accuracy in Whois, please.
>
>
>
> *As a member of the community,   i consider that you are a hypocrite.
> Your so-call  caring about ARIN  accuracy in whois is just an excuse for
> you to protect your company's benefit.   *
>
>
> *Let me expose what your intention behind this proposal, i think the
> community deserve the right to see your true face. *
>
> *What you want to do is to help your own company to  easily transfer
> either the purchased ip  or the old allocated ip from Arin into the Asia
> Pacific region; meanwhile  your company is able to keep squeezing and
> draining  the remained free pool of Arin. *
>
>
> *Your support of #3 will make it easy for your company to transfer ip into
> Asia Pacific,    which will create a "the needs of Arin IP badly" image in
> the local  ARIN region.   Your purchased /13  from that bankruptcy is the
> justification of your company's needs in Arin region. Now you want a policy
> to help your company to transfer the "old" and " purchase" ip to Asia
> Pacific( you must be a good liar at making your justification to be
> approved by Arin), which will not affect your continuing application of big
> chunk block from Arin.     *
>
>
> *The system has already been established to take care of giant baby like
> your company  and leave the smaller organisations without chance to have
> their deserved ip and suffer.*
>
>
> *Wake up the community.  Do you want this hypocrite to dry up the free
> pool?*
>
> *I am against this proposal, it will only open the doors for some  players
> to drain up the free pool of ARIN quickly. *
>
>
> *Jay*
>
>
>
> David R Huberman
>
> Microsoft Corporation
>
> Senior IT/OPS Program Manager (GFS)
>
> ________________________________
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140401/4a55310d/attachment.htm>

From hannigan at gmail.com  Tue Apr  1 10:58:07 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 1 Apr 2014 10:58:07 -0400
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <CAMDXq5PNBYH0+hhwCx-YsjXfZbomeE-RB+GY-Hb40CjvqLWc-Q@mail.gmail.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<5335A9D1.7020506@umn.edu>
	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
	<533763FC.7030302@matthew.at>
	<BD23C833-0608-4F05-9F39-8D11709052F1@arin.net>
	<53378659.60605@matthew.at>
	<A36E7C47-7D8C-45E6-8E23-5286B1A58ADB@arin.net>
	<CAMDXq5MwkbT=2QHZYGV1kWkVeTxmbhM_q8g7F_g-sR4rHs3k3Q@mail.gmail.com>
	<2DA95900-8FCB-484E-B998-5D1E1E1A7E75@arin.net>
	<CAMDXq5PNBYH0+hhwCx-YsjXfZbomeE-RB+GY-Hb40CjvqLWc-Q@mail.gmail.com>
Message-ID: <CAMDXq5ML8cjx1S7xd8XDqMVg554BWtwCD8X5oR5xDS7+Ee44LQ@mail.gmail.com>

On Mon, Mar 31, 2014 at 4:59 PM, Martin Hannigan <hannigan at gmail.com> wrote:
> On Mon, Mar 31, 2014 at 4:52 PM, John Curran <jcurran at arin.net> wrote:
>> On Mar 31, 2014, at 3:11 PM, Martin Hannigan <hannigan at gmail.com> wrote:
>>
>>> On Sun, Mar 30, 2014 at 5:00 AM, John Curran <jcurran at arin.net> wrote:
>>>>
>>>> NRPM 11 was designed for parties requesting allocations from ARIN for
>>>> research purposes; not ARIN checking the quality/integrity of new block
>>>> received from IANA.  Given the recent occurance, I believe it is prudent
>>>> for ARIN to utilize NRPM 11 going forward for purposes of this quality
>>>> checking, as it makes visible the organization doing the testing/making
>>>> use of the space, including duration of the activity and research nature,
>>>> as well as reaffirming the expected uniqueness requirement.
>>>
>>> If I understand this correctly, Matthew suggested that an update to
>>> Section 11 would be more useful? If that's the case I agree. It would
>>> require a few, simple, modifications.
>>
>> I think his suggestion to make use of NRPM 11 for this purpose is quite
>> excellent.   It was not process that we used in the past, but shall be
>> done that way going forward.   To the extent that the community wishes
>> to improve NRPM 11 policy text for this purpose of address space testing,
>> that is also welcome.
>>
>>> Why would ARIN ever need to issue an LOA if whatever is distributed is
>>> in the registry? All the LOA responsibilities if even needed at that
>>> point would fall to the registrant.
>>
>> Agreed; that is the major benefit of taking an "NRPM 11" approach to address
>> space testing - ARIN stays focused on being a registry and leaves the use of
>> address space to registrants.  Since registrants are unique for a given address
>> block, we also preempt multiple parties with potentially conflict plans on the
>> use (or routing) of any given portion of address space.
>>
>
>
> Yes, I agree. This is the preferable route.
>
> Best,
>
> -M<


To add to this, it appears that we can condense most of the hand
waving down to a modification in Section 11.4 that adds to the end of
the paragraph "All resource assignments will be registered in the ARIN
WHOIS database and in a manner not conflicting with any other
registrations". Or any other language that would accomplish the same
thing.

We ought not to specifically restrict ARIN from writing an LOA. There
may be a circumstance where it is necessary and fully legitimate.
Admittedly, the instances where it would be needed would be corner
cases, but operators in the AP region, for example, are very strict
and I've had some strange reasons for writing LOA for my own prefixes.
It may also interfere with the encumbrance testing that John
mentioned. I suspect there are also some other tricky authority
questions.

This sounds like a legitimate error to me so this should be enough to
instill a codified message that we want registrations and self
service. Anything else needs more attention.

Best,

-M<


From csquat at ccsd.net  Tue Apr  1 11:00:17 2014
From: csquat at ccsd.net (Chris R. Squatritto)
Date: Tue, 01 Apr 2014 08:00:17 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 1
Message-ID: <fc.004c4e074f28d7153b9aca0024517fdb.4f28d71b@interact.ccsd.net>

I am out of the office this week and will not be checking email.  Please
contact Troy Miller for assistance..

Thank you for contacting me, and have a great day.

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

From kkargel at polartel.com  Tue Apr  1 11:31:12 2014
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 1 Apr 2014 10:31:12 -0500
Subject: [arin-ppml] Subject: ARIN Draft Policy 2014-2 Improved
	8.4	Anti-Flip Language
In-Reply-To: <CAMApp36dtrtYWu6uJ-Fe2VnkrD7OQzNUeAp_PO5xSxNsvKW92A@mail.gmail.com>
References: <CALJtNObcjm08RmMRPscL+rnVOjxnF829bmcZcHGD=kUNy4RyPw@mail.gmail.com>
	<CAMApp36dtrtYWu6uJ-Fe2VnkrD7OQzNUeAp_PO5xSxNsvKW92A@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD2801364551E6@MAIL1.polartel.local>

While I want to say I did not appreciate the violence of the original message I do agree with the sentiment.  Let's not make it easy to siphon off ARIN resources.

Kevin


From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Darte
Sent: Tuesday, April 01, 2014 9:35 AM
To: Jay Martin
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Subject: ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip Language

Jay,

I appreciate that you have a view to express that is opposed to the Draft Policy.  I understand that you may even be upset about it and that you believe that the motivation is contrary to the community's interest. But I think that your personalized attack on the author is unwarranted and outside both the spirit of and stated Acceptable Use Policy for the PPML.

You may find the specific rules at https://www.arin.net/participate/mailing_lists/aup.html

Bill Darte
AC Shepherd
ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip Language

On Tue, Apr 1, 2014 at 12:48 AM, Jay Martin <jaymartin926 at gmail.com<mailto:jaymartin926 at gmail.com>> wrote:



Hello community,







Message: 1

Date: Wed, 5 Mar 2014 21:17:58 +0000

From: David Huberman <David.Huberman at microsoft.com<mailto:David.Huberman at microsoft.com>>

To: Bill Darte <billdarte at gmail.com<mailto:billdarte at gmail.com>>, "arin-ppml at arin.net<mailto:arin-ppml at arin.net>"

<arin-ppml at arin.net<mailto:arin-ppml at arin.net>>, Owen DeLong <owen at delong.com<mailto:owen at delong.com>>

Subject: Re: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4

Anti-Flip Language

Message-ID:

<87b03e32ad2743559958047e94c94044 at DM2PR03MB398.namprd03.prod.outlook.com<mailto:87b03e32ad2743559958047e94c94044 at DM2PR03MB398.namprd03.prod.outlook.com>>



Content-Type: text/plain; charset="us-ascii"



As the author of this proposal, and having encountered the real-world consequences of existing 8.4 anti-flip language, I support #3 as the cleanest, simplest approach that best promotes Whois accuracy.





Can you specify what have you encountered in the real world ? which finally "inspire" you to write this proposal.  I think your company is so selfish and what your cared is your own company.  Keep buying ip and planning to transfer them into Asia Pacific region; meanwhile drain out of the IPs from the remained Arin pool.






ARIN is a registry, not a regulator. Let's write policy that promotes accuracy in Whois, please.





As a member of the community,   i consider that you are a hypocrite.   Your so-call  caring about ARIN  accuracy in whois is just an excuse for you to protect your company's benefit.



Let me expose what your intention behind this proposal, i think the community deserve the right to see your true face.

What you want to do is to help your own company to  easily transfer either the purchased ip  or the old allocated ip from Arin into the Asia Pacific region; meanwhile  your company is able to keep squeezing and draining  the remained free pool of Arin.



Your support of #3 will make it easy for your company to transfer ip into Asia Pacific,    which will create a "the needs of Arin IP badly" image in the local  ARIN region.   Your purchased /13  from that bankruptcy is the justification of your company's needs in Arin region. Now you want a policy to help your company to transfer the "old" and " purchase" ip to Asia Pacific( you must be a good liar at making your justification to be approved by Arin), which will not affect your continuing application of big chunk block from Arin.



The system has already been established to take care of giant baby like your company  and leave the smaller organisations without chance to have their deserved ip and suffer.



Wake up the community.  Do you want this hypocrite to dry up the free pool?

I am against this proposal, it will only open the doors for some  players to drain up the free pool of ARIN quickly.



Jay





David R Huberman

Microsoft Corporation

Senior IT/OPS Program Manager (GFS)

________________________________





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

From cgrundemann at gmail.com  Tue Apr  1 14:13:58 2014
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 2 Apr 2014 02:13:58 +0800
Subject: [arin-ppml] [arin-discuss]  Term Limit Proposal
In-Reply-To: <8335CAF4177E7A4CBC4670E5F9FA9B415EF4403C@CRC-Exchange02.corp.clearrate.net>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<CAP-guGVopDTYEJLMDpQqy8u-m0KU5FBDP_JEnTPLcy3w9i5WUg@mail.gmail.com>
	<CAMDXq5NJaRnqs2qip6xAPC57oX7tnN23s8M5U5_kX_61ugw_CQ@mail.gmail.com>
	<8335CAF4177E7A4CBC4670E5F9FA9B415EF4403C@CRC-Exchange02.corp.clearrate.net>
Message-ID: <CAC1-dtnpswRcs_VtQniJMMEhDusEtaJamGWQJc6S48S9U-DHig@mail.gmail.com>

On Tue, Apr 1, 2014 at 4:08 AM, Paul Timmins <ptimmins at clearrate.com> wrote:

> > ________________________________________
> > From: arin-discuss-bounces at arin.net [arin-discuss-bounces at arin.net] on
> behalf of Martin Hannigan [hannigan at gmail.com]
> > Sent: Monday, March 31, 2014 4:02 PM
> > To: William Herrin
> > Cc: arin-ppml at arin.net; arin-discuss at arin.net>
> > Subject: Re: [arin-discuss] [arin-ppml] Term Limit Proposal
> >
> > > I would NOT support this for the board. ARIN benefits from the board's
> > > continuity.
> >
> > If you really want change, term limit the Board and forget the AC.
>
> Do people really WANT change though? I think part of what helps the
> community at large is the predictability of policy w/r/t number allocation.
>

> A neutral entity controlling allocation uniformly per a generally stable
> policy provides a good regulatory environment for everyone, I'd think.
>

+1

NRPM stability is a good thing for both network operators and Internet
users.

Also, needed change seems to happen in the current frame work and I see no
indication that "more" change is a good thing without looking at the
specific changes. Which of course leads to the question: Perhaps some of
those advocating for term limits actually seek a very specific change, or
set of changes, that they believe they could achieve by taking over the AC
after booting out those who have repeatedly shown that they will support
the entire community rather than be bowled over by special interests?
Hmmm...

Food for thought,
~Chris



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



-- 
@ChrisGrundemann
http://chrisgrundemann.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140402/6a01e62d/attachment.htm>

From john.sweeting at twcable.com  Tue Apr  1 16:04:06 2014
From: john.sweeting at twcable.com (Sweeting, John)
Date: Tue, 1 Apr 2014 16:04:06 -0400
Subject: [arin-ppml] [arin-discuss]  Term Limit Proposal
In-Reply-To: <5031830E-8DC0-4FCF-AE14-B3E4A6D020D8@la-broadband.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<CAP-guGVopDTYEJLMDpQqy8u-m0KU5FBDP_JEnTPLcy3w9i5WUg@mail.gmail.com>
	<CAMDXq5NJaRnqs2qip6xAPC57oX7tnN23s8M5U5_kX_61ugw_CQ@mail.gmail.com>
	<8335CAF4177E7A4CBC4670E5F9FA9B415EF4403C@CRC-Exchange02.corp.clearrate.net>
	<CAC1-dtnpswRcs_VtQniJMMEhDusEtaJamGWQJc6S48S9U-DHig@mail.gmail.com>
	<5031830E-8DC0-4FCF-AE14-B3E4A6D020D8@la-broadband.com>
Message-ID: <AF9D6FED-334A-43D2-8CFB-E31B9F5D2210@twcable.com>

Jesse

Not sure who else you are referring to but Chris is not a sitting AC member.

Thanks
John

Sent from my iPhone

On Apr 1, 2014, at 11:48 AM, "Jesse Geddis" <jesse at la-broadband.com<mailto:jesse at la-broadband.com>> wrote:

Rotflol conspiracy theories abound. Completely ignoring the fact that the two folks to broached the topic are sitting AC members...

Facts for thought...

The policy changes I want to push I submit. Note the previous fee discussion, modelling, and resultant proposal. I can't speak for anyone else but that's my current priority and has nothing to do with the AC. I've made no secret, however, about slow start and initial allocation policies for ISP's being problematic. But haven't yet proposed a change.

Jesse Geddis
LA Broadband LLC

On Apr 1, 2014, at 11:13 AM, Chris Grundemann <cgrundemann at gmail.com<mailto:cgrundemann at gmail.com>> wrote:




On Tue, Apr 1, 2014 at 4:08 AM, Paul Timmins <ptimmins at clearrate.com<mailto:ptimmins at clearrate.com>> wrote:
> ________________________________________
> From: arin-discuss-bounces at arin.net<mailto:arin-discuss-bounces at arin.net> [arin-discuss-bounces at arin.net<mailto:arin-discuss-bounces at arin.net>] on behalf of Martin Hannigan [hannigan at gmail.com<mailto:hannigan at gmail.com>]
> Sent: Monday, March 31, 2014 4:02 PM
> To: William Herrin
> Cc: arin-ppml at arin.net<mailto:arin-ppml at arin.net>; arin-discuss at arin.net<mailto:arin-discuss at arin.net>>
> Subject: Re: [arin-discuss] [arin-ppml] Term Limit Proposal
>
> > I would NOT support this for the board. ARIN benefits from the board's
> > continuity.
>
> If you really want change, term limit the Board and forget the AC.

Do people really WANT change though? I think part of what helps the community at large is the predictability of policy w/r/t number allocation.

A neutral entity controlling allocation uniformly per a generally stable policy provides a good regulatory environment for everyone, I'd think.

+1

NRPM stability is a good thing for both network operators and Internet users.

Also, needed change seems to happen in the current frame work and I see no indication that "more" change is a good thing without looking at the specific changes. Which of course leads to the question: Perhaps some of those advocating for term limits actually seek a very specific change, or set of changes, that they believe they could achieve by taking over the AC after booting out those who have repeatedly shown that they will support the entire community rather than be bowled over by special interests? Hmmm...

Food for thought,
~Chris



-Paul
_______________________________________________
ARIN-Discuss
You are receiving this message because you are subscribed to
the ARIN Discussion Mailing List (ARIN-discuss at arin.net<mailto:ARIN-discuss at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-discuss
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.



--
@ChrisGrundemann
http://chrisgrundemann.com
_______________________________________________
ARIN-Discuss
You are receiving this message because you are subscribed to
the ARIN Discussion Mailing List (ARIN-discuss at arin.net<mailto:ARIN-discuss at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-discuss
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.
_______________________________________________
ARIN-Discuss
You are receiving this message because you are subscribed to
the ARIN Discussion Mailing List (ARIN-discuss at arin.net<mailto:ARIN-discuss at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-discuss
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140401/7ebbe928/attachment.htm>

From john.sweeting at twcable.com  Tue Apr  1 17:48:17 2014
From: john.sweeting at twcable.com (Sweeting, John)
Date: Tue, 1 Apr 2014 17:48:17 -0400
Subject: [arin-ppml] [arin-discuss]  Term Limit Proposal
In-Reply-To: <ACFD953F-C135-4042-B910-74BA35B8CD3A@la-broadband.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<CAP-guGVopDTYEJLMDpQqy8u-m0KU5FBDP_JEnTPLcy3w9i5WUg@mail.gmail.com>
	<CAMDXq5NJaRnqs2qip6xAPC57oX7tnN23s8M5U5_kX_61ugw_CQ@mail.gmail.com>
	<8335CAF4177E7A4CBC4670E5F9FA9B415EF4403C@CRC-Exchange02.corp.clearrate.net>
	<CAC1-dtnpswRcs_VtQniJMMEhDusEtaJamGWQJc6S48S9U-DHig@mail.gmail.com>
	<5031830E-8DC0-4FCF-AE14-B3E4A6D020D8@la-broadband.com>
	<AF9D6FED-334A-43D2-8CFB-E31B9F5D2210@twcable.com>
	<ACFD953F-C135-4042-B910-74BA35B8CD3A@la-broadband.com>
Message-ID: <EAF0CB21-CC70-4592-87FE-FA2AA40B43CF@twcable.com>

Cool, thanks for the clarification

Sent from my iPhone

On Apr 1, 2014, at 1:35 PM, "Jesse Geddis" <jesse at la-broadband.com<mailto:jesse at la-broadband.com>> wrote:

John,

Honestly I shouldn't have bothered responding to his email as it was clearly just meant to be a diversion. However:

Chris opposes it so it clearly wasn't in reference too him...
Marla brought it to the list (was on the AC 2005-2010)
Scott seconded it (is on the AC)

To my knowledge, neither Marla or Scott (or the multitude of others who have voiced support) have mentioned or given any indication of any involvement in a surreptitious ARIN coup, government or corporate espionage, foreign governmental plots, or arms for hostages plots....

I think we've pretty well exhausted this topic at this point and now are wading deep into Crazy Town. I understand the suggestion has been officially made. Mr. Curran, is there anything further ARIN needs from the membership on the matter?

-------------------
Jesse Geddis
LA Broadband

On Apr 1, 2014, at 1:04 PM, "Sweeting, John" <john.sweeting at twcable.com<mailto:john.sweeting at twcable.com>> wrote:

Jesse

Not sure who else you are referring to but Chris is not a sitting AC member.

Thanks
John

Sent from my iPhone

On Apr 1, 2014, at 11:48 AM, "Jesse Geddis" <jesse at la-broadband.com<mailto:jesse at la-broadband.com>> wrote:

Rotflol conspiracy theories abound. Completely ignoring the fact that the two folks to broached the topic are sitting AC members...

Facts for thought...

The policy changes I want to push I submit. Note the previous fee discussion, modelling, and resultant proposal. I can't speak for anyone else but that's my current priority and has nothing to do with the AC. I've made no secret, however, about slow start and initial allocation policies for ISP's being problematic. But haven't yet proposed a change.

Jesse Geddis
LA Broadband LLC

On Apr 1, 2014, at 11:13 AM, Chris Grundemann <cgrundemann at gmail.com<mailto:cgrundemann at gmail.com>> wrote:




On Tue, Apr 1, 2014 at 4:08 AM, Paul Timmins <ptimmins at clearrate.com<mailto:ptimmins at clearrate.com>> wrote:
> ________________________________________
> From: arin-discuss-bounces at arin.net<mailto:arin-discuss-bounces at arin.net> [arin-discuss-bounces at arin.net<mailto:arin-discuss-bounces at arin.net>] on behalf of Martin Hannigan [hannigan at gmail.com<mailto:hannigan at gmail.com>]
> Sent: Monday, March 31, 2014 4:02 PM
> To: William Herrin
> Cc: arin-ppml at arin.net<mailto:arin-ppml at arin.net>; arin-discuss at arin.net<mailto:arin-discuss at arin.net>>
> Subject: Re: [arin-discuss] [arin-ppml] Term Limit Proposal
>
> > I would NOT support this for the board. ARIN benefits from the board's
> > continuity.
>
> If you really want change, term limit the Board and forget the AC.

Do people really WANT change though? I think part of what helps the community at large is the predictability of policy w/r/t number allocation.

A neutral entity controlling allocation uniformly per a generally stable policy provides a good regulatory environment for everyone, I'd think.

+1

NRPM stability is a good thing for both network operators and Internet users.

Also, needed change seems to happen in the current frame work and I see no indication that "more" change is a good thing without looking at the specific changes. Which of course leads to the question: Perhaps some of those advocating for term limits actually seek a very specific change, or set of changes, that they believe they could achieve by taking over the AC after booting out those who have repeatedly shown that they will support the entire community rather than be bowled over by special interests? Hmmm...

Food for thought,
~Chris



-Paul
_______________________________________________
ARIN-Discuss
You are receiving this message because you are subscribed to
the ARIN Discussion Mailing List (ARIN-discuss at arin.net<mailto:ARIN-discuss at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-discuss
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.



--
@ChrisGrundemann
http://chrisgrundemann.com
_______________________________________________
ARIN-Discuss
You are receiving this message because you are subscribed to
the ARIN Discussion Mailing List (ARIN-discuss at arin.net<mailto:ARIN-discuss at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-discuss
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.
_______________________________________________
ARIN-Discuss
You are receiving this message because you are subscribed to
the ARIN Discussion Mailing List (ARIN-discuss at arin.net<mailto:ARIN-discuss at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-discuss
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140401/6091ae32/attachment.htm>

From paul at egate.net  Tue Apr  1 18:02:24 2014
From: paul at egate.net (Paul Andersen)
Date: Tue, 1 Apr 2014 18:02:24 -0400
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <alpine.BSF.2.00.1403311124560.52227@mail.inlandnet.com>
References: <alpine.BSF.2.00.1403311124560.52227@mail.inlandnet.com>
Message-ID: <65ECCDF2-0114-4943-B364-D5A810D545F7@egate.net>


John (Springer),

The Governance Committee of the Board has been looking at a variety of broader issues recently.

As a committee we've been cautious to not let Governance issues monopolize our limited bandwidth. Many similar organizations can consume themselves in governance exercises and lose sight of their mission.

Term limits have been discussed at the Committee and Board level on a few occasions and much like the discussion here, there is a large variety of viewpoints but not a clear consensus.

Our current focus of activities is as follows:

* Ensuring there is an appropriate amount of accountability to ensure member input is required prior to a key change in the organization such as the mission.
* Work to ensure conflict of interest provisions meet best practices for an organization like ARIN
* Work on the Nomination Committee to improve the depth of candidates and also ensure the membership has the information it seeks to make an informed decision at voting time.

We are also looking at the broader issue of composition, structure and selection of bodies such as the Board and the Advisory Council. The issue of term limits would certainly continue to be considered here.

As committee chair I would find it valuable to continue to hear from the community what problems you believe need solving in respect to composition, structure and selection. I think if the community can assist in finding consensus around these problems the committee can decide what are the right actions to resolve those.

I continue to watch the mailing list thread with interest. Thanks to all who have provided constructive input to the committee and of course welcome further feedback either directly or to the mailing list. 

Hope that helps...

Cheers,

Paul
Chair, ARIN BoT Governance Committee


On Mar 31, 2014, at 2:56 PM, John Springer <springer at inlandnet.com> wrote:

> I notice from the 2013 ARIN Annual Report
> 
> https://www.arin.net/about_us/corp_docs/annual/report2013.pdf
> 
> (p. 11, BOARD OF TRUSTEES ACTIONS), an item, "Referred question of term limits to the ARIN Governance Committee".
> 
> It appears this happened on 1/7/2013.
> 
> https://www.arin.net/about_us/bot/bot2013_0107.html
> 
> Is there anything that can be publicly said about the deliberations of this committee, on this subject, so far?
> 
> There doesn't appear to be anything published in official BoT materials since:
> 
> site:https://www.arin.net/about_us/bot/ "term limits"
> 
> I ask because of the recent interest in the topic.
> 
> John Springer
> as a member of the community
> 
> _______________________________________________
> 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.



From mysidia at gmail.com  Tue Apr  1 20:38:09 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 1 Apr 2014 19:38:09 -0500
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <CAMDXq5Oew3CydPvxXzOKm7p3ug9sh3hKJ6O+KpAmdbq=zciw5Q@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<CAP-guGVopDTYEJLMDpQqy8u-m0KU5FBDP_JEnTPLcy3w9i5WUg@mail.gmail.com>
	<CAMDXq5NJaRnqs2qip6xAPC57oX7tnN23s8M5U5_kX_61ugw_CQ@mail.gmail.com>
	<CAP-guGUpsfY64btZXVg2VCbBJMSyE82NaMnbEC3d=hMnVROW_g@mail.gmail.com>
	<CAMDXq5Oew3CydPvxXzOKm7p3ug9sh3hKJ6O+KpAmdbq=zciw5Q@mail.gmail.com>
Message-ID: <CAAAwwbWWmC4z9-iH=4s=Y-0a=VrFAqx3KBSJtv475EgKKdHiKA@mail.gmail.com>

On Mon, Mar 31, 2014 at 6:12 PM, Martin Hannigan <hannigan at gmail.com> wrote:

> On Mon, Mar 31, 2014 at 5:21 PM, William Herrin <bill at herrin.us> wrote:
>
> > Change for change's sake is rarely for the better. Stability is
>
Agreed.


>  > usually a good thing. I don't see rotating out AC members having a
> > negative impact on ARIN's overall stability. Frequent turnover on the
> > board, however...
>

I believe "term limits" to the AC currently to be a solution in search of a
problem.
The exact benefits are vague and poorly explained.

The idea of term limits would seem to be a net negative, due to all the
time waste that would be involved in implementing them, and the additional
complexity imposed upon future selection of the AC by the community:   with
voters/members possibly being deprived of the best possible choices for the
selection of the AC.


> As far as term limits go, there are a multitude of organizations that
> use them and suffer little from it including federal, state and
> municipal governments, non profts like the Appalachian Mountain Club,
> NANOG, and many others.
>

These are much larger entities.   There are a large number of people who
could serve on the board of a non-profit or governmental entity.

There are few who are even sufficiently familiar with the NRPM and
technical issues surrounding IP addressing policy  to do the AC's job..



> There are a variety of problems term limits may help with including
> the self perpetuation concern, under representation (only a fraction
> of resource holders are actually "represented" and stagnation (Gov
> term limit task and PDP Simplification Committee). Term limits would
> likely resolve or soften some worthwhile problems.
>

If you could drop "concern" from the statement, and then explain how each
of these has become a real problem with the AC,   then you would  possibly
have a reasonable argument for term limits.


> Why is ARIN different than all of these other venerable organizations?
>

They are not ARIN.      Many governmental, commercial, and non-profit
organizations take on their activities in a manner that would not
necessarily be appropriate for ARIN.

Certainly "term limits" has not been shown to be something that makes those
organizations venerable.


Meanwhile, ARIN itself is a venerable organization with no term limits
really needed thus far.


> Best
> -M<
>
> --
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140401/d91b59b0/attachment.htm>

From heather.skanks at gmail.com  Tue Apr  1 22:21:31 2014
From: heather.skanks at gmail.com (Heather Schiller)
Date: Tue, 1 Apr 2014 22:21:31 -0400
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <CAMDXq5ML8cjx1S7xd8XDqMVg554BWtwCD8X5oR5xDS7+Ee44LQ@mail.gmail.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<5335A9D1.7020506@umn.edu>
	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
	<533763FC.7030302@matthew.at>
	<BD23C833-0608-4F05-9F39-8D11709052F1@arin.net>
	<53378659.60605@matthew.at>
	<A36E7C47-7D8C-45E6-8E23-5286B1A58ADB@arin.net>
	<CAMDXq5MwkbT=2QHZYGV1kWkVeTxmbhM_q8g7F_g-sR4rHs3k3Q@mail.gmail.com>
	<2DA95900-8FCB-484E-B998-5D1E1E1A7E75@arin.net>
	<CAMDXq5PNBYH0+hhwCx-YsjXfZbomeE-RB+GY-Hb40CjvqLWc-Q@mail.gmail.com>
	<CAMDXq5ML8cjx1S7xd8XDqMVg554BWtwCD8X5oR5xDS7+Ee44LQ@mail.gmail.com>
Message-ID: <CADricwrWTiHe6OqWtWN1OGOGHRS+9d4JzRW3WPSbRaLxBugE5w@mail.gmail.com>

The suggested text restricting LOA is:  "ARIN will not issue a Letter of
Authority (LOA) to route a research prefix unless the allocation is
properly registered in whois."

The text does not specifically restrict ARIN from issuing an LOA
altogether, it requires that the resource be registered in whois.  I think
the text allows them to issue LOA for research where necessary and
legitimate.  It should not impede them from issuing LOA in any other
circumstance (though, outside of research, I don't imagine they get many
requests for LOA)   Can you foresee a circumstance where it would be
appropriate for ARIN to issue an LOA for something *not* registered in
whois?   Do you think the current text impedes them from issuing necessary
and legitimate LOA's?

--Heather


On Tue, Apr 1, 2014 at 10:58 AM, Martin Hannigan <hannigan at gmail.com> wrote:

> On Mon, Mar 31, 2014 at 4:59 PM, Martin Hannigan <hannigan at gmail.com>
> wrote:
> > On Mon, Mar 31, 2014 at 4:52 PM, John Curran <jcurran at arin.net> wrote:
> >> On Mar 31, 2014, at 3:11 PM, Martin Hannigan <hannigan at gmail.com>
> wrote:
> >>
> >>> On Sun, Mar 30, 2014 at 5:00 AM, John Curran <jcurran at arin.net> wrote:
> >>>>
> >>>> NRPM 11 was designed for parties requesting allocations from ARIN for
> >>>> research purposes; not ARIN checking the quality/integrity of new
> block
> >>>> received from IANA.  Given the recent occurance, I believe it is
> prudent
> >>>> for ARIN to utilize NRPM 11 going forward for purposes of this quality
> >>>> checking, as it makes visible the organization doing the
> testing/making
> >>>> use of the space, including duration of the activity and research
> nature,
> >>>> as well as reaffirming the expected uniqueness requirement.
> >>>
> >>> If I understand this correctly, Matthew suggested that an update to
> >>> Section 11 would be more useful? If that's the case I agree. It would
> >>> require a few, simple, modifications.
> >>
> >> I think his suggestion to make use of NRPM 11 for this purpose is quite
> >> excellent.   It was not process that we used in the past, but shall be
> >> done that way going forward.   To the extent that the community wishes
> >> to improve NRPM 11 policy text for this purpose of address space
> testing,
> >> that is also welcome.
> >>
> >>> Why would ARIN ever need to issue an LOA if whatever is distributed is
> >>> in the registry? All the LOA responsibilities if even needed at that
> >>> point would fall to the registrant.
> >>
> >> Agreed; that is the major benefit of taking an "NRPM 11" approach to
> address
> >> space testing - ARIN stays focused on being a registry and leaves the
> use of
> >> address space to registrants.  Since registrants are unique for a given
> address
> >> block, we also preempt multiple parties with potentially conflict plans
> on the
> >> use (or routing) of any given portion of address space.
> >>
> >
> >
> > Yes, I agree. This is the preferable route.
> >
> > Best,
> >
> > -M<
>
>
> To add to this, it appears that we can condense most of the hand
> waving down to a modification in Section 11.4 that adds to the end of
> the paragraph "All resource assignments will be registered in the ARIN
> WHOIS database and in a manner not conflicting with any other
> registrations". Or any other language that would accomplish the same
> thing.
>
> We ought not to specifically restrict ARIN from writing an LOA. There
> may be a circumstance where it is necessary and fully legitimate.
> Admittedly, the instances where it would be needed would be corner
> cases, but operators in the AP region, for example, are very strict
> and I've had some strange reasons for writing LOA for my own prefixes.
> It may also interfere with the encumbrance testing that John
> mentioned. I suspect there are also some other tricky authority
> questions.
>
> This sounds like a legitimate error to me so this should be enough to
> instill a codified message that we want registrations and self
> service. Anything else needs more attention.
>
> Best,
>
> -M<
> _______________________________________________
> 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/20140401/f948d21e/attachment.htm>

From hannigan at gmail.com  Tue Apr  1 22:23:06 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 1 Apr 2014 22:23:06 -0400
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <CADricwrWTiHe6OqWtWN1OGOGHRS+9d4JzRW3WPSbRaLxBugE5w@mail.gmail.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<5335A9D1.7020506@umn.edu>
	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
	<533763FC.7030302@matthew.at>
	<BD23C833-0608-4F05-9F39-8D11709052F1@arin.net>
	<53378659.60605@matthew.at>
	<A36E7C47-7D8C-45E6-8E23-5286B1A58ADB@arin.net>
	<CAMDXq5MwkbT=2QHZYGV1kWkVeTxmbhM_q8g7F_g-sR4rHs3k3Q@mail.gmail.com>
	<2DA95900-8FCB-484E-B998-5D1E1E1A7E75@arin.net>
	<CAMDXq5PNBYH0+hhwCx-YsjXfZbomeE-RB+GY-Hb40CjvqLWc-Q@mail.gmail.com>
	<CAMDXq5ML8cjx1S7xd8XDqMVg554BWtwCD8X5oR5xDS7+Ee44LQ@mail.gmail.com>
	<CADricwrWTiHe6OqWtWN1OGOGHRS+9d4JzRW3WPSbRaLxBugE5w@mail.gmail.com>
Message-ID: <CAMDXq5NWfVm4--bh-vENC-ZU51ZqxozVe38Wgi7J0gPxQ7_27w@mail.gmail.com>

It's a no op then. There's no need to mention LOA's at all.

On Tuesday, April 1, 2014, Heather Schiller <heather.skanks at gmail.com>
wrote:

>
> The suggested text restricting LOA is:  "ARIN will not issue a Letter of
> Authority (LOA) to route a research prefix unless the allocation is
> properly registered in whois."
>
> The text does not specifically restrict ARIN from issuing an LOA
> altogether, it requires that the resource be registered in whois.  I think
> the text allows them to issue LOA for research where necessary and
> legitimate.  It should not impede them from issuing LOA in any other
> circumstance (though, outside of research, I don't imagine they get many
> requests for LOA)   Can you foresee a circumstance where it would be
> appropriate for ARIN to issue an LOA for something *not* registered in
> whois?   Do you think the current text impedes them from issuing necessary
> and legitimate LOA's?
>
> --Heather
>
>
> On Tue, Apr 1, 2014 at 10:58 AM, Martin Hannigan <hannigan at gmail.com<javascript:_e(%7B%7D,'cvml','hannigan at gmail.com');>
> > wrote:
>
>> On Mon, Mar 31, 2014 at 4:59 PM, Martin Hannigan <hannigan at gmail.com<javascript:_e(%7B%7D,'cvml','hannigan at gmail.com');>>
>> wrote:
>> > On Mon, Mar 31, 2014 at 4:52 PM, John Curran <jcurran at arin.net<javascript:_e(%7B%7D,'cvml','jcurran at arin.net');>>
>> wrote:
>> >> On Mar 31, 2014, at 3:11 PM, Martin Hannigan <hannigan at gmail.com<javascript:_e(%7B%7D,'cvml','hannigan at gmail.com');>>
>> wrote:
>> >>
>> >>> On Sun, Mar 30, 2014 at 5:00 AM, John Curran <jcurran at arin.net<javascript:_e(%7B%7D,'cvml','jcurran at arin.net');>>
>> wrote:
>> >>>>
>> >>>> NRPM 11 was designed for parties requesting allocations from ARIN for
>> >>>> research purposes; not ARIN checking the quality/integrity of new
>> block
>> >>>> received from IANA.  Given the recent occurance, I believe it is
>> prudent
>> >>>> for ARIN to utilize NRPM 11 going forward for purposes of this
>> quality
>> >>>> checking, as it makes visible the organization doing the
>> testing/making
>> >>>> use of the space, including duration of the activity and research
>> nature,
>> >>>> as well as reaffirming the expected uniqueness requirement.
>> >>>
>> >>> If I understand this correctly, Matthew suggested that an update to
>> >>> Section 11 would be more useful? If that's the case I agree. It would
>> >>> require a few, simple, modifications.
>> >>
>> >> I think his suggestion to make use of NRPM 11 for this purpose is quite
>> >> excellent.   It was not process that we used in the past, but shall be
>> >> done that way going forward.   To the extent that the community wishes
>> >> to improve NRPM 11 policy text for this purpose of address space
>> testing,
>> >> that is also welcome.
>> >>
>> >>> Why would ARIN ever need to issue an LOA if whatever is distributed is
>> >>> in the registry? All the LOA responsibilities if even needed at that
>> >>> point would fall to the registrant.
>> >>
>> >> Agreed; that is the major benefit of taking an "NRPM 11" approach to
>> address
>> >> space testing - ARIN stays focused on being a registry and leaves the
>> use of
>> >> address space to registrants.  Since registrants are unique for a
>> given address
>> >> block, we also preempt multiple parties with potentially conflict
>> plans on the
>> >> use (or routing) of any given portion of address space.
>> >>
>> >
>> >
>> > Yes, I agree. This is the preferable route.
>> >
>> > Best,
>> >
>> > -M<
>>
>>
>> To add to this, it appears that we can condense most of the hand
>> waving down to a modification in Section 11.4 that adds to the end of
>> the paragraph "All resource assignments will be registered in the ARIN
>> WHOIS database and in a manner not conflicting with any other
>> registrations". Or any other language that would accomplish the same
>> thing.
>>
>> We ought not to specifically restrict ARIN from writing an LOA. There
>> may be a circumstance where it is necessary and fully legitimate.
>> Admittedly, the instances where it would be needed would be corner
>> cases, but operators in the AP region, for example, are very strict
>> and I've had some strange reasons for writing LOA for my own prefixes.
>> It may also interfere with the encumbrance testing that John
>> mentioned. I suspect there are also some other tricky authority
>> questions.
>>
>> This sounds like a legitimate error to me so this should be enough to
>> instill a codified message that we want registrations and self
>> service. Anything else needs more attention.
>>
>> Best,
>>
>> -M<
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<javascript:_e(%7B%7D,'cvml','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<javascript:_e(%7B%7D,'cvml','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/20140401/fcee5bf2/attachment.htm>

From David.Huberman at microsoft.com  Tue Apr  1 22:30:21 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Wed, 2 Apr 2014 02:30:21 +0000
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <CAMDXq5NWfVm4--bh-vENC-ZU51ZqxozVe38Wgi7J0gPxQ7_27w@mail.gmail.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<5335A9D1.7020506@umn.edu>	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
	<533763FC.7030302@matthew.at>
	<BD23C833-0608-4F05-9F39-8D11709052F1@arin.net>	<53378659.60605@matthew.at>
	<A36E7C47-7D8C-45E6-8E23-5286B1A58ADB@arin.net>
	<CAMDXq5MwkbT=2QHZYGV1kWkVeTxmbhM_q8g7F_g-sR4rHs3k3Q@mail.gmail.com>
	<2DA95900-8FCB-484E-B998-5D1E1E1A7E75@arin.net>
	<CAMDXq5PNBYH0+hhwCx-YsjXfZbomeE-RB+GY-Hb40CjvqLWc-Q@mail.gmail.com>
	<CAMDXq5ML8cjx1S7xd8XDqMVg554BWtwCD8X5oR5xDS7+Ee44LQ@mail.gmail.com>
	<CADricwrWTiHe6OqWtWN1OGOGHRS+9d4JzRW3WPSbRaLxBugE5w@mail.gmail.com>
	<CAMDXq5NWfVm4--bh-vENC-ZU51ZqxozVe38Wgi7J0gPxQ7_27w@mail.gmail.com>
Message-ID: <fe82fdff62b544fe88554760b8adf99d@DM2PR03MB398.namprd03.prod.outlook.com>

Whether it's no-op or op, please note that an LOA is actually a "Letter of Agency".  Maybe some networks now call it a Letter of Authority, but it's properly Agency.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan
Sent: Tuesday, April 1, 2014 7:23 PM
To: Heather Schiller
Cc: John Curran; arin-ppml at arin.net
Subject: Re: [arin-ppml] 2600::/12 LOA


It's a no op then. There's no need to mention LOA's at all.

On Tuesday, April 1, 2014, Heather Schiller <heather.skanks at gmail.com<mailto:heather.skanks at gmail.com>> wrote:

The suggested text restricting LOA is:  "ARIN will not issue a Letter of Authority (LOA) to route a research prefix unless the allocation is properly registered in whois."

The text does not specifically restrict ARIN from issuing an LOA altogether, it requires that the resource be registered in whois.  I think the text allows them to issue LOA for research where necessary and legitimate.  It should not impede them from issuing LOA in any other circumstance (though, outside of research, I don't imagine they get many requests for LOA)   Can you foresee a circumstance where it would be appropriate for ARIN to issue an LOA for something *not* registered in whois?   Do you think the current text impedes them from issuing necessary and legitimate LOA's?

--Heather

On Tue, Apr 1, 2014 at 10:58 AM, Martin Hannigan <hannigan at gmail.com<javascript:_e(%7B%7D,'cvml','hannigan at gmail.com');>> wrote:
On Mon, Mar 31, 2014 at 4:59 PM, Martin Hannigan <hannigan at gmail.com<javascript:_e(%7B%7D,'cvml','hannigan at gmail.com');>> wrote:
> On Mon, Mar 31, 2014 at 4:52 PM, John Curran <jcurran at arin.net<javascript:_e(%7B%7D,'cvml','jcurran at arin.net');>> wrote:
>> On Mar 31, 2014, at 3:11 PM, Martin Hannigan <hannigan at gmail.com<javascript:_e(%7B%7D,'cvml','hannigan at gmail.com');>> wrote:
>>
>>> On Sun, Mar 30, 2014 at 5:00 AM, John Curran <jcurran at arin.net<javascript:_e(%7B%7D,'cvml','jcurran at arin.net');>> wrote:
>>>>
>>>> NRPM 11 was designed for parties requesting allocations from ARIN for
>>>> research purposes; not ARIN checking the quality/integrity of new block
>>>> received from IANA.  Given the recent occurance, I believe it is prudent
>>>> for ARIN to utilize NRPM 11 going forward for purposes of this quality
>>>> checking, as it makes visible the organization doing the testing/making
>>>> use of the space, including duration of the activity and research nature,
>>>> as well as reaffirming the expected uniqueness requirement.
>>>
>>> If I understand this correctly, Matthew suggested that an update to
>>> Section 11 would be more useful? If that's the case I agree. It would
>>> require a few, simple, modifications.
>>
>> I think his suggestion to make use of NRPM 11 for this purpose is quite
>> excellent.   It was not process that we used in the past, but shall be
>> done that way going forward.   To the extent that the community wishes
>> to improve NRPM 11 policy text for this purpose of address space testing,
>> that is also welcome.
>>
>>> Why would ARIN ever need to issue an LOA if whatever is distributed is
>>> in the registry? All the LOA responsibilities if even needed at that
>>> point would fall to the registrant.
>>
>> Agreed; that is the major benefit of taking an "NRPM 11" approach to address
>> space testing - ARIN stays focused on being a registry and leaves the use of
>> address space to registrants.  Since registrants are unique for a given address
>> block, we also preempt multiple parties with potentially conflict plans on the
>> use (or routing) of any given portion of address space.
>>
>
>
> Yes, I agree. This is the preferable route.
>
> Best,
>
> -M<

To add to this, it appears that we can condense most of the hand
waving down to a modification in Section 11.4 that adds to the end of
the paragraph "All resource assignments will be registered in the ARIN
WHOIS database and in a manner not conflicting with any other
registrations". Or any other language that would accomplish the same
thing.

We ought not to specifically restrict ARIN from writing an LOA. There
may be a circumstance where it is necessary and fully legitimate.
Admittedly, the instances where it would be needed would be corner
cases, but operators in the AP region, for example, are very strict
and I've had some strange reasons for writing LOA for my own prefixes.
It may also interfere with the encumbrance testing that John
mentioned. I suspect there are also some other tricky authority
questions.

This sounds like a legitimate error to me so this should be enough to
instill a codified message that we want registrations and self
service. Anything else needs more attention.

Best,

-M<
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<javascript:_e(%7B%7D,'cvml','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<javascript:_e(%7B%7D,'cvml','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/20140402/f21f73db/attachment.htm>

From nikiyangxf at gmail.com  Tue Apr  1 22:34:51 2014
From: nikiyangxf at gmail.com (xiaofan yang)
Date: Wed, 2 Apr 2014 10:34:51 +0800
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
 and 8.2 Utilization Requirements
Message-ID: <CAPhL6MoirOmJJ1TEFxu_uOdM-QRykoZZ3Ged5u71ATmh_mB+5Q@mail.gmail.com>

*Hi John, *


*We would like to do a 8.2transfer because of our restructure. *

*However,  the transferred ips are underutilized.  based on your comments
in the list, it seems that if those ips are lack of utilisation, ARIN will
ask us to return those ips or  ARIN will not approve our transfer ?*


*I have asked ARIN HM to explain and Shawn said if we can provide the
appropriate documents,  no matter if those ips are lack of utilisation,
Arin will approve the transfer and furthermore, we are free to transfer
those ips to others in basis of 8.3 transfer.   I am quite confused here.
it seems that John' comment conflicts with Arin HM's comments.   Which one
should my company follow?      Please see ARIN HM's comments below. *


*Please note that a transfer of resources is one of the options that is
listed in NRPM to restore compliance for underutilized resources.
Specifically, "ARIN will work with the resource holder(s) to return,
aggregate, transfer, or reclaim resources as needed to restore compliance
via the processes outlined in current ARIN policy." *


*- If the resources that Company A currently holds are underutilized, and
Company B provides legal evidence that they have acquired the assets that
use those resources, a transfer can be approved. In reference to
utilization, Company B may convey to ARIN that upon completion of the 8.2,
the resources will be transferred to a specified recipient via an 8.3
transfer. *


*- It is then incumbent on the Specified Recipient of the 8.3 to qualify
for the resources under ARIN policy for the 8.3 transfer to be approved. *





*John curran's comments*

Parties who have their resources under an RSA or LRSA cannot have their
resources

revoked for lack of utilization, although ARIN does ask about their
utilization

during NRPM 8.2 transfer; in cases of significant lack of utilization we
will also

note the option of voluntary return as well as the ability to transfer via
NRPM

8.3/8.4 i.e. the other options under NRPM 8.2 language, specifically -



"ARIN will work with the resource holder(s) to return, aggregate, transfer,

or reclaim resources as needed to restore compliance via the processes

outlined in current ARIN policy."


I do not know if asking parties (that are undergoing NRPM 8.2 transfer) to
know

their number resource utilization serves a useful purpose to the community,
but

that is the primary role of NRPM 8.2. Note that it may also serve as a
deterrent

(although hard to prove) in some cases to M & A transactions purely for
purposes

of obtaining IP space, since ARIN will seek to understand the utilization
of the

combined entity and may not agree to allow the transfer per community policy

(and parties that endeavor to work around such requirements via fraudulent

representations to ARIN can have the number resources reclaimed per NRPM 12)




The intent of NRPM 8.2, however, is quite clear - parties merging with other

parties will have a discussion with ARIN about the number resources
utilization

of the combined entity.





Regards,

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

From hannigan at gmail.com  Tue Apr  1 22:45:09 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 1 Apr 2014 22:45:09 -0400
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <CAAAwwbWWmC4z9-iH=4s=Y-0a=VrFAqx3KBSJtv475EgKKdHiKA@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<CAP-guGVopDTYEJLMDpQqy8u-m0KU5FBDP_JEnTPLcy3w9i5WUg@mail.gmail.com>
	<CAMDXq5NJaRnqs2qip6xAPC57oX7tnN23s8M5U5_kX_61ugw_CQ@mail.gmail.com>
	<CAP-guGUpsfY64btZXVg2VCbBJMSyE82NaMnbEC3d=hMnVROW_g@mail.gmail.com>
	<CAMDXq5Oew3CydPvxXzOKm7p3ug9sh3hKJ6O+KpAmdbq=zciw5Q@mail.gmail.com>
	<CAAAwwbWWmC4z9-iH=4s=Y-0a=VrFAqx3KBSJtv475EgKKdHiKA@mail.gmail.com>
Message-ID: <CAMDXq5NNG8H9s3abSo8Rs44fSHJ2xVDPUh8gMtuaNDztO4az4g@mail.gmail.com>

On Tue, Apr 1, 2014 at 8:38 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> On Mon, Mar 31, 2014 at 6:12 PM, Martin Hannigan <hannigan at gmail.com> wrote:
>>
>> On Mon, Mar 31, 2014 at 5:21 PM, William Herrin <bill at herrin.us> wrote:
>>
>> > Change for change's sake is rarely for the better. Stability is
>
> Agreed.
>
>>
>> > usually a good thing. I don't see rotating out AC members having a
>> > negative impact on ARIN's overall stability. Frequent turnover on the
>> > board, however...
>
>
> I believe "term limits" to the AC currently to be a solution in search of a
> problem.

Good for you.


[ clip ]

>> As far as term limits go, there are a multitude of organizations that
>> use them and suffer little from it including federal, state and
>> municipal governments, non profts like the Appalachian Mountain Club,
>> NANOG, and many others.
>
>
> These are much larger entities.   There are a large number of people who
> could serve on the board of a non-profit or governmental entity.
> There are few who are even sufficiently familiar with the NRPM and technical
> issues surrounding IP addressing policy  to do the AC's job..
>

What does that have to do with operating an open and transparent
framework for all of us to do the work? Zip.

[ clip ]

> They are not ARIN.      Many governmental, commercial, and non-profit
> organizations take on their activities in a manner that would not
> necessarily be appropriate for ARIN.
>

As tasty as red-herrings are, they're usually obvious.




-M<


From jcurran at arin.net  Tue Apr  1 22:50:08 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 2 Apr 2014 02:50:08 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <CAPhL6MoirOmJJ1TEFxu_uOdM-QRykoZZ3Ged5u71ATmh_mB+5Q@mail.gmail.com>
References: <CAPhL6MoirOmJJ1TEFxu_uOdM-QRykoZZ3Ged5u71ATmh_mB+5Q@mail.gmail.com>
Message-ID: <8089E44B-EBB1-4E91-9CAC-1A33A29F9012@arin.net>

On Apr 1, 2014, at 7:34 PM, xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>> wrote:

Hi John,

We would like to do a 8.2transfer because of our restructure.
However,  the transferred ips are underutilized.  based on your comments in the list, it seems that if those ips are lack of utilisation, ARIN will ask us to return those ips or  ARIN will not approve our transfer ?

I have asked ARIN HM to explain and Shawn said if we can provide the appropriate documents,  no matter if those ips are lack of utilisation, Arin will approve the transfer and furthermore, we are free to transfer those ips to others in basis of 8.3 transfer.   I am quite confused here. it seems that John? comment conflicts with Arin HM?s comments.   Which one should my company follow?    ...
Regards,
Niki


Niki -

ARIN will seek that you return the additional address space or transfer it to another party
(via NRPM 8.3/NRPM 8.4) as part of the approval of your NRPM 8.2 restructure transfer.

This is effectively what ARIN Hostmaster indicated to you, and what I attempted to convey
(perhaps unsuccessfully) in my earlier comments.

Thanks!
/John

John Curran
President and CEO
ARIN



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

From jaymartin926 at gmail.com  Wed Apr  2 00:40:00 2014
From: jaymartin926 at gmail.com (Jay Martin)
Date: Wed, 2 Apr 2014 12:40:00 +0800
Subject: [arin-ppml] Subject: ARIN Draft Policy 2014-2 Improved 8.4
 Anti-Flip Language
In-Reply-To: <8695009A81378E48879980039EEDAD2801364551E6@MAIL1.polartel.local>
References: <CALJtNObcjm08RmMRPscL+rnVOjxnF829bmcZcHGD=kUNy4RyPw@mail.gmail.com>
	<CAMApp36dtrtYWu6uJ-Fe2VnkrD7OQzNUeAp_PO5xSxNsvKW92A@mail.gmail.com>
	<8695009A81378E48879980039EEDAD2801364551E6@MAIL1.polartel.local>
Message-ID: <CALJtNOb6Xh0d6Y5DeHZMK7FFRkLi6EoZxAetZg4UUd1WOeqL_Q@mail.gmail.com>

Hi  Kevin,


Have you known that one ARIN member who received 23.192.0.0-23.211.255.255
from free pool also strongly supports this anti-language proposal?
meanwhile, they have applied a very large apnic  pre-approval (hope) for
transferring their "old" ips into its apnic account.


So, i think it will  be good for the community to restrict transfers on a
per-organisation basis in case such an organisation queeze the so few
remained ARIN free pool.  the time frame of ineligible for re-transfer or
re-sale should be at least 24months or more to avoid the speculator and to
avoid people who are good at finding the loopholes of  ARIN policy.


Jay


On Tue, Apr 1, 2014 at 11:31 PM, Kevin Kargel <kkargel at polartel.com> wrote:

> While I want to say I did not appreciate the violence of the original
> message I do agree with the sentiment.  Let's not make it easy to siphon
> off ARIN resources.
>
>
>
> Kevin
>
>
>
>
>
> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On
> Behalf Of *Bill Darte
> *Sent:* Tuesday, April 01, 2014 9:35 AM
> *To:* Jay Martin
> *Cc:* arin-ppml at arin.net
> *Subject:* Re: [arin-ppml] Subject: ARIN Draft Policy 2014-2 Improved 8.4
> Anti-Flip Language
>
>
>
> Jay,
>
>
>
> I appreciate that you have a view to express that is opposed to the Draft
> Policy.  I understand that you may even be upset about it and that you
> believe that the motivation is contrary to the community's interest. But I
> think that your personalized attack on the author is unwarranted and
> outside both the spirit of and stated Acceptable Use Policy for the PPML.
>
>
>
> You may find the specific rules at
> https://www.arin.net/participate/mailing_lists/aup.html
>
>
>
> Bill Darte
>
> AC Shepherd
>
> ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip Language
>
>
>
> On Tue, Apr 1, 2014 at 12:48 AM, Jay Martin <jaymartin926 at gmail.com>
> wrote:
>
>
>
> *Hello community, *
>
>
>
>
>
>
>
> Message: 1
>
> Date: Wed, 5 Mar 2014 21:17:58 +0000
>
> From: David Huberman <David.Huberman at microsoft.com>
>
> To: Bill Darte <billdarte at gmail.com>, "arin-ppml at arin.net"
>
> <arin-ppml at arin.net>, Owen DeLong <owen at delong.com>
>
> Subject: Re: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4
>
> Anti-Flip Language
>
> Message-ID:
>
> <87b03e32ad2743559958047e94c94044 at DM2PR03MB398.namprd03.prod.outlook.com>
>
>
>
> Content-Type: text/plain; charset="us-ascii"
>
>
>
> As the author of this proposal, and having encountered the real-world
> consequences of existing 8.4 anti-flip language, I support #3 as the
> cleanest, simplest approach that best promotes Whois accuracy.
>
>
>
>
>
> *Can you specify what have you encountered in the real world ? which
> finally "inspire" you to write this proposal.  I think your company is so
> selfish and what your cared is your own company.  Keep buying ip and *
> *pla**nning to transfer them into Asia Pacific region; meanwhile drain
> out of the IPs from the remained Arin pool. *
>
>
>
>
>
>
>
> ARIN is a registry, not a regulator. Let's write policy that promotes
> accuracy in Whois, please.
>
>
>
>
>
> *As a member of the community,   i consider that you are a hypocrite.
> Your so-call  caring about ARIN  accuracy in whois is just an excuse for
> you to protect your company's benefit.   *
>
>
>
> *Let me expose what your intention behind this proposal, i think the
> community deserve the right to see your true face. *
>
> *What you want to do is to help your own company to  easily transfer
> either the purchased ip  or the old allocated ip from Arin into the Asia
> Pacific region; meanwhile  your company is able to keep squeezing and
> draining  the remained free pool of Arin. *
>
>
>
> *Your support of #3 will make it easy for your company to transfer ip into
> Asia Pacific,    which will create a "the needs of Arin IP badly" image in
> the local  ARIN region.   Your purchased /13  from that bankruptcy is the
> justification of your company's needs in Arin region. Now you want a policy
> to help your company to transfer the "old" and " purchase" ip to Asia
> Pacific( you must be a good liar at making your justification to be
> approved by Arin), which will not affect your continuing application of big
> chunk block from Arin.     *
>
>
>
> *The system has already been established to take care of giant baby like
> your company  and leave the smaller organisations without chance to have
> their deserved ip and suffer.*
>
>
>
> *Wake up the community.  Do you want this hypocrite to dry up the free
> pool?*
>
> *I am against this proposal, it will only open the doors for some  players
> to drain up the free pool of ARIN quickly. *
>
>
>
> *Jay*
>
>
>
>
>
> David R Huberman
>
> Microsoft Corporation
>
> Senior IT/OPS Program Manager (GFS)
>
> ________________________________
>
>
>
>
>
>
>
> _______________________________________________
> 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/20140402/35c471de/attachment.htm>

From nikiyangxf at gmail.com  Wed Apr  2 01:00:15 2014
From: nikiyangxf at gmail.com (xiaofan yang)
Date: Wed, 2 Apr 2014 13:00:15 +0800
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <8089E44B-EBB1-4E91-9CAC-1A33A29F9012@arin.net>
References: <CAPhL6MoirOmJJ1TEFxu_uOdM-QRykoZZ3Ged5u71ATmh_mB+5Q@mail.gmail.com>
	<8089E44B-EBB1-4E91-9CAC-1A33A29F9012@arin.net>
Message-ID: <CAPhL6MqE4-_K9ps9EsLvAwrsj8DvD1R+grgZKMAB6qpy_3YSUw@mail.gmail.com>

Hi John,

Thanks for your reply.  So if we do not want to return the address, we can
have them transferred for sale?
and ARIN will not treat our 8.2 transfer as the disguise of  8.3 transfer
 if 8.3 transfer come next after the 8.2 transfer?

Niki


On Wed, Apr 2, 2014 at 10:50 AM, John Curran <jcurran at arin.net> wrote:

>  On Apr 1, 2014, at 7:34 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:
>
>  *Hi John, *
>
>  *We would like to do a 8.2transfer because of our restructure. *
> *However,  the transferred ips are underutilized.  based on your comments
> in the list, it seems that if those ips are lack of utilisation, ARIN will
> ask us to return those ips or  ARIN will not approve our transfer ?*
>
>  *I have asked ARIN HM to explain and Shawn said if we can provide the
> appropriate documents,  no matter if those ips are lack of utilisation,
> Arin will approve the transfer and furthermore, we are free to transfer
> those ips to others in basis of 8.3 transfer.   I am quite confused here.
> it seems that John' comment conflicts with Arin HM's comments.   Which one
> should my company follow?    ...*
> Regards,
> Niki
>
>
>  Niki -
>
>  ARIN will seek that you return the additional address space or transfer
> it to another party
> (via NRPM 8.3/NRPM 8.4) as part of the approval of your NRPM 8.2
> restructure transfer.
>
>  This is effectively what ARIN Hostmaster indicated to you, and what I
> attempted to convey
> (perhaps unsuccessfully) in my earlier comments.
>
>  Thanks!
> /John
>
>  John Curran
> President and CEO
> ARIN
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140402/ce2f028d/attachment.htm>

From jcurran at arin.net  Wed Apr  2 01:04:11 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 2 Apr 2014 05:04:11 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <CAPhL6MqE4-_K9ps9EsLvAwrsj8DvD1R+grgZKMAB6qpy_3YSUw@mail.gmail.com>
References: <CAPhL6MoirOmJJ1TEFxu_uOdM-QRykoZZ3Ged5u71ATmh_mB+5Q@mail.gmail.com>
	<8089E44B-EBB1-4E91-9CAC-1A33A29F9012@arin.net>
	<CAPhL6MqE4-_K9ps9EsLvAwrsj8DvD1R+grgZKMAB6qpy_3YSUw@mail.gmail.com>
Message-ID: <748D323F-21D9-4142-817F-ADD484F756DF@arin.net>

On Apr 1, 2014, at 10:00 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:

> Hi John, 
> 
> Thanks for your reply.  So if we do not want to return the address, we can have them transferred for sale?
> and ARIN will not treat our 8.2 transfer as the disguise of  8.3 transfer  if 8.3 transfer come next after the 8.2 transfer?

That is correct due to alignment with present policy.  Please work with
hostmaster at arin.net regarding specific details of the requests.

Thanks!
/John

John Curran
President and CEO
ARIN



From adudek16 at gmail.com  Wed Apr  2 08:50:01 2014
From: adudek16 at gmail.com (Aaron Dudek)
Date: Wed, 2 Apr 2014 08:50:01 -0400
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <fe82fdff62b544fe88554760b8adf99d@DM2PR03MB398.namprd03.prod.outlook.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<5335A9D1.7020506@umn.edu>
	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
	<533763FC.7030302@matthew.at>
	<BD23C833-0608-4F05-9F39-8D11709052F1@arin.net>
	<53378659.60605@matthew.at>
	<A36E7C47-7D8C-45E6-8E23-5286B1A58ADB@arin.net>
	<CAMDXq5MwkbT=2QHZYGV1kWkVeTxmbhM_q8g7F_g-sR4rHs3k3Q@mail.gmail.com>
	<2DA95900-8FCB-484E-B998-5D1E1E1A7E75@arin.net>
	<CAMDXq5PNBYH0+hhwCx-YsjXfZbomeE-RB+GY-Hb40CjvqLWc-Q@mail.gmail.com>
	<CAMDXq5ML8cjx1S7xd8XDqMVg554BWtwCD8X5oR5xDS7+Ee44LQ@mail.gmail.com>
	<CADricwrWTiHe6OqWtWN1OGOGHRS+9d4JzRW3WPSbRaLxBugE5w@mail.gmail.com>
	<CAMDXq5NWfVm4--bh-vENC-ZU51ZqxozVe38Wgi7J0gPxQ7_27w@mail.gmail.com>
	<fe82fdff62b544fe88554760b8adf99d@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAA0LXWXWQNdBZQtEADzCWS9cPGdizkpR=8T=-YmX32fmAjpwrA@mail.gmail.com>

LOA has multiple meanings.
See. http://acronyms.thefreedictionary.com/LOA
However the author has defined it as Letter Of Authority (as per
ARIN-prop-202).

Aaron Dudek


On Tuesday, April 1, 2014, David Huberman <David.Huberman at microsoft.com>
wrote:

>  Whether it's no-op or op, please note that an LOA is actually a "Letter
> of Agency".  Maybe some networks now call it a Letter of Authority, but
> it's properly Agency.
>
>
>
> *David R Huberman*
>
> Microsoft Corporation
>
> Senior IT/OPS Program Manager (GFS)
>
>
>
> *From:* arin-ppml-bounces at arin.net<javascript:_e(%7B%7D,'cvml','arin-ppml-bounces at arin.net');>[mailto:
> arin-ppml-bounces at arin.net<javascript:_e(%7B%7D,'cvml','arin-ppml-bounces at arin.net');>]
> *On Behalf Of *Martin Hannigan
> *Sent:* Tuesday, April 1, 2014 7:23 PM
> *To:* Heather Schiller
> *Cc:* John Curran; arin-ppml at arin.net<javascript:_e(%7B%7D,'cvml','arin-ppml at arin.net');>
> *Subject:* Re: [arin-ppml] 2600::/12 LOA
>
>
>
>
>
> It's a no op then. There's no need to mention LOA's at all.
>
>
> On Tuesday, April 1, 2014, Heather Schiller <heather.skanks at gmail.com>
> wrote:
>
>
>
> The suggested text restricting LOA is:  "ARIN will not issue a Letter of
> Authority (LOA) to route a research prefix unless the allocation is
> properly registered in whois."
>
>
>
> The text does not specifically restrict ARIN from issuing an LOA
> altogether, it requires that the resource be registered in whois.  I think
> the text allows them to issue LOA for research where necessary and
> legitimate.  It should not impede them from issuing LOA in any other
> circumstance (though, outside of research, I don't imagine they get many
> requests for LOA)   Can you foresee a circumstance where it would be
> appropriate for ARIN to issue an LOA for something *not* registered in
> whois?   Do you think the current text impedes them from issuing necessary
> and legitimate LOA's?
>
>
>
> --Heather
>
>
>
> On Tue, Apr 1, 2014 at 10:58 AM, Martin Hannigan <hannigan at gmail.com>
> wrote:
>
>  On Mon, Mar 31, 2014 at 4:59 PM, Martin Hannigan <hannigan at gmail.com>
> wrote:
> > On Mon, Mar 31, 2014 at 4:52 PM, John Curran <jcurran at arin.net> wrote:
> >> On Mar 31, 2014, at 3:11 PM, Martin Hannigan <hannigan at gmail.com>
> wrote:
> >>
> >>> On Sun, Mar 30, 2014 at 5:00 AM, John Curran <jcurran at arin.net> wrote:
> >>>>
> >>>> NRPM 11 was designed for parties requesting allocations from ARIN for
> >>>> research purposes; not ARIN checking the quality/integrity of new
> block
> >>>> received from IANA.  Given the recent occurance, I believe it is
> prudent
> >>>> for ARIN to utilize NRPM 11 going forward for purposes of this quality
> >>>> checking, as it makes visible the organization doing the
> testing/making
> >>>> use of the space, including duration of the activity and research
> nature,
> >>>> as well as reaffirming the expected uniqueness requirement.
> >>>
> >>> If I understand this correctly, Matthew suggested that an update to
> >>> Section 11 would be more useful? If that's the case I agree. It would
> >>> require a few, simple, modifications.
> >>
> >> I think his suggestion to make use of NRPM 11 for this purpose is quite
> >> excellent.   It was not process that we used in the past, but shall be
> >> done that way going forward.   To the extent that the community wishes
> >> to improve NRPM 11 policy text for this purpose of address space
> testing,
> >> that is also welcome.
> >>
> >>> Why would ARIN ever need to issue an LOA if whatever is distributed is
> >>> in the registry? All the LOA responsibilities if even needed at that
> >>> point would fall to the registrant.
> >>
> >> Agreed; that is the major benefit of taking an "NRPM 11" approach to
> address
> >> space testing - ARIN stays focused on being a registry and leaves the
> use of
> >> address space to registrants.  Since registrants are unique for a given
> address
> >> block, we also preempt multiple parties with potentially conflict plans
> on the
> >> use (or routing) of any given portion of address space.
> >>
> >
> >
> > Yes, I agree. This is the preferable route.
> >
> > Best,
> >
> > -M<
>
>   To add to this, it appears that we can condense most of the hand
> waving down to a modification in Section 11.4 that adds to the end of
> the paragraph "All resource assignments will be registered in the ARIN
> WHOIS database and in a manner not conflicting with any other
> registrations". Or any other language that would accomplish the same
> thing.
>
> We ought not to specifically restrict ARIN from writing an LOA. There
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140402/b004ba8f/attachment.htm>

From nikiyangxf at gmail.com  Wed Apr  2 19:27:52 2014
From: nikiyangxf at gmail.com (xiaofan yang)
Date: Thu, 3 Apr 2014 07:27:52 +0800
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <748D323F-21D9-4142-817F-ADD484F756DF@arin.net>
References: <CAPhL6MoirOmJJ1TEFxu_uOdM-QRykoZZ3Ged5u71ATmh_mB+5Q@mail.gmail.com>
	<8089E44B-EBB1-4E91-9CAC-1A33A29F9012@arin.net>
	<CAPhL6MqE4-_K9ps9EsLvAwrsj8DvD1R+grgZKMAB6qpy_3YSUw@mail.gmail.com>
	<748D323F-21D9-4142-817F-ADD484F756DF@arin.net>
Message-ID: <CAPhL6MoiAO1AAjg2_XHmPYJ_dFV5h8A+seQN4Pb789xfczQPmw@mail.gmail.com>

Hi John,


I have further enquiry about ARIN 8.2 process.


Number one:I am also worried about the costs of doing a 8.2 transfer
followed by a 8.3 transfer.  I wonder if I will have to involve the legal
help to deal with ARIN legal.  In my case I bought a company that now is
out of business. How complicated does ARIN make this process?  I want some
assurance that I will be treated equally to any other companies whether it
is  a big company or a small company like us.



Number two:  If we do a 8.2 transfer followed by a 8.3 transfer, will the
stated purpose for our number resources remains the same?? I am afraid of
that ARIN will not approve our transfer.


Number three:  As we have bought the company,  do we have the property
right on those IPs?  in our past agreement and future agreement arranged
for 8.3,  we would like to have some kinds of property right on those IPs,
will that conflict with ARIN policy?



Niki




On Wed, Apr 2, 2014 at 1:04 PM, John Curran <jcurran at arin.net> wrote:

> On Apr 1, 2014, at 10:00 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:
>
> > Hi John,
> >
> > Thanks for your reply.  So if we do not want to return the address, we
> can have them transferred for sale?
> > and ARIN will not treat our 8.2 transfer as the disguise of  8.3
> transfer  if 8.3 transfer come next after the 8.2 transfer?
>
> That is correct due to alignment with present policy.  Please work with
> hostmaster at arin.net regarding specific details of the requests.
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140403/76092704/attachment.htm>

From csquat at ccsd.net  Wed Apr  2 19:30:45 2014
From: csquat at ccsd.net (Chris R. Squatritto)
Date: Wed, 02 Apr 2014 16:30:45 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 7
Message-ID: <fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74@interact.ccsd.net>

I am out of the office this week and will not be checking email.  Please
contact Troy Miller for assistance..

Thank you for contacting me, and have a great day.

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

From jcurran at arin.net  Wed Apr  2 19:59:20 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 2 Apr 2014 23:59:20 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <CAPhL6MoiAO1AAjg2_XHmPYJ_dFV5h8A+seQN4Pb789xfczQPmw@mail.gmail.com>
References: <CAPhL6MoirOmJJ1TEFxu_uOdM-QRykoZZ3Ged5u71ATmh_mB+5Q@mail.gmail.com>
	<8089E44B-EBB1-4E91-9CAC-1A33A29F9012@arin.net>
	<CAPhL6MqE4-_K9ps9EsLvAwrsj8DvD1R+grgZKMAB6qpy_3YSUw@mail.gmail.com>
	<748D323F-21D9-4142-817F-ADD484F756DF@arin.net>
	<CAPhL6MoiAO1AAjg2_XHmPYJ_dFV5h8A+seQN4Pb789xfczQPmw@mail.gmail.com>
Message-ID: <6BBC9339-AE30-446A-8406-8237A8C3477F@arin.net>

On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:

> Hi John, 
> 
> I have further enquiry about ARIN 8.2 process. 
> 
> Number one:I am also worried about the costs of doing a 8.2 transfer followed by a 8.3 transfer.  I wonder if I will have to involve the legal help to deal with ARIN legal.  In my case I bought a company that now is out of business. How complicated does ARIN make this process?  I want some assurance that I will be treated equally to any other companies whether it is  a big company or a small company like us.

Niki -

You will be treated equally, but in truth I'm not certain that is actually what you want...
(for example, a process which seems routine for a large organization could still pose 
a disproportionate burden to a smaller organization since organization size is not a
factor in the verification process.)

The first and foremost activity is to make sure that we have your organization registered
as the rightful address holder, and that will require an NRPM 8.2 transfer.  It can actually
be relatively straightforward process, as long as you have clear documentation of the 
purchase of the company.  Review the instructions here for additional information about
what is accepted - <https://www.arin.net/resources/request/transfers_8_2.html>

> Number two:  If we do a 8.2 transfer followed by a 8.3 transfer, will the stated purpose for our number resources remains the same?? I am afraid of that ARIN will not approve our transfer. 

If you are the clear party with the rights after your purchase, ARIN will approve your
transfer.  We may note that you have more addresses than you now need, and thus
we expect you to return or transfer the remainder (but that would seem to line up with
your intentions in any case.)

If you have purchased a company without adequate documentation, or if multiple
parties purchased multiple pieces of the company, or if there some question about
what was purchased based on the documentation, then it can be more challenging 
to get the resources appropriately listed with you as the rightful holder.  You will need
to apply for the transfer and work with the ARIN Hostmaster to determine if there is
any issue in your particular case.

> Number three:  As we have bought the company,  do we have the property right on those IPs?  in our past agreement and future agreement arranged for 8.3,  we would like to have some kinds of property right on those IPs,  will that conflict with ARIN policy?

Wonderful question - it is ARIN's position that you have a specific set of rights to the 
address blocks in the registry (as defined by the registration services agreement that
you enter with ARIN), and these rights include:

    (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database; 
    (2) The right to use the Included Number Resources within the ARIN database; and
    (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of property rights
in the address blocks, as it is inconsistent with the ability to manage the address blocks
in accordance with community-developed policy in the region.  If you have other beliefs
with respect to your rights, that would probably be an area for you to seek legal advice.

I hope this helps; please do not hesitate to ask if you have any additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN



From mueller at syr.edu  Thu Apr  3 11:33:13 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Thu, 3 Apr 2014 15:33:13 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <6BBC9339-AE30-446A-8406-8237A8C3477F@arin.net>
References: <CAPhL6MoirOmJJ1TEFxu_uOdM-QRykoZZ3Ged5u71ATmh_mB+5Q@mail.gmail.com>
	<8089E44B-EBB1-4E91-9CAC-1A33A29F9012@arin.net>
	<CAPhL6MqE4-_K9ps9EsLvAwrsj8DvD1R+grgZKMAB6qpy_3YSUw@mail.gmail.com>
	<748D323F-21D9-4142-817F-ADD484F756DF@arin.net>
	<CAPhL6MoiAO1AAjg2_XHmPYJ_dFV5h8A+seQN4Pb789xfczQPmw@mail.gmail.com>
	<6BBC9339-AE30-446A-8406-8237A8C3477F@arin.net>
Message-ID: <1846d87fe7164f22a7c63e9d1fed321e@EX13-MBX-13.ad.syr.edu>

Niki:
For most economists and lawyers, the definition of a "property right" involves the right to use, the right to exclude others from using, and the right to transfer. As John's message makes clear, all those rights are present in the number block lease you get from ARIN. So although the RSA makes you formally declaim a property right, what you are getting from the RSA is a bundle of rights that for all practical purposes has the same economic features as a property right. 

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

Wonderful question - it is ARIN's position that you have a specific set of rights to the address blocks in the registry (as defined by the registration services agreement that you enter with ARIN), and these rights include:

    (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database; 
    (2) The right to use the Included Number Resources within the ARIN database; and
    (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of property rights in the address blocks, as it is inconsistent with the ability to manage the address blocks in accordance with community-developed policy in the region.  If you have other beliefs with respect to your rights, that would probably be an area for you to seek legal advice.

I hope this helps; please do not hesitate to ask if you have any additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN

_______________________________________________
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.


From nikiyangxf at gmail.com  Thu Apr  3 19:33:04 2014
From: nikiyangxf at gmail.com (xiaofan yang)
Date: Fri, 4 Apr 2014 07:33:04 +0800
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <6BBC9339-AE30-446A-8406-8237A8C3477F@arin.net>
References: <CAPhL6MoirOmJJ1TEFxu_uOdM-QRykoZZ3Ged5u71ATmh_mB+5Q@mail.gmail.com>
	<8089E44B-EBB1-4E91-9CAC-1A33A29F9012@arin.net>
	<CAPhL6MqE4-_K9ps9EsLvAwrsj8DvD1R+grgZKMAB6qpy_3YSUw@mail.gmail.com>
	<748D323F-21D9-4142-817F-ADD484F756DF@arin.net>
	<CAPhL6MoiAO1AAjg2_XHmPYJ_dFV5h8A+seQN4Pb789xfczQPmw@mail.gmail.com>
	<6BBC9339-AE30-446A-8406-8237A8C3477F@arin.net>
Message-ID: <CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg@mail.gmail.com>

Hi John,


In basis of your reply,  if the block is underutilised,ARIN will either ask
the  company to return the IPs  or transfer to other third party via 8.3
transfer after our 8.2 transfer.


Say we have two /16 after this 8.2 transfer, what if we only transfer one
/16 to the other third party via 8.3 transfer, meanwhile, we keep the
other /16 left unused after our 8.2 transfer for quiet a while.   Will ARIN
ask us to return the remained /16 to the free pool?  furthmore, how long
will ARIN allow us to keep the other /16 unused before we transfer it to
the third party via 8.3 transfer ?



Niki




On Thu, Apr 3, 2014 at 7:59 AM, John Curran <jcurran at arin.net> wrote:

> On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:
>
> > Hi John,
> >
> > I have further enquiry about ARIN 8.2 process.
> >
> > Number one:I am also worried about the costs of doing a 8.2 transfer
> followed by a 8.3 transfer.  I wonder if I will have to involve the legal
> help to deal with ARIN legal.  In my case I bought a company that now is
> out of business. How complicated does ARIN make this process?  I want some
> assurance that I will be treated equally to any other companies whether it
> is  a big company or a small company like us.
>
> Niki -
>
> You will be treated equally, but in truth I'm not certain that is actually
> what you want...
> (for example, a process which seems routine for a large organization could
> still pose
> a disproportionate burden to a smaller organization since organization
> size is not a
> factor in the verification process.)
>
> The first and foremost activity is to make sure that we have your
> organization registered
> as the rightful address holder, and that will require an NRPM 8.2
> transfer.  It can actually
> be relatively straightforward process, as long as you have clear
> documentation of the
> purchase of the company.  Review the instructions here for additional
> information about
> what is accepted - <
> https://www.arin.net/resources/request/transfers_8_2.html>
>
> > Number two:  If we do a 8.2 transfer followed by a 8.3 transfer, will
> the stated purpose for our number resources remains the same?? I am afraid
> of that ARIN will not approve our transfer.
>
> If you are the clear party with the rights after your purchase, ARIN will
> approve your
> transfer.  We may note that you have more addresses than you now need, and
> thus
> we expect you to return or transfer the remainder (but that would seem to
> line up with
> your intentions in any case.)
>
> If you have purchased a company without adequate documentation, or if
> multiple
> parties purchased multiple pieces of the company, or if there some
> question about
> what was purchased based on the documentation, then it can be more
> challenging
> to get the resources appropriately listed with you as the rightful holder.
>  You will need
> to apply for the transfer and work with the ARIN Hostmaster to determine
> if there is
> any issue in your particular case.
>
> > Number three:  As we have bought the company,  do we have the property
> right on those IPs?  in our past agreement and future agreement arranged
> for 8.3,  we would like to have some kinds of property right on those IPs,
>  will that conflict with ARIN policy?
>
> Wonderful question - it is ARIN's position that you have a specific set of
> rights to the
> address blocks in the registry (as defined by the registration services
> agreement that
> you enter with ARIN), and these rights include:
>
>     (1) The exclusive right to be the registrant of the Included Number
> Resources within the ARIN database;
>     (2) The right to use the Included Number Resources within the ARIN
> database; and
>     (3) The right to transfer the registration of the Included Number
> Resources pursuant to the Policies.
>
> ARIN registration services agreement includes a specific disclaimer of
> property rights
> in the address blocks, as it is inconsistent with the ability to manage
> the address blocks
> in accordance with community-developed policy in the region.  If you have
> other beliefs
> with respect to your rights, that would probably be an area for you to
> seek legal advice.
>
> I hope this helps; please do not hesitate to ask if you have any
> additional questions.
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140404/fd4aa749/attachment.htm>

From nikiyangxf at gmail.com  Thu Apr  3 19:43:43 2014
From: nikiyangxf at gmail.com (xiaofan yang)
Date: Fri, 4 Apr 2014 07:43:43 +0800
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <1846d87fe7164f22a7c63e9d1fed321e@EX13-MBX-13.ad.syr.edu>
References: <CAPhL6MoirOmJJ1TEFxu_uOdM-QRykoZZ3Ged5u71ATmh_mB+5Q@mail.gmail.com>
	<8089E44B-EBB1-4E91-9CAC-1A33A29F9012@arin.net>
	<CAPhL6MqE4-_K9ps9EsLvAwrsj8DvD1R+grgZKMAB6qpy_3YSUw@mail.gmail.com>
	<748D323F-21D9-4142-817F-ADD484F756DF@arin.net>
	<CAPhL6MoiAO1AAjg2_XHmPYJ_dFV5h8A+seQN4Pb789xfczQPmw@mail.gmail.com>
	<6BBC9339-AE30-446A-8406-8237A8C3477F@arin.net>
	<1846d87fe7164f22a7c63e9d1fed321e@EX13-MBX-13.ad.syr.edu>
Message-ID: <CAPhL6MrQdn-=5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A@mail.gmail.com>

Hi Milton,

thanks for your inspiring reply.  Now i know that we have the "ownership"
of those IPs.    as you are one of the AC, i take your reply seriously and
also this is good news for the community, especially for those legacy
holders, if the holder of ARIN non-legacy IPs can have the "ownership'
 then the holder of legacy IPs definitely has the ownership  on their IPs
 no matter whether they sign the RSA , LRSA or not.

Hope ARIN will not impose unpredictable "restrictions" when legacy or
non-legacy holder begins its transfer request. Moreover,  when ARIN reject
a transfer , hope ARIN will not use the "confidential terms" as an excuse
for not reply communities' questions in ppml.   or ARIN will reply with
bunch of info mean nothing.
Niki


On Thu, Apr 3, 2014 at 11:33 PM, Milton L Mueller <mueller at syr.edu> wrote:

> Niki:
> For most economists and lawyers, the definition of a "property right"
> involves the right to use, the right to exclude others from using, and the
> right to transfer. As John's message makes clear, all those rights are
> present in the number block lease you get from ARIN. So although the RSA
> makes you formally declaim a property right, what you are getting from the
> RSA is a bundle of rights that for all practical purposes has the same
> economic features as a property right.
>
> -----Original Message-----
>
> Wonderful question - it is ARIN's position that you have a specific set of
> rights to the address blocks in the registry (as defined by the
> registration services agreement that you enter with ARIN), and these rights
> include:
>
>     (1) The exclusive right to be the registrant of the Included Number
> Resources within the ARIN database;
>     (2) The right to use the Included Number Resources within the ARIN
> database; and
>     (3) The right to transfer the registration of the Included Number
> Resources pursuant to the Policies.
>
> ARIN registration services agreement includes a specific disclaimer of
> property rights in the address blocks, as it is inconsistent with the
> ability to manage the address blocks in accordance with community-developed
> policy in the region.  If you have other beliefs with respect to your
> rights, that would probably be an area for you to seek legal advice.
>
> I hope this helps; please do not hesitate to ask if you have any
> additional questions.
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> ARIN
>
> _______________________________________________
> 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/20140404/57c3a01e/attachment.htm>

From csquat at ccsd.net  Thu Apr  3 19:45:04 2014
From: csquat at ccsd.net (Chris R. Squatritto)
Date: Thu, 03 Apr 2014 16:45:04 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
Message-ID: <fc.004c4e074f46c9bc3b9aca00a1d36962.4f46c9be@interact.ccsd.net>

I am out of the office this week and will not be checking email.  Please
contact Troy Miller for assistance..

Thank you for contacting me, and have a great day.

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

From john.sweeting at twcable.com  Thu Apr  3 20:04:05 2014
From: john.sweeting at twcable.com (Sweeting, John)
Date: Thu, 3 Apr 2014 20:04:05 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <CAPhL6MrQdn-=5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A@mail.gmail.com>
References: <CAPhL6MoirOmJJ1TEFxu_uOdM-QRykoZZ3Ged5u71ATmh_mB+5Q@mail.gmail.com>
	<8089E44B-EBB1-4E91-9CAC-1A33A29F9012@arin.net>
	<CAPhL6MqE4-_K9ps9EsLvAwrsj8DvD1R+grgZKMAB6qpy_3YSUw@mail.gmail.com>
	<748D323F-21D9-4142-817F-ADD484F756DF@arin.net>
	<CAPhL6MoiAO1AAjg2_XHmPYJ_dFV5h8A+seQN4Pb789xfczQPmw@mail.gmail.com>
	<6BBC9339-AE30-446A-8406-8237A8C3477F@arin.net>
	<1846d87fe7164f22a7c63e9d1fed321e@EX13-MBX-13.ad.syr.edu>
	<CAPhL6MrQdn-=5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A@mail.gmail.com>
Message-ID: <C67A9BA5-6B38-4379-957B-7D7709A92133@twcable.com>

Niki

In no way should you take Milton's reply as an official stance or answer from the AC. He should have made it quite clear that he was speaking only as Milton and in anyway representing the AC.

Thank you
John S

Sent from my iPhone

On Apr 3, 2014, at 4:45 PM, "xiaofan yang" <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>> wrote:

Hi Milton,

thanks for your inspiring reply.  Now i know that we have the "ownership" of those IPs.    as you are one of the AC, i take your reply seriously and also this is good news for the community, especially for those legacy holders, if the holder of ARIN non-legacy IPs can have the "ownership'  then the holder of legacy IPs definitely has the ownership  on their IPs  no matter whether they sign the RSA , LRSA or not.

Hope ARIN will not impose unpredictable "restrictions" when legacy or non-legacy holder begins its transfer request. Moreover,  when ARIN reject a transfer , hope ARIN will not use the "confidential terms" as an excuse for not reply communities' questions in ppml.   or ARIN will reply with bunch of info mean nothing.
Niki


On Thu, Apr 3, 2014 at 11:33 PM, Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>> wrote:
Niki:
For most economists and lawyers, the definition of a "property right" involves the right to use, the right to exclude others from using, and the right to transfer. As John's message makes clear, all those rights are present in the number block lease you get from ARIN. So although the RSA makes you formally declaim a property right, what you are getting from the RSA is a bundle of rights that for all practical purposes has the same economic features as a property right.

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

Wonderful question - it is ARIN's position that you have a specific set of rights to the address blocks in the registry (as defined by the registration services agreement that you enter with ARIN), and these rights include:

    (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
    (2) The right to use the Included Number Resources within the ARIN database; and
    (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of property rights in the address blocks, as it is inconsistent with the ability to manage the address blocks in accordance with community-developed policy in the region.  If you have other beliefs with respect to your rights, that would probably be an area for you to seek legal advice.

I hope this helps; please do not hesitate to ask if you have any additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto: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<mailto: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<mailto:info at arin.net> if you experience any issues.

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140403/cf0c6531/attachment.htm>

From rockymm8 at gmail.com  Thu Apr  3 21:02:18 2014
From: rockymm8 at gmail.com (Rocky)
Date: Fri, 4 Apr 2014 09:02:18 +0800
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
Message-ID: <7AD26173D4094238B51D28EE6DE8A020@gmail.com>

Hello there,

What you are planning to do  seems  like you try to disguise an 8.3 transfer as an 8.2 transfer.   
I do not think it is appropriate for  allowing an 8.2 transfer followed by an 8.3/8.4 transfer.  

If the company does not need the IPv4 and the IPv4 are lack of utilisation,   why not ask this company to return the IPv4 for the benefit of the community?  

If the company wants to sell the IPv4 after an 8.2 to buyers through an 8.3/8.4,  why not the company directly transfer the IPv4 from its original organisation instead of  doing  an 8.2 first then followed by an 8.3/8.4 transfer.   Are the seller  trying to hide something or as the seller is afraid of doing something against the policy, so they try to make such an arrangement?  

There is a highly suspicious of ? IPv4 laundry? or ?IPv4 speculation?  about this company.     Maybe we need more transparency of the buy&sale of the IPv4 to make sure the behaviour of the seller is compatible with  policy.   

I suggest to resolve the language conflict between 8.2 transfer policy and RSA and further to suggest to figure out some measures to stop the  speculation on IPv4  via an 8.2 then followed by an 8.3/8.4 transfer.      If the company does not use the IPv4 after an 8.2 transfer, why not return them to free pool for the benefit of the whole community?  

Any ideas on this ?



On Friday, April 4, 2014 at 7:43 AM, arin-ppml-request at arin.net wrote:

> Send ARIN-PPML mailing list submissions to
> arin-ppml at arin.net (mailto:arin-ppml at arin.net)
>  
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
> arin-ppml-request at arin.net (mailto:arin-ppml-request at arin.net)
>  
> You can reach the person managing the list at
> arin-ppml-owner at arin.net (mailto:arin-ppml-owner at arin.net)
>  
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>  
>  
> Today's Topics:
>  
> 1. Re: ARIN-PPML Digest, Vol 106, Issue 7 (Chris R. Squatritto)
> 2. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> and 8.2 Utilization Requirements (John Curran)
> 3. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> and 8.2 Utilization Requirements (Milton L Mueller)
> 4. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> and 8.2 Utilization Requirements (xiaofan yang)
> 5. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> and 8.2 Utilization Requirements (xiaofan yang)
>  
>  
> ----------------------------------------------------------------------
>  
> Message: 1
> Date: Wed, 02 Apr 2014 16:30:45 -0700
> From: "Chris R. Squatritto" <csquat at ccsd.net (mailto:csquat at ccsd.net)>
> To: arin-ppml at arin.net (mailto:arin-ppml at arin.net)
> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 7
> Message-ID:
> <fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net (mailto:fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net)>
> Content-Type: text/plain; charset="utf-8"
>  
> I am out of the office this week and will not be checking email. Please
> contact Troy Miller for assistance..
>  
> Thank you for contacting me, and have a great day.
>  
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140402/5723c721/attachment-0001.html>
>  
> ------------------------------
>  
> Message: 2
> Date: Wed, 2 Apr 2014 23:59:20 +0000
> From: John Curran <jcurran at arin.net (mailto:jcurran at arin.net)>
> To: xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)>
> Cc: "arin-ppml at arin.net (mailto:arin-ppml at arin.net)" <arin-ppml at arin.net (mailto:arin-ppml at arin.net)>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> Between RSA and 8.2 Utilization Requirements
> Message-ID: <6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net (mailto:6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net)>
> Content-Type: text/plain; charset="iso-8859-1"
>  
> On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)> wrote:
>  
> > Hi John,  
> >  
> > I have further enquiry about ARIN 8.2 process.  
> >  
> > Number one:I am also worried about the costs of doing a 8.2 transfer followed by a 8.3 transfer. I wonder if I will have to involve the legal help to deal with ARIN legal. In my case I bought a company that now is out of business. How complicated does ARIN make this process? I want some assurance that I will be treated equally to any other companies whether it is a big company or a small company like us.
>  
> Niki -
>  
> You will be treated equally, but in truth I'm not certain that is actually what you want...
> (for example, a process which seems routine for a large organization could still pose  
> a disproportionate burden to a smaller organization since organization size is not a
> factor in the verification process.)
>  
> The first and foremost activity is to make sure that we have your organization registered
> as the rightful address holder, and that will require an NRPM 8.2 transfer. It can actually
> be relatively straightforward process, as long as you have clear documentation of the  
> purchase of the company. Review the instructions here for additional information about
> what is accepted - <https://www.arin.net/resources/request/transfers_8_2.html>
>  
> > Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will the stated purpose for our number resources remains the same?? I am afraid of that ARIN will not approve our transfer.  
>  
> If you are the clear party with the rights after your purchase, ARIN will approve your
> transfer. We may note that you have more addresses than you now need, and thus
> we expect you to return or transfer the remainder (but that would seem to line up with
> your intentions in any case.)
>  
> If you have purchased a company without adequate documentation, or if multiple
> parties purchased multiple pieces of the company, or if there some question about
> what was purchased based on the documentation, then it can be more challenging  
> to get the resources appropriately listed with you as the rightful holder. You will need
> to apply for the transfer and work with the ARIN Hostmaster to determine if there is
> any issue in your particular case.
>  
> > Number three: As we have bought the company, do we have the property right on those IPs? in our past agreement and future agreement arranged for 8.3, we would like to have some kinds of property right on those IPs, will that conflict with ARIN policy?
>  
> Wonderful question - it is ARIN's position that you have a specific set of rights to the  
> address blocks in the registry (as defined by the registration services agreement that
> you enter with ARIN), and these rights include:
>  
> (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;  
> (2) The right to use the Included Number Resources within the ARIN database; and
> (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.
>  
> ARIN registration services agreement includes a specific disclaimer of property rights
> in the address blocks, as it is inconsistent with the ability to manage the address blocks
> in accordance with community-developed policy in the region. If you have other beliefs
> with respect to your rights, that would probably be an area for you to seek legal advice.
>  
> I hope this helps; please do not hesitate to ask if you have any additional questions.
>  
> Thanks!
> /John
>  
> John Curran
> President and CEO
> ARIN
>  
>  
>  
> ------------------------------
>  
> Message: 3
> Date: Thu, 3 Apr 2014 15:33:13 +0000
> From: Milton L Mueller <mueller at syr.edu (mailto:mueller at syr.edu)>
> To: "'John Curran'" <jcurran at arin.net (mailto:jcurran at arin.net)>, xiaofan yang
> <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)>
> Cc: "arin-ppml at arin.net (mailto:arin-ppml at arin.net)" <arin-ppml at arin.net (mailto:arin-ppml at arin.net)>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> Between RSA and 8.2 Utilization Requirements
> Message-ID: <1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu (mailto:1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu)>
> Content-Type: text/plain; charset="us-ascii"
>  
> Niki:
> For most economists and lawyers, the definition of a "property right" involves the right to use, the right to exclude others from using, and the right to transfer. As John's message makes clear, all those rights are present in the number block lease you get from ARIN. So although the RSA makes you formally declaim a property right, what you are getting from the RSA is a bundle of rights that for all practical purposes has the same economic features as a property right.  
>  
> -----Original Message-----
>  
> Wonderful question - it is ARIN's position that you have a specific set of rights to the address blocks in the registry (as defined by the registration services agreement that you enter with ARIN), and these rights include:
>  
> (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;  
> (2) The right to use the Included Number Resources within the ARIN database; and
> (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.
>  
> ARIN registration services agreement includes a specific disclaimer of property rights in the address blocks, as it is inconsistent with the ability to manage the address blocks in accordance with community-developed policy in the region. If you have other beliefs with respect to your rights, that would probably be an area for you to seek legal advice.
>  
> I hope this helps; please do not hesitate to ask if you have any additional questions.
>  
> Thanks!
> /John
>  
> John Curran
> President and CEO
> ARIN
>  
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net (mailto: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 (mailto:info at arin.net) if you experience any issues.
>  
>  
> ------------------------------
>  
> Message: 4
> Date: Fri, 4 Apr 2014 07:33:04 +0800
> From: xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)>
> To: John Curran <jcurran at arin.net (mailto:jcurran at arin.net)>
> Cc: "arin-ppml at arin.net (mailto:arin-ppml at arin.net)" <arin-ppml at arin.net (mailto:arin-ppml at arin.net)>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> Between RSA and 8.2 Utilization Requirements
> Message-ID:
> <CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com (mailto:CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com)>
> Content-Type: text/plain; charset="iso-8859-1"
>  
> Hi John,
>  
>  
> In basis of your reply, if the block is underutilised,ARIN will either ask
> the company to return the IPs or transfer to other third party via 8.3
> transfer after our 8.2 transfer.
>  
>  
> Say we have two /16 after this 8.2 transfer, what if we only transfer one
> /16 to the other third party via 8.3 transfer, meanwhile, we keep the
> other /16 left unused after our 8.2 transfer for quiet a while. Will ARIN
> ask us to return the remained /16 to the free pool? furthmore, how long
> will ARIN allow us to keep the other /16 unused before we transfer it to
> the third party via 8.3 transfer ?
>  
>  
>  
> Niki
>  
>  
>  
>  
> On Thu, Apr 3, 2014 at 7:59 AM, John Curran <jcurran at arin.net (mailto:jcurran at arin.net)> wrote:
>  
> > On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)> wrote:
> >  
> > > Hi John,
> > >  
> > > I have further enquiry about ARIN 8.2 process.
> > >  
> > > Number one:I am also worried about the costs of doing a 8.2 transfer
> > followed by a 8.3 transfer. I wonder if I will have to involve the legal
> > help to deal with ARIN legal. In my case I bought a company that now is
> > out of business. How complicated does ARIN make this process? I want some
> > assurance that I will be treated equally to any other companies whether it
> > is a big company or a small company like us.
> >  
> > Niki -
> >  
> > You will be treated equally, but in truth I'm not certain that is actually
> > what you want...
> > (for example, a process which seems routine for a large organization could
> > still pose
> > a disproportionate burden to a smaller organization since organization
> > size is not a
> > factor in the verification process.)
> >  
> > The first and foremost activity is to make sure that we have your
> > organization registered
> > as the rightful address holder, and that will require an NRPM 8.2
> > transfer. It can actually
> > be relatively straightforward process, as long as you have clear
> > documentation of the
> > purchase of the company. Review the instructions here for additional
> > information about
> > what is accepted - <
> > https://www.arin.net/resources/request/transfers_8_2.html>
> >  
> > > Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will
> > the stated purpose for our number resources remains the same?? I am afraid
> > of that ARIN will not approve our transfer.
> >  
> > If you are the clear party with the rights after your purchase, ARIN will
> > approve your
> > transfer. We may note that you have more addresses than you now need, and
> > thus
> > we expect you to return or transfer the remainder (but that would seem to
> > line up with
> > your intentions in any case.)
> >  
> > If you have purchased a company without adequate documentation, or if
> > multiple
> > parties purchased multiple pieces of the company, or if there some
> > question about
> > what was purchased based on the documentation, then it can be more
> > challenging
> > to get the resources appropriately listed with you as the rightful holder.
> > You will need
> > to apply for the transfer and work with the ARIN Hostmaster to determine
> > if there is
> > any issue in your particular case.
> >  
> > > Number three: As we have bought the company, do we have the property
> > right on those IPs? in our past agreement and future agreement arranged
> > for 8.3, we would like to have some kinds of property right on those IPs,
> > will that conflict with ARIN policy?
> >  
> > Wonderful question - it is ARIN's position that you have a specific set of
> > rights to the
> > address blocks in the registry (as defined by the registration services
> > agreement that
> > you enter with ARIN), and these rights include:
> >  
> > (1) The exclusive right to be the registrant of the Included Number
> > Resources within the ARIN database;
> > (2) The right to use the Included Number Resources within the ARIN
> > database; and
> > (3) The right to transfer the registration of the Included Number
> > Resources pursuant to the Policies.
> >  
> > ARIN registration services agreement includes a specific disclaimer of
> > property rights
> > in the address blocks, as it is inconsistent with the ability to manage
> > the address blocks
> > in accordance with community-developed policy in the region. If you have
> > other beliefs
> > with respect to your rights, that would probably be an area for you to
> > seek legal advice.
> >  
> > I hope this helps; please do not hesitate to ask if you have any
> > additional questions.
> >  
> > Thanks!
> > /John
> >  
> > John Curran
> > President and CEO
> > ARIN
> >  
>  
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/fd4aa749/attachment-0001.html>
>  
> ------------------------------
>  
> Message: 5
> Date: Fri, 4 Apr 2014 07:43:43 +0800
> From: xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)>
> To: Milton L Mueller <mueller at syr.edu (mailto:mueller at syr.edu)>
> Cc: John Curran <jcurran at arin.net (mailto:jcurran at arin.net)>, "arin-ppml at arin.net (mailto:arin-ppml at arin.net)"
> <arin-ppml at arin.net (mailto:arin-ppml at arin.net)>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> Between RSA and 8.2 Utilization Requirements
> Message-ID:
> <CAPhL6MrQdn-=5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com (mailto:5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com)>
> Content-Type: text/plain; charset="iso-8859-1"
>  
> Hi Milton,
>  
> thanks for your inspiring reply. Now i know that we have the "ownership"
> of those IPs. as you are one of the AC, i take your reply seriously and
> also this is good news for the community, especially for those legacy
> holders, if the holder of ARIN non-legacy IPs can have the "ownership'
> then the holder of legacy IPs definitely has the ownership on their IPs
> no matter whether they sign the RSA , LRSA or not.
>  
> Hope ARIN will not impose unpredictable "restrictions" when legacy or
> non-legacy holder begins its transfer request. Moreover, when ARIN reject
> a transfer , hope ARIN will not use the "confidential terms" as an excuse
> for not reply communities' questions in ppml. or ARIN will reply with
> bunch of info mean nothing.
> Niki
>  
>  
> On Thu, Apr 3, 2014 at 11:33 PM, Milton L Mueller <mueller at syr.edu (mailto:mueller at syr.edu)> wrote:
>  
> > Niki:
> > For most economists and lawyers, the definition of a "property right"
> > involves the right to use, the right to exclude others from using, and the
> > right to transfer. As John's message makes clear, all those rights are
> > present in the number block lease you get from ARIN. So although the RSA
> > makes you formally declaim a property right, what you are getting from the
> > RSA is a bundle of rights that for all practical purposes has the same
> > economic features as a property right.
> >  
> > -----Original Message-----
> >  
> > Wonderful question - it is ARIN's position that you have a specific set of
> > rights to the address blocks in the registry (as defined by the
> > registration services agreement that you enter with ARIN), and these rights
> > include:
> >  
> > (1) The exclusive right to be the registrant of the Included Number
> > Resources within the ARIN database;
> > (2) The right to use the Included Number Resources within the ARIN
> > database; and
> > (3) The right to transfer the registration of the Included Number
> > Resources pursuant to the Policies.
> >  
> > ARIN registration services agreement includes a specific disclaimer of
> > property rights in the address blocks, as it is inconsistent with the
> > ability to manage the address blocks in accordance with community-developed
> > policy in the region. If you have other beliefs with respect to your
> > rights, that would probably be an area for you to seek legal advice.
> >  
> > I hope this helps; please do not hesitate to ask if you have any
> > additional questions.
> >  
> > Thanks!
> > /John
> >  
> > John Curran
> > President and CEO
> > ARIN
> >  
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to the ARIN
> > Public Policy Mailing List (ARIN-PPML at arin.net (mailto: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 (mailto:info at arin.net) if you experience any issues.
> >  
>  
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/57c3a01e/attachment.html>
>  
> ------------------------------
>  
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net (mailto:ARIN-PPML at arin.net)
> http://lists.arin.net/mailman/listinfo/arin-ppml
>  
> End of ARIN-PPML Digest, Vol 106, Issue 8
> *****************************************
>  
>  


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

From scottleibrand at gmail.com  Thu Apr  3 21:25:06 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 3 Apr 2014 18:25:06 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <7AD26173D4094238B51D28EE6DE8A020@gmail.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<7AD26173D4094238B51D28EE6DE8A020@gmail.com>
Message-ID: <04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>

Rocky,

Many such 8.2 transfers are efforts to get ARIN's records up to date regarding M&A transactions that happened years ago. It is not possible for a no-longer-existent entity to execute the 8.3 transfer, so it has to be 8.2 transferred to the new entity first. 

Scott

> On Apr 3, 2014, at 6:02 PM, Rocky <rockymm8 at gmail.com> wrote:
> 
> Hello there,
> 
> What you are planning to do  seems  like you try to disguise an 8.3 transfer as an 8.2 transfer. 
> I do not think it is appropriate for  allowing an 8.2 transfer followed by an 8.3/8.4 transfer. 
> 
> If the company does not need the IPv4 and the IPv4 are lack of utilisation,   why not ask this company to return the IPv4 for the benefit of the community?
> 
> If the company wants to sell the IPv4 after an 8.2 to buyers through an 8.3/8.4,  why not the company directly transfer the IPv4 from its original organisation instead of  doing  an 8.2 first then followed by an 8.3/8.4 transfer.   Are the seller  trying to hide something or as the seller is afraid of doing something against the policy, so they try to make such an arrangement?
> 
> There is a highly suspicious of ? IPv4 laundry? or ?IPv4 speculation?  about this company.     Maybe we need more transparency of the buy&sale of the IPv4 to make sure the behaviour of the seller is compatible with  policy. 
> 
> I suggest to resolve the language conflict between 8.2 transfer policy and RSA and further to suggest to figure out some measures to stop the  speculation on IPv4  via an 8.2 then followed by an 8.3/8.4 transfer.      If the company does not use the IPv4 after an 8.2 transfer, why not return them to free pool for the benefit of the whole community?
> 
> Any ideas on this ?
> 
> 
>> On Friday, April 4, 2014 at 7:43 AM, arin-ppml-request at arin.net wrote:
>> 
>> Send ARIN-PPML mailing list submissions to
>> arin-ppml at arin.net
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> or, via email, send a message with subject or body 'help' to
>> arin-ppml-request at arin.net
>> 
>> You can reach the person managing the list at
>> arin-ppml-owner at arin.net
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of ARIN-PPML digest..."
>> 
>> 
>> Today's Topics:
>> 
>> 1. Re: ARIN-PPML Digest, Vol 106, Issue 7 (Chris R. Squatritto)
>> 2. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
>> and 8.2 Utilization Requirements (John Curran)
>> 3. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
>> and 8.2 Utilization Requirements (Milton L Mueller)
>> 4. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
>> and 8.2 Utilization Requirements (xiaofan yang)
>> 5. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
>> and 8.2 Utilization Requirements (xiaofan yang)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Wed, 02 Apr 2014 16:30:45 -0700
>> From: "Chris R. Squatritto" <csquat at ccsd.net>
>> To: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 7
>> Message-ID:
>> <fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> I am out of the office this week and will not be checking email. Please
>> contact Troy Miller for assistance..
>> 
>> Thank you for contacting me, and have a great day.
>> 
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140402/5723c721/attachment-0001.html>
>> 
>> ------------------------------
>> 
>> Message: 2
>> Date: Wed, 2 Apr 2014 23:59:20 +0000
>> From: John Curran <jcurran at arin.net>
>> To: xiaofan yang <nikiyangxf at gmail.com>
>> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
>> Between RSA and 8.2 Utilization Requirements
>> Message-ID: <6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>>> On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:
>>> 
>>> Hi John,
>>> 
>>> I have further enquiry about ARIN 8.2 process.
>>> 
>>> Number one:I am also worried about the costs of doing a 8.2 transfer followed by a 8.3 transfer. I wonder if I will have to involve the legal help to deal with ARIN legal. In my case I bought a company that now is out of business. How complicated does ARIN make this process? I want some assurance that I will be treated equally to any other companies whether it is a big company or a small company like us.
>> 
>> Niki -
>> 
>> You will be treated equally, but in truth I'm not certain that is actually what you want...
>> (for example, a process which seems routine for a large organization could still pose
>> a disproportionate burden to a smaller organization since organization size is not a
>> factor in the verification process.)
>> 
>> The first and foremost activity is to make sure that we have your organization registered
>> as the rightful address holder, and that will require an NRPM 8.2 transfer. It can actually
>> be relatively straightforward process, as long as you have clear documentation of the
>> purchase of the company. Review the instructions here for additional information about
>> what is accepted - <https://www.arin.net/resources/request/transfers_8_2.html>
>> 
>>> Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will the stated purpose for our number resources remains the same?? I am afraid of that ARIN will not approve our transfer.
>> 
>> If you are the clear party with the rights after your purchase, ARIN will approve your
>> transfer. We may note that you have more addresses than you now need, and thus
>> we expect you to return or transfer the remainder (but that would seem to line up with
>> your intentions in any case.)
>> 
>> If you have purchased a company without adequate documentation, or if multiple
>> parties purchased multiple pieces of the company, or if there some question about
>> what was purchased based on the documentation, then it can be more challenging
>> to get the resources appropriately listed with you as the rightful holder. You will need
>> to apply for the transfer and work with the ARIN Hostmaster to determine if there is
>> any issue in your particular case.
>> 
>>> Number three: As we have bought the company, do we have the property right on those IPs? in our past agreement and future agreement arranged for 8.3, we would like to have some kinds of property right on those IPs, will that conflict with ARIN policy?
>> 
>> Wonderful question - it is ARIN's position that you have a specific set of rights to the
>> address blocks in the registry (as defined by the registration services agreement that
>> you enter with ARIN), and these rights include:
>> 
>> (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
>> (2) The right to use the Included Number Resources within the ARIN database; and
>> (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.
>> 
>> ARIN registration services agreement includes a specific disclaimer of property rights
>> in the address blocks, as it is inconsistent with the ability to manage the address blocks
>> in accordance with community-developed policy in the region. If you have other beliefs
>> with respect to your rights, that would probably be an area for you to seek legal advice.
>> 
>> I hope this helps; please do not hesitate to ask if you have any additional questions.
>> 
>> Thanks!
>> /John
>> 
>> John Curran
>> President and CEO
>> ARIN
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 3
>> Date: Thu, 3 Apr 2014 15:33:13 +0000
>> From: Milton L Mueller <mueller at syr.edu>
>> To: "'John Curran'" <jcurran at arin.net>, xiaofan yang
>> <nikiyangxf at gmail.com>
>> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
>> Between RSA and 8.2 Utilization Requirements
>> Message-ID: <1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu>
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> Niki:
>> For most economists and lawyers, the definition of a "property right" involves the right to use, the right to exclude others from using, and the right to transfer. As John's message makes clear, all those rights are present in the number block lease you get from ARIN. So although the RSA makes you formally declaim a property right, what you are getting from the RSA is a bundle of rights that for all practical purposes has the same economic features as a property right.
>> 
>> -----Original Message-----
>> 
>> Wonderful question - it is ARIN's position that you have a specific set of rights to the address blocks in the registry (as defined by the registration services agreement that you enter with ARIN), and these rights include:
>> 
>> (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
>> (2) The right to use the Included Number Resources within the ARIN database; and
>> (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.
>> 
>> ARIN registration services agreement includes a specific disclaimer of property rights in the address blocks, as it is inconsistent with the ability to manage the address blocks in accordance with community-developed policy in the region. If you have other beliefs with respect to your rights, that would probably be an area for you to seek legal advice.
>> 
>> I hope this helps; please do not hesitate to ask if you have any additional questions.
>> 
>> Thanks!
>> /John
>> 
>> John Curran
>> President and CEO
>> ARIN
>> 
>> _______________________________________________
>> 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.
>> 
>> 
>> ------------------------------
>> 
>> Message: 4
>> Date: Fri, 4 Apr 2014 07:33:04 +0800
>> From: xiaofan yang <nikiyangxf at gmail.com>
>> To: John Curran <jcurran at arin.net>
>> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
>> Between RSA and 8.2 Utilization Requirements
>> Message-ID:
>> <CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> Hi John,
>> 
>> 
>> In basis of your reply, if the block is underutilised,ARIN will either ask
>> the company to return the IPs or transfer to other third party via 8.3
>> transfer after our 8.2 transfer.
>> 
>> 
>> Say we have two /16 after this 8.2 transfer, what if we only transfer one
>> /16 to the other third party via 8.3 transfer, meanwhile, we keep the
>> other /16 left unused after our 8.2 transfer for quiet a while. Will ARIN
>> ask us to return the remained /16 to the free pool? furthmore, how long
>> will ARIN allow us to keep the other /16 unused before we transfer it to
>> the third party via 8.3 transfer ?
>> 
>> 
>> 
>> Niki
>> 
>> 
>> 
>> 
>>> On Thu, Apr 3, 2014 at 7:59 AM, John Curran <jcurran at arin.net> wrote:
>>> 
>>>> On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:
>>>> 
>>>> Hi John,
>>>> 
>>>> I have further enquiry about ARIN 8.2 process.
>>>> 
>>>> Number one:I am also worried about the costs of doing a 8.2 transfer
>>> followed by a 8.3 transfer. I wonder if I will have to involve the legal
>>> help to deal with ARIN legal. In my case I bought a company that now is
>>> out of business. How complicated does ARIN make this process? I want some
>>> assurance that I will be treated equally to any other companies whether it
>>> is a big company or a small company like us.
>>> 
>>> Niki -
>>> 
>>> You will be treated equally, but in truth I'm not certain that is actually
>>> what you want...
>>> (for example, a process which seems routine for a large organization could
>>> still pose
>>> a disproportionate burden to a smaller organization since organization
>>> size is not a
>>> factor in the verification process.)
>>> 
>>> The first and foremost activity is to make sure that we have your
>>> organization registered
>>> as the rightful address holder, and that will require an NRPM 8.2
>>> transfer. It can actually
>>> be relatively straightforward process, as long as you have clear
>>> documentation of the
>>> purchase of the company. Review the instructions here for additional
>>> information about
>>> what is accepted - <
>>> https://www.arin.net/resources/request/transfers_8_2.html>
>>> 
>>>> Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will
>>> the stated purpose for our number resources remains the same?? I am afraid
>>> of that ARIN will not approve our transfer.
>>> 
>>> If you are the clear party with the rights after your purchase, ARIN will
>>> approve your
>>> transfer. We may note that you have more addresses than you now need, and
>>> thus
>>> we expect you to return or transfer the remainder (but that would seem to
>>> line up with
>>> your intentions in any case.)
>>> 
>>> If you have purchased a company without adequate documentation, or if
>>> multiple
>>> parties purchased multiple pieces of the company, or if there some
>>> question about
>>> what was purchased based on the documentation, then it can be more
>>> challenging
>>> to get the resources appropriately listed with you as the rightful holder.
>>> You will need
>>> to apply for the transfer and work with the ARIN Hostmaster to determine
>>> if there is
>>> any issue in your particular case.
>>> 
>>>> Number three: As we have bought the company, do we have the property
>>> right on those IPs? in our past agreement and future agreement arranged
>>> for 8.3, we would like to have some kinds of property right on those IPs,
>>> will that conflict with ARIN policy?
>>> 
>>> Wonderful question - it is ARIN's position that you have a specific set of
>>> rights to the
>>> address blocks in the registry (as defined by the registration services
>>> agreement that
>>> you enter with ARIN), and these rights include:
>>> 
>>> (1) The exclusive right to be the registrant of the Included Number
>>> Resources within the ARIN database;
>>> (2) The right to use the Included Number Resources within the ARIN
>>> database; and
>>> (3) The right to transfer the registration of the Included Number
>>> Resources pursuant to the Policies.
>>> 
>>> ARIN registration services agreement includes a specific disclaimer of
>>> property rights
>>> in the address blocks, as it is inconsistent with the ability to manage
>>> the address blocks
>>> in accordance with community-developed policy in the region. If you have
>>> other beliefs
>>> with respect to your rights, that would probably be an area for you to
>>> seek legal advice.
>>> 
>>> I hope this helps; please do not hesitate to ask if you have any
>>> additional questions.
>>> 
>>> Thanks!
>>> /John
>>> 
>>> John Curran
>>> President and CEO
>>> ARIN
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/fd4aa749/attachment-0001.html>
>> 
>> ------------------------------
>> 
>> Message: 5
>> Date: Fri, 4 Apr 2014 07:43:43 +0800
>> From: xiaofan yang <nikiyangxf at gmail.com>
>> To: Milton L Mueller <mueller at syr.edu>
>> Cc: John Curran <jcurran at arin.net>, "arin-ppml at arin.net"
>> <arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
>> Between RSA and 8.2 Utilization Requirements
>> Message-ID:
>> <CAPhL6MrQdn-=5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> Hi Milton,
>> 
>> thanks for your inspiring reply. Now i know that we have the "ownership"
>> of those IPs. as you are one of the AC, i take your reply seriously and
>> also this is good news for the community, especially for those legacy
>> holders, if the holder of ARIN non-legacy IPs can have the "ownership'
>> then the holder of legacy IPs definitely has the ownership on their IPs
>> no matter whether they sign the RSA , LRSA or not.
>> 
>> Hope ARIN will not impose unpredictable "restrictions" when legacy or
>> non-legacy holder begins its transfer request. Moreover, when ARIN reject
>> a transfer , hope ARIN will not use the "confidential terms" as an excuse
>> for not reply communities' questions in ppml. or ARIN will reply with
>> bunch of info mean nothing.
>> Niki
>> 
>> 
>>> On Thu, Apr 3, 2014 at 11:33 PM, Milton L Mueller <mueller at syr.edu> wrote:
>>> 
>>> Niki:
>>> For most economists and lawyers, the definition of a "property right"
>>> involves the right to use, the right to exclude others from using, and the
>>> right to transfer. As John's message makes clear, all those rights are
>>> present in the number block lease you get from ARIN. So although the RSA
>>> makes you formally declaim a property right, what you are getting from the
>>> RSA is a bundle of rights that for all practical purposes has the same
>>> economic features as a property right.
>>> 
>>> -----Original Message-----
>>> 
>>> Wonderful question - it is ARIN's position that you have a specific set of
>>> rights to the address blocks in the registry (as defined by the
>>> registration services agreement that you enter with ARIN), and these rights
>>> include:
>>> 
>>> (1) The exclusive right to be the registrant of the Included Number
>>> Resources within the ARIN database;
>>> (2) The right to use the Included Number Resources within the ARIN
>>> database; and
>>> (3) The right to transfer the registration of the Included Number
>>> Resources pursuant to the Policies.
>>> 
>>> ARIN registration services agreement includes a specific disclaimer of
>>> property rights in the address blocks, as it is inconsistent with the
>>> ability to manage the address blocks in accordance with community-developed
>>> policy in the region. If you have other beliefs with respect to your
>>> rights, that would probably be an area for you to seek legal advice.
>>> 
>>> I hope this helps; please do not hesitate to ask if you have any
>>> additional questions.
>>> 
>>> Thanks!
>>> /John
>>> 
>>> John Curran
>>> President and CEO
>>> ARIN
>>> 
>>> _______________________________________________
>>> 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: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/57c3a01e/attachment.html>
>> 
>> ------------------------------
>> 
>> _______________________________________________
>> ARIN-PPML mailing list
>> ARIN-PPML at arin.net
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> 
>> End of ARIN-PPML Digest, Vol 106, Issue 8
>> *****************************************
> 
> _______________________________________________
> 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/20140403/86ab1c8b/attachment.htm>

From rockymm8 at gmail.com  Thu Apr  3 23:04:30 2014
From: rockymm8 at gmail.com (Rocky)
Date: Fri, 4 Apr 2014 11:04:30 +0800
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 10
In-Reply-To: <mailman.1557.1396574716.28847.arin-ppml@arin.net>
References: <mailman.1557.1396574716.28847.arin-ppml@arin.net>
Message-ID: <BCF55E8E80244BB78F99AC5E58488E7C@gmail.com>

Scott

thanks for your explanation.   
1. how can ARIN make sure this 8.2 transfer is not speculating about IPv4?
2. if the entity no longer existent,  why not return the IPv4  after its dissolved?  or why not update the ARIN database in time after the M/A.  What you are trying to say make me feel that ARIN policy is encouraging the  stockpile of IPv4? some People do it until the IPv4 becomes expensive and some people can benefit huge from its stockpile ( for past many years) by update its registration info via 8.2 transfer  to sell a great price after the next 8.3 transfer.
the check of utilisation rate under 8.2 is just a formalism and considering the wording there conflicts with RSA, why not delete the utilisation rate requirement in the 8.2? or revise the RSA accordingly.

Rocky



On Friday, April 4, 2014 at 9:25 AM, arin-ppml-request at arin.net wrote:  
> Send ARIN-PPML mailing list submissions to
> arin-ppml at arin.net (mailto:arin-ppml at arin.net)
>  
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
> arin-ppml-request at arin.net (mailto:arin-ppml-request at arin.net)
>  
> You can reach the person managing the list at
> arin-ppml-owner at arin.net (mailto:arin-ppml-owner at arin.net)
>  
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>  
>  
> Today's Topics:
>  
> 1. Re: ARIN-PPML Digest, Vol 106, Issue 8 (Scott Leibrand)
>  
>  
> ----------------------------------------------------------------------
>  
> Message: 1
> Date: Thu, 3 Apr 2014 18:25:06 -0700
> From: Scott Leibrand <scottleibrand at gmail.com (mailto:scottleibrand at gmail.com)>
> To: Rocky <rockymm8 at gmail.com (mailto:rockymm8 at gmail.com)>
> Cc: "arin-ppml at arin.net (mailto:arin-ppml at arin.net)" <arin-ppml at arin.net (mailto:arin-ppml at arin.net)>
> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
> Message-ID: <04DC25C4-5352-4DC8-A114-EA1724DC88EE at gmail.com (mailto:04DC25C4-5352-4DC8-A114-EA1724DC88EE at gmail.com)>
> Content-Type: text/plain; charset="utf-8"
>  
> Rocky,
>  
> Many such 8.2 transfers are efforts to get ARIN's records up to date regarding M&A transactions that happened years ago. It is not possible for a no-longer-existent entity to execute the 8.3 transfer, so it has to be 8.2 transferred to the new entity first.  
>  
> Scott
>  
> > On Apr 3, 2014, at 6:02 PM, Rocky <rockymm8 at gmail.com (mailto:rockymm8 at gmail.com)> wrote:
> >  
> > Hello there,
> >  
> > What you are planning to do seems like you try to disguise an 8.3 transfer as an 8.2 transfer.  
> > I do not think it is appropriate for allowing an 8.2 transfer followed by an 8.3/8.4 transfer.  
> >  
> > If the company does not need the IPv4 and the IPv4 are lack of utilisation, why not ask this company to return the IPv4 for the benefit of the community?
> >  
> > If the company wants to sell the IPv4 after an 8.2 to buyers through an 8.3/8.4, why not the company directly transfer the IPv4 from its original organisation instead of doing an 8.2 first then followed by an 8.3/8.4 transfer. Are the seller trying to hide something or as the seller is afraid of doing something against the policy, so they try to make such an arrangement?
> >  
> > There is a highly suspicious of ? IPv4 laundry? or ?IPv4 speculation? about this company. Maybe we need more transparency of the buy&sale of the IPv4 to make sure the behaviour of the seller is compatible with policy.  
> >  
> > I suggest to resolve the language conflict between 8.2 transfer policy and RSA and further to suggest to figure out some measures to stop the speculation on IPv4 via an 8.2 then followed by an 8.3/8.4 transfer. If the company does not use the IPv4 after an 8.2 transfer, why not return them to free pool for the benefit of the whole community?
> >  
> > Any ideas on this ?
> >  
> >  
> > > On Friday, April 4, 2014 at 7:43 AM, arin-ppml-request at arin.net (mailto:arin-ppml-request at arin.net) wrote:
> > >  
> > > Send ARIN-PPML mailing list submissions to
> > > arin-ppml at arin.net (mailto:arin-ppml at arin.net)
> > >  
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > or, via email, send a message with subject or body 'help' to
> > > arin-ppml-request at arin.net (mailto:arin-ppml-request at arin.net)
> > >  
> > > You can reach the person managing the list at
> > > arin-ppml-owner at arin.net (mailto:arin-ppml-owner at arin.net)
> > >  
> > > When replying, please edit your Subject line so it is more specific
> > > than "Re: Contents of ARIN-PPML digest..."
> > >  
> > >  
> > > Today's Topics:
> > >  
> > > 1. Re: ARIN-PPML Digest, Vol 106, Issue 7 (Chris R. Squatritto)
> > > 2. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> > > and 8.2 Utilization Requirements (John Curran)
> > > 3. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> > > and 8.2 Utilization Requirements (Milton L Mueller)
> > > 4. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> > > and 8.2 Utilization Requirements (xiaofan yang)
> > > 5. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> > > and 8.2 Utilization Requirements (xiaofan yang)
> > >  
> > >  
> > > ----------------------------------------------------------------------
> > >  
> > > Message: 1
> > > Date: Wed, 02 Apr 2014 16:30:45 -0700
> > > From: "Chris R. Squatritto" <csquat at ccsd.net (mailto:csquat at ccsd.net)>
> > > To: arin-ppml at arin.net (mailto:arin-ppml at arin.net)
> > > Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 7
> > > Message-ID:
> > > <fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net (mailto:fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net)>
> > > Content-Type: text/plain; charset="utf-8"
> > >  
> > > I am out of the office this week and will not be checking email. Please
> > > contact Troy Miller for assistance..
> > >  
> > > Thank you for contacting me, and have a great day.
> > >  
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140402/5723c721/attachment-0001.html>
> > >  
> > > ------------------------------
> > >  
> > > Message: 2
> > > Date: Wed, 2 Apr 2014 23:59:20 +0000
> > > From: John Curran <jcurran at arin.net (mailto:jcurran at arin.net)>
> > > To: xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)>
> > > Cc: "arin-ppml at arin.net (mailto:arin-ppml at arin.net)" <arin-ppml at arin.net (mailto:arin-ppml at arin.net)>
> > > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> > > Between RSA and 8.2 Utilization Requirements
> > > Message-ID: <6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net (mailto:6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net)>
> > > Content-Type: text/plain; charset="iso-8859-1"
> > >  
> > > > On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)> wrote:
> > > >  
> > > > Hi John,
> > > >  
> > > > I have further enquiry about ARIN 8.2 process.
> > > >  
> > > > Number one:I am also worried about the costs of doing a 8.2 transfer followed by a 8.3 transfer. I wonder if I will have to involve the legal help to deal with ARIN legal. In my case I bought a company that now is out of business. How complicated does ARIN make this process? I want some assurance that I will be treated equally to any other companies whether it is a big company or a small company like us.
> > >  
> > > Niki -
> > >  
> > > You will be treated equally, but in truth I'm not certain that is actually what you want...
> > > (for example, a process which seems routine for a large organization could still pose
> > > a disproportionate burden to a smaller organization since organization size is not a
> > > factor in the verification process.)
> > >  
> > > The first and foremost activity is to make sure that we have your organization registered
> > > as the rightful address holder, and that will require an NRPM 8.2 transfer. It can actually
> > > be relatively straightforward process, as long as you have clear documentation of the
> > > purchase of the company. Review the instructions here for additional information about
> > > what is accepted - <https://www.arin.net/resources/request/transfers_8_2.html>
> > >  
> > > > Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will the stated purpose for our number resources remains the same?? I am afraid of that ARIN will not approve our transfer.
> > >  
> > > If you are the clear party with the rights after your purchase, ARIN will approve your
> > > transfer. We may note that you have more addresses than you now need, and thus
> > > we expect you to return or transfer the remainder (but that would seem to line up with
> > > your intentions in any case.)
> > >  
> > > If you have purchased a company without adequate documentation, or if multiple
> > > parties purchased multiple pieces of the company, or if there some question about
> > > what was purchased based on the documentation, then it can be more challenging
> > > to get the resources appropriately listed with you as the rightful holder. You will need
> > > to apply for the transfer and work with the ARIN Hostmaster to determine if there is
> > > any issue in your particular case.
> > >  
> > > > Number three: As we have bought the company, do we have the property right on those IPs? in our past agreement and future agreement arranged for 8.3, we would like to have some kinds of property right on those IPs, will that conflict with ARIN policy?
> > >  
> > > Wonderful question - it is ARIN's position that you have a specific set of rights to the
> > > address blocks in the registry (as defined by the registration services agreement that
> > > you enter with ARIN), and these rights include:
> > >  
> > > (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
> > > (2) The right to use the Included Number Resources within the ARIN database; and
> > > (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.
> > >  
> > > ARIN registration services agreement includes a specific disclaimer of property rights
> > > in the address blocks, as it is inconsistent with the ability to manage the address blocks
> > > in accordance with community-developed policy in the region. If you have other beliefs
> > > with respect to your rights, that would probably be an area for you to seek legal advice.
> > >  
> > > I hope this helps; please do not hesitate to ask if you have any additional questions.
> > >  
> > > Thanks!
> > > /John
> > >  
> > > John Curran
> > > President and CEO
> > > ARIN
> > >  
> > >  
> > >  
> > > ------------------------------
> > >  
> > > Message: 3
> > > Date: Thu, 3 Apr 2014 15:33:13 +0000
> > > From: Milton L Mueller <mueller at syr.edu (mailto:mueller at syr.edu)>
> > > To: "'John Curran'" <jcurran at arin.net (mailto:jcurran at arin.net)>, xiaofan yang
> > > <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)>
> > > Cc: "arin-ppml at arin.net (mailto:arin-ppml at arin.net)" <arin-ppml at arin.net (mailto:arin-ppml at arin.net)>
> > > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> > > Between RSA and 8.2 Utilization Requirements
> > > Message-ID: <1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu (mailto:1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu)>
> > > Content-Type: text/plain; charset="us-ascii"
> > >  
> > > Niki:
> > > For most economists and lawyers, the definition of a "property right" involves the right to use, the right to exclude others from using, and the right to transfer. As John's message makes clear, all those rights are present in the number block lease you get from ARIN. So although the RSA makes you formally declaim a property right, what you are getting from the RSA is a bundle of rights that for all practical purposes has the same economic features as a property right.
> > >  
> > > -----Original Message-----
> > >  
> > > Wonderful question - it is ARIN's position that you have a specific set of rights to the address blocks in the registry (as defined by the registration services agreement that you enter with ARIN), and these rights include:
> > >  
> > > (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
> > > (2) The right to use the Included Number Resources within the ARIN database; and
> > > (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.
> > >  
> > > ARIN registration services agreement includes a specific disclaimer of property rights in the address blocks, as it is inconsistent with the ability to manage the address blocks in accordance with community-developed policy in the region. If you have other beliefs with respect to your rights, that would probably be an area for you to seek legal advice.
> > >  
> > > I hope this helps; please do not hesitate to ask if you have any additional questions.
> > >  
> > > Thanks!
> > > /John
> > >  
> > > John Curran
> > > President and CEO
> > > ARIN
> > >  
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net (mailto: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 (mailto:info at arin.net) if you experience any issues.
> > >  
> > >  
> > > ------------------------------
> > >  
> > > Message: 4
> > > Date: Fri, 4 Apr 2014 07:33:04 +0800
> > > From: xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)>
> > > To: John Curran <jcurran at arin.net (mailto:jcurran at arin.net)>
> > > Cc: "arin-ppml at arin.net (mailto:arin-ppml at arin.net)" <arin-ppml at arin.net (mailto:arin-ppml at arin.net)>
> > > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> > > Between RSA and 8.2 Utilization Requirements
> > > Message-ID:
> > > <CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com (mailto:CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com)>
> > > Content-Type: text/plain; charset="iso-8859-1"
> > >  
> > > Hi John,
> > >  
> > >  
> > > In basis of your reply, if the block is underutilised,ARIN will either ask
> > > the company to return the IPs or transfer to other third party via 8.3
> > > transfer after our 8.2 transfer.
> > >  
> > >  
> > > Say we have two /16 after this 8.2 transfer, what if we only transfer one
> > > /16 to the other third party via 8.3 transfer, meanwhile, we keep the
> > > other /16 left unused after our 8.2 transfer for quiet a while. Will ARIN
> > > ask us to return the remained /16 to the free pool? furthmore, how long
> > > will ARIN allow us to keep the other /16 unused before we transfer it to
> > > the third party via 8.3 transfer ?
> > >  
> > >  
> > >  
> > > Niki
> > >  
> > >  
> > >  
> > >  
> > > > On Thu, Apr 3, 2014 at 7:59 AM, John Curran <jcurran at arin.net (mailto:jcurran at arin.net)> wrote:
> > > >  
> > > > > On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)> wrote:
> > > > >  
> > > > > Hi John,
> > > > >  
> > > > > I have further enquiry about ARIN 8.2 process.
> > > > >  
> > > > > Number one:I am also worried about the costs of doing a 8.2 transfer
> > > > followed by a 8.3 transfer. I wonder if I will have to involve the legal
> > > > help to deal with ARIN legal. In my case I bought a company that now is
> > > > out of business. How complicated does ARIN make this process? I want some
> > > > assurance that I will be treated equally to any other companies whether it
> > > > is a big company or a small company like us.
> > > >  
> > > > Niki -
> > > >  
> > > > You will be treated equally, but in truth I'm not certain that is actually
> > > > what you want...
> > > > (for example, a process which seems routine for a large organization could
> > > > still pose
> > > > a disproportionate burden to a smaller organization since organization
> > > > size is not a
> > > > factor in the verification process.)
> > > >  
> > > > The first and foremost activity is to make sure that we have your
> > > > organization registered
> > > > as the rightful address holder, and that will require an NRPM 8.2
> > > > transfer. It can actually
> > > > be relatively straightforward process, as long as you have clear
> > > > documentation of the
> > > > purchase of the company. Review the instructions here for additional
> > > > information about
> > > > what is accepted - <
> > > > https://www.arin.net/resources/request/transfers_8_2.html>
> > > >  
> > > > > Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will
> > > > the stated purpose for our number resources remains the same?? I am afraid
> > > > of that ARIN will not approve our transfer.
> > > >  
> > > > If you are the clear party with the rights after your purchase, ARIN will
> > > > approve your
> > > > transfer. We may note that you have more addresses than you now need, and
> > > > thus
> > > > we expect you to return or transfer the remainder (but that would seem to
> > > > line up with
> > > > your intentions in any case.)
> > > >  
> > > > If you have purchased a company without adequate documentation, or if
> > > > multiple
> > > > parties purchased multiple pieces of the company, or if there some
> > > > question about
> > > > what was purchased based on the documentation, then it can be more
> > > > challenging
> > > > to get the resources appropriately listed with you as the rightful holder.
> > > > You will need
> > > > to apply for the transfer and work with the ARIN Hostmaster to determine
> > > > if there is
> > > > any issue in your particular case.
> > > >  
> > > > > Number three: As we have bought the company, do we have the property
> > > > right on those IPs? in our past agreement and future agreement arranged
> > > > for 8.3, we would like to have some kinds of property right on those IPs,
> > > > will that conflict with ARIN policy?
> > > >  
> > > > Wonderful question - it is ARIN's position that you have a specific set of
> > > > rights to the
> > > > address blocks in the registry (as defined by the registration services
> > > > agreement that
> > > > you enter with ARIN), and these rights include:
> > > >  
> > > > (1) The exclusive right to be the registrant of the Included Number
> > > > Resources within the ARIN database;
> > > > (2) The right to use the Included Number Resources within the ARIN
> > > > database; and
> > > > (3) The right to transfer the registration of the Included Number
> > > > Resources pursuant to the Policies.
> > > >  
> > > > ARIN registration services agreement includes a specific disclaimer of
> > > > property rights
> > > > in the address blocks, as it is inconsistent with the ability to manage
> > > > the address blocks
> > > > in accordance with community-developed policy in the region. If you have
> > > > other beliefs
> > > > with respect to your rights, that would probably be an area for you to
> > > > seek legal advice.
> > > >  
> > > > I hope this helps; please do not hesitate to ask if you have any
> > > > additional questions.
> > > >  
> > > > Thanks!
> > > > /John
> > > >  
> > > > John Curran
> > > > President and CEO
> > > > ARIN
> > > >  
> > >  
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/fd4aa749/attachment-0001.html>
> > >  
> > > ------------------------------
> > >  
> > > Message: 5
> > > Date: Fri, 4 Apr 2014 07:43:43 +0800
> > > From: xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)>
> > > To: Milton L Mueller <mueller at syr.edu (mailto:mueller at syr.edu)>
> > > Cc: John Curran <jcurran at arin.net (mailto:jcurran at arin.net)>, "arin-ppml at arin.net (mailto:arin-ppml at arin.net)"
> > > <arin-ppml at arin.net (mailto:arin-ppml at arin.net)>
> > > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> > > Between RSA and 8.2 Utilization Requirements
> > > Message-ID:
> > > <CAPhL6MrQdn-=5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com (mailto:5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com)>
> > > Content-Type: text/plain; charset="iso-8859-1"
> > >  
> > > Hi Milton,
> > >  
> > > thanks for your inspiring reply. Now i know that we have the "ownership"
> > > of those IPs. as you are one of the AC, i take your reply seriously and
> > > also this is good news for the community, especially for those legacy
> > > holders, if the holder of ARIN non-legacy IPs can have the "ownership'
> > > then the holder of legacy IPs definitely has the ownership on their IPs
> > > no matter whether they sign the RSA , LRSA or not.
> > >  
> > > Hope ARIN will not impose unpredictable "restrictions" when legacy or
> > > non-legacy holder begins its transfer request. Moreover, when ARIN reject
> > > a transfer , hope ARIN will not use the "confidential terms" as an excuse
> > > for not reply communities' questions in ppml. or ARIN will reply with
> > > bunch of info mean nothing.
> > > Niki
> > >  
> > >  
> > > > On Thu, Apr 3, 2014 at 11:33 PM, Milton L Mueller <mueller at syr.edu (mailto:mueller at syr.edu)> wrote:
> > > >  
> > > > Niki:
> > > > For most economists and lawyers, the definition of a "property right"
> > > > involves the right to use, the right to exclude others from using, and the
> > > > right to transfer. As John's message makes clear, all those rights are
> > > > present in the number block lease you get from ARIN. So although the RSA
> > > > makes you formally declaim a property right, what you are getting from the
> > > > RSA is a bundle of rights that for all practical purposes has the same
> > > > economic features as a property right.
> > > >  
> > > > -----Original Message-----
> > > >  
> > > > Wonderful question - it is ARIN's position that you have a specific set of
> > > > rights to the address blocks in the registry (as defined by the
> > > > registration services agreement that you enter with ARIN), and these rights
> > > > include:
> > > >  
> > > > (1) The exclusive right to be the registrant of the Included Number
> > > > Resources within the ARIN database;
> > > > (2) The right to use the Included Number Resources within the ARIN
> > > > database; and
> > > > (3) The right to transfer the registration of the Included Number
> > > > Resources pursuant to the Policies.
> > > >  
> > > > ARIN registration services agreement includes a specific disclaimer of
> > > > property rights in the address blocks, as it is inconsistent with the
> > > > ability to manage the address blocks in accordance with community-developed
> > > > policy in the region. If you have other beliefs with respect to your
> > > > rights, that would probably be an area for you to seek legal advice.
> > > >  
> > > > I hope this helps; please do not hesitate to ask if you have any
> > > > additional questions.
> > > >  
> > > > Thanks!
> > > > /John
> > > >  
> > > > John Curran
> > > > President and CEO
> > > > ARIN
> > > >  
> > > > _______________________________________________
> > > > PPML
> > > > You are receiving this message because you are subscribed to the ARIN
> > > > Public Policy Mailing List (ARIN-PPML at arin.net (mailto: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 (mailto:info at arin.net) if you experience any issues.
> > > >  
> > >  
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/57c3a01e/attachment.html>
> > >  
> > > ------------------------------
> > >  
> > > _______________________________________________
> > > ARIN-PPML mailing list
> > > ARIN-PPML at arin.net (mailto:ARIN-PPML at arin.net)
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > >  
> > > End of ARIN-PPML Digest, Vol 106, Issue 8
> > > *****************************************
> > >  
> >  
> >  
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net (mailto: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 (mailto:info at arin.net) if you experience any issues.
> >  
>  
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140403/86ab1c8b/attachment.html>
>  
> ------------------------------
>  
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net (mailto:ARIN-PPML at arin.net)
> http://lists.arin.net/mailman/listinfo/arin-ppml
>  
> End of ARIN-PPML Digest, Vol 106, Issue 10
> ******************************************
>  
>  


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

From jcurran at arin.net  Fri Apr  4 00:47:02 2014
From: jcurran at arin.net (John Curran)
Date: Fri, 4 Apr 2014 04:47:02 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg@mail.gmail.com>
References: <CAPhL6MoirOmJJ1TEFxu_uOdM-QRykoZZ3Ged5u71ATmh_mB+5Q@mail.gmail.com>
	<8089E44B-EBB1-4E91-9CAC-1A33A29F9012@arin.net>
	<CAPhL6MqE4-_K9ps9EsLvAwrsj8DvD1R+grgZKMAB6qpy_3YSUw@mail.gmail.com>
	<748D323F-21D9-4142-817F-ADD484F756DF@arin.net>
	<CAPhL6MoiAO1AAjg2_XHmPYJ_dFV5h8A+seQN4Pb789xfczQPmw@mail.gmail.com>
	<6BBC9339-AE30-446A-8406-8237A8C3477F@arin.net>
	<CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg@mail.gmail.com>
Message-ID: <4EE45D13-CD9C-4CE9-BC76-76370C136059@arin.net>

On Apr 3, 2014, at 7:33 PM, xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>> wrote:

Hi John,

In basis of your reply,  if the block is underutilised,ARIN will either ask the  company to return the IPs  or transfer to other third party via 8.3 transfer after our 8.2 transfer.

Correct.

Say we have two /16 after this 8.2 transfer, what if we only transfer one /16 to the other third party via 8.3 transfer, meanwhile, we keep the  other /16 left unused after our 8.2 transfer for quiet a while.   Will ARIN ask us to return the remained /16 to the free pool?  furthmore, how long will ARIN allow us to keep the other /16 unused before we transfer it to the third party via 8.3 transfer ?

Niki -

ARIN will continue to work with you as needed, so long as you are still working
in good faith towards compliance with policy.  For more information on your
particular circumstances, please contact <hostmaster at arin.net<mailto:hostmaster at arin.net>>.

Thanks!
/John

John Curran
President and CEO
ARIN



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

From narten at us.ibm.com  Fri Apr  4 00:53:02 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 04 Apr 2014 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201404040453.s344r26N010908@rotala.raleigh.ibm.com>

Total of 75 messages in the last 7 days.
 
script run at: Fri Apr  4 00:53:01 EDT 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  9.33% |    7 |  5.20% |    62801 | hannigan at gmail.com
  6.67% |    5 |  7.28% |    87903 | cja at daydream.com
  9.33% |    7 |  4.31% |    52089 | jcurran at arin.net
  5.33% |    4 |  7.73% |    93278 | david.huberman at microsoft.com
  2.67% |    2 | 10.04% |   121171 | rockymm8 at gmail.com
  6.67% |    5 |  5.49% |    66245 | nikiyangxf at gmail.com
  2.67% |    2 |  7.14% |    86221 | scottleibrand at gmail.com
  4.00% |    3 |  5.52% |    66634 | john.sweeting at twcable.com
  4.00% |    3 |  5.39% |    65055 | farmer at umn.edu
  5.33% |    4 |  3.57% |    43088 | mysidia at gmail.com
  2.67% |    2 |  5.73% |    69194 | bill at tknow.com
  5.33% |    4 |  2.05% |    24713 | csquat at ccsd.net
  2.67% |    2 |  3.79% |    45784 | jaymartin926 at gmail.com
  1.33% |    1 |  4.45% |    53764 | jay-arin at tp.org
  4.00% |    3 |  1.74% |    20973 | matthew at matthew.at
  2.67% |    2 |  2.53% |    30586 | heather.skanks at gmail.com
  2.67% |    2 |  2.49% |    30085 | george.herbert at gmail.com
  1.33% |    1 |  2.64% |    31846 | timothy.s.morizot at irs.gov
  2.67% |    2 |  1.07% |    12920 | bill at herrin.us
  1.33% |    1 |  2.20% |    26609 | kkargel at polartel.com
  1.33% |    1 |  1.58% |    19027 | adudek16 at gmail.com
  1.33% |    1 |  1.48% |    17903 | billdarte at gmail.com
  1.33% |    1 |  0.96% |    11537 | cgrundemann at gmail.com
  1.33% |    1 |  0.79% |     9597 | afried at deteque.com
  1.33% |    1 |  0.68% |     8213 | narten at us.ibm.com
  1.33% |    1 |  0.63% |     7663 | mueller at syr.edu
  1.33% |    1 |  0.62% |     7448 | paul at egate.net
  1.33% |    1 |  0.55% |     6603 | owen at delong.com
  1.33% |    1 |  0.54% |     6557 | joe at oregon.uoregon.edu
  1.33% |    1 |  0.52% |     6297 | thinkofit at gmail.com
  1.33% |    1 |  0.47% |     5637 | babydr at baby-dragons.com
  1.33% |    1 |  0.45% |     5388 | springer at inlandnet.com
  1.33% |    1 |  0.38% |     4558 | owens at nysernet.org
--------+------+--------+----------+------------------------
100.00% |   75 |100.00% |  1207387 | Total



From jcurran at arin.net  Fri Apr  4 01:01:15 2014
From: jcurran at arin.net (John Curran)
Date: Fri, 4 Apr 2014 05:01:15 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <CAPhL6MrQdn-=5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A@mail.gmail.com>
References: <CAPhL6MoirOmJJ1TEFxu_uOdM-QRykoZZ3Ged5u71ATmh_mB+5Q@mail.gmail.com>
	<8089E44B-EBB1-4E91-9CAC-1A33A29F9012@arin.net>
	<CAPhL6MqE4-_K9ps9EsLvAwrsj8DvD1R+grgZKMAB6qpy_3YSUw@mail.gmail.com>
	<748D323F-21D9-4142-817F-ADD484F756DF@arin.net>
	<CAPhL6MoiAO1AAjg2_XHmPYJ_dFV5h8A+seQN4Pb789xfczQPmw@mail.gmail.com>
	<6BBC9339-AE30-446A-8406-8237A8C3477F@arin.net>
	<1846d87fe7164f22a7c63e9d1fed321e@EX13-MBX-13.ad.syr.edu>
	<CAPhL6MrQdn-=5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A@mail.gmail.com>
Message-ID: <6F4E7B12-D04A-4B16-91CD-433114D22AB2@arin.net>

On Apr 3, 2014, at 7:43 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:

> thanks for your inspiring reply.  Now i know that we have the "ownership" of those IPs.    as you are one of the AC, i take your reply seriously and also this is good news for the community, especially for those legacy holders, if the holder of ARIN non-legacy IPs can have the "ownership'  then the holder of legacy IPs definitely has the ownership  on their IPs  no matter whether they sign the RSA , LRSA or not.


I believe that your assertions above are unlikely to work out as you might expect, 
and, as noted earlier, you might want to seek out legal advice in these matters.

Best wishes,
/John

John Curran
President and CEO
ARIN



From scottleibrand at gmail.com  Fri Apr  4 01:29:10 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 3 Apr 2014 22:29:10 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 10
In-Reply-To: <BCF55E8E80244BB78F99AC5E58488E7C@gmail.com>
References: <mailman.1557.1396574716.28847.arin-ppml@arin.net>
	<BCF55E8E80244BB78F99AC5E58488E7C@gmail.com>
Message-ID: <E5423262-8639-4928-9568-81100FAC3666@gmail.com>


> On Apr 3, 2014, at 8:04 PM, Rocky <rockymm8 at gmail.com> wrote:
> 
> Scott
> 
> thanks for your explanation. 
> 1. how can ARIN make sure this 8.2 transfer is not speculating about IPv4?

If you can clarify what you mean by speculating in this particular case, we can discuss the various aspects of policy that may help.  Or, see below. 

> 2. if the entity no longer existent,  why not return the IPv4  after its dissolved?

That would be ideal, and has happened in the past. Now that the IPv4 free pool is nearing exhaustion, though, most successors to companies with IPv4 holdings would prefer to monetize them. The end result to the community (those of us not involved in the transaction) is the same: the addresses get back into use. 

>   or why not update the ARIN database in time after the M/A.

Again, that would've been ideal, but in many cases did not happen. Updating records takes work, so unless there's some incentive (like being able to transfer the resources under 8.3) it sometimes gets overlooked or not prioritized. 

> What you are trying to say make me feel that ARIN policy is encouraging the  stockpile of IPv4? some People do it until the IPv4 becomes expensive and some people can benefit huge from its stockpile ( for past many years) by update its registration info via 8.2 transfer  to sell a great price after the next 8.3 transfer.

Generally, ARIN policy seeks to prevent that on the front end, by requiring justified need for allocations from the free pool. There is also policy in place to prevent "flipping" space after an allocation. 

> the check of utilisation rate under 8.2 is just a formalism and considering the wording there conflicts with RSA, why not delete the utilisation rate requirement in the 8.2? or revise the RSA accordingly.

The original intent of this language was to encourage ARIN to work with the recipient of the 8.2 transfer to get all the addresses into use. Since the RSA now prevents reclamation, that should probably be removed from the policy, as should "aggregate". But the "ARIN will work with the resource holder(s) to return or transfer resources as needed" language would still be operative if we left it in place. 

-Scott

> 
> 
> 
> 
>> On Friday, April 4, 2014 at 9:25 AM, arin-ppml-request at arin.net wrote:
>> Send ARIN-PPML mailing list submissions to
>> arin-ppml at arin.net
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> or, via email, send a message with subject or body 'help' to
>> arin-ppml-request at arin.net
>> 
>> You can reach the person managing the list at
>> arin-ppml-owner at arin.net
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of ARIN-PPML digest..."
>> 
>> 
>> Today's Topics:
>> 
>> 1. Re: ARIN-PPML Digest, Vol 106, Issue 8 (Scott Leibrand)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Thu, 3 Apr 2014 18:25:06 -0700
>> From: Scott Leibrand <scottleibrand at gmail.com>
>> To: Rocky <rockymm8 at gmail.com>
>> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
>> Message-ID: <04DC25C4-5352-4DC8-A114-EA1724DC88EE at gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> Rocky,
>> 
>> Many such 8.2 transfers are efforts to get ARIN's records up to date regarding M&A transactions that happened years ago. It is not possible for a no-longer-existent entity to execute the 8.3 transfer, so it has to be 8.2 transferred to the new entity first.
>> 
>> Scott
>> 
>>> On Apr 3, 2014, at 6:02 PM, Rocky <rockymm8 at gmail.com> wrote:
>>> 
>>> Hello there,
>>> 
>>> What you are planning to do seems like you try to disguise an 8.3 transfer as an 8.2 transfer.
>>> I do not think it is appropriate for allowing an 8.2 transfer followed by an 8.3/8.4 transfer.
>>> 
>>> If the company does not need the IPv4 and the IPv4 are lack of utilisation, why not ask this company to return the IPv4 for the benefit of the community?
>>> 
>>> If the company wants to sell the IPv4 after an 8.2 to buyers through an 8.3/8.4, why not the company directly transfer the IPv4 from its original organisation instead of doing an 8.2 first then followed by an 8.3/8.4 transfer. Are the seller trying to hide something or as the seller is afraid of doing something against the policy, so they try to make such an arrangement?
>>> 
>>> There is a highly suspicious of ? IPv4 laundry? or ?IPv4 speculation? about this company. Maybe we need more transparency of the buy&sale of the IPv4 to make sure the behaviour of the seller is compatible with policy.
>>> 
>>> I suggest to resolve the language conflict between 8.2 transfer policy and RSA and further to suggest to figure out some measures to stop the speculation on IPv4 via an 8.2 then followed by an 8.3/8.4 transfer. If the company does not use the IPv4 after an 8.2 transfer, why not return them to free pool for the benefit of the whole community?
>>> 
>>> Any ideas on this ?
>>> 
>>> 
>>>> On Friday, April 4, 2014 at 7:43 AM, arin-ppml-request at arin.net wrote:
>>>> 
>>>> Send ARIN-PPML mailing list submissions to
>>>> arin-ppml at arin.net
>>>> 
>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> or, via email, send a message with subject or body 'help' to
>>>> arin-ppml-request at arin.net
>>>> 
>>>> You can reach the person managing the list at
>>>> arin-ppml-owner at arin.net
>>>> 
>>>> When replying, please edit your Subject line so it is more specific
>>>> than "Re: Contents of ARIN-PPML digest..."
>>>> 
>>>> 
>>>> Today's Topics:
>>>> 
>>>> 1. Re: ARIN-PPML Digest, Vol 106, Issue 7 (Chris R. Squatritto)
>>>> 2. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
>>>> and 8.2 Utilization Requirements (John Curran)
>>>> 3. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
>>>> and 8.2 Utilization Requirements (Milton L Mueller)
>>>> 4. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
>>>> and 8.2 Utilization Requirements (xiaofan yang)
>>>> 5. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
>>>> and 8.2 Utilization Requirements (xiaofan yang)
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>> 
>>>> Message: 1
>>>> Date: Wed, 02 Apr 2014 16:30:45 -0700
>>>> From: "Chris R. Squatritto" <csquat at ccsd.net>
>>>> To: arin-ppml at arin.net
>>>> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 7
>>>> Message-ID:
>>>> <fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net>
>>>> Content-Type: text/plain; charset="utf-8"
>>>> 
>>>> I am out of the office this week and will not be checking email. Please
>>>> contact Troy Miller for assistance..
>>>> 
>>>> Thank you for contacting me, and have a great day.
>>>> 
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140402/5723c721/attachment-0001.html>
>>>> 
>>>> ------------------------------
>>>> 
>>>> Message: 2
>>>> Date: Wed, 2 Apr 2014 23:59:20 +0000
>>>> From: John Curran <jcurran at arin.net>
>>>> To: xiaofan yang <nikiyangxf at gmail.com>
>>>> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
>>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
>>>> Between RSA and 8.2 Utilization Requirements
>>>> Message-ID: <6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net>
>>>> Content-Type: text/plain; charset="iso-8859-1"
>>>> 
>>>>> On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:
>>>>> 
>>>>> Hi John,
>>>>> 
>>>>> I have further enquiry about ARIN 8.2 process.
>>>>> 
>>>>> Number one:I am also worried about the costs of doing a 8.2 transfer followed by a 8.3 transfer. I wonder if I will have to involve the legal help to deal with ARIN legal. In my case I bought a company that now is out of business. How complicated does ARIN make this process? I want some assurance that I will be treated equally to any other companies whether it is a big company or a small company like us.
>>>> 
>>>> Niki -
>>>> 
>>>> You will be treated equally, but in truth I'm not certain that is actually what you want...
>>>> (for example, a process which seems routine for a large organization could still pose
>>>> a disproportionate burden to a smaller organization since organization size is not a
>>>> factor in the verification process.)
>>>> 
>>>> The first and foremost activity is to make sure that we have your organization registered
>>>> as the rightful address holder, and that will require an NRPM 8.2 transfer. It can actually
>>>> be relatively straightforward process, as long as you have clear documentation of the
>>>> purchase of the company. Review the instructions here for additional information about
>>>> what is accepted - <https://www.arin.net/resources/request/transfers_8_2.html>
>>>> 
>>>>> Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will the stated purpose for our number resources remains the same?? I am afraid of that ARIN will not approve our transfer.
>>>> 
>>>> If you are the clear party with the rights after your purchase, ARIN will approve your
>>>> transfer. We may note that you have more addresses than you now need, and thus
>>>> we expect you to return or transfer the remainder (but that would seem to line up with
>>>> your intentions in any case.)
>>>> 
>>>> If you have purchased a company without adequate documentation, or if multiple
>>>> parties purchased multiple pieces of the company, or if there some question about
>>>> what was purchased based on the documentation, then it can be more challenging
>>>> to get the resources appropriately listed with you as the rightful holder. You will need
>>>> to apply for the transfer and work with the ARIN Hostmaster to determine if there is
>>>> any issue in your particular case.
>>>> 
>>>>> Number three: As we have bought the company, do we have the property right on those IPs? in our past agreement and future agreement arranged for 8.3, we would like to have some kinds of property right on those IPs, will that conflict with ARIN policy?
>>>> 
>>>> Wonderful question - it is ARIN's position that you have a specific set of rights to the
>>>> address blocks in the registry (as defined by the registration services agreement that
>>>> you enter with ARIN), and these rights include:
>>>> 
>>>> (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
>>>> (2) The right to use the Included Number Resources within the ARIN database; and
>>>> (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.
>>>> 
>>>> ARIN registration services agreement includes a specific disclaimer of property rights
>>>> in the address blocks, as it is inconsistent with the ability to manage the address blocks
>>>> in accordance with community-developed policy in the region. If you have other beliefs
>>>> with respect to your rights, that would probably be an area for you to seek legal advice.
>>>> 
>>>> I hope this helps; please do not hesitate to ask if you have any additional questions.
>>>> 
>>>> Thanks!
>>>> /John
>>>> 
>>>> John Curran
>>>> President and CEO
>>>> ARIN
>>>> 
>>>> 
>>>> 
>>>> ------------------------------
>>>> 
>>>> Message: 3
>>>> Date: Thu, 3 Apr 2014 15:33:13 +0000
>>>> From: Milton L Mueller <mueller at syr.edu>
>>>> To: "'John Curran'" <jcurran at arin.net>, xiaofan yang
>>>> <nikiyangxf at gmail.com>
>>>> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
>>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
>>>> Between RSA and 8.2 Utilization Requirements
>>>> Message-ID: <1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu>
>>>> Content-Type: text/plain; charset="us-ascii"
>>>> 
>>>> Niki:
>>>> For most economists and lawyers, the definition of a "property right" involves the right to use, the right to exclude others from using, and the right to transfer. As John's message makes clear, all those rights are present in the number block lease you get from ARIN. So although the RSA makes you formally declaim a property right, what you are getting from the RSA is a bundle of rights that for all practical purposes has the same economic features as a property right.
>>>> 
>>>> -----Original Message-----
>>>> 
>>>> Wonderful question - it is ARIN's position that you have a specific set of rights to the address blocks in the registry (as defined by the registration services agreement that you enter with ARIN), and these rights include:
>>>> 
>>>> (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
>>>> (2) The right to use the Included Number Resources within the ARIN database; and
>>>> (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.
>>>> 
>>>> ARIN registration services agreement includes a specific disclaimer of property rights in the address blocks, as it is inconsistent with the ability to manage the address blocks in accordance with community-developed policy in the region. If you have other beliefs with respect to your rights, that would probably be an area for you to seek legal advice.
>>>> 
>>>> I hope this helps; please do not hesitate to ask if you have any additional questions.
>>>> 
>>>> Thanks!
>>>> /John
>>>> 
>>>> John Curran
>>>> President and CEO
>>>> ARIN
>>>> 
>>>> _______________________________________________
>>>> 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.
>>>> 
>>>> 
>>>> ------------------------------
>>>> 
>>>> Message: 4
>>>> Date: Fri, 4 Apr 2014 07:33:04 +0800
>>>> From: xiaofan yang <nikiyangxf at gmail.com>
>>>> To: John Curran <jcurran at arin.net>
>>>> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
>>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
>>>> Between RSA and 8.2 Utilization Requirements
>>>> Message-ID:
>>>> <CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com>
>>>> Content-Type: text/plain; charset="iso-8859-1"
>>>> 
>>>> Hi John,
>>>> 
>>>> 
>>>> In basis of your reply, if the block is underutilised,ARIN will either ask
>>>> the company to return the IPs or transfer to other third party via 8.3
>>>> transfer after our 8.2 transfer.
>>>> 
>>>> 
>>>> Say we have two /16 after this 8.2 transfer, what if we only transfer one
>>>> /16 to the other third party via 8.3 transfer, meanwhile, we keep the
>>>> other /16 left unused after our 8.2 transfer for quiet a while. Will ARIN
>>>> ask us to return the remained /16 to the free pool? furthmore, how long
>>>> will ARIN allow us to keep the other /16 unused before we transfer it to
>>>> the third party via 8.3 transfer ?
>>>> 
>>>> 
>>>> 
>>>> Niki
>>>> 
>>>> 
>>>> 
>>>> 
>>>>>> On Thu, Apr 3, 2014 at 7:59 AM, John Curran <jcurran at arin.net> wrote:
>>>>>> 
>>>>>> On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:
>>>>>> 
>>>>>> Hi John,
>>>>>> 
>>>>>> I have further enquiry about ARIN 8.2 process.
>>>>>> 
>>>>>> Number one:I am also worried about the costs of doing a 8.2 transfer
>>>>> followed by a 8.3 transfer. I wonder if I will have to involve the legal
>>>>> help to deal with ARIN legal. In my case I bought a company that now is
>>>>> out of business. How complicated does ARIN make this process? I want some
>>>>> assurance that I will be treated equally to any other companies whether it
>>>>> is a big company or a small company like us.
>>>>> 
>>>>> Niki -
>>>>> 
>>>>> You will be treated equally, but in truth I'm not certain that is actually
>>>>> what you want...
>>>>> (for example, a process which seems routine for a large organization could
>>>>> still pose
>>>>> a disproportionate burden to a smaller organization since organization
>>>>> size is not a
>>>>> factor in the verification process.)
>>>>> 
>>>>> The first and foremost activity is to make sure that we have your
>>>>> organization registered
>>>>> as the rightful address holder, and that will require an NRPM 8.2
>>>>> transfer. It can actually
>>>>> be relatively straightforward process, as long as you have clear
>>>>> documentation of the
>>>>> purchase of the company. Review the instructions here for additional
>>>>> information about
>>>>> what is accepted - <
>>>>> https://www.arin.net/resources/request/transfers_8_2.html>
>>>>> 
>>>>>> Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will
>>>>> the stated purpose for our number resources remains the same?? I am afraid
>>>>> of that ARIN will not approve our transfer.
>>>>> 
>>>>> If you are the clear party with the rights after your purchase, ARIN will
>>>>> approve your
>>>>> transfer. We may note that you have more addresses than you now need, and
>>>>> thus
>>>>> we expect you to return or transfer the remainder (but that would seem to
>>>>> line up with
>>>>> your intentions in any case.)
>>>>> 
>>>>> If you have purchased a company without adequate documentation, or if
>>>>> multiple
>>>>> parties purchased multiple pieces of the company, or if there some
>>>>> question about
>>>>> what was purchased based on the documentation, then it can be more
>>>>> challenging
>>>>> to get the resources appropriately listed with you as the rightful holder.
>>>>> You will need
>>>>> to apply for the transfer and work with the ARIN Hostmaster to determine
>>>>> if there is
>>>>> any issue in your particular case.
>>>>> 
>>>>>> Number three: As we have bought the company, do we have the property
>>>>> right on those IPs? in our past agreement and future agreement arranged
>>>>> for 8.3, we would like to have some kinds of property right on those IPs,
>>>>> will that conflict with ARIN policy?
>>>>> 
>>>>> Wonderful question - it is ARIN's position that you have a specific set of
>>>>> rights to the
>>>>> address blocks in the registry (as defined by the registration services
>>>>> agreement that
>>>>> you enter with ARIN), and these rights include:
>>>>> 
>>>>> (1) The exclusive right to be the registrant of the Included Number
>>>>> Resources within the ARIN database;
>>>>> (2) The right to use the Included Number Resources within the ARIN
>>>>> database; and
>>>>> (3) The right to transfer the registration of the Included Number
>>>>> Resources pursuant to the Policies.
>>>>> 
>>>>> ARIN registration services agreement includes a specific disclaimer of
>>>>> property rights
>>>>> in the address blocks, as it is inconsistent with the ability to manage
>>>>> the address blocks
>>>>> in accordance with community-developed policy in the region. If you have
>>>>> other beliefs
>>>>> with respect to your rights, that would probably be an area for you to
>>>>> seek legal advice.
>>>>> 
>>>>> I hope this helps; please do not hesitate to ask if you have any
>>>>> additional questions.
>>>>> 
>>>>> Thanks!
>>>>> /John
>>>>> 
>>>>> John Curran
>>>>> President and CEO
>>>>> ARIN
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/fd4aa749/attachment-0001.html>
>>>> 
>>>> ------------------------------
>>>> 
>>>> Message: 5
>>>> Date: Fri, 4 Apr 2014 07:43:43 +0800
>>>> From: xiaofan yang <nikiyangxf at gmail.com>
>>>> To: Milton L Mueller <mueller at syr.edu>
>>>> Cc: John Curran <jcurran at arin.net>, "arin-ppml at arin.net"
>>>> <arin-ppml at arin.net>
>>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
>>>> Between RSA and 8.2 Utilization Requirements
>>>> Message-ID:
>>>> <CAPhL6MrQdn-=5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com>
>>>> Content-Type: text/plain; charset="iso-8859-1"
>>>> 
>>>> Hi Milton,
>>>> 
>>>> thanks for your inspiring reply. Now i know that we have the "ownership"
>>>> of those IPs. as you are one of the AC, i take your reply seriously and
>>>> also this is good news for the community, especially for those legacy
>>>> holders, if the holder of ARIN non-legacy IPs can have the "ownership'
>>>> then the holder of legacy IPs definitely has the ownership on their IPs
>>>> no matter whether they sign the RSA , LRSA or not.
>>>> 
>>>> Hope ARIN will not impose unpredictable "restrictions" when legacy or
>>>> non-legacy holder begins its transfer request. Moreover, when ARIN reject
>>>> a transfer , hope ARIN will not use the "confidential terms" as an excuse
>>>> for not reply communities' questions in ppml. or ARIN will reply with
>>>> bunch of info mean nothing.
>>>> Niki
>>>> 
>>>> 
>>>>> On Thu, Apr 3, 2014 at 11:33 PM, Milton L Mueller <mueller at syr.edu> wrote:
>>>>> 
>>>>> Niki:
>>>>> For most economists and lawyers, the definition of a "property right"
>>>>> involves the right to use, the right to exclude others from using, and the
>>>>> right to transfer. As John's message makes clear, all those rights are
>>>>> present in the number block lease you get from ARIN. So although the RSA
>>>>> makes you formally declaim a property right, what you are getting from the
>>>>> RSA is a bundle of rights that for all practical purposes has the same
>>>>> economic features as a property right.
>>>>> 
>>>>> -----Original Message-----
>>>>> 
>>>>> Wonderful question - it is ARIN's position that you have a specific set of
>>>>> rights to the address blocks in the registry (as defined by the
>>>>> registration services agreement that you enter with ARIN), and these rights
>>>>> include:
>>>>> 
>>>>> (1) The exclusive right to be the registrant of the Included Number
>>>>> Resources within the ARIN database;
>>>>> (2) The right to use the Included Number Resources within the ARIN
>>>>> database; and
>>>>> (3) The right to transfer the registration of the Included Number
>>>>> Resources pursuant to the Policies.
>>>>> 
>>>>> ARIN registration services agreement includes a specific disclaimer of
>>>>> property rights in the address blocks, as it is inconsistent with the
>>>>> ability to manage the address blocks in accordance with community-developed
>>>>> policy in the region. If you have other beliefs with respect to your
>>>>> rights, that would probably be an area for you to seek legal advice.
>>>>> 
>>>>> I hope this helps; please do not hesitate to ask if you have any
>>>>> additional questions.
>>>>> 
>>>>> Thanks!
>>>>> /John
>>>>> 
>>>>> John Curran
>>>>> President and CEO
>>>>> ARIN
>>>>> 
>>>>> _______________________________________________
>>>>> 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: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/57c3a01e/attachment.html>
>>>> 
>>>> ------------------------------
>>>> 
>>>> _______________________________________________
>>>> ARIN-PPML mailing list
>>>> ARIN-PPML at arin.net
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> 
>>>> End of ARIN-PPML Digest, Vol 106, Issue 8
>>>> *****************************************
>>> 
>>> _______________________________________________
>>> 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: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140403/86ab1c8b/attachment.html>
>> 
>> ------------------------------
>> 
>> _______________________________________________
>> ARIN-PPML mailing list
>> ARIN-PPML at arin.net
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> 
>> End of ARIN-PPML Digest, Vol 106, Issue 10
>> ******************************************
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140403/e4d91deb/attachment.htm>

From kkargel at polartel.com  Fri Apr  4 09:56:02 2014
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 4 Apr 2014 08:56:02 -0500
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<7AD26173D4094238B51D28EE6DE8A020@gmail.com>
	<04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>

I guess I am confused.  I thought that resources assigned to entities that no longer exist should be reclaimed to the pool.
Kevin


From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
Sent: Thursday, April 03, 2014 8:25 PM
To: Rocky
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

Rocky,

Many such 8.2 transfers are efforts to get ARIN's records up to date regarding M&A transactions that happened years ago. It is not possible for a no-longer-existent entity to execute the 8.3 transfer, so it has to be 8.2 transferred to the new entity first.
Scott

On Apr 3, 2014, at 6:02 PM, Rocky <rockymm8 at gmail.com<mailto:rockymm8 at gmail.com>> wrote:

Hello there,



What you are planning to do  seems  like you try to disguise an 8.3 transfer as an 8.2 transfer.

I do not think it is appropriate for  allowing an 8.2 transfer followed by an 8.3/8.4 transfer.



If the company does not need the IPv4 and the IPv4 are lack of utilisation,   why not ask this company to return the IPv4 for the benefit of the community?



If the company wants to sell the IPv4 after an 8.2 to buyers through an 8.3/8.4,  why not the company directly transfer the IPv4 from its original organisation instead of  doing  an 8.2 first then followed by an 8.3/8.4 transfer.   Are the seller  trying to hide something or as the seller is afraid of doing something against the policy, so they try to make such an arrangement?



There is a highly suspicious of ? IPv4 laundry? or ?IPv4 speculation?  about this company.     Maybe we need more transparency of the buy&sale of the IPv4 to make sure the behaviour of the seller is compatible with  policy.



I suggest to resolve the language conflict between 8.2 transfer policy and RSA and further to suggest to figure out some measures to stop the  speculation on IPv4  via an 8.2 then followed by an 8.3/8.4 transfer.      If the company does not use the IPv4 after an 8.2 transfer, why not return them to free pool for the benefit of the whole community?



Any ideas on this ?



On Friday, April 4, 2014 at 7:43 AM, arin-ppml-request at arin.net<mailto:arin-ppml-request at arin.net> wrote:
Send ARIN-PPML mailing list submissions to
arin-ppml at arin.net<mailto:arin-ppml at arin.net>

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
arin-ppml-request at arin.net<mailto:arin-ppml-request at arin.net>

You can reach the person managing the list at
arin-ppml-owner at arin.net<mailto:arin-ppml-owner at arin.net>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."


Today's Topics:

1. Re: ARIN-PPML Digest, Vol 106, Issue 7 (Chris R. Squatritto)
2. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
and 8.2 Utilization Requirements (John Curran)
3. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
and 8.2 Utilization Requirements (Milton L Mueller)
4. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
and 8.2 Utilization Requirements (xiaofan yang)
5. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
and 8.2 Utilization Requirements (xiaofan yang)


----------------------------------------------------------------------

Message: 1
Date: Wed, 02 Apr 2014 16:30:45 -0700
From: "Chris R. Squatritto" <csquat at ccsd.net<mailto:csquat at ccsd.net>>
To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 7
Message-ID:
<fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net<mailto:fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net>>
Content-Type: text/plain; charset="utf-8"

I am out of the office this week and will not be checking email. Please
contact Troy Miller for assistance..

Thank you for contacting me, and have a great day.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140402/5723c721/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 2 Apr 2014 23:59:20 +0000
From: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>>
To: xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
Between RSA and 8.2 Utilization Requirements
Message-ID: <6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net<mailto:6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net>>
Content-Type: text/plain; charset="iso-8859-1"

On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>> wrote:

Hi John,

I have further enquiry about ARIN 8.2 process.

Number one:I am also worried about the costs of doing a 8.2 transfer followed by a 8.3 transfer. I wonder if I will have to involve the legal help to deal with ARIN legal. In my case I bought a company that now is out of business. How complicated does ARIN make this process? I want some assurance that I will be treated equally to any other companies whether it is a big company or a small company like us.

Niki -

You will be treated equally, but in truth I'm not certain that is actually what you want...
(for example, a process which seems routine for a large organization could still pose
a disproportionate burden to a smaller organization since organization size is not a
factor in the verification process.)

The first and foremost activity is to make sure that we have your organization registered
as the rightful address holder, and that will require an NRPM 8.2 transfer. It can actually
be relatively straightforward process, as long as you have clear documentation of the
purchase of the company. Review the instructions here for additional information about
what is accepted - <https://www.arin.net/resources/request/transfers_8_2.html>

Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will the stated purpose for our number resources remains the same?? I am afraid of that ARIN will not approve our transfer.

If you are the clear party with the rights after your purchase, ARIN will approve your
transfer. We may note that you have more addresses than you now need, and thus
we expect you to return or transfer the remainder (but that would seem to line up with
your intentions in any case.)

If you have purchased a company without adequate documentation, or if multiple
parties purchased multiple pieces of the company, or if there some question about
what was purchased based on the documentation, then it can be more challenging
to get the resources appropriately listed with you as the rightful holder. You will need
to apply for the transfer and work with the ARIN Hostmaster to determine if there is
any issue in your particular case.

Number three: As we have bought the company, do we have the property right on those IPs? in our past agreement and future agreement arranged for 8.3, we would like to have some kinds of property right on those IPs, will that conflict with ARIN policy?

Wonderful question - it is ARIN's position that you have a specific set of rights to the
address blocks in the registry (as defined by the registration services agreement that
you enter with ARIN), and these rights include:

(1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
(2) The right to use the Included Number Resources within the ARIN database; and
(3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of property rights
in the address blocks, as it is inconsistent with the ability to manage the address blocks
in accordance with community-developed policy in the region. If you have other beliefs
with respect to your rights, that would probably be an area for you to seek legal advice.

I hope this helps; please do not hesitate to ask if you have any additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN



------------------------------

Message: 3
Date: Thu, 3 Apr 2014 15:33:13 +0000
From: Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>>
To: "'John Curran'" <jcurran at arin.net<mailto:jcurran at arin.net>>, xiaofan yang
<nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
Between RSA and 8.2 Utilization Requirements
Message-ID: <1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu<mailto:1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu>>
Content-Type: text/plain; charset="us-ascii"

Niki:
For most economists and lawyers, the definition of a "property right" involves the right to use, the right to exclude others from using, and the right to transfer. As John's message makes clear, all those rights are present in the number block lease you get from ARIN. So although the RSA makes you formally declaim a property right, what you are getting from the RSA is a bundle of rights that for all practical purposes has the same economic features as a property right.

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

Wonderful question - it is ARIN's position that you have a specific set of rights to the address blocks in the registry (as defined by the registration services agreement that you enter with ARIN), and these rights include:

(1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
(2) The right to use the Included Number Resources within the ARIN database; and
(3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of property rights in the address blocks, as it is inconsistent with the ability to manage the address blocks in accordance with community-developed policy in the region. If you have other beliefs with respect to your rights, that would probably be an area for you to seek legal advice.

I hope this helps; please do not hesitate to ask if you have any additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.


------------------------------

Message: 4
Date: Fri, 4 Apr 2014 07:33:04 +0800
From: xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>>
To: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
Between RSA and 8.2 Utilization Requirements
Message-ID:
<CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com<mailto:CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com>>
Content-Type: text/plain; charset="iso-8859-1"

Hi John,


In basis of your reply, if the block is underutilised,ARIN will either ask
the company to return the IPs or transfer to other third party via 8.3
transfer after our 8.2 transfer.


Say we have two /16 after this 8.2 transfer, what if we only transfer one
/16 to the other third party via 8.3 transfer, meanwhile, we keep the
other /16 left unused after our 8.2 transfer for quiet a while. Will ARIN
ask us to return the remained /16 to the free pool? furthmore, how long
will ARIN allow us to keep the other /16 unused before we transfer it to
the third party via 8.3 transfer ?



Niki




On Thu, Apr 3, 2014 at 7:59 AM, John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> wrote:

On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>> wrote:

Hi John,

I have further enquiry about ARIN 8.2 process.

Number one:I am also worried about the costs of doing a 8.2 transfer
followed by a 8.3 transfer. I wonder if I will have to involve the legal
help to deal with ARIN legal. In my case I bought a company that now is
out of business. How complicated does ARIN make this process? I want some
assurance that I will be treated equally to any other companies whether it
is a big company or a small company like us.

Niki -

You will be treated equally, but in truth I'm not certain that is actually
what you want...
(for example, a process which seems routine for a large organization could
still pose
a disproportionate burden to a smaller organization since organization
size is not a
factor in the verification process.)

The first and foremost activity is to make sure that we have your
organization registered
as the rightful address holder, and that will require an NRPM 8.2
transfer. It can actually
be relatively straightforward process, as long as you have clear
documentation of the
purchase of the company. Review the instructions here for additional
information about
what is accepted - <
https://www.arin.net/resources/request/transfers_8_2.html>

Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will
the stated purpose for our number resources remains the same?? I am afraid
of that ARIN will not approve our transfer.

If you are the clear party with the rights after your purchase, ARIN will
approve your
transfer. We may note that you have more addresses than you now need, and
thus
we expect you to return or transfer the remainder (but that would seem to
line up with
your intentions in any case.)

If you have purchased a company without adequate documentation, or if
multiple
parties purchased multiple pieces of the company, or if there some
question about
what was purchased based on the documentation, then it can be more
challenging
to get the resources appropriately listed with you as the rightful holder.
You will need
to apply for the transfer and work with the ARIN Hostmaster to determine
if there is
any issue in your particular case.

Number three: As we have bought the company, do we have the property
right on those IPs? in our past agreement and future agreement arranged
for 8.3, we would like to have some kinds of property right on those IPs,
will that conflict with ARIN policy?

Wonderful question - it is ARIN's position that you have a specific set of
rights to the
address blocks in the registry (as defined by the registration services
agreement that
you enter with ARIN), and these rights include:

(1) The exclusive right to be the registrant of the Included Number
Resources within the ARIN database;
(2) The right to use the Included Number Resources within the ARIN
database; and
(3) The right to transfer the registration of the Included Number
Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of
property rights
in the address blocks, as it is inconsistent with the ability to manage
the address blocks
in accordance with community-developed policy in the region. If you have
other beliefs
with respect to your rights, that would probably be an area for you to
seek legal advice.

I hope this helps; please do not hesitate to ask if you have any
additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/fd4aa749/attachment-0001.html>

------------------------------

Message: 5
Date: Fri, 4 Apr 2014 07:43:43 +0800
From: xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>>
To: Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>>
Cc: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>>, "arin-ppml at arin.net<mailto:arin-ppml at arin.net>"
<arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
Between RSA and 8.2 Utilization Requirements
Message-ID:
<CAPhL6MrQdn-=5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com<mailto:5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com>>
Content-Type: text/plain; charset="iso-8859-1"

Hi Milton,

thanks for your inspiring reply. Now i know that we have the "ownership"
of those IPs. as you are one of the AC, i take your reply seriously and
also this is good news for the community, especially for those legacy
holders, if the holder of ARIN non-legacy IPs can have the "ownership'
then the holder of legacy IPs definitely has the ownership on their IPs
no matter whether they sign the RSA , LRSA or not.

Hope ARIN will not impose unpredictable "restrictions" when legacy or
non-legacy holder begins its transfer request. Moreover, when ARIN reject
a transfer , hope ARIN will not use the "confidential terms" as an excuse
for not reply communities' questions in ppml. or ARIN will reply with
bunch of info mean nothing.
Niki


On Thu, Apr 3, 2014 at 11:33 PM, Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>> wrote:

Niki:
For most economists and lawyers, the definition of a "property right"
involves the right to use, the right to exclude others from using, and the
right to transfer. As John's message makes clear, all those rights are
present in the number block lease you get from ARIN. So although the RSA
makes you formally declaim a property right, what you are getting from the
RSA is a bundle of rights that for all practical purposes has the same
economic features as a property right.

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

Wonderful question - it is ARIN's position that you have a specific set of
rights to the address blocks in the registry (as defined by the
registration services agreement that you enter with ARIN), and these rights
include:

(1) The exclusive right to be the registrant of the Included Number
Resources within the ARIN database;
(2) The right to use the Included Number Resources within the ARIN
database; and
(3) The right to transfer the registration of the Included Number
Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of
property rights in the address blocks, as it is inconsistent with the
ability to manage the address blocks in accordance with community-developed
policy in the region. If you have other beliefs with respect to your
rights, that would probably be an area for you to seek legal advice.

I hope this helps; please do not hesitate to ask if you have any
additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN
Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/57c3a01e/attachment.html>

------------------------------

_______________________________________________
ARIN-PPML mailing list
ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>
http://lists.arin.net/mailman/listinfo/arin-ppml

End of ARIN-PPML Digest, Vol 106, Issue 8
*****************************************

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto: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/20140404/f4d70674/attachment.htm>

From csquat at ccsd.net  Fri Apr  4 09:57:37 2014
From: csquat at ccsd.net (Chris R. Squatritto)
Date: Fri, 04 Apr 2014 06:57:37 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 13
Message-ID: <fc.004c4e074f493fc23b9aca000b42b1ad.4f493fc3@interact.ccsd.net>

I am out of the office this week and will not be checking email.  Please
contact Troy Miller for assistance..

Thank you for contacting me, and have a great day.

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

From David.Huberman at microsoft.com  Fri Apr  4 10:31:25 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Fri, 4 Apr 2014 14:31:25 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<7AD26173D4094238B51D28EE6DE8A020@gmail.com>
	<04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
Message-ID: <2364ac2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>

ARIN is a registry, not a regulator.  The more you guys want to

build in rules that are anti-competitive and blind to the market

reality, the more inaccurate Whois gets.



Upon v4 exhaustion, we should remove needs basis from

transfers, remove the RSA text that makes the signer disclaim

property rights, and motivate registrants to keep Whois accurate

so that network operators can get good information about their

traffic.



David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)
________________________________
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of Kevin Kargel <kkargel at polartel.com>
Sent: Friday, April 4, 2014 6:56 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

I guess I am confused.  I thought that resources assigned to entities that no longer exist should be reclaimed to the pool.
Kevin


From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
Sent: Thursday, April 03, 2014 8:25 PM
To: Rocky
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

Rocky,

Many such 8.2 transfers are efforts to get ARIN's records up to date regarding M&A transactions that happened years ago. It is not possible for a no-longer-existent entity to execute the 8.3 transfer, so it has to be 8.2 transferred to the new entity first.
Scott

On Apr 3, 2014, at 6:02 PM, Rocky <rockymm8 at gmail.com<mailto:rockymm8 at gmail.com>> wrote:

Hello there,



What you are planning to do  seems  like you try to disguise an 8.3 transfer as an 8.2 transfer.

I do not think it is appropriate for  allowing an 8.2 transfer followed by an 8.3/8.4 transfer.



If the company does not need the IPv4 and the IPv4 are lack of utilisation,   why not ask this company to return the IPv4 for the benefit of the community?



If the company wants to sell the IPv4 after an 8.2 to buyers through an 8.3/8.4,  why not the company directly transfer the IPv4 from its original organisation instead of  doing  an 8.2 first then followed by an 8.3/8.4 transfer.   Are the seller  trying to hide something or as the seller is afraid of doing something against the policy, so they try to make such an arrangement?



There is a highly suspicious of ? IPv4 laundry? or ?IPv4 speculation?  about this company.     Maybe we need more transparency of the buy&sale of the IPv4 to make sure the behaviour of the seller is compatible with  policy.



I suggest to resolve the language conflict between 8.2 transfer policy and RSA and further to suggest to figure out some measures to stop the  speculation on IPv4  via an 8.2 then followed by an 8.3/8.4 transfer.      If the company does not use the IPv4 after an 8.2 transfer, why not return them to free pool for the benefit of the whole community?



Any ideas on this ?



On Friday, April 4, 2014 at 7:43 AM, arin-ppml-request at arin.net<mailto:arin-ppml-request at arin.net> wrote:
Send ARIN-PPML mailing list submissions to
arin-ppml at arin.net<mailto:arin-ppml at arin.net>

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
arin-ppml-request at arin.net<mailto:arin-ppml-request at arin.net>

You can reach the person managing the list at
arin-ppml-owner at arin.net<mailto:arin-ppml-owner at arin.net>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."


Today's Topics:

1. Re: ARIN-PPML Digest, Vol 106, Issue 7 (Chris R. Squatritto)
2. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
and 8.2 Utilization Requirements (John Curran)
3. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
and 8.2 Utilization Requirements (Milton L Mueller)
4. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
and 8.2 Utilization Requirements (xiaofan yang)
5. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
and 8.2 Utilization Requirements (xiaofan yang)


----------------------------------------------------------------------

Message: 1
Date: Wed, 02 Apr 2014 16:30:45 -0700
From: "Chris R. Squatritto" <csquat at ccsd.net<mailto:csquat at ccsd.net>>
To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 7
Message-ID:
<fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net<mailto:fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net>>
Content-Type: text/plain; charset="utf-8"

I am out of the office this week and will not be checking email. Please
contact Troy Miller for assistance..

Thank you for contacting me, and have a great day.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140402/5723c721/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 2 Apr 2014 23:59:20 +0000
From: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>>
To: xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
Between RSA and 8.2 Utilization Requirements
Message-ID: <6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net<mailto:6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net>>
Content-Type: text/plain; charset="iso-8859-1"

On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>> wrote:

Hi John,

I have further enquiry about ARIN 8.2 process.

Number one:I am also worried about the costs of doing a 8.2 transfer followed by a 8.3 transfer. I wonder if I will have to involve the legal help to deal with ARIN legal. In my case I bought a company that now is out of business. How complicated does ARIN make this process? I want some assurance that I will be treated equally to any other companies whether it is a big company or a small company like us.

Niki -

You will be treated equally, but in truth I'm not certain that is actually what you want...
(for example, a process which seems routine for a large organization could still pose
a disproportionate burden to a smaller organization since organization size is not a
factor in the verification process.)

The first and foremost activity is to make sure that we have your organization registered
as the rightful address holder, and that will require an NRPM 8.2 transfer. It can actually
be relatively straightforward process, as long as you have clear documentation of the
purchase of the company. Review the instructions here for additional information about
what is accepted - <https://www.arin.net/resources/request/transfers_8_2.html>

Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will the stated purpose for our number resources remains the same?? I am afraid of that ARIN will not approve our transfer.

If you are the clear party with the rights after your purchase, ARIN will approve your
transfer. We may note that you have more addresses than you now need, and thus
we expect you to return or transfer the remainder (but that would seem to line up with
your intentions in any case.)

If you have purchased a company without adequate documentation, or if multiple
parties purchased multiple pieces of the company, or if there some question about
what was purchased based on the documentation, then it can be more challenging
to get the resources appropriately listed with you as the rightful holder. You will need
to apply for the transfer and work with the ARIN Hostmaster to determine if there is
any issue in your particular case.

Number three: As we have bought the company, do we have the property right on those IPs? in our past agreement and future agreement arranged for 8.3, we would like to have some kinds of property right on those IPs, will that conflict with ARIN policy?

Wonderful question - it is ARIN's position that you have a specific set of rights to the
address blocks in the registry (as defined by the registration services agreement that
you enter with ARIN), and these rights include:

(1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
(2) The right to use the Included Number Resources within the ARIN database; and
(3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of property rights
in the address blocks, as it is inconsistent with the ability to manage the address blocks
in accordance with community-developed policy in the region. If you have other beliefs
with respect to your rights, that would probably be an area for you to seek legal advice.

I hope this helps; please do not hesitate to ask if you have any additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN



------------------------------

Message: 3
Date: Thu, 3 Apr 2014 15:33:13 +0000
From: Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>>
To: "'John Curran'" <jcurran at arin.net<mailto:jcurran at arin.net>>, xiaofan yang
<nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
Between RSA and 8.2 Utilization Requirements
Message-ID: <1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu<mailto:1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu>>
Content-Type: text/plain; charset="us-ascii"

Niki:
For most economists and lawyers, the definition of a "property right" involves the right to use, the right to exclude others from using, and the right to transfer. As John's message makes clear, all those rights are present in the number block lease you get from ARIN. So although the RSA makes you formally declaim a property right, what you are getting from the RSA is a bundle of rights that for all practical purposes has the same economic features as a property right.

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

Wonderful question - it is ARIN's position that you have a specific set of rights to the address blocks in the registry (as defined by the registration services agreement that you enter with ARIN), and these rights include:

(1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
(2) The right to use the Included Number Resources within the ARIN database; and
(3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of property rights in the address blocks, as it is inconsistent with the ability to manage the address blocks in accordance with community-developed policy in the region. If you have other beliefs with respect to your rights, that would probably be an area for you to seek legal advice.

I hope this helps; please do not hesitate to ask if you have any additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.


------------------------------

Message: 4
Date: Fri, 4 Apr 2014 07:33:04 +0800
From: xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>>
To: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
Between RSA and 8.2 Utilization Requirements
Message-ID:
<CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com<mailto:CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com>>
Content-Type: text/plain; charset="iso-8859-1"

Hi John,


In basis of your reply, if the block is underutilised,ARIN will either ask
the company to return the IPs or transfer to other third party via 8.3
transfer after our 8.2 transfer.


Say we have two /16 after this 8.2 transfer, what if we only transfer one
/16 to the other third party via 8.3 transfer, meanwhile, we keep the
other /16 left unused after our 8.2 transfer for quiet a while. Will ARIN
ask us to return the remained /16 to the free pool? furthmore, how long
will ARIN allow us to keep the other /16 unused before we transfer it to
the third party via 8.3 transfer ?



Niki




On Thu, Apr 3, 2014 at 7:59 AM, John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> wrote:

On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>> wrote:

Hi John,

I have further enquiry about ARIN 8.2 process.

Number one:I am also worried about the costs of doing a 8.2 transfer
followed by a 8.3 transfer. I wonder if I will have to involve the legal
help to deal with ARIN legal. In my case I bought a company that now is
out of business. How complicated does ARIN make this process? I want some
assurance that I will be treated equally to any other companies whether it
is a big company or a small company like us.

Niki -

You will be treated equally, but in truth I'm not certain that is actually
what you want...
(for example, a process which seems routine for a large organization could
still pose
a disproportionate burden to a smaller organization since organization
size is not a
factor in the verification process.)

The first and foremost activity is to make sure that we have your
organization registered
as the rightful address holder, and that will require an NRPM 8.2
transfer. It can actually
be relatively straightforward process, as long as you have clear
documentation of the
purchase of the company. Review the instructions here for additional
information about
what is accepted - <
https://www.arin.net/resources/request/transfers_8_2.html>

Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will
the stated purpose for our number resources remains the same?? I am afraid
of that ARIN will not approve our transfer.

If you are the clear party with the rights after your purchase, ARIN will
approve your
transfer. We may note that you have more addresses than you now need, and
thus
we expect you to return or transfer the remainder (but that would seem to
line up with
your intentions in any case.)

If you have purchased a company without adequate documentation, or if
multiple
parties purchased multiple pieces of the company, or if there some
question about
what was purchased based on the documentation, then it can be more
challenging
to get the resources appropriately listed with you as the rightful holder.
You will need
to apply for the transfer and work with the ARIN Hostmaster to determine
if there is
any issue in your particular case.

Number three: As we have bought the company, do we have the property
right on those IPs? in our past agreement and future agreement arranged
for 8.3, we would like to have some kinds of property right on those IPs,
will that conflict with ARIN policy?

Wonderful question - it is ARIN's position that you have a specific set of
rights to the
address blocks in the registry (as defined by the registration services
agreement that
you enter with ARIN), and these rights include:

(1) The exclusive right to be the registrant of the Included Number
Resources within the ARIN database;
(2) The right to use the Included Number Resources within the ARIN
database; and
(3) The right to transfer the registration of the Included Number
Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of
property rights
in the address blocks, as it is inconsistent with the ability to manage
the address blocks
in accordance with community-developed policy in the region. If you have
other beliefs
with respect to your rights, that would probably be an area for you to
seek legal advice.

I hope this helps; please do not hesitate to ask if you have any
additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/fd4aa749/attachment-0001.html>

------------------------------

Message: 5
Date: Fri, 4 Apr 2014 07:43:43 +0800
From: xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>>
To: Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>>
Cc: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>>, "arin-ppml at arin.net<mailto:arin-ppml at arin.net>"
<arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
Between RSA and 8.2 Utilization Requirements
Message-ID:
<CAPhL6MrQdn-=5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com<mailto:5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com>>
Content-Type: text/plain; charset="iso-8859-1"

Hi Milton,

thanks for your inspiring reply. Now i know that we have the "ownership"
of those IPs. as you are one of the AC, i take your reply seriously and
also this is good news for the community, especially for those legacy
holders, if the holder of ARIN non-legacy IPs can have the "ownership'
then the holder of legacy IPs definitely has the ownership on their IPs
no matter whether they sign the RSA , LRSA or not.

Hope ARIN will not impose unpredictable "restrictions" when legacy or
non-legacy holder begins its transfer request. Moreover, when ARIN reject
a transfer , hope ARIN will not use the "confidential terms" as an excuse
for not reply communities' questions in ppml. or ARIN will reply with
bunch of info mean nothing.
Niki


On Thu, Apr 3, 2014 at 11:33 PM, Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>> wrote:

Niki:
For most economists and lawyers, the definition of a "property right"
involves the right to use, the right to exclude others from using, and the
right to transfer. As John's message makes clear, all those rights are
present in the number block lease you get from ARIN. So although the RSA
makes you formally declaim a property right, what you are getting from the
RSA is a bundle of rights that for all practical purposes has the same
economic features as a property right.

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

Wonderful question - it is ARIN's position that you have a specific set of
rights to the address blocks in the registry (as defined by the
registration services agreement that you enter with ARIN), and these rights
include:

(1) The exclusive right to be the registrant of the Included Number
Resources within the ARIN database;
(2) The right to use the Included Number Resources within the ARIN
database; and
(3) The right to transfer the registration of the Included Number
Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of
property rights in the address blocks, as it is inconsistent with the
ability to manage the address blocks in accordance with community-developed
policy in the region. If you have other beliefs with respect to your
rights, that would probably be an area for you to seek legal advice.

I hope this helps; please do not hesitate to ask if you have any
additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN
Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/57c3a01e/attachment.html>

------------------------------

_______________________________________________
ARIN-PPML mailing list
ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>
http://lists.arin.net/mailman/listinfo/arin-ppml

End of ARIN-PPML Digest, Vol 106, Issue 8
*****************************************

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto: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/20140404/74847887/attachment.htm>

From Timothy.S.Morizot at irs.gov  Fri Apr  4 10:45:39 2014
From: Timothy.S.Morizot at irs.gov (Morizot Timothy S)
Date: Fri, 4 Apr 2014 14:45:39 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <2364ac2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<7AD26173D4094238B51D28EE6DE8A020@gmail.com>
	<04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
	<2364ac2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>
Message-ID: <968C470DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov>

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Huberman
> Sent: Friday, April 04, 2014 9:31 AM
> 
> ARIN is a registry, not a regulator.  

You keep saying that, but simply asserting it does not make it reality. ARIN doesn't just register number allocations, it also makes those allocations. It doesn't just blindly register any and every request it receives. Everyone agrees to some form of needs basis when it comes to the free pool. (At the extreme end, everyone agrees it would be unreasonable to allocate the entire free pool, v4 or v6, simply because somebody asked for it.) They also have to ensure that bad actors don't hijack number allocations that are rightfully assigned to others. All of that requires rules (regulations by another name) and enforcing those rules makes ARIN the regulator of them.

You can disagree with the scope and nature of the regulations or with the actions of the regulator to enforce them, but the assertion that ARIN is not a regulator is simply false and will always be false as long as there are any rules at all in place that must be enforced.

Scott


From kkargel at polartel.com  Fri Apr  4 10:55:48 2014
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 4 Apr 2014 09:55:48 -0500
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <2364ac2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<7AD26173D4094238B51D28EE6DE8A020@gmail.com>
	<04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
	<2364ac2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>
Message-ID: <8695009A81378E48879980039EEDAD28013645561D@MAIL1.polartel.local>

Agreed.  ARIN should be a registry and as such absolutely should be non-competitive and blind to the market.  The registry should not be configured to support the market.  IMHO ARIN should not be participating in or catering to the market in any form.
Kevin


From: David Huberman [mailto:David.Huberman at microsoft.com]
Sent: Friday, April 04, 2014 9:31 AM
To: Kevin Kargel; arin-ppml at arin.net
Subject: RE: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8


ARIN is a registry, not a regulator.  The more you guys want to

build in rules that are anti-competitive and blind to the market

reality, the more inaccurate Whois gets.



Upon v4 exhaustion, we should remove needs basis from

transfers, remove the RSA text that makes the signer disclaim

property rights, and motivate registrants to keep Whois accurate

so that network operators can get good information about their

traffic.


David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)
________________________________
From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> <arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>> on behalf of Kevin Kargel <kkargel at polartel.com<mailto:kkargel at polartel.com>>
Sent: Friday, April 4, 2014 6:56 AM
To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

I guess I am confused.  I thought that resources assigned to entities that no longer exist should be reclaimed to the pool.
Kevin


From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
Sent: Thursday, April 03, 2014 8:25 PM
To: Rocky
Cc: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

Rocky,

Many such 8.2 transfers are efforts to get ARIN's records up to date regarding M&A transactions that happened years ago. It is not possible for a no-longer-existent entity to execute the 8.3 transfer, so it has to be 8.2 transferred to the new entity first.
Scott

On Apr 3, 2014, at 6:02 PM, Rocky <rockymm8 at gmail.com<mailto:rockymm8 at gmail.com>> wrote:

Hello there,



What you are planning to do  seems  like you try to disguise an 8.3 transfer as an 8.2 transfer.

I do not think it is appropriate for  allowing an 8.2 transfer followed by an 8.3/8.4 transfer.



If the company does not need the IPv4 and the IPv4 are lack of utilisation,   why not ask this company to return the IPv4 for the benefit of the community?



If the company wants to sell the IPv4 after an 8.2 to buyers through an 8.3/8.4,  why not the company directly transfer the IPv4 from its original organisation instead of  doing  an 8.2 first then followed by an 8.3/8.4 transfer.   Are the seller  trying to hide something or as the seller is afraid of doing something against the policy, so they try to make such an arrangement?



There is a highly suspicious of " IPv4 laundry" or "IPv4 speculation"  about this company.     Maybe we need more transparency of the buy&sale of the IPv4 to make sure the behaviour of the seller is compatible with  policy.



I suggest to resolve the language conflict between 8.2 transfer policy and RSA and further to suggest to figure out some measures to stop the  speculation on IPv4  via an 8.2 then followed by an 8.3/8.4 transfer.      If the company does not use the IPv4 after an 8.2 transfer, why not return them to free pool for the benefit of the whole community?



Any ideas on this ?



On Friday, April 4, 2014 at 7:43 AM, arin-ppml-request at arin.net<mailto:arin-ppml-request at arin.net> wrote:
Send ARIN-PPML mailing list submissions to
arin-ppml at arin.net<mailto:arin-ppml at arin.net>

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
arin-ppml-request at arin.net<mailto:arin-ppml-request at arin.net>

You can reach the person managing the list at
arin-ppml-owner at arin.net<mailto:arin-ppml-owner at arin.net>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."


Today's Topics:

1. Re: ARIN-PPML Digest, Vol 106, Issue 7 (Chris R. Squatritto)
2. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
and 8.2 Utilization Requirements (John Curran)
3. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
and 8.2 Utilization Requirements (Milton L Mueller)
4. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
and 8.2 Utilization Requirements (xiaofan yang)
5. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
and 8.2 Utilization Requirements (xiaofan yang)


----------------------------------------------------------------------

Message: 1
Date: Wed, 02 Apr 2014 16:30:45 -0700
From: "Chris R. Squatritto" <csquat at ccsd.net<mailto:csquat at ccsd.net>>
To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 7
Message-ID:
<fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net<mailto:fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net>>
Content-Type: text/plain; charset="utf-8"

I am out of the office this week and will not be checking email. Please
contact Troy Miller for assistance..

Thank you for contacting me, and have a great day.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140402/5723c721/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 2 Apr 2014 23:59:20 +0000
From: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>>
To: xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
Between RSA and 8.2 Utilization Requirements
Message-ID: <6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net<mailto:6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net>>
Content-Type: text/plain; charset="iso-8859-1"

On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>> wrote:

Hi John,

I have further enquiry about ARIN 8.2 process.

Number one:I am also worried about the costs of doing a 8.2 transfer followed by a 8.3 transfer. I wonder if I will have to involve the legal help to deal with ARIN legal. In my case I bought a company that now is out of business. How complicated does ARIN make this process? I want some assurance that I will be treated equally to any other companies whether it is a big company or a small company like us.

Niki -

You will be treated equally, but in truth I'm not certain that is actually what you want...
(for example, a process which seems routine for a large organization could still pose
a disproportionate burden to a smaller organization since organization size is not a
factor in the verification process.)

The first and foremost activity is to make sure that we have your organization registered
as the rightful address holder, and that will require an NRPM 8.2 transfer. It can actually
be relatively straightforward process, as long as you have clear documentation of the
purchase of the company. Review the instructions here for additional information about
what is accepted - <https://www.arin.net/resources/request/transfers_8_2.html>

Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will the stated purpose for our number resources remains the same?? I am afraid of that ARIN will not approve our transfer.

If you are the clear party with the rights after your purchase, ARIN will approve your
transfer. We may note that you have more addresses than you now need, and thus
we expect you to return or transfer the remainder (but that would seem to line up with
your intentions in any case.)

If you have purchased a company without adequate documentation, or if multiple
parties purchased multiple pieces of the company, or if there some question about
what was purchased based on the documentation, then it can be more challenging
to get the resources appropriately listed with you as the rightful holder. You will need
to apply for the transfer and work with the ARIN Hostmaster to determine if there is
any issue in your particular case.

Number three: As we have bought the company, do we have the property right on those IPs? in our past agreement and future agreement arranged for 8.3, we would like to have some kinds of property right on those IPs, will that conflict with ARIN policy?

Wonderful question - it is ARIN's position that you have a specific set of rights to the
address blocks in the registry (as defined by the registration services agreement that
you enter with ARIN), and these rights include:

(1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
(2) The right to use the Included Number Resources within the ARIN database; and
(3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of property rights
in the address blocks, as it is inconsistent with the ability to manage the address blocks
in accordance with community-developed policy in the region. If you have other beliefs
with respect to your rights, that would probably be an area for you to seek legal advice.

I hope this helps; please do not hesitate to ask if you have any additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN



------------------------------

Message: 3
Date: Thu, 3 Apr 2014 15:33:13 +0000
From: Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>>
To: "'John Curran'" <jcurran at arin.net<mailto:jcurran at arin.net>>, xiaofan yang
<nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
Between RSA and 8.2 Utilization Requirements
Message-ID: <1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu<mailto:1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu>>
Content-Type: text/plain; charset="us-ascii"

Niki:
For most economists and lawyers, the definition of a "property right" involves the right to use, the right to exclude others from using, and the right to transfer. As John's message makes clear, all those rights are present in the number block lease you get from ARIN. So although the RSA makes you formally declaim a property right, what you are getting from the RSA is a bundle of rights that for all practical purposes has the same economic features as a property right.

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

Wonderful question - it is ARIN's position that you have a specific set of rights to the address blocks in the registry (as defined by the registration services agreement that you enter with ARIN), and these rights include:

(1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
(2) The right to use the Included Number Resources within the ARIN database; and
(3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of property rights in the address blocks, as it is inconsistent with the ability to manage the address blocks in accordance with community-developed policy in the region. If you have other beliefs with respect to your rights, that would probably be an area for you to seek legal advice.

I hope this helps; please do not hesitate to ask if you have any additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.


------------------------------

Message: 4
Date: Fri, 4 Apr 2014 07:33:04 +0800
From: xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>>
To: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
Between RSA and 8.2 Utilization Requirements
Message-ID:
<CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com<mailto:CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com>>
Content-Type: text/plain; charset="iso-8859-1"

Hi John,


In basis of your reply, if the block is underutilised,ARIN will either ask
the company to return the IPs or transfer to other third party via 8.3
transfer after our 8.2 transfer.


Say we have two /16 after this 8.2 transfer, what if we only transfer one
/16 to the other third party via 8.3 transfer, meanwhile, we keep the
other /16 left unused after our 8.2 transfer for quiet a while. Will ARIN
ask us to return the remained /16 to the free pool? furthmore, how long
will ARIN allow us to keep the other /16 unused before we transfer it to
the third party via 8.3 transfer ?



Niki




On Thu, Apr 3, 2014 at 7:59 AM, John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> wrote:

On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>> wrote:

Hi John,

I have further enquiry about ARIN 8.2 process.

Number one:I am also worried about the costs of doing a 8.2 transfer
followed by a 8.3 transfer. I wonder if I will have to involve the legal
help to deal with ARIN legal. In my case I bought a company that now is
out of business. How complicated does ARIN make this process? I want some
assurance that I will be treated equally to any other companies whether it
is a big company or a small company like us.

Niki -

You will be treated equally, but in truth I'm not certain that is actually
what you want...
(for example, a process which seems routine for a large organization could
still pose
a disproportionate burden to a smaller organization since organization
size is not a
factor in the verification process.)

The first and foremost activity is to make sure that we have your
organization registered
as the rightful address holder, and that will require an NRPM 8.2
transfer. It can actually
be relatively straightforward process, as long as you have clear
documentation of the
purchase of the company. Review the instructions here for additional
information about
what is accepted - <
https://www.arin.net/resources/request/transfers_8_2.html>

Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will
the stated purpose for our number resources remains the same?? I am afraid
of that ARIN will not approve our transfer.

If you are the clear party with the rights after your purchase, ARIN will
approve your
transfer. We may note that you have more addresses than you now need, and
thus
we expect you to return or transfer the remainder (but that would seem to
line up with
your intentions in any case.)

If you have purchased a company without adequate documentation, or if
multiple
parties purchased multiple pieces of the company, or if there some
question about
what was purchased based on the documentation, then it can be more
challenging
to get the resources appropriately listed with you as the rightful holder.
You will need
to apply for the transfer and work with the ARIN Hostmaster to determine
if there is
any issue in your particular case.

Number three: As we have bought the company, do we have the property
right on those IPs? in our past agreement and future agreement arranged
for 8.3, we would like to have some kinds of property right on those IPs,
will that conflict with ARIN policy?

Wonderful question - it is ARIN's position that you have a specific set of
rights to the
address blocks in the registry (as defined by the registration services
agreement that
you enter with ARIN), and these rights include:

(1) The exclusive right to be the registrant of the Included Number
Resources within the ARIN database;
(2) The right to use the Included Number Resources within the ARIN
database; and
(3) The right to transfer the registration of the Included Number
Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of
property rights
in the address blocks, as it is inconsistent with the ability to manage
the address blocks
in accordance with community-developed policy in the region. If you have
other beliefs
with respect to your rights, that would probably be an area for you to
seek legal advice.

I hope this helps; please do not hesitate to ask if you have any
additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/fd4aa749/attachment-0001.html>

------------------------------

Message: 5
Date: Fri, 4 Apr 2014 07:43:43 +0800
From: xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>>
To: Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>>
Cc: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>>, "arin-ppml at arin.net<mailto:arin-ppml at arin.net>"
<arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
Between RSA and 8.2 Utilization Requirements
Message-ID:
<CAPhL6MrQdn-=5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com<mailto:5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com>>
Content-Type: text/plain; charset="iso-8859-1"

Hi Milton,

thanks for your inspiring reply. Now i know that we have the "ownership"
of those IPs. as you are one of the AC, i take your reply seriously and
also this is good news for the community, especially for those legacy
holders, if the holder of ARIN non-legacy IPs can have the "ownership'
then the holder of legacy IPs definitely has the ownership on their IPs
no matter whether they sign the RSA , LRSA or not.

Hope ARIN will not impose unpredictable "restrictions" when legacy or
non-legacy holder begins its transfer request. Moreover, when ARIN reject
a transfer , hope ARIN will not use the "confidential terms" as an excuse
for not reply communities' questions in ppml. or ARIN will reply with
bunch of info mean nothing.
Niki


On Thu, Apr 3, 2014 at 11:33 PM, Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>> wrote:

Niki:
For most economists and lawyers, the definition of a "property right"
involves the right to use, the right to exclude others from using, and the
right to transfer. As John's message makes clear, all those rights are
present in the number block lease you get from ARIN. So although the RSA
makes you formally declaim a property right, what you are getting from the
RSA is a bundle of rights that for all practical purposes has the same
economic features as a property right.

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

Wonderful question - it is ARIN's position that you have a specific set of
rights to the address blocks in the registry (as defined by the
registration services agreement that you enter with ARIN), and these rights
include:

(1) The exclusive right to be the registrant of the Included Number
Resources within the ARIN database;
(2) The right to use the Included Number Resources within the ARIN
database; and
(3) The right to transfer the registration of the Included Number
Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of
property rights in the address blocks, as it is inconsistent with the
ability to manage the address blocks in accordance with community-developed
policy in the region. If you have other beliefs with respect to your
rights, that would probably be an area for you to seek legal advice.

I hope this helps; please do not hesitate to ask if you have any
additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN
Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/57c3a01e/attachment.html>

------------------------------

_______________________________________________
ARIN-PPML mailing list
ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>
http://lists.arin.net/mailman/listinfo/arin-ppml

End of ARIN-PPML Digest, Vol 106, Issue 8
*****************************************

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto: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/20140404/386a5000/attachment.htm>

From David.Huberman at microsoft.com  Fri Apr  4 11:21:53 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Fri, 4 Apr 2014 15:21:53 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <968C470DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<7AD26173D4094238B51D28EE6DE8A020@gmail.com>
	<04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
	<2364ac2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>,
	<968C470DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov>
Message-ID: <d315c6acaaac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com>

Hi Scott,

Thank you for the reply. Please allow me to explain why I keep
repeating that ARIN is not a regulator. I believe ARIN only 
exists to serve the network operator community. It has been 
tasked to do so via the IETF.

You wrote:
"It doesn't blindly register any request it receives".

I agree. But let's discuss those rules.

For ASNs, there exists a minimal rule set that only seeks to ensure
that a requestor has a legitimate need PER RFC1930.  Again: the
rule set - the policies in NRPM - are wholly about RFC1930 
compliance.  In turn, RFC1930 is a concise document which lays
out the differences between locally-unique and globally-unique
autonomous systems.

For IPv4, there exists a rather expansive rule set.  But when NRPM
was first published in 2003 - based primarily on the rules found
in various spots on the ARIN website that Kim Hubbard maintained
prior to that - the rule set was designed to ensure that the requestor
met the terms of RFC2050. 

RFC2050 was an important document at the time it was published,
because literally, routers were melting.  BGP could not converge due
to disaggregation.  So RFC2050 addressed that problem -- and the
longer-term problem of IPv4 exhaustion without a safety net -- by
writing some rules about how to more sanely give out IP address
space. 

Today, however, RFC2050 has been deprecated by RFC7020.  RFC7020
lays out three primary goals:
- Allocation Pool Management
- Hierarchical Allocation
- Registry Accuracy

With an exhausted IPv4 pool, there are no "pool limitations at the time
of allocation" as there are no allocations.  ARIN's role in IPv4 is primarily
the third goal above: registry accuracy.

That's why I advocate removing needs-basis from transfers in a post-
exhaustion world.  There's no pool to manage[1], so the only OFFICIAL
mandate ARIN has from the network operator community is to run an
accurate registry.


My whole point is that the network operator community governs itself.
We make technical rules -- protocols -- collaboratively in the IETF. In
turn, we as a community have tasked ARIN with managing the numbers
part of the network, and have done so with formal documents that have
clear directives.

When this community -- the ARIN policy making community -- makes
rules (and takes on an attitude) that is beyond the mandate of the
governing RFCs, that's when you get the Randy Bush's rightly
decrying the "amateur policy makers". That's when you get companies
like Depository trying to literally compete with ARIN. And that's when 
you get network operators who are less and less interested - and 
in some cases, actually dis-motivated - from participating in the ARIN
system.

I advocate the principles of RFC7020, and in doing so, beg this community
to only make rules which conform to the spirit of IETF drafts. I beg the
ARIN CEO and Board to find a way to run a registry operation that is
nimble and responsive. The better ARIN is - policy-wise and operationally
- the better ARIN serves us.

/david

[1] Yes, I know. There are bits and pieces that come into ARIN's inventory
due to churn (companies going out of business for real and defaulting
on the Terms and Conditions of the RSA, and therefore forfeiting their
allocations and assignments).  That's why I haven't touched section 4,
except an attempt prior to ARIN in Phoenix to simplify the section.


________________________________________
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of Morizot Timothy S <Timothy.S.Morizot at irs.gov>
Sent: Friday, April 4, 2014 7:45 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Huberman
> Sent: Friday, April 04, 2014 9:31 AM
>
> ARIN is a registry, not a regulator.

You keep saying that, but simply asserting it does not make it reality. ARIN doesn't just register number allocations, it also makes those allocations. It doesn't just blindly register any and every request it receives. Everyone agrees to some form of needs basis when it comes to the free pool. (At the extreme end, everyone agrees it would be unreasonable to allocate the entire free pool, v4 or v6, simply because somebody asked for it.) They also have to ensure that bad actors don't hijack number allocations that are rightfully assigned to others. All of that requires rules (regulations by another name) and enforcing those rules makes ARIN the regulator of them.

You can disagree with the scope and nature of the regulations or with the actions of the regulator to enforce them, but the assertion that ARIN is not a regulator is simply false and will always be false as long as there are any rules at all in place that must be enforced.

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.


From scottleibrand at gmail.com  Fri Apr  4 11:46:58 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 4 Apr 2014 08:46:58 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<7AD26173D4094238B51D28EE6DE8A020@gmail.com>
	<04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
Message-ID: <E0D0B096-415E-41B3-845C-E309DDDFB1EB@gmail.com>

They usually have a legal successor, even if they're no longer a going concern (and can't execute contracts or effectuate 8.3 transfers). And usually the legal successor wants to dispose of the addresses themselves in some way, not just return them. 

Scott

> On Apr 4, 2014, at 6:56 AM, Kevin Kargel <kkargel at polartel.com> wrote:
> 
> I guess I am confused.  I thought that resources assigned to entities that no longer exist should be reclaimed to the pool. 
> Kevin
>  
>  
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
> Sent: Thursday, April 03, 2014 8:25 PM
> To: Rocky
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
>  
> Rocky,
>  
> Many such 8.2 transfers are efforts to get ARIN's records up to date regarding M&A transactions that happened years ago. It is not possible for a no-longer-existent entity to execute the 8.3 transfer, so it has to be 8.2 transferred to the new entity first. 
> 
> Scott
> 
> On Apr 3, 2014, at 6:02 PM, Rocky <rockymm8 at gmail.com> wrote:
> 
> Hello there,
>  
> What you are planning to do  seems  like you try to disguise an 8.3 transfer as an 8.2 transfer. 
> I do not think it is appropriate for  allowing an 8.2 transfer followed by an 8.3/8.4 transfer. 
>  
> If the company does not need the IPv4 and the IPv4 are lack of utilisation,   why not ask this company to return the IPv4 for the benefit of the community?
>  
> If the company wants to sell the IPv4 after an 8.2 to buyers through an 8.3/8.4,  why not the company directly transfer the IPv4 from its original organisation instead of  doing  an 8.2 first then followed by an 8.3/8.4 transfer.   Are the seller  trying to hide something or as the seller is afraid of doing something against the policy, so they try to make such an arrangement?
>  
> There is a highly suspicious of ? IPv4 laundry? or ?IPv4 speculation?  about this company.     Maybe we need more transparency of the buy&sale of the IPv4 to make sure the behaviour of the seller is compatible with  policy. 
>  
> I suggest to resolve the language conflict between 8.2 transfer policy and RSA and further to suggest to figure out some measures to stop the  speculation on IPv4  via an 8.2 then followed by an 8.3/8.4 transfer.      If the company does not use the IPv4 after an 8.2 transfer, why not return them to free pool for the benefit of the whole community?
>  
> Any ideas on this ?
>  
>  
> On Friday, April 4, 2014 at 7:43 AM, arin-ppml-request at arin.net wrote:
> 
> Send ARIN-PPML mailing list submissions to
> arin-ppml at arin.net
>  
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
> arin-ppml-request at arin.net
>  
> You can reach the person managing the list at
> arin-ppml-owner at arin.net
>  
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>  
>  
> Today's Topics:
>  
> 1. Re: ARIN-PPML Digest, Vol 106, Issue 7 (Chris R. Squatritto)
> 2. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> and 8.2 Utilization Requirements (John Curran)
> 3. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> and 8.2 Utilization Requirements (Milton L Mueller)
> 4. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> and 8.2 Utilization Requirements (xiaofan yang)
> 5. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> and 8.2 Utilization Requirements (xiaofan yang)
>  
>  
> ----------------------------------------------------------------------
>  
> Message: 1
> Date: Wed, 02 Apr 2014 16:30:45 -0700
> From: "Chris R. Squatritto" <csquat at ccsd.net>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 7
> Message-ID:
> <fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net>
> Content-Type: text/plain; charset="utf-8"
>  
> I am out of the office this week and will not be checking email. Please
> contact Troy Miller for assistance..
>  
> Thank you for contacting me, and have a great day.
>  
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140402/5723c721/attachment-0001.html>
>  
> ------------------------------
>  
> Message: 2
> Date: Wed, 2 Apr 2014 23:59:20 +0000
> From: John Curran <jcurran at arin.net>
> To: xiaofan yang <nikiyangxf at gmail.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> Between RSA and 8.2 Utilization Requirements
> Message-ID: <6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net>
> Content-Type: text/plain; charset="iso-8859-1"
>  
> On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:
>  
> Hi John,
>  
> I have further enquiry about ARIN 8.2 process.
>  
> Number one:I am also worried about the costs of doing a 8.2 transfer followed by a 8.3 transfer. I wonder if I will have to involve the legal help to deal with ARIN legal. In my case I bought a company that now is out of business. How complicated does ARIN make this process? I want some assurance that I will be treated equally to any other companies whether it is a big company or a small company like us.
>  
> Niki -
>  
> You will be treated equally, but in truth I'm not certain that is actually what you want...
> (for example, a process which seems routine for a large organization could still pose
> a disproportionate burden to a smaller organization since organization size is not a
> factor in the verification process.)
>  
> The first and foremost activity is to make sure that we have your organization registered
> as the rightful address holder, and that will require an NRPM 8.2 transfer. It can actually
> be relatively straightforward process, as long as you have clear documentation of the
> purchase of the company. Review the instructions here for additional information about
> what is accepted - <https://www.arin.net/resources/request/transfers_8_2.html>
>  
> Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will the stated purpose for our number resources remains the same?? I am afraid of that ARIN will not approve our transfer.
>  
> If you are the clear party with the rights after your purchase, ARIN will approve your
> transfer. We may note that you have more addresses than you now need, and thus
> we expect you to return or transfer the remainder (but that would seem to line up with
> your intentions in any case.)
>  
> If you have purchased a company without adequate documentation, or if multiple
> parties purchased multiple pieces of the company, or if there some question about
> what was purchased based on the documentation, then it can be more challenging
> to get the resources appropriately listed with you as the rightful holder. You will need
> to apply for the transfer and work with the ARIN Hostmaster to determine if there is
> any issue in your particular case.
>  
> Number three: As we have bought the company, do we have the property right on those IPs? in our past agreement and future agreement arranged for 8.3, we would like to have some kinds of property right on those IPs, will that conflict with ARIN policy?
>  
> Wonderful question - it is ARIN's position that you have a specific set of rights to the
> address blocks in the registry (as defined by the registration services agreement that
> you enter with ARIN), and these rights include:
>  
> (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
> (2) The right to use the Included Number Resources within the ARIN database; and
> (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.
>  
> ARIN registration services agreement includes a specific disclaimer of property rights
> in the address blocks, as it is inconsistent with the ability to manage the address blocks
> in accordance with community-developed policy in the region. If you have other beliefs
> with respect to your rights, that would probably be an area for you to seek legal advice.
>  
> I hope this helps; please do not hesitate to ask if you have any additional questions.
>  
> Thanks!
> /John
>  
> John Curran
> President and CEO
> ARIN
>  
>  
>  
> ------------------------------
>  
> Message: 3
> Date: Thu, 3 Apr 2014 15:33:13 +0000
> From: Milton L Mueller <mueller at syr.edu>
> To: "'John Curran'" <jcurran at arin.net>, xiaofan yang
> <nikiyangxf at gmail.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> Between RSA and 8.2 Utilization Requirements
> Message-ID: <1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu>
> Content-Type: text/plain; charset="us-ascii"
>  
> Niki:
> For most economists and lawyers, the definition of a "property right" involves the right to use, the right to exclude others from using, and the right to transfer. As John's message makes clear, all those rights are present in the number block lease you get from ARIN. So although the RSA makes you formally declaim a property right, what you are getting from the RSA is a bundle of rights that for all practical purposes has the same economic features as a property right.
>  
> -----Original Message-----
>  
> Wonderful question - it is ARIN's position that you have a specific set of rights to the address blocks in the registry (as defined by the registration services agreement that you enter with ARIN), and these rights include:
>  
> (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
> (2) The right to use the Included Number Resources within the ARIN database; and
> (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.
>  
> ARIN registration services agreement includes a specific disclaimer of property rights in the address blocks, as it is inconsistent with the ability to manage the address blocks in accordance with community-developed policy in the region. If you have other beliefs with respect to your rights, that would probably be an area for you to seek legal advice.
>  
> I hope this helps; please do not hesitate to ask if you have any additional questions.
>  
> Thanks!
> /John
>  
> John Curran
> President and CEO
> ARIN
>  
> _______________________________________________
> 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.
>  
>  
> ------------------------------
>  
> Message: 4
> Date: Fri, 4 Apr 2014 07:33:04 +0800
> From: xiaofan yang <nikiyangxf at gmail.com>
> To: John Curran <jcurran at arin.net>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> Between RSA and 8.2 Utilization Requirements
> Message-ID:
> <CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>  
> Hi John,
>  
>  
> In basis of your reply, if the block is underutilised,ARIN will either ask
> the company to return the IPs or transfer to other third party via 8.3
> transfer after our 8.2 transfer.
>  
>  
> Say we have two /16 after this 8.2 transfer, what if we only transfer one
> /16 to the other third party via 8.3 transfer, meanwhile, we keep the
> other /16 left unused after our 8.2 transfer for quiet a while. Will ARIN
> ask us to return the remained /16 to the free pool? furthmore, how long
> will ARIN allow us to keep the other /16 unused before we transfer it to
> the third party via 8.3 transfer ?
>  
>  
>  
> Niki
>  
>  
>  
>  
> On Thu, Apr 3, 2014 at 7:59 AM, John Curran <jcurran at arin.net> wrote:
>  
> On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:
>  
> Hi John,
>  
> I have further enquiry about ARIN 8.2 process.
>  
> Number one:I am also worried about the costs of doing a 8.2 transfer
> followed by a 8.3 transfer. I wonder if I will have to involve the legal
> help to deal with ARIN legal. In my case I bought a company that now is
> out of business. How complicated does ARIN make this process? I want some
> assurance that I will be treated equally to any other companies whether it
> is a big company or a small company like us.
>  
> Niki -
>  
> You will be treated equally, but in truth I'm not certain that is actually
> what you want...
> (for example, a process which seems routine for a large organization could
> still pose
> a disproportionate burden to a smaller organization since organization
> size is not a
> factor in the verification process.)
>  
> The first and foremost activity is to make sure that we have your
> organization registered
> as the rightful address holder, and that will require an NRPM 8.2
> transfer. It can actually
> be relatively straightforward process, as long as you have clear
> documentation of the
> purchase of the company. Review the instructions here for additional
> information about
> what is accepted - <
> https://www.arin.net/resources/request/transfers_8_2.html>
>  
> Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will
> the stated purpose for our number resources remains the same?? I am afraid
> of that ARIN will not approve our transfer.
>  
> If you are the clear party with the rights after your purchase, ARIN will
> approve your
> transfer. We may note that you have more addresses than you now need, and
> thus
> we expect you to return or transfer the remainder (but that would seem to
> line up with
> your intentions in any case.)
>  
> If you have purchased a company without adequate documentation, or if
> multiple
> parties purchased multiple pieces of the company, or if there some
> question about
> what was purchased based on the documentation, then it can be more
> challenging
> to get the resources appropriately listed with you as the rightful holder.
> You will need
> to apply for the transfer and work with the ARIN Hostmaster to determine
> if there is
> any issue in your particular case.
>  
> Number three: As we have bought the company, do we have the property
> right on those IPs? in our past agreement and future agreement arranged
> for 8.3, we would like to have some kinds of property right on those IPs,
> will that conflict with ARIN policy?
>  
> Wonderful question - it is ARIN's position that you have a specific set of
> rights to the
> address blocks in the registry (as defined by the registration services
> agreement that
> you enter with ARIN), and these rights include:
>  
> (1) The exclusive right to be the registrant of the Included Number
> Resources within the ARIN database;
> (2) The right to use the Included Number Resources within the ARIN
> database; and
> (3) The right to transfer the registration of the Included Number
> Resources pursuant to the Policies.
>  
> ARIN registration services agreement includes a specific disclaimer of
> property rights
> in the address blocks, as it is inconsistent with the ability to manage
> the address blocks
> in accordance with community-developed policy in the region. If you have
> other beliefs
> with respect to your rights, that would probably be an area for you to
> seek legal advice.
>  
> I hope this helps; please do not hesitate to ask if you have any
> additional questions.
>  
> Thanks!
> /John
>  
> John Curran
> President and CEO
> ARIN
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/fd4aa749/attachment-0001.html>
>  
> ------------------------------
>  
> Message: 5
> Date: Fri, 4 Apr 2014 07:43:43 +0800
> From: xiaofan yang <nikiyangxf at gmail.com>
> To: Milton L Mueller <mueller at syr.edu>
> Cc: John Curran <jcurran at arin.net>, "arin-ppml at arin.net"
> <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> Between RSA and 8.2 Utilization Requirements
> Message-ID:
> <CAPhL6MrQdn-=5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>  
> Hi Milton,
>  
> thanks for your inspiring reply. Now i know that we have the "ownership"
> of those IPs. as you are one of the AC, i take your reply seriously and
> also this is good news for the community, especially for those legacy
> holders, if the holder of ARIN non-legacy IPs can have the "ownership'
> then the holder of legacy IPs definitely has the ownership on their IPs
> no matter whether they sign the RSA , LRSA or not.
>  
> Hope ARIN will not impose unpredictable "restrictions" when legacy or
> non-legacy holder begins its transfer request. Moreover, when ARIN reject
> a transfer , hope ARIN will not use the "confidential terms" as an excuse
> for not reply communities' questions in ppml. or ARIN will reply with
> bunch of info mean nothing.
> Niki
>  
>  
> On Thu, Apr 3, 2014 at 11:33 PM, Milton L Mueller <mueller at syr.edu> wrote:
>  
> Niki:
> For most economists and lawyers, the definition of a "property right"
> involves the right to use, the right to exclude others from using, and the
> right to transfer. As John's message makes clear, all those rights are
> present in the number block lease you get from ARIN. So although the RSA
> makes you formally declaim a property right, what you are getting from the
> RSA is a bundle of rights that for all practical purposes has the same
> economic features as a property right.
>  
> -----Original Message-----
>  
> Wonderful question - it is ARIN's position that you have a specific set of
> rights to the address blocks in the registry (as defined by the
> registration services agreement that you enter with ARIN), and these rights
> include:
>  
> (1) The exclusive right to be the registrant of the Included Number
> Resources within the ARIN database;
> (2) The right to use the Included Number Resources within the ARIN
> database; and
> (3) The right to transfer the registration of the Included Number
> Resources pursuant to the Policies.
>  
> ARIN registration services agreement includes a specific disclaimer of
> property rights in the address blocks, as it is inconsistent with the
> ability to manage the address blocks in accordance with community-developed
> policy in the region. If you have other beliefs with respect to your
> rights, that would probably be an area for you to seek legal advice.
>  
> I hope this helps; please do not hesitate to ask if you have any
> additional questions.
>  
> Thanks!
> /John
>  
> John Curran
> President and CEO
> ARIN
>  
> _______________________________________________
> 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: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/57c3a01e/attachment.html>
>  
> ------------------------------
>  
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>  
> End of ARIN-PPML Digest, Vol 106, Issue 8
> *****************************************
>  
> _______________________________________________
> 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/20140404/a93b1d1c/attachment.htm>

From Timothy.S.Morizot at irs.gov  Fri Apr  4 11:47:02 2014
From: Timothy.S.Morizot at irs.gov (Morizot Timothy S)
Date: Fri, 4 Apr 2014 15:47:02 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <d315c6acaaac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<7AD26173D4094238B51D28EE6DE8A020@gmail.com>
	<04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
	<2364ac2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>,
	<968C470DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov>
	<d315c6acaaac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com>
Message-ID: <968C470DAC25FB419E0159952F28F0C06A75D85F@MEM0200CP3XF04.ds.irsnet.gov>

> -----Original Message-----
> From: David Huberman [mailto:David.Huberman at microsoft.com]
> Sent: Friday, April 04, 2014 10:22 AM
> 
> With an exhausted IPv4 pool, there are no "pool limitations at the time
> of allocation" as there are no allocations.  ARIN's role in IPv4 is primarily
> the third goal above: registry accuracy.
> 
> That's why I advocate removing needs-basis from transfers in a post-
> exhaustion world.  There's no pool to manage[1], so the only OFFICIAL
> mandate ARIN has from the network operator community is to run an
> accurate registry.

I've actually been consistently in favor of IPv4 policies over the past couple of years that seemed likely to exhaust the IPv4 free pool sooner rather than later, so I have no real objection to altering the existing rules. I'm not convinced that eliminating needs basis in a post-exhaustion world would lead to fairer utilization or more competitiveness, but I would probably favor such a change since it would likely make IPv4 less palatable more quickly. (Of course, I believe the global inter-rir policy has a needs basis aspect so I think removing all needs basis from transfers would mean ARIN could no longer do inter-rir transfers, but that's a separate issue.)

They still have to protect against hijacking, which is a process that requires active regulation, even without needs basis for IPv4 transfers.

And, of course, there will be a need for at least some sort of needs basis on the IPv6 side going forward.

So I'm not necessarily againt simplifying policy in rational ways or to achieve clearly expressed aims. I don't think there's very much that's going to convince legacy holders who aren't already actively engaged to improve their registry information, though. That part of the IPv4 registry is and will almost certainly remain a swamp. I think it's more productive to focus on an accurate IPv6 registry and move on.

Scott


From jcurran at arin.net  Fri Apr  4 11:58:16 2014
From: jcurran at arin.net (John Curran)
Date: Fri, 4 Apr 2014 15:58:16 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <d315c6acaaac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<7AD26173D4094238B51D28EE6DE8A020@gmail.com>
	<04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
	<2364ac2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>
	<968C470DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov>
	<d315c6acaaac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com>
Message-ID: <721C156E-DEB9-4823-8873-AA6570C15F13@arin.net>

On Apr 4, 2014, at 11:21 AM, David Huberman <David.Huberman at microsoft.com> wrote:

> Today, however, RFC2050 has been deprecated by RFC7020.  RFC7020
> lays out three primary goals:
> - Allocation Pool Management
> - Hierarchical Allocation
> - Registry Accuracy
> ...
> That's why I advocate removing needs-basis from transfers in a post-
> exhaustion world.  There's no pool to manage[1], so the only OFFICIAL
> mandate ARIN has from the network operator community is to run an
> accurate registry.

Be very careful, David, in referring to RFC7020 as a mandate from 
the network operator community... it would be best characterized 
simply as a document which has undergone IETF review.  Note that 
there are at least as frequent cries about the lack of operators 
at IETF as there are about lack of operators in RIR activities...

> When this community -- the ARIN policy making community -- makes
> rules (and takes on an attitude) that is beyond the mandate of the
> governing RFCs, 

To be clear - RFC 7020 is a cleanup of RFC 2050 to remove the embedded 
(and obsolete) 1996-era IPv4 allocation policy within the document, 
leaving a clearer description of the existing Internet number registry 
system.  The absence of policy is intentional, but that is not expressing
a constraint on policy creation, it is done with the explicit recognition
that "The RIRs also conduct regional number policy development used in the 
administration of the number resources for which they are responsible."

> I advocate the principles of RFC7020, and in doing so, beg this community
> to only make rules which conform to the spirit of IETF drafts.

To the extent that the community develops policy which is applicable in 
administration of number resources in the region, such policy conforms
to the spirit of RFC 7020.   

Despite the above, I agree that folks should think carefully about the 
need for any given policy-based restriction, as number resource policy 
can have real-world impacts on other organizations which are as great 
or greater than any perceived benefit that might result.  If there is an 
aspect of number resource policy that is needed because its absence will 
result in harm to your organization, then it is important to speak up and 
see if there are others who feel similarly with overall consensus to create
policy...  In cases where the harm is not apparent, there is no need for
creation or continuance of policy, since (in agreement with David) the 
policy is supposed to serve the community, not the other way around.

Thanks!
/John

John Curran
President and CEO
ARIN



From David.Huberman at microsoft.com  Fri Apr  4 12:57:27 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Fri, 4 Apr 2014 16:57:27 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <968C470DAC25FB419E0159952F28F0C06A75D85F@MEM0200CP3XF04.ds.irsnet.gov>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<7AD26173D4094238B51D28EE6DE8A020@gmail.com>
	<04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
	<2364ac2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>,
	<968C470DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov>
	<d315c6acaaac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com>
	<968C470DAC25FB419E0159952F28F0C06A75D85F@MEM0200CP3XF04.ds.irsnet.gov>
Message-ID: <7bffb818d7724352b455eb414c43a673@BY2PR03MB394.namprd03.prod.outlook.com>

In my message you are replying to, I accidentally forgot to address the hijacking issue.  (Last message from me on list today, I promise!)

I think Owen DeLong and Stephen Sprunk did a really good job addressing the whole hijacking and scamming problem when they authored NRPM section 12.  Between ARIN's legal protections in the RSA and as a business incorporated in, and operating in, the United States, and the policy levers that NRPM 12 give, I think that whole issue is well covered by policy.   In general, I do not agree with section 4, 6, or 6 policy that tries to account for scammers.  We should make policy for the 99%, not the 1%.  Let ARIN as a business, and ARIN as an enforcer of NRPM 12, deal with that -- and report back to us any deficiencies in tools.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Morizot Timothy S
Sent: Friday, April 4, 2014 8:47 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

> -----Original Message-----
> From: David Huberman [mailto:David.Huberman at microsoft.com]
> Sent: Friday, April 04, 2014 10:22 AM
> 
> With an exhausted IPv4 pool, there are no "pool limitations at the 
> time of allocation" as there are no allocations.  ARIN's role in IPv4 
> is primarily the third goal above: registry accuracy.
> 
> That's why I advocate removing needs-basis from transfers in a post- 
> exhaustion world.  There's no pool to manage[1], so the only OFFICIAL 
> mandate ARIN has from the network operator community is to run an 
> accurate registry.

I've actually been consistently in favor of IPv4 policies over the past couple of years that seemed likely to exhaust the IPv4 free pool sooner rather than later, so I have no real objection to altering the existing rules. I'm not convinced that eliminating needs basis in a post-exhaustion world would lead to fairer utilization or more competitiveness, but I would probably favor such a change since it would likely make IPv4 less palatable more quickly. (Of course, I believe the global inter-rir policy has a needs basis aspect so I think removing all needs basis from transfers would mean ARIN could no longer do inter-rir transfers, but that's a separate issue.)

They still have to protect against hijacking, which is a process that requires active regulation, even without needs basis for IPv4 transfers.

And, of course, there will be a need for at least some sort of needs basis on the IPv6 side going forward.

So I'm not necessarily againt simplifying policy in rational ways or to achieve clearly expressed aims. I don't think there's very much that's going to convince legacy holders who aren't already actively engaged to improve their registry information, though. That part of the IPv4 registry is and will almost certainly remain a swamp. I think it's more productive to focus on an accurate IPv6 registry and move on.

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.


From SRyerse at eclipse-networks.com  Fri Apr  4 13:25:43 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Fri, 4 Apr 2014 17:25:43 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <d315c6acaaac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net><7AD26173D4094
	238B51D28EE6DE8A020@gmail.com><04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.c
	om>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local><2364a
	c2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>,
	<968C47
	0DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov>
	<d315c6acaaac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201529268D3@ENI-MAIL.eclipse-networks.com>

David is right that when he advocates removing needs-basis from transfers in a post- exhaustion world.  However, the only difference between then and now is that ARIN probably has a larger unallocated IPv4 then it will after Exhaustion.  The size of what ARIN has in its unallocated pool really makes no difference to ARINs Mission, and the Mission won't really change at Exhaustion. 

I have said many times in the past that ARINs Mission is TO Allocate and it isn't NOT TO Allocate which some of the IPv4 polices are designed to do.  Of course after I pointed that out many times and many ways, the ARIN Board took it upon itself to remove that phrase from its Mission Statement - without input from this Community I might add.  (But it still exists in related documents.)

ARIN should not be in the business of turning down resource requests if they have the resources to allocate - EVER.  Doing so is arbitrary and discriminatory.  ARIN should only be in the business of right sizing allocations to match the size of the organization (including their existing network size) making the request - AND - keeping the registry database as accurate as possible.  

When ARIN denies allocation requests like they did to us, they force organizations like ours to make a decision on possibly purchasing resources outside of ARIN.  When that happens, the result of the needs based polices may be an off the ARIN books transaction and the registry database becomes less accurate.  Thus existing policies cause ARIN to NOT be able to fulfill its Mission of keeping an accurate database. 

But there I go again, trying to infuse reality and common sense into policy discussions . . . . .

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman
Sent: Friday, April 04, 2014 11:22 AM
To: Morizot Timothy S; arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

Hi Scott,

Thank you for the reply. Please allow me to explain why I keep repeating that ARIN is not a regulator. I believe ARIN only exists to serve the network operator community. It has been tasked to do so via the IETF.

You wrote:
"It doesn't blindly register any request it receives".

I agree. But let's discuss those rules.

For ASNs, there exists a minimal rule set that only seeks to ensure that a requestor has a legitimate need PER RFC1930.  Again: the rule set - the policies in NRPM - are wholly about RFC1930 compliance.  In turn, RFC1930 is a concise document which lays out the differences between locally-unique and globally-unique autonomous systems.

For IPv4, there exists a rather expansive rule set.  But when NRPM was first published in 2003 - based primarily on the rules found in various spots on the ARIN website that Kim Hubbard maintained prior to that - the rule set was designed to ensure that the requestor met the terms of RFC2050. 

RFC2050 was an important document at the time it was published, because literally, routers were melting.  BGP could not converge due to disaggregation.  So RFC2050 addressed that problem -- and the longer-term problem of IPv4 exhaustion without a safety net -- by writing some rules about how to more sanely give out IP address space. 

Today, however, RFC2050 has been deprecated by RFC7020.  RFC7020 lays out three primary goals:
- Allocation Pool Management
- Hierarchical Allocation
- Registry Accuracy

With an exhausted IPv4 pool, there are no "pool limitations at the time of allocation" as there are no allocations.  ARIN's role in IPv4 is primarily the third goal above: registry accuracy.

That's why I advocate removing needs-basis from transfers in a post- exhaustion world.  There's no pool to manage[1], so the only OFFICIAL mandate ARIN has from the network operator community is to run an accurate registry.


My whole point is that the network operator community governs itself.
We make technical rules -- protocols -- collaboratively in the IETF. In turn, we as a community have tasked ARIN with managing the numbers part of the network, and have done so with formal documents that have clear directives.

When this community -- the ARIN policy making community -- makes rules (and takes on an attitude) that is beyond the mandate of the governing RFCs, that's when you get the Randy Bush's rightly decrying the "amateur policy makers". That's when you get companies like Depository trying to literally compete with ARIN. And that's when you get network operators who are less and less interested - and in some cases, actually dis-motivated - from participating in the ARIN system.

I advocate the principles of RFC7020, and in doing so, beg this community to only make rules which conform to the spirit of IETF drafts. I beg the ARIN CEO and Board to find a way to run a registry operation that is nimble and responsive. The better ARIN is - policy-wise and operationally
- the better ARIN serves us.

/david

[1] Yes, I know. There are bits and pieces that come into ARIN's inventory due to churn (companies going out of business for real and defaulting on the Terms and Conditions of the RSA, and therefore forfeiting their allocations and assignments).  That's why I haven't touched section 4, except an attempt prior to ARIN in Phoenix to simplify the section.


________________________________________
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of Morizot Timothy S <Timothy.S.Morizot at irs.gov>
Sent: Friday, April 4, 2014 7:45 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] 
> On Behalf Of David Huberman
> Sent: Friday, April 04, 2014 9:31 AM
>
> ARIN is a registry, not a regulator.

You keep saying that, but simply asserting it does not make it reality. ARIN doesn't just register number allocations, it also makes those allocations. It doesn't just blindly register any and every request it receives. Everyone agrees to some form of needs basis when it comes to the free pool. (At the extreme end, everyone agrees it would be unreasonable to allocate the entire free pool, v4 or v6, simply because somebody asked for it.) They also have to ensure that bad actors don't hijack number allocations that are rightfully assigned to others. All of that requires rules (regulations by another name) and enforcing those rules makes ARIN the regulator of them.

You can disagree with the scope and nature of the regulations or with the actions of the regulator to enforce them, but the assertion that ARIN is not a regulator is simply false and will always be false as long as there are any rules at all in place that must be enforced.

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.

From Timothy.S.Morizot at irs.gov  Fri Apr  4 13:32:06 2014
From: Timothy.S.Morizot at irs.gov (Morizot Timothy S)
Date: Fri, 4 Apr 2014 17:32:06 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201529268D3@ENI-MAIL.eclipse-networks.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net><7AD26173D4094
	238B51D28EE6DE8A020@gmail.com><04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.c
	om>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local><2364a
	c2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>,
	<968C47
	0DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov>
	<d315c6acaaac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201529268D3@ENI-MAIL.eclipse-networks.com>
Message-ID: <968C470DAC25FB419E0159952F28F0C06A75D95B@MEM0200CP3XF04.ds.irsnet.gov>

> -----Original Message-----
> From: Steven Ryerse [mailto:SRyerse at eclipse-networks.com]
> Sent: Friday, April 04, 2014 12:26 PM
> 
> ARIN should not be in the business of turning down resource requests if they
> have the resources to allocate - EVER.  Doing so is arbitrary and
> discriminatory.  ARIN should only be in the business of right sizing allocations
> to match the size of the organization (including their existing network size)
> making the request - AND - keeping the registry database as accurate as
> possible.

So which is it? Should they never EVER turn down resource requests? Or should they "right-size" them, which by any definition you might set means there are some requests they would deny altogether?

Do you truly fail to see the logical inconsistency in the paragraph above?

Scott


From SRyerse at eclipse-networks.com  Fri Apr  4 14:00:32 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Fri, 4 Apr 2014 18:00:32 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <968C470DAC25FB419E0159952F28F0C06A75D95B@MEM0200CP3XF04.ds.irsnet.gov>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net><7AD26173D4094
	238B51D28EE6DE8A020@gmail.com><04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.c
	om>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local><2364a
	c2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>,
	<968C47
	0DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov><d315c6acaa
	ac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com><5B9E90747FA2
	974D91A54FCFA1B8AD1201529268D3@ENI-MAIL.eclipse-networks.com>
	<968C470DAC25FB419E0159952F28F0C06A75D95B@MEM0200CP3XF04.ds.irsnet.gov>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120152926A3E@ENI-MAIL.eclipse-networks.com>

If an org with no resources applies they should at least be able to get the minimum which has been set by this community which I think is currently at a /22.  Always!

If an org wants larger than a /22 they need to be able to demonstrate in a reasonable way that they are a larger org with a network size that justifies a larger allocation.  The first way is what allocation do they already have?  If they have say a /19  or equivalent maybe they can demonstrate they need say another /19 by furnishing to ARIN maybe their financials and the investment they have actually made to justify another /19 or whatever.  (I'm just using the /19 as an example.)

If an org wants say a /9 which is obviously a very large block, they need to justify that in a similar way that T-Mobile did with ARIN a while back when they got something like 3/4 of a /8.  

Organizations supply financials to Banks all the time and this and supplying network info can be a similar process.  If an org can prove they just spent 50 million on a new data center then that should be justification to get an allocation of a size to run that size data center. 

So if we want the current minimum we should just apply and it should be allocated, and as long as we keep paying our fees to ARIN it is ours to use.  If we stop paying that block goes back into the pool that ARIN has to allocate.  

If we want a /19 or a /16 then we need to satisfy ARIN that we are an org of that size and have a network that justifies a /19 or a /16.  And maybe prove the actual expenditures. 

And if we want a /9, regardless of what we have now, we're gonna really have to provide solid info that justifies the size of our org and the size of our network justifies a /9.  

This is not rocket science. It would however require the input of the many knowledgeable members of this community to help determine what is require at each level.  I think this community could handle that just fine!

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?


-----Original Message-----
From: Morizot Timothy S [mailto:Timothy.S.Morizot at irs.gov] 
Sent: Friday, April 04, 2014 1:32 PM
To: Steven Ryerse; David Huberman; arin-ppml at arin.net
Subject: RE: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

> -----Original Message-----
> From: Steven Ryerse [mailto:SRyerse at eclipse-networks.com]
> Sent: Friday, April 04, 2014 12:26 PM
> 
> ARIN should not be in the business of turning down resource requests 
> if they have the resources to allocate - EVER.  Doing so is arbitrary 
> and discriminatory.  ARIN should only be in the business of right 
> sizing allocations to match the size of the organization (including 
> their existing network size) making the request - AND - keeping the 
> registry database as accurate as possible.

So which is it? Should they never EVER turn down resource requests? Or should they "right-size" them, which by any definition you might set means there are some requests they would deny altogether?

Do you truly fail to see the logical inconsistency in the paragraph above?

Scott


From mueller at syr.edu  Fri Apr  4 16:25:18 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 4 Apr 2014 20:25:18 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <d315c6acaaac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<7AD26173D4094238B51D28EE6DE8A020@gmail.com>
	<04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
	<2364ac2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>,
	<968C470DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov>
	<d315c6acaaac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com>
Message-ID: <15fd165f2e584b09b54cab728f31b6e1@EX13-MBX-13.ad.syr.edu>


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

> With an exhausted IPv4 pool, there are no "pool limitations at the 
> time of allocation" as there are no allocations.  ARIN's role in IPv4 is 
> primarily the third goal above: registry accuracy.
> 
> That's why I advocate removing needs-basis from transfers in a post- 
> exhaustion world.  There's no pool to manage[1], so the only OFFICIAL 
> mandate ARIN has from the network operator community is to run 
> an accurate registry.

I agree with David. 
Needs assessment was designed to be a rationing mechanism that filled in the gap left by the absence of a price system for Ipv4 addresses. 
Because ARIN hands out free pool number blocks for free, the absence of needs assessment would provoke a first come first served land rush and subsequent tragedy of the commons. Once you reach exhaust, however, no one gets number blocks for free, everyone must pay a market price for them. The rationale for needs assessment is totally gone. Restricting transfers in this environment _will_ inevitably produce inaccuracies in the registry data. 


From dogwallah at gmail.com  Fri Apr  4 17:12:34 2014
From: dogwallah at gmail.com (McTim)
Date: Fri, 4 Apr 2014 17:12:34 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120152926A3E@ENI-MAIL.eclipse-networks.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
	<968C470DAC25FB419E0159952F28F0C06A75D95B@MEM0200CP3XF04.ds.irsnet.gov>
	<5B9E90747FA2974D91A54FCFA1B8AD120152926A3E@ENI-MAIL.eclipse-networks.com>
Message-ID: <CACAaNxhd9CRV5gRB=qSKzq4ZYTz1GJu2dvuyisbqFA0XjBnkLA@mail.gmail.com>

On Fri, Apr 4, 2014 at 2:00 PM, Steven Ryerse
<SRyerse at eclipse-networks.com> wrote:
> If an org with no resources applies they should at least be able to get the minimum which has been set by this community which I think is currently at a /22.  Always!
>
> If an org wants larger than a /22 they need to be able to demonstrate in a reasonable way that they are a larger org with a network size that justifies a larger allocation.


Which is what is meant by "needs based" allocation if I am not mistaken.

-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel


From SRyerse at eclipse-networks.com  Fri Apr  4 17:27:39 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Fri, 4 Apr 2014 21:27:39 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <CACAaNxhd9CRV5gRB=qSKzq4ZYTz1GJu2dvuyisbqFA0XjBnkLA@mail.gmail.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net><8695009A81378
	E48879980039EEDAD2801364555EE@MAIL1.polartel.local><968C470DAC25FB419E01599
	52F28F0C06A75D95B@MEM0200CP3XF04.ds.irsnet.gov>
	<5B9E90747FA2974D91A54FCFA1B8AD120152926A3E@ENI-MAIL.eclipse-networks.com>
	<CACAaNxhd9CRV5gRB=qSKzq4ZYTz1GJu2dvuyisbqFA0XjBnkLA@mail.gmail.com>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120152927077@ENI-MAIL.eclipse-networks.com>

We are a tiny org with a tiny network in relation to say a fortune 1000 company.  We should never be approved for a /8 or a /16 or some resource that is way larger than we are.  

We should however, be approved for resources that match our size.  I think we are the ones who should determine if we need resources and not some arbitrary policy that ARIN tries to comply with.  ARINs job should only be to get us resources that matches our size and record it in the public database.  That is ARINs Mission.  


Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?


-----Original Message-----
From: McTim [mailto:dogwallah at gmail.com] 
Sent: Friday, April 04, 2014 5:13 PM
To: Steven Ryerse
Cc: Morizot Timothy S; David Huberman; arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

On Fri, Apr 4, 2014 at 2:00 PM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:
> If an org with no resources applies they should at least be able to get the minimum which has been set by this community which I think is currently at a /22.  Always!
>
> If an org wants larger than a /22 they need to be able to demonstrate in a reasonable way that they are a larger org with a network size that justifies a larger allocation.


Which is what is meant by "needs based" allocation if I am not mistaken.

--
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A route indicates how we get there."  Jon Postel

From owen at delong.com  Fri Apr  4 18:15:16 2014
From: owen at delong.com (Owen DeLong)
Date: Fri, 4 Apr 2014 15:15:16 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <2364ac2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<7AD26173D4094238B51D28EE6DE8A020@gmail.com>
	<04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
	<2364ac2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>
Message-ID: <5223E8F2-2E27-42DE-ABF3-EC7CF696A7E0@delong.com>


On Apr 4, 2014, at 7:31 AM, David Huberman <David.Huberman at microsoft.com> wrote:

> ARIN is a registry, not a regulator.  The more you guys want to
> build in rules that are anti-competitive and blind to the market
> reality, the more inaccurate Whois gets.

Operating a registry in a manner that is fair to all means that there need to be rules by which the registry is operated.

What you are calling anti-competitive rules are what I perceive as rules which prevent abuse of one class of users by another class of users of the registry.

> Upon v4 exhaustion, we should remove needs basis from
> transfers, remove the RSA text that makes the signer disclaim
> property rights, and motivate registrants to keep Whois accurate
> so that network operators can get good information about their
> traffic.

That is one opinion. I don?t share it, and neither do many other people.

You?ve offered nothing to show that removing those rules would motivate registrants to keep whois accurate.

There?s certainly been plenty of speculation that the current rules offer disincentives for doing so, and I?m even willing to accept that to a limited extent, that may be true. However, that?s not the same as showing that removing the rules would provide any incentive in the opposite direction.

Owen

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

From owen at delong.com  Fri Apr  4 18:34:22 2014
From: owen at delong.com (Owen DeLong)
Date: Fri, 4 Apr 2014 15:34:22 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <7bffb818d7724352b455eb414c43a673@BY2PR03MB394.namprd03.prod.outlook.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<7AD26173D4094238B51D28EE6DE8A020@gmail.com>
	<04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
	<2364ac2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>,
	<968C470DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov>
	<d315c6acaaac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com>
	<968C470DAC25FB419E0159952F28F0C06A75D85F@MEM0200CP3XF04.ds.irsnet.gov>
	<7bffb818d7724352b455eb414c43a673@BY2PR03MB394.namprd03.prod.outlook.com>
Message-ID: <CBC5D4D5-FF0C-4B66-8B60-395667AE194C@delong.com>

I find this very interesting considering that both Stephen and I wrote NRPM 12 as an effort to prevent ARIN from over-reaching on enforcement and to provide reassurance to the community that ARIN was focused on providing appropriate protections of community resources and not merely bureaucracy for the sake of bureaucracy.

I do not believe that the existing provisions in NRPM 4 or NRPM 6 for the prevention of fraud and/or gaming of the system are unnecessary or obviated by what is contained in section 12. Indeed, in order to function at all, section 12 depends on those policies to provide guidance as to how and when the enforcement mechanisms defined in section 12 are to be used.

Owen

On Apr 4, 2014, at 9:57 AM, David Huberman <David.Huberman at microsoft.com> wrote:

> In my message you are replying to, I accidentally forgot to address the hijacking issue.  (Last message from me on list today, I promise!)
> 
> I think Owen DeLong and Stephen Sprunk did a really good job addressing the whole hijacking and scamming problem when they authored NRPM section 12.  Between ARIN's legal protections in the RSA and as a business incorporated in, and operating in, the United States, and the policy levers that NRPM 12 give, I think that whole issue is well covered by policy.   In general, I do not agree with section 4, 6, or 6 policy that tries to account for scammers.  We should make policy for the 99%, not the 1%.  Let ARIN as a business, and ARIN as an enforcer of NRPM 12, deal with that -- and report back to us any deficiencies in tools.
> 
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Morizot Timothy S
> Sent: Friday, April 4, 2014 8:47 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
> 
>> -----Original Message-----
>> From: David Huberman [mailto:David.Huberman at microsoft.com]
>> Sent: Friday, April 04, 2014 10:22 AM
>> 
>> With an exhausted IPv4 pool, there are no "pool limitations at the 
>> time of allocation" as there are no allocations.  ARIN's role in IPv4 
>> is primarily the third goal above: registry accuracy.
>> 
>> That's why I advocate removing needs-basis from transfers in a post- 
>> exhaustion world.  There's no pool to manage[1], so the only OFFICIAL 
>> mandate ARIN has from the network operator community is to run an 
>> accurate registry.
> 
> I've actually been consistently in favor of IPv4 policies over the past couple of years that seemed likely to exhaust the IPv4 free pool sooner rather than later, so I have no real objection to altering the existing rules. I'm not convinced that eliminating needs basis in a post-exhaustion world would lead to fairer utilization or more competitiveness, but I would probably favor such a change since it would likely make IPv4 less palatable more quickly. (Of course, I believe the global inter-rir policy has a needs basis aspect so I think removing all needs basis from transfers would mean ARIN could no longer do inter-rir transfers, but that's a separate issue.)
> 
> They still have to protect against hijacking, which is a process that requires active regulation, even without needs basis for IPv4 transfers.
> 
> And, of course, there will be a need for at least some sort of needs basis on the IPv6 side going forward.
> 
> So I'm not necessarily againt simplifying policy in rational ways or to achieve clearly expressed aims. I don't think there's very much that's going to convince legacy holders who aren't already actively engaged to improve their registry information, though. That part of the IPv4 registry is and will almost certainly remain a swamp. I think it's more productive to focus on an accurate IPv6 registry and move on.
> 
> 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.



From owen at delong.com  Fri Apr  4 18:44:11 2014
From: owen at delong.com (Owen DeLong)
Date: Fri, 4 Apr 2014 15:44:11 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120152926A3E@ENI-MAIL.eclipse-networks.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net><7AD26173D4094
	238B51D28EE6DE8A020@gmail.com><04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.c
	om>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local><2364a
	c2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>,
	<968C47
	0DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov><d315c6acaa
	ac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com><5B9E90747FA2
	974D91A54FCFA1B8AD1201529268D3@ENI-MAIL.eclipse-networks.com>
	<968C470DAC25FB419E0159952F28F0C06A75D95B@MEM0200CP3XF04.ds.irsnet.gov>
	<5B9E90747FA2974D91A54FCFA1B8AD120152926A3E@ENI-MAIL.eclipse-networks.com>
Message-ID: <0623FEA5-2D55-442B-9FFD-CC9613DC1C5E@delong.com>


On Apr 4, 2014, at 11:00 AM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:

> If an org with no resources applies they should at least be able to get the minimum which has been set by this community which I think is currently at a /22.  Always!

Depends? End-user /24, ISP multi-homed /22, ISP non-multi-homed /20 IIRC.

> If an org wants larger than a /22 they need to be able to demonstrate in a reasonable way that they are a larger org with a network size that justifies a larger allocation.  The first way is what allocation do they already have?  If they have say a /19  or equivalent maybe they can demonstrate they need say another /19 by furnishing to ARIN maybe their financials and the investment they have actually made to justify another /19 or whatever.  (I'm just using the /19 as an example.)

Why would financials or investment have any direct correlation with network size in any organization, let alone all organizations?

> Organizations supply financials to Banks all the time and this and supplying network info can be a similar process.  If an org can prove they just spent 50 million on a new data center then that should be justification to get an allocation of a size to run that size data center. 

How do you judge the size of a datacenter in IP resource requirements based on the amount of money spent on the datacenter? A relatively small datacenter with a lot of virtual hosts on a small number of machines might need a whole lot more IP addressing than a vastly more expensive datacenter housing a small number of supercomputers and their ancillary systems, costing 100s or even 1000s of times more money.

> So if we want the current minimum we should just apply and it should be allocated, and as long as we keep paying our fees to ARIN it is ours to use.  If we stop paying that block goes back into the pool that ARIN has to allocate.  

So if I stand up a bunch of shell companies, they should each be able to get a /22 and I should be able to repeat that exercise until I run out of money or desire for address space? An interesting theory.

> If we want a /19 or a /16 then we need to satisfy ARIN that we are an org of that size and have a network that justifies a /19 or a /16.  And maybe prove the actual expenditures. 
> 
> And if we want a /9, regardless of what we have now, we're gonna really have to provide solid info that justifies the size of our org and the size of our network justifies a /9.  

These two statements do not seem to differ from current practice, so I?m not sure what sort of change, if any, you are advocating for in this case.

> This is not rocket science. It would however require the input of the many knowledgeable members of this community to help determine what is require at each level.  I think this community could handle that just fine!

I think we have? How do you think the existing NRPM 4 and NRPM 6 (and the rest of NRPM for that matter) have come about?

Owen



From owen at delong.com  Fri Apr  4 18:50:17 2014
From: owen at delong.com (Owen DeLong)
Date: Fri, 4 Apr 2014 15:50:17 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <15fd165f2e584b09b54cab728f31b6e1@EX13-MBX-13.ad.syr.edu>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net>
	<7AD26173D4094238B51D28EE6DE8A020@gmail.com>
	<04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.com>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local>
	<2364ac2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>,
	<968C470DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov>
	<d315c6acaaac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com>
	<15fd165f2e584b09b54cab728f31b6e1@EX13-MBX-13.ad.syr.edu>
Message-ID: <BED1EFF2-6A00-4138-A1B8-118D590C5D1B@delong.com>


On Apr 4, 2014, at 1:25 PM, Milton L Mueller <mueller at syr.edu> wrote:

> 
> -----Original Message-----
> 
>> With an exhausted IPv4 pool, there are no "pool limitations at the 
>> time of allocation" as there are no allocations.  ARIN's role in IPv4 is 
>> primarily the third goal above: registry accuracy.
>> 
>> That's why I advocate removing needs-basis from transfers in a post- 
>> exhaustion world.  There's no pool to manage[1], so the only OFFICIAL 
>> mandate ARIN has from the network operator community is to run 
>> an accurate registry.
> 
> I agree with David. 
> Needs assessment was designed to be a rationing mechanism that filled in the gap left by the absence of a price system for Ipv4 addresses. 

Continuing to make this assertion doesn?t make it any more true than it was the first time you uttered it.

Needs assessment existed long before any form of ?rationing? of IP space was ever perceived as necessary. The nature and scrutiny of the process have evolved over time, but needs assessment has existed since the definition of network classes.

> Because ARIN hands out free pool number blocks for free, the absence of needs assessment would provoke a first come first served land rush and subsequent tragedy of the commons. Once you reach exhaust, however, no one gets number blocks for free, everyone must pay a market price for them. The rationale for needs assessment is totally gone. Restricting transfers in this environment _will_ inevitably produce inaccuracies in the registry data. 

Can you back this assertion up with facts to support it? I think it is entirely possible that there will be some unpaid transfer arrangements after free pool runout for a variety of reasons. Yes, market rate transactions will likely be the predominant mechanism by which addresses are moved from one organization to another, but I haven?t seen anything to suggest that they will be the exclusive mechanism. Especially when you consider that there are various ways to define exhaustion and most definitions have more to do with when the RIR receives a request it cannot satisfy than when the RIR is no longer able to satisfy ANY request(s).

Further, nobody has yet offered any evidence that such restrictions will inevitably produce any greater level of registry inaccuracy than removing them. In fact, I think there is at least as strong a likelihood that removing such restrictions would eliminate almost all incentives to update registry data at any time.

Owen



From owen at delong.com  Fri Apr  4 18:58:35 2014
From: owen at delong.com (Owen DeLong)
Date: Fri, 4 Apr 2014 15:58:35 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120152927077@ENI-MAIL.eclipse-networks.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net><8695009A81378
	E48879980039EEDAD2801364555EE@MAIL1.polartel.local><968C470DAC25FB419E01599
	52F28F0C06A75D95B@MEM0200CP3XF04.ds.irsnet.gov>
	<5B9E90747FA2974D91A54FCFA1B8AD120152926A3E@ENI-MAIL.eclipse-networks.com>
	<CACAaNxhd9CRV5gRB=qSKzq4ZYTz1GJu2dvuyisbqFA0XjBnkLA@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD120152927077@ENI-MAIL.eclipse-networks.com>
Message-ID: <AA45DE61-07AF-4A31-9594-F908302806E5@delong.com>

I do find it interesting, Steven, that with all you have complained about ?arbitrary policy? on this list, you have yet to submit a single proposal to change that policy.

Given that the policy was developed through community consensus of those that chose to participate here on this very list and at ARIN public policy meetings (in person or remotely), how can you call it ?arbitrary??

If you?d like help writing a proposal to get the policy you want, I am happy to help you. While I don?t agree with you, I still consider it part of my job as an elected member of the AC* to assist you in any way that I can to get your ideas for improving ARIN policy in front of the community.

Owen

* I say this only as my own opinion. While I express my belief about my job as an AC member, I am not expressing any official opinion of the ARIN AC or on behalf of ARIN or the AC in any way. I do not know to what extent the AC as a body or my fellow AC members would agree with my statement.

On Apr 4, 2014, at 2:27 PM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:

> We are a tiny org with a tiny network in relation to say a fortune 1000 company.  We should never be approved for a /8 or a /16 or some resource that is way larger than we are.  
> 
> We should however, be approved for resources that match our size.  I think we are the ones who should determine if we need resources and not some arbitrary policy that ARIN tries to comply with.  ARINs job should only be to get us resources that matches our size and record it in the public database.  That is ARINs Mission.  
> 
> 
> Steven Ryerse
> President
> 100 Ashford Center North, Suite 110, Atlanta, GA  30338
> 770.656.1460 - Cell
> 770.399.9099- Office
> 
> ? Eclipse Networks, Inc.
>                     Conquering Complex Networks?
> 
> 
> -----Original Message-----
> From: McTim [mailto:dogwallah at gmail.com] 
> Sent: Friday, April 04, 2014 5:13 PM
> To: Steven Ryerse
> Cc: Morizot Timothy S; David Huberman; arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
> 
> On Fri, Apr 4, 2014 at 2:00 PM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:
>> If an org with no resources applies they should at least be able to get the minimum which has been set by this community which I think is currently at a /22.  Always!
>> 
>> If an org wants larger than a /22 they need to be able to demonstrate in a reasonable way that they are a larger org with a network size that justifies a larger allocation.
> 
> 
> Which is what is meant by "needs based" allocation if I am not mistaken.
> 
> --
> Cheers,
> 
> McTim
> "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."  Jon Postel
> _______________________________________________
> 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.



From michael at linuxmagic.com  Fri Apr  4 19:06:35 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Fri, 04 Apr 2014 16:06:35 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <0623FEA5-2D55-442B-9FFD-CC9613DC1C5E@delong.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net><7AD26173D4094	238B51D28EE6DE8A020@gmail.com><04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.c	om>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local><2364a	c2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>,
	<968C47	0DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov><d315c6acaa	ac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com><5B9E90747FA2	974D91A54FCFA1B8AD1201529268D3@ENI-MAIL.eclipse-networks.com>	<968C470DAC25FB419E0159952F28F0C06A75D95B@MEM0200CP3XF04.ds.irsnet.gov>	<5B9E90747FA2974D91A54FCFA1B8AD120152926A3E@ENI-MAIL.eclipse-networks.com>
	<0623FEA5-2D55-442B-9FFD-CC9613DC1C5E@delong.com>
Message-ID: <533F3AFB.3070105@linuxmagic.com>

On 14-04-04 03:44 PM, Owen DeLong wrote:
>
> On Apr 4, 2014, at 11:00 AM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:
>
>> If an org with no resources applies they should at least be able to get the minimum which has been set by this community which I think is currently at a /22.  Always!
>
> Depends? End-user /24, ISP multi-homed /22, ISP non-multi-homed /20 IIRC.

Personally, I still think the above is limiting, eg the small operator 
who is not multi-homed, and only really needs a /22

>
>> If an org wants larger than a /22 they need to be able to demonstrate in a reasonable way that they are a larger org with a network size that justifies a larger allocation.  The first way is what allocation do they already have?  If they have say a /19  or equivalent maybe they can demonstrate they need say another /19 by furnishing to ARIN maybe their financials and the investment they have actually made to justify another /19 or whatever.  (I'm just using the /19 as an example.)

ah.. reasonable way... that is the rub.. I see hosting companies with 
throw away domains occupying the whole /19 using it as justification for 
getting another /19 of fresh IP(s) they can rent out.. not to disrupt 
the thread.. ARIN has a tough time.. what is a legitimate use to one 
person is maybe not to another.. I am never sure if IP(s) used to 
generate outbound traffic is a good justification, there are other ways 
to share an IP Address for outbound.. I think a priority should be 
somehow worded in that 'inbound' destinations take priority over 
outbound sources.. eg, you have to advertise a public service that it 
accessible.. it should take precedence over say someone that uses their 
IP(s) to generate bulk outbound traffic ..



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From hannigan at gmail.com  Fri Apr  4 20:12:46 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 4 Apr 2014 20:12:46 -0400
Subject: [arin-ppml]  Update: 2014-1 Out of Region Use
In-Reply-To: <CA+Ld8r8irr5GkBnz-WWaiESRSjD5RjDXY1=JtqzOz+EVYf2j1A@mail.gmail.com>
References: <5335AFF6.2060507@umn.edu>
	<87f821b26ba1410bb718278161a9c529@DM2PR03MB398.namprd03.prod.outlook.com>
	<CA+Ld8r8irr5GkBnz-WWaiESRSjD5RjDXY1=JtqzOz+EVYf2j1A@mail.gmail.com>
Message-ID: <CAMDXq5NDbG3zanfDAZfdvy-BAsu+n9aY9thjC5sKzC0GL3vppg@mail.gmail.com>

Same, +1.

Which isn't Section 11 a better place to address this?

Best,

-M<


On Fri, Mar 28, 2014 at 1:55 PM, David Huberman <
David.Huberman at microsoft.com <javascript:;>> wrote:
> Support in principle, strongly opposed as written.
>
> ARIN is a registry, not a regulator.  Networks with global reach should
not have regulatory rules placed on them by ARIN whose job is primarily to
record number assignments, not make rules which affect network topology.
Thus I support the idea that numbers should not be bound to arbitrary
political boundaries.
>
> I oppose this draft as written, however, because it adds hundreds of
words to NRPM where only a few are needed to address the stated goal.  The
problem statement indicates: " The next logical option is to discuss a
proposal that clearly permits out of region use without limits".  Well ok.
 If you wanted to do that explicitly in policy, how about:
>
>         Section 1.x -  ARIN-issued number resources may be used on
equipment located anywhere.
>
> All the rest of the text that I see in this draft come down to, "if you
have resources in other RIRs, we'll audit them to ensure you aren't double
dipping." Policy already allows that:
>
>         "ISPs must have efficiently utilized all previous allocations and
at least 80% of their most recent allocation
>          in order to receive additional space."
>
>         " In order to justify an additional assignment, end-users must
have efficiently utilized at least 80% of all
>         previous assignments, and must provide ARIN with utilization
details"
>
> We need to simplify NRPM and start peeling back a lot of this
over-regulatory policy.  To do so, let's write clearer and more concise
policy proposals, please.
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
>
> From: arin-ppml-bounces at arin.net <javascript:;> [mailto:
arin-ppml-bounces at arin.net <javascript:;>] On Behalf Of David Farmer
> Sent: Friday, March 28, 2014 10:23 AM
> To: ARIN PPML
> Subject: [arin-ppml] Update: 2014-1 Out of Region Use
>
> Based on the discussion at the PPC in Atlanta (link below), the following
changes are proposed.
>
>
https://www.arin.net/participate/meetings/reports/ppc_nanog60/webcast/2014-1.mov
>
> There is a summary of the changes and a red-lined version of the policy
text with new and deleted text highlighted following the complete Draft
Policy.
>
> ----
>
> Draft Policy ARIN-2014-1
> Out of Region Use
>
> Date: 28 March 2014
>
> Problem statement:
>
> Current policy neither clearly forbids nor clearly permits out or region
use of ARIN registered resources. This has created confusion and
controversy within the ARIN community for some time. Earlier work on this
issue has explored several options to restrict or otherwise limit out of
region use. None of these options have gained consensus within the
community. The next logical option is to discuss a proposal that clearly
permits out of region use without limits, beyond those already existing in
policy.
>
> Permitting out of region use, however, poses issues that have to be
addressed by policy and adjustments to operational practice. Out of region
use needs a clear definition and any operational practices based on that
definition must not be unnecessarily burdensome. It is significantly more
difficult and costly for ARIN Staff to independently verify the
justification and utilization of resources that are reassigned or otherwise
used outside of the ARIN service region. There needs to be recognition of
this difference in policy and associated operational practices, especially
the cost differential when there is more than an incidental amount of out
of region use.
>
> Policy statement:
>
> Create new Section X;
>
> X. Out of Region Use
>
> ARIN registered resources may be used outside the ARIN service region and
such use is valid justification for new or additional resources. Resources
are considered to be used outside the region if the user or customer
service address or the technical infrastructure address, such as the point
of presence (POP), data center, or other similar location, are outside the
ARIN service region.
>
> There is a general presumption that requesting resources from ARIN for
use within another RIR's service region duplicates any resources held by
the organization with that other RIR.  Therefore, the organization should,
not hold any resources with the other RIR, or demonstrate that all such
resources held are utilized based on ARIN policy requirements, or provide
an operational justification clarifying how the resources from ARIN will
not duplicate any underutilized resources held with the other RIR.
>
> Only the utilization rate of ARIN registered resources or immediate need
may be use to determine a valid request size beyond the applicable minimum
allocation size.  The utilization rate of resources received from another
RIR is not applicable in determining a valid request size.
>
> X.1 Verification of Out of Region Use
>
> The utilization of all ARIN registered resources must be verified when
evaluating a request for additional resources or during a resource review,
including any resources used outside the ARIN service region. All ARIN
registered resources used outside the region must be verified to no less
than an equivalent standard as resources used within the ARIN region. To
this end ARIN, in its sole discretion, may engage independent external
entities to assist it in the verification of information related to any
resources used outside the region.
>
> X.2 Reporting Resources Held with other RIRs
>
> Except to the extent that incidental use, multi-instance use, or the
critical infrastructure criteria described below apply, when out of region
need is used to justify a request for resources from ARIN; The requesting
organization will also report to ARIN the utilization status, based on
applicable ARIN policy, of all resources it holds with the RIRs who's
service regions the need justifying a request to ARIN is within, and any
additional supporting documentation requested by ARIN regarding these
reported resource.
>
> X.3 Incidental Use
>
> Out of region use of ARIN registered resources by an organization that
totals less than an equivalent of a /20 of IPv4, a /36 of IPv6, and two (2)
ASNs within each of the other RIR's service regions are considered
incidental use and as such are accounted for as if used within the ARIN
service region.
>
> X.4 Multi-Instance Use
>
> Any resources used simultaneously in multiple locations, such as an
anycast prefix or ASN, are considered as used within the ARIN service
region, provided at least one instance is located within the region,
regardless of how many other instances are located outside the region.
>
> X.5 Critical Infrastructure
>
> Resources justified through ARIN critical infrastructure policies are
accounted for as if used within the ARIN service region, regardless of
their actual location of use.
>
> Comments:
> a. Timetable for implementation: Immediate
>
> b. Anything else
>
> Current policy is ambiguous on the issue of out of region use of ARIN
registered resources. The only guidance on the issue in current policy is
in Section 2.2, that defines the term RIR; "... The primary role of RIRs is
to manage and distribute public Internet address space within their
respective regions." Some in the community believe this means out of region
use should be at least limited or restricted while others believe this is
only intended to focus efforts within the region and not define where
resources may be used.
>
> Several other policy proposals have explored restricting or otherwise
limiting out of region use. None of these proposals gained consensus within
the ARIN community. During the latest of these proposals, ARIN-2013-6,
several standards were explored, a majority of use within region, a
plurality of use within region, and some discussion of a minimum of 20
percent use within region. It was felt that each of these standards would
interfered, to one extent or another, with the legitimate operations of
multi- or trans-regional networks.
>
> Section 2.2 tells us, the primary purpose of the RIRs are to manage and
distribute resources within their regions. None the less, there have always
been networks that don't neatly fit within the regions created by the RIR
system. These legitimate trans-regional networks are operated by
international businesses or global service providers, many of which are
based within the ARIN region. Prior to IPv4 run-out, many of these
trans-regional networks requested resources from ARIN for use both inside
or outside the region, as long as the requests were justified by need.
>
> As a result of IPv4 run-out, many in the community want to restrict out
of region use to prevent ARIN resources from going to networks without a
real technical presence in the ARIN region. However, any attempt to limit
or restrict such out of region use inevitably will affect these legitimate
trans-regional networks. Further, even the most restrictive regional use
requirements will not significantly prolong the availability of IPv4
resources within the ARIN region. Therefore, attempting to restrict or
limit out of region use of resources, even if it were for IPv4 only, is
ineffective, inefficient, and overly burdensome to important elements of
the global Internet.
>
> The major concept behind this proposal is to allow out of region use
without any limits, other than those already in policy, but bring an
economic and reporting factors to play on the issue. It requires ARIN to
verify out of region use of ARIN registered resources to no less than an
equivalent standard as in region use, and enables ARIN to engage external
entities to assist in this verification. It is expected ARIN will have
agreements with all such external entities to ensure the confidentiality of
all supporting documentation is preserved.
>
> ARIN engaging external entities to assist in verification of out of
region use is mostly an ARIN business issue, and not primarily a policy
issue. However, today there is a general assumption that such verification
for in region use is done almost exclusively in house at ARIN. Making this
issue clear in policy follows a principle of least surprise, as the use of
such external entities is likely to be frequently necessary to verify out
of region use, especially in parts of the world where English is not the
primary language. Or put another way, use of an external entity when
verifying out of region use is more likely to be the rule rather than an
exception.
>
> When resources are requested for out of region use an organization also
needs to report the utilization status of all resources it holds with the
RIRs for the regions that the requested need is within.  This is to ensure
there are not underutilized resources held with another RIR that would
contradict the justified need for resources from ARIN.
>
> There are additional expenses and complexity involved in verifying out of
region use, as a result of language and logistical barriers that the
regionality of the RIR system was originally conceived to mitigate.
> In addition, evaluating the reported information about resources held
with other RIRs, needed to ensure ARIN resources are not duplicating
resources held with outer RIRs, increase staff's burden related to out of
region use. Furthermore, section 2.2 is clear that providing resources for
out of region use is, at best, only a secondary role for ARIN. As a result,
out of region use should not significantly burden the primary role of
providing resources for use within the region. These factors justify a
recommendation to the Board of Trusties to create a separate fee structure
for out of region use, creating the aforementioned economic factor.
>
> This economic factor and the recommendation for a separate fee structure,
are again mostly ARIN business issues, and not part of policy in general.
However, this is one of those instances where policies and fees are
intertwined.
>
> It seems reasonable that this economic factor should be applied only to
those that make substantial use of ARIN registered resources outside the
region, and not to those that primarily use resources within the region.
This proposal defines incidental out of region use, to ensure that trivial,
insignificant or otherwise incidental use are exempt from the discussed
economic factor, the reporting of resources help with other RIRs as well,
and are accounted for as if used within the region.
>
> Some amount of out of region use should be considered normal even for a
network primarily based within the ARIN region. For example, numbering a
global backbone that provides global access necessary for in region
customers. Also, the other RIRs have minimum requirements to justify an
initial allocation or assignment, similar to ARIN. These and other examples
and issues, justify allowing some minimal amount of out of region use to be
accounted for as if it were in region use. The currently proposed policy
statement, X.3, defines incidental use in terms of an absolute thresholds
for each type of resource.
>
> Another option would be a percentage based threshold, say 20%. However, a
percentage based threshold has the disadvantage that even a minimal change
in usage can cause the ratio between in region and out of region use to
change, potentially causing an oscillation around this threshold. This
creates significant uncertainty for organizations as to if the discussed
economic factor will apply to them, or not. Where as once an absolute
threshold has been crossed by a significant amount, it is highly unlikely
that any additional changes in usage will cause an oscillation around the
threshold, providing much more certainty for most organizations.
>
> Additionally, the proposal deals with a couple special cases in X.4 and
X.5. Due to the relatively small resource impact and high importance to
overall Internet stability; resources for critical infrastructure are
accounted for as if used within the region. Anycast prefixes, and other
resources used simultaneously in multiple locations, are considered as used
outside the region only when they are exclusively used outside the region.
Or put another way, as long as at least one instance is located within the
region, they are considered used within the region, regardless of how many
other instances are located outside the region. Both of these special cases
have an overall positive impact on the Internet and should not be
discouraged in anyway by this policy, lumping them in with general out of
region use could be a disservice to the Internet and unnecessarily
burdensome.
>
> The intent of allowing an operational justification to clarify how
resources received from ARIN will not duplicate any underutilized resources
held with another RIR is to account for situations like; It may be
necessary to use resources from another RIR to meet legal or regulatory
requirements, or prevailing operational expectations, in some economies
around the world. In such cases it is justified to also receive minimal
resources from another RIR for use only in those economies. And using
resources received from ARIN for the rest of a global network.
>
> In summary, this proposal ensures that global organizations or global
service providers base within the ARIN region may receive resources to
operate their global network solely from ARIN, if they wish to do so. As
long as the utilization of the out of region resources are verified to no
less than an equivalent standard as in region resources and any additional
reporting requirements are also meet. This is particularly important for
IPv6; requiring organizations get IPv6 resources from multiple RIRs, or
even making it appear that they should, will result in additional unique
non-aggregatable prefixes within the IPv6 route table, rather than
minimizing them, which one of the policy objectives for IPv6.
>
> Finally, a separate but somewhat related issue; regardless of where ARIN
registered resources are used, inside or outside of the ARIN service
region, organizations must first qualify to receive resources from ARIN.
ARIN's current operational practice is that an organization must be formed
within the ARIN service region in order to qualify to receive any resources
from ARIN. The issue of who should be eligible to receive resources was
commingled with out of region use in ARIN-2013-6. It was felt these issues
should be considered separately. Therefore, the issue of who should be
eligible to receive resources is purposefully not dealt with by this
proposal, and if any changes are necessary there should be separate policy
proposals to deal with this issue independently.
>
> ----
>
> Summary of Changes;
>
> - Clarified out of region use is valid justification for both new or
additional resources.
>
> - Eliminated "user or customer billing address" from definition for out
of region use, and change the items left to sentence from, instead of list
form.
>
> - Added that there is a general presumption that requesting resources
from ARIN for use within another RIR's service region duplicates any
resources held by the organization with that other RIR.
>
> - Made it clear that only the utilization rate of ARIN resources or
immediate need are used to determine the valid request size.
>
> - New sections X.2 "Reporting Resources Held with other RIRs," this new
section is intended to have organizations report the utilization of their
resources, based on ARIN Policy, for the other RIRs where they are
requesting ARIN resources for.  Except to the extent incidental use,
multi-instance use, or critical infrastructure clauses apply.
>
> - Changed incidental use to be on a per other RIR region basis to
simplify the determination of if the Reporting Resources Held with other
RIRs applies.
>
> - Changed multi-instance use to use "at least one instance is located
within the region" language.
>
> - Updated the comments section to account for the above changes.
>
> ----
> Here is an annotated version of the policy text
>
> Deleted Text
> New Text
> Retained Text
> X. Out of Region Use
>
> ARIN registered resources may be used outside the ARIN service region and
such use is valid justification for new or additional resources. Resources
are considered to be used outside the region if any of the following are
located outside the region. A. The user or customer billing address B. the
user or customer service address or C. the technical infrastructure
address, such as the point of presence (POP), data center, or other similar
location, are outside the ARIN service region.
>
> There is a general presumption that requesting resources from ARIN for
use within another RIR's service region duplicates any resources held by
the organization with that other RIR.  Therefore, the organization should,
not hold any resources with the other RIR, or demonstrate that all such
resources held are utilized based on ARIN policy requirements, or provide
an operational justification clarifying how the resources from ARIN will
not duplicate any underutilized resources held with the other RIR.
>
> Only the utilization rate of ARIN registered resources or immediate need
may be use to determine a valid request size beyond the applicable minimum
allocation size.  The utilization rate of resources received from another
RIR is not applicable in determining a valid request size.
>
> X.1 Verification of Out of Region Use
>
> The utilization of all ARIN registered resources must be verified when
evaluating a request for additional resources or during a resource review,
including any resources used outside the ARIN service region. All ARIN
registered resources used outside the region must be verified to no less
than an equivalent standard as resources used within the ARIN region. To
this end ARIN, in its sole discretion, may engage independent external
entities to assist it in the verification of information related to any
resources used outside the region.
>
> X.2 Reporting Resources Held with other RIRs
>
> Except to the extent that incidental use, multi-instance use, or the
critical infrastructure criteria described below apply, when out of region
need is used to justify a request for resources from ARIN; The requesting
organization will also report to ARIN the utilization status, based on
applicable ARIN policy, of all resources it holds with the RIRs who's
service regions the need justifying a request to ARIN is within, and any
additional supporting documentation requested by ARIN regarding these
reported resource.
>
> X.23 Incidental Use
>
> Out of region use of ARIN registered resources by an organization that
totals less than an equivalent of a /20 of IPv4, a /36 of IPv6, and two (2)
10 ASNs within each of the other RIR's service regions are considered
incidental use and as such are accounted for as if used within the ARIN
service region.
>
> X.4 Multi-Instance Use
>
> Any resources used simultaneously in multiple locations, such as an
anycast prefix or ASN, are accounted for as used outside the region, only
if they are exclusively used outside the region.considered as used within
the ARIN service region, provided at least one instance is located within
the region, regardless of how many other instances are located outside the
region.
>
> X.35 Critical Infrastructure
>
> Resources justified through ARIN critical infrastructure policies are
accounted for as if used within the ARIN service region, regardless of
their actual location of use.
>
>
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu <javascript:;>
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140404/2f266624/attachment.htm>

From hannigan at gmail.com  Fri Apr  4 20:14:00 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 4 Apr 2014 20:14:00 -0400
Subject: [arin-ppml] Update: 2014-1 Out of Region Use
In-Reply-To: <CAMDXq5NDbG3zanfDAZfdvy-BAsu+n9aY9thjC5sKzC0GL3vppg@mail.gmail.com>
References: <5335AFF6.2060507@umn.edu>
	<87f821b26ba1410bb718278161a9c529@DM2PR03MB398.namprd03.prod.outlook.com>
	<CA+Ld8r8irr5GkBnz-WWaiESRSjD5RjDXY1=JtqzOz+EVYf2j1A@mail.gmail.com>
	<CAMDXq5NDbG3zanfDAZfdvy-BAsu+n9aY9thjC5sKzC0GL3vppg@mail.gmail.com>
Message-ID: <CAMDXq5NLusAn3N_B7VusROyWT1hyFQfv6wdbC6KpbdVh66HuVw@mail.gmail.com>

Oops, buffer overflow. Wrong thread. Simply, +1 for this thread.



On Friday, April 4, 2014, Martin Hannigan <hannigan at gmail.com> wrote:

>
> Same, +1.
>
> Which isn't Section 11 a better place to address this?
>
> Best,
>
> -M<
>
>
> On Fri, Mar 28, 2014 at 1:55 PM, David Huberman <
> David.Huberman at microsoft.com> wrote:
> > Support in principle, strongly opposed as written.
> >
> > ARIN is a registry, not a regulator.  Networks with global reach should
> not have regulatory rules placed on them by ARIN whose job is primarily to
> record number assignments, not make rules which affect network topology.
> Thus I support the idea that numbers should not be bound to arbitrary
> political boundaries.
> >
> > I oppose this draft as written, however, because it adds hundreds of
> words to NRPM where only a few are needed to address the stated goal.  The
> problem statement indicates: " The next logical option is to discuss a
> proposal that clearly permits out of region use without limits".  Well ok.
>  If you wanted to do that explicitly in policy, how about:
> >
> >         Section 1.x -  ARIN-issued number resources may be used on
> equipment located anywhere.
> >
> > All the rest of the text that I see in this draft come down to, "if you
> have resources in other RIRs, we'll audit them to ensure you aren't double
> dipping." Policy already allows that:
> >
> >         "ISPs must have efficiently utilized all previous allocations
> and at least 80% of their most recent allocation
> >          in order to receive additional space."
> >
> >         " In order to justify an additional assignment, end-users must
> have efficiently utilized at least 80% of all
> >         previous assignments, and must provide ARIN with utilization
> details"
> >
> > We need to simplify NRPM and start peeling back a lot of this
> over-regulatory policy.  To do so, let's write clearer and more concise
> policy proposals, please.
> >
> > David R Huberman
> > Microsoft Corporation
> > Senior IT/OPS Program Manager (GFS)
> >
> >
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Farmer
> > Sent: Friday, March 28, 2014 10:23 AM
> > To: ARIN PPML
> > Subject: [arin-ppml] Update: 2014-1 Out of Region Use
> >
> > Based on the discussion at the PPC in Atlanta (link below), the
> following changes are proposed.
> >
> >
> https://www.arin.net/participate/meetings/reports/ppc_nanog60/webcast/2014-1.mov
> >
> > There is a summary of the changes and a red-lined version of the policy
> text with new and deleted text highlighted following the complete Draft
> Policy.
> >
> > ----
> >
> > Draft Policy ARIN-2014-1
> > Out of Region Use
> >
> > Date: 28 March 2014
> >
> > Problem statement:
> >
> > Current policy neither clearly forbids nor clearly permits out or region
> use of ARIN registered resources. This has created confusion and
> controversy within the ARIN community for some time. Earlier work on this
> issue has explored several options to restrict or otherwise limit out of
> region use. None of these options have gained consensus within the
> community. The next logical option is to discuss a proposal that clearly
> permits out of region use without limits, beyond those already existing in
> policy.
> >
> > Permitting out of region use, however, poses issues that have to be
> addressed by policy and adjustments to operational practice. Out of region
> use needs a clear definition and any operational practices based on that
> definition must not be unnecessarily burdensome. It is significantly more
> difficult and costly for ARIN Staff to independently verify the
> justification and utilization of resources that are reassigned or otherwise
> used outside of the ARIN service region. There needs to be recognition of
> this difference in policy and associated operational practices, especially
> the cost differential when there is more than an incidental amount of out
> of region use.
> >
> > Policy statement:
> >
> > Create new Section X;
> >
> > X. Out of Region Use
> >
> > ARIN registered resources may be used outside the ARIN service region
> and such use is valid justification for new or additional resources.
> Resources are considered to be used outside the region if the user or
> customer service address or the technical infrastructure address, such as
> the point of presence (POP), data center, or other similar location, are
> outside the ARIN service region.
> >
> > There is a general presumption that requesting resources from ARIN for
> use within another RIR's service region duplicates any resources held by
> the organization with that other RIR.  Therefore, the organization should,
> not hold any resources with the other RIR, or demonstrate that all such
> resources held are utilized based on ARIN policy requirements, or provide
> an operational justification clarifying how the resources from ARIN will
> not duplicate any underutilize
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140404/c67f52aa/attachment.htm>

From rockymm8 at gmail.com  Fri Apr  4 20:32:19 2014
From: rockymm8 at gmail.com (Rocky)
Date: Sat, 5 Apr 2014 08:32:19 +0800
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 10
In-Reply-To: <E5423262-8639-4928-9568-81100FAC3666@gmail.com>
References: <mailman.1557.1396574716.28847.arin-ppml@arin.net>
	<BCF55E8E80244BB78F99AC5E58488E7C@gmail.com>
	<E5423262-8639-4928-9568-81100FAC3666@gmail.com>
Message-ID: <4364DF824EE34491BCA5232FA285BB75@gmail.com>

Scott,  

There are several cases under ARIN review process.  Let?s see how ARIN really applies its policy first and then comes my disclosure of  evidences to the community and let the community decides if ARIN does it right or wrong.  

Rocky




On Friday, April 4, 2014 at 1:29 PM, Scott Leibrand wrote:

>  
> On Apr 3, 2014, at 8:04 PM, Rocky <rockymm8 at gmail.com (mailto:rockymm8 at gmail.com)> wrote:
>  
> > Scott  
> >  
> > thanks for your explanation.   
> > 1. how can ARIN make sure this 8.2 transfer is not speculating about IPv4?
> >  
> >  
>  
>  
> If you can clarify what you mean by speculating in this particular case, we can discuss the various aspects of policy that may help.  Or, see below.  
>  
> > 2. if the entity no longer existent,  why not return the IPv4  after its dissolved?
>  
> That would be ideal, and has happened in the past. Now that the IPv4 free pool is nearing exhaustion, though, most successors to companies with IPv4 holdings would prefer to monetize them. The end result to the community (those of us not involved in the transaction) is the same: the addresses get back into use.  
>  
> >   or why not update the ARIN database in time after the M/A.
>  
> Again, that would've been ideal, but in many cases did not happen. Updating records takes work, so unless there's some incentive (like being able to transfer the resources under 8.3) it sometimes gets overlooked or not prioritized.  
> > What you are trying to say make me feel that ARIN policy is encouraging the  stockpile of IPv4? some People do it until the IPv4 becomes expensive and some people can benefit huge from its stockpile ( for past many years) by update its registration info via 8.2 transfer  to sell a great price after the next 8.3 transfer.
>  
> Generally, ARIN policy seeks to prevent that on the front end, by requiring justified need for allocations from the free pool. There is also policy in place to prevent "flipping" space after an allocation.  
> > the check of utilisation rate under 8.2 is just a formalism and considering the wording there conflicts with RSA, why not delete the utilisation rate requirement in the 8.2? or revise the RSA accordingly.
>  
> The original intent of this language was to encourage ARIN to work with the recipient of the 8.2 transfer to get all the addresses into use. Since the RSA now prevents reclamation, that should probably be removed from the policy, as should "aggregate". But the "ARIN will work with the resource holder(s) to return or transfer resources as needed" language would still be operative if we left it in place.  
>  
> -Scott
>  
> >  
> >  
> >  
> >  
> > On Friday, April 4, 2014 at 9:25 AM, arin-ppml-request at arin.net (mailto:arin-ppml-request at arin.net) wrote:
> > > Send ARIN-PPML mailing list submissions to
> > > arin-ppml at arin.net (mailto:arin-ppml at arin.net)
> > >  
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > or, via email, send a message with subject or body 'help' to
> > > arin-ppml-request at arin.net (mailto:arin-ppml-request at arin.net)
> > >  
> > > You can reach the person managing the list at
> > > arin-ppml-owner at arin.net (mailto:arin-ppml-owner at arin.net)
> > >  
> > > When replying, please edit your Subject line so it is more specific
> > > than "Re: Contents of ARIN-PPML digest..."
> > >  
> > >  
> > > Today's Topics:
> > >  
> > > 1. Re: ARIN-PPML Digest, Vol 106, Issue 8 (Scott Leibrand)
> > >  
> > >  
> > > ----------------------------------------------------------------------
> > >  
> > > Message: 1
> > > Date: Thu, 3 Apr 2014 18:25:06 -0700
> > > From: Scott Leibrand <scottleibrand at gmail.com (mailto:scottleibrand at gmail.com)>
> > > To: Rocky <rockymm8 at gmail.com (mailto:rockymm8 at gmail.com)>
> > > Cc: "arin-ppml at arin.net (mailto:arin-ppml at arin.net)" <arin-ppml at arin.net (mailto:arin-ppml at arin.net)>
> > > Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
> > > Message-ID: <04DC25C4-5352-4DC8-A114-EA1724DC88EE at gmail.com (mailto:04DC25C4-5352-4DC8-A114-EA1724DC88EE at gmail.com)>
> > > Content-Type: text/plain; charset="utf-8"
> > >  
> > > Rocky,
> > >  
> > > Many such 8.2 transfers are efforts to get ARIN's records up to date regarding M&A transactions that happened years ago. It is not possible for a no-longer-existent entity to execute the 8.3 transfer, so it has to be 8.2 transferred to the new entity first.  
> > >  
> > > Scott
> > >  
> > > > On Apr 3, 2014, at 6:02 PM, Rocky <rockymm8 at gmail.com (mailto:rockymm8 at gmail.com)> wrote:
> > > >  
> > > > Hello there,
> > > >  
> > > > What you are planning to do seems like you try to disguise an 8.3 transfer as an 8.2 transfer.  
> > > > I do not think it is appropriate for allowing an 8.2 transfer followed by an 8.3/8.4 transfer.  
> > > >  
> > > > If the company does not need the IPv4 and the IPv4 are lack of utilisation, why not ask this company to return the IPv4 for the benefit of the community?
> > > >  
> > > > If the company wants to sell the IPv4 after an 8.2 to buyers through an 8.3/8.4, why not the company directly transfer the IPv4 from its original organisation instead of doing an 8.2 first then followed by an 8.3/8.4 transfer. Are the seller trying to hide something or as the seller is afraid of doing something against the policy, so they try to make such an arrangement?
> > > >  
> > > > There is a highly suspicious of ? IPv4 laundry? or ?IPv4 speculation? about this company. Maybe we need more transparency of the buy&sale of the IPv4 to make sure the behaviour of the seller is compatible with policy.  
> > > >  
> > > > I suggest to resolve the language conflict between 8.2 transfer policy and RSA and further to suggest to figure out some measures to stop the speculation on IPv4 via an 8.2 then followed by an 8.3/8.4 transfer. If the company does not use the IPv4 after an 8.2 transfer, why not return them to free pool for the benefit of the whole community?
> > > >  
> > > > Any ideas on this ?
> > > >  
> > > >  
> > > > > On Friday, April 4, 2014 at 7:43 AM, arin-ppml-request at arin.net (mailto:arin-ppml-request at arin.net) wrote:
> > > > >  
> > > > > Send ARIN-PPML mailing list submissions to
> > > > > arin-ppml at arin.net (mailto:arin-ppml at arin.net)
> > > > >  
> > > > > To subscribe or unsubscribe via the World Wide Web, visit
> > > > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > > > or, via email, send a message with subject or body 'help' to
> > > > > arin-ppml-request at arin.net (mailto:arin-ppml-request at arin.net)
> > > > >  
> > > > > You can reach the person managing the list at
> > > > > arin-ppml-owner at arin.net (mailto:arin-ppml-owner at arin.net)
> > > > >  
> > > > > When replying, please edit your Subject line so it is more specific
> > > > > than "Re: Contents of ARIN-PPML digest..."
> > > > >  
> > > > >  
> > > > > Today's Topics:
> > > > >  
> > > > > 1. Re: ARIN-PPML Digest, Vol 106, Issue 7 (Chris R. Squatritto)
> > > > > 2. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> > > > > and 8.2 Utilization Requirements (John Curran)
> > > > > 3. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> > > > > and 8.2 Utilization Requirements (Milton L Mueller)
> > > > > 4. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> > > > > and 8.2 Utilization Requirements (xiaofan yang)
> > > > > 5. Re: Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> > > > > and 8.2 Utilization Requirements (xiaofan yang)
> > > > >  
> > > > >  
> > > > > ----------------------------------------------------------------------
> > > > >  
> > > > > Message: 1
> > > > > Date: Wed, 02 Apr 2014 16:30:45 -0700
> > > > > From: "Chris R. Squatritto" <csquat at ccsd.net (mailto:csquat at ccsd.net)>
> > > > > To: arin-ppml at arin.net (mailto:arin-ppml at arin.net)
> > > > > Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 7
> > > > > Message-ID:
> > > > > <fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net (mailto:fc.004c4e074f3bba733b9aca00e3f873db.4f3bba74 at interact.ccsd.net)>
> > > > > Content-Type: text/plain; charset="utf-8"
> > > > >  
> > > > > I am out of the office this week and will not be checking email. Please
> > > > > contact Troy Miller for assistance..
> > > > >  
> > > > > Thank you for contacting me, and have a great day.
> > > > >  
> > > > > -------------- next part --------------
> > > > > An HTML attachment was scrubbed...
> > > > > URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140402/5723c721/attachment-0001.html>
> > > > >  
> > > > > ------------------------------
> > > > >  
> > > > > Message: 2
> > > > > Date: Wed, 2 Apr 2014 23:59:20 +0000
> > > > > From: John Curran <jcurran at arin.net (mailto:jcurran at arin.net)>
> > > > > To: xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)>
> > > > > Cc: "arin-ppml at arin.net (mailto:arin-ppml at arin.net)" <arin-ppml at arin.net (mailto:arin-ppml at arin.net)>
> > > > > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> > > > > Between RSA and 8.2 Utilization Requirements
> > > > > Message-ID: <6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net (mailto:6BBC9339-AE30-446A-8406-8237A8C3477F at arin.net)>
> > > > > Content-Type: text/plain; charset="iso-8859-1"
> > > > >  
> > > > > > On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)> wrote:
> > > > > >  
> > > > > > Hi John,
> > > > > >  
> > > > > > I have further enquiry about ARIN 8.2 process.
> > > > > >  
> > > > > > Number one:I am also worried about the costs of doing a 8.2 transfer followed by a 8.3 transfer. I wonder if I will have to involve the legal help to deal with ARIN legal. In my case I bought a company that now is out of business. How complicated does ARIN make this process? I want some assurance that I will be treated equally to any other companies whether it is a big company or a small company like us.
> > > > >  
> > > > > Niki -
> > > > >  
> > > > > You will be treated equally, but in truth I'm not certain that is actually what you want...
> > > > > (for example, a process which seems routine for a large organization could still pose
> > > > > a disproportionate burden to a smaller organization since organization size is not a
> > > > > factor in the verification process.)
> > > > >  
> > > > > The first and foremost activity is to make sure that we have your organization registered
> > > > > as the rightful address holder, and that will require an NRPM 8.2 transfer. It can actually
> > > > > be relatively straightforward process, as long as you have clear documentation of the
> > > > > purchase of the company. Review the instructions here for additional information about
> > > > > what is accepted - <https://www.arin.net/resources/request/transfers_8_2.html>
> > > > >  
> > > > > > Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will the stated purpose for our number resources remains the same?? I am afraid of that ARIN will not approve our transfer.
> > > > >  
> > > > > If you are the clear party with the rights after your purchase, ARIN will approve your
> > > > > transfer. We may note that you have more addresses than you now need, and thus
> > > > > we expect you to return or transfer the remainder (but that would seem to line up with
> > > > > your intentions in any case.)
> > > > >  
> > > > > If you have purchased a company without adequate documentation, or if multiple
> > > > > parties purchased multiple pieces of the company, or if there some question about
> > > > > what was purchased based on the documentation, then it can be more challenging
> > > > > to get the resources appropriately listed with you as the rightful holder. You will need
> > > > > to apply for the transfer and work with the ARIN Hostmaster to determine if there is
> > > > > any issue in your particular case.
> > > > >  
> > > > > > Number three: As we have bought the company, do we have the property right on those IPs? in our past agreement and future agreement arranged for 8.3, we would like to have some kinds of property right on those IPs, will that conflict with ARIN policy?
> > > > >  
> > > > > Wonderful question - it is ARIN's position that you have a specific set of rights to the
> > > > > address blocks in the registry (as defined by the registration services agreement that
> > > > > you enter with ARIN), and these rights include:
> > > > >  
> > > > > (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
> > > > > (2) The right to use the Included Number Resources within the ARIN database; and
> > > > > (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.
> > > > >  
> > > > > ARIN registration services agreement includes a specific disclaimer of property rights
> > > > > in the address blocks, as it is inconsistent with the ability to manage the address blocks
> > > > > in accordance with community-developed policy in the region. If you have other beliefs
> > > > > with respect to your rights, that would probably be an area for you to seek legal advice.
> > > > >  
> > > > > I hope this helps; please do not hesitate to ask if you have any additional questions.
> > > > >  
> > > > > Thanks!
> > > > > /John
> > > > >  
> > > > > John Curran
> > > > > President and CEO
> > > > > ARIN
> > > > >  
> > > > >  
> > > > >  
> > > > > ------------------------------
> > > > >  
> > > > > Message: 3
> > > > > Date: Thu, 3 Apr 2014 15:33:13 +0000
> > > > > From: Milton L Mueller <mueller at syr.edu (mailto:mueller at syr.edu)>
> > > > > To: "'John Curran'" <jcurran at arin.net (mailto:jcurran at arin.net)>, xiaofan yang
> > > > > <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)>
> > > > > Cc: "arin-ppml at arin.net (mailto:arin-ppml at arin.net)" <arin-ppml at arin.net (mailto:arin-ppml at arin.net)>
> > > > > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> > > > > Between RSA and 8.2 Utilization Requirements
> > > > > Message-ID: <1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu (mailto:1846d87fe7164f22a7c63e9d1fed321e at EX13-MBX-13.ad.syr.edu)>
> > > > > Content-Type: text/plain; charset="us-ascii"
> > > > >  
> > > > > Niki:
> > > > > For most economists and lawyers, the definition of a "property right" involves the right to use, the right to exclude others from using, and the right to transfer. As John's message makes clear, all those rights are present in the number block lease you get from ARIN. So although the RSA makes you formally declaim a property right, what you are getting from the RSA is a bundle of rights that for all practical purposes has the same economic features as a property right.
> > > > >  
> > > > > -----Original Message-----
> > > > >  
> > > > > Wonderful question - it is ARIN's position that you have a specific set of rights to the address blocks in the registry (as defined by the registration services agreement that you enter with ARIN), and these rights include:
> > > > >  
> > > > > (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
> > > > > (2) The right to use the Included Number Resources within the ARIN database; and
> > > > > (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.
> > > > >  
> > > > > ARIN registration services agreement includes a specific disclaimer of property rights in the address blocks, as it is inconsistent with the ability to manage the address blocks in accordance with community-developed policy in the region. If you have other beliefs with respect to your rights, that would probably be an area for you to seek legal advice.
> > > > >  
> > > > > I hope this helps; please do not hesitate to ask if you have any additional questions.
> > > > >  
> > > > > Thanks!
> > > > > /John
> > > > >  
> > > > > John Curran
> > > > > President and CEO
> > > > > ARIN
> > > > >  
> > > > > _______________________________________________
> > > > > PPML
> > > > > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net (mailto: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 (mailto:info at arin.net) if you experience any issues.
> > > > >  
> > > > >  
> > > > > ------------------------------
> > > > >  
> > > > > Message: 4
> > > > > Date: Fri, 4 Apr 2014 07:33:04 +0800
> > > > > From: xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)>
> > > > > To: John Curran <jcurran at arin.net (mailto:jcurran at arin.net)>
> > > > > Cc: "arin-ppml at arin.net (mailto:arin-ppml at arin.net)" <arin-ppml at arin.net (mailto:arin-ppml at arin.net)>
> > > > > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> > > > > Between RSA and 8.2 Utilization Requirements
> > > > > Message-ID:
> > > > > <CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com (mailto:CAPhL6MpzKW1q2Cw9+SfZ+hap6ecwns6JzdBEp+xvK8dF7VMwxg at mail.gmail.com)>
> > > > > Content-Type: text/plain; charset="iso-8859-1"
> > > > >  
> > > > > Hi John,
> > > > >  
> > > > >  
> > > > > In basis of your reply, if the block is underutilised,ARIN will either ask
> > > > > the company to return the IPs or transfer to other third party via 8.3
> > > > > transfer after our 8.2 transfer.
> > > > >  
> > > > >  
> > > > > Say we have two /16 after this 8.2 transfer, what if we only transfer one
> > > > > /16 to the other third party via 8.3 transfer, meanwhile, we keep the
> > > > > other /16 left unused after our 8.2 transfer for quiet a while. Will ARIN
> > > > > ask us to return the remained /16 to the free pool? furthmore, how long
> > > > > will ARIN allow us to keep the other /16 unused before we transfer it to
> > > > > the third party via 8.3 transfer ?
> > > > >  
> > > > >  
> > > > >  
> > > > > Niki
> > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > > > > On Thu, Apr 3, 2014 at 7:59 AM, John Curran <jcurran at arin.net (mailto:jcurran at arin.net)> wrote:
> > > > > >  
> > > > > > > On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)> wrote:
> > > > > > >  
> > > > > > > Hi John,
> > > > > > >  
> > > > > > > I have further enquiry about ARIN 8.2 process.
> > > > > > >  
> > > > > > > Number one:I am also worried about the costs of doing a 8.2 transfer
> > > > > > followed by a 8.3 transfer. I wonder if I will have to involve the legal
> > > > > > help to deal with ARIN legal. In my case I bought a company that now is
> > > > > > out of business. How complicated does ARIN make this process? I want some
> > > > > > assurance that I will be treated equally to any other companies whether it
> > > > > > is a big company or a small company like us.
> > > > > >  
> > > > > > Niki -
> > > > > >  
> > > > > > You will be treated equally, but in truth I'm not certain that is actually
> > > > > > what you want...
> > > > > > (for example, a process which seems routine for a large organization could
> > > > > > still pose
> > > > > > a disproportionate burden to a smaller organization since organization
> > > > > > size is not a
> > > > > > factor in the verification process.)
> > > > > >  
> > > > > > The first and foremost activity is to make sure that we have your
> > > > > > organization registered
> > > > > > as the rightful address holder, and that will require an NRPM 8.2
> > > > > > transfer. It can actually
> > > > > > be relatively straightforward process, as long as you have clear
> > > > > > documentation of the
> > > > > > purchase of the company. Review the instructions here for additional
> > > > > > information about
> > > > > > what is accepted - <
> > > > > > https://www.arin.net/resources/request/transfers_8_2.html>
> > > > > >  
> > > > > > > Number two: If we do a 8.2 transfer followed by a 8.3 transfer, will
> > > > > > the stated purpose for our number resources remains the same?? I am afraid
> > > > > > of that ARIN will not approve our transfer.
> > > > > >  
> > > > > > If you are the clear party with the rights after your purchase, ARIN will
> > > > > > approve your
> > > > > > transfer. We may note that you have more addresses than you now need, and
> > > > > > thus
> > > > > > we expect you to return or transfer the remainder (but that would seem to
> > > > > > line up with
> > > > > > your intentions in any case.)
> > > > > >  
> > > > > > If you have purchased a company without adequate documentation, or if
> > > > > > multiple
> > > > > > parties purchased multiple pieces of the company, or if there some
> > > > > > question about
> > > > > > what was purchased based on the documentation, then it can be more
> > > > > > challenging
> > > > > > to get the resources appropriately listed with you as the rightful holder.
> > > > > > You will need
> > > > > > to apply for the transfer and work with the ARIN Hostmaster to determine
> > > > > > if there is
> > > > > > any issue in your particular case.
> > > > > >  
> > > > > > > Number three: As we have bought the company, do we have the property
> > > > > > right on those IPs? in our past agreement and future agreement arranged
> > > > > > for 8.3, we would like to have some kinds of property right on those IPs,
> > > > > > will that conflict with ARIN policy?
> > > > > >  
> > > > > > Wonderful question - it is ARIN's position that you have a specific set of
> > > > > > rights to the
> > > > > > address blocks in the registry (as defined by the registration services
> > > > > > agreement that
> > > > > > you enter with ARIN), and these rights include:
> > > > > >  
> > > > > > (1) The exclusive right to be the registrant of the Included Number
> > > > > > Resources within the ARIN database;
> > > > > > (2) The right to use the Included Number Resources within the ARIN
> > > > > > database; and
> > > > > > (3) The right to transfer the registration of the Included Number
> > > > > > Resources pursuant to the Policies.
> > > > > >  
> > > > > > ARIN registration services agreement includes a specific disclaimer of
> > > > > > property rights
> > > > > > in the address blocks, as it is inconsistent with the ability to manage
> > > > > > the address blocks
> > > > > > in accordance with community-developed policy in the region. If you have
> > > > > > other beliefs
> > > > > > with respect to your rights, that would probably be an area for you to
> > > > > > seek legal advice.
> > > > > >  
> > > > > > I hope this helps; please do not hesitate to ask if you have any
> > > > > > additional questions.
> > > > > >  
> > > > > > Thanks!
> > > > > > /John
> > > > > >  
> > > > > > John Curran
> > > > > > President and CEO
> > > > > > ARIN
> > > > > >  
> > > > >  
> > > > > -------------- next part --------------
> > > > > An HTML attachment was scrubbed...
> > > > > URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/fd4aa749/attachment-0001.html>
> > > > >  
> > > > > ------------------------------
> > > > >  
> > > > > Message: 5
> > > > > Date: Fri, 4 Apr 2014 07:43:43 +0800
> > > > > From: xiaofan yang <nikiyangxf at gmail.com (mailto:nikiyangxf at gmail.com)>
> > > > > To: Milton L Mueller <mueller at syr.edu (mailto:mueller at syr.edu)>
> > > > > Cc: John Curran <jcurran at arin.net (mailto:jcurran at arin.net)>, "arin-ppml at arin.net (mailto:arin-ppml at arin.net)"
> > > > > <arin-ppml at arin.net (mailto:arin-ppml at arin.net)>
> > > > > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
> > > > > Between RSA and 8.2 Utilization Requirements
> > > > > Message-ID:
> > > > > <CAPhL6MrQdn-=5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com (mailto:5g8ZKSntVpVca7pRrwuWLxCAiTrgv2d672wX3A at mail.gmail.com)>
> > > > > Content-Type: text/plain; charset="iso-8859-1"
> > > > >  
> > > > > Hi Milton,
> > > > >  
> > > > > thanks for your inspiring reply. Now i know that we have the "ownership"
> > > > > of those IPs. as you are one of the AC, i take your reply seriously and
> > > > > also this is good news for the community, especially for those legacy
> > > > > holders, if the holder of ARIN non-legacy IPs can have the "ownership'
> > > > > then the holder of legacy IPs definitely has the ownership on their IPs
> > > > > no matter whether they sign the RSA , LRSA or not.
> > > > >  
> > > > > Hope ARIN will not impose unpredictable "restrictions" when legacy or
> > > > > non-legacy holder begins its transfer request. Moreover, when ARIN reject
> > > > > a transfer , hope ARIN will not use the "confidential terms" as an excuse
> > > > > for not reply communities' questions in ppml. or ARIN will reply with
> > > > > bunch of info mean nothing.
> > > > > Niki
> > > > >  
> > > > >  
> > > > > > On Thu, Apr 3, 2014 at 11:33 PM, Milton L Mueller <mueller at syr.edu (mailto:mueller at syr.edu)> wrote:
> > > > > >  
> > > > > > Niki:
> > > > > > For most economists and lawyers, the definition of a "property right"
> > > > > > involves the right to use, the right to exclude others from using, and the
> > > > > > right to transfer. As John's message makes clear, all those rights are
> > > > > > present in the number block lease you get from ARIN. So although the RSA
> > > > > > makes you formally declaim a property right, what you are getting from the
> > > > > > RSA is a bundle of rights that for all practical purposes has the same
> > > > > > economic features as a property right.
> > > > > >  
> > > > > > -----Original Message-----
> > > > > >  
> > > > > > Wonderful question - it is ARIN's position that you have a specific set of
> > > > > > rights to the address blocks in the registry (as defined by the
> > > > > > registration services agreement that you enter with ARIN), and these rights
> > > > > > include:
> > > > > >  
> > > > > > (1) The exclusive right to be the registrant of the Included Number
> > > > > > Resources within the ARIN database;
> > > > > > (2) The right to use the Included Number Resources within the ARIN
> > > > > > database; and
> > > > > > (3) The right to transfer the registration of the Included Number
> > > > > > Resources pursuant to the Policies.
> > > > > >  
> > > > > > ARIN registration services agreement includes a specific disclaimer of
> > > > > > property rights in the address blocks, as it is inconsistent with the
> > > > > > ability to manage the address blocks in accordance with community-developed
> > > > > > policy in the region. If you have other beliefs with respect to your
> > > > > > rights, that would probably be an area for you to seek legal advice.
> > > > > >  
> > > > > > I hope this helps; please do not hesitate to ask if you have any
> > > > > > additional questions.
> > > > > >  
> > > > > > Thanks!
> > > > > > /John
> > > > > >  
> > > > > > John Curran
> > > > > > President and CEO
> > > > > > ARIN
> > > > > >  
> > > > > > _______________________________________________
> > > > > > PPML
> > > > > > You are receiving this message because you are subscribed to the ARIN
> > > > > > Public Policy Mailing List (ARIN-PPML at arin.net (mailto: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 (mailto:info at arin.net) if you experience any issues.
> > > > > >  
> > > > >  
> > > > > -------------- next part --------------
> > > > > An HTML attachment was scrubbed...
> > > > > URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140404/57c3a01e/attachment.html>
> > > > >  
> > > > > ------------------------------
> > > > >  
> > > > > _______________________________________________
> > > > > ARIN-PPML mailing list
> > > > > ARIN-PPML at arin.net (mailto:ARIN-PPML at arin.net)
> > > > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > > >  
> > > > > End of ARIN-PPML Digest, Vol 106, Issue 8
> > > > > *****************************************
> > > > >  
> > > >  
> > > >  
> > > > _______________________________________________
> > > > PPML
> > > > You are receiving this message because you are subscribed to
> > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net (mailto: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 (mailto:info at arin.net) if you experience any issues.
> > > >  
> > >  
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140403/86ab1c8b/attachment.html>
> > >  
> > > ------------------------------
> > >  
> > > _______________________________________________
> > > ARIN-PPML mailing list
> > > ARIN-PPML at arin.net (mailto:ARIN-PPML at arin.net)
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > >  
> > > End of ARIN-PPML Digest, Vol 106, Issue 10
> > > ******************************************
> > >  
> > >  
> > >  
> >  
> >  

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

From owen at delong.com  Fri Apr  4 20:38:04 2014
From: owen at delong.com (Owen DeLong)
Date: Fri, 4 Apr 2014 17:38:04 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <533F3AFB.3070105@linuxmagic.com>
References: <mailman.1551.1396568627.28847.arin-ppml@arin.net><7AD26173D4094	238B51D28EE6DE8A020@gmail.com><04DC25C4-5352-4DC8-A114-EA1724DC88EE@gmail.c	om>,
	<8695009A81378E48879980039EEDAD2801364555EE@MAIL1.polartel.local><2364a	c2d4a3e489f8f6d53ae4988b71c@BY2PR03MB394.namprd03.prod.outlook.com>,
	<968C47	0DAC25FB419E0159952F28F0C06A75D811@MEM0200CP3XF04.ds.irsnet.gov><d315c6acaa	ac467d88b85ab969f64491@BY2PR03MB394.namprd03.prod.outlook.com><5B9E90747FA2	974D91A54FCFA1B8AD1201529268D3@ENI-MAIL.eclipse-networks.com>	<968C470DAC25FB419E0159952F28F0C06A75D95B@MEM0200CP3XF04.ds.irsnet.gov>	<5B9E90747FA2974D91A54FCFA1B8AD120152926A3E@ENI-MAIL.eclipse-networks.com>
	<0623FEA5-2D55-442B-9FFD-CC9613DC1C5E@delong.com>
	<533F3AFB.3070105@linuxmagic.com>
Message-ID: <0157E22C-8D33-4B3F-8145-F2D39DAB0261@delong.com>


On Apr 4, 2014, at 4:06 PM, Michael Peddemors <michael at linuxmagic.com> wrote:

> On 14-04-04 03:44 PM, Owen DeLong wrote:
>> 
>> On Apr 4, 2014, at 11:00 AM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:
>> 
>>> If an org with no resources applies they should at least be able to get the minimum which has been set by this community which I think is currently at a /22.  Always!
>> 
>> Depends? End-user /24, ISP multi-homed /22, ISP non-multi-homed /20 IIRC.
> 
> Personally, I still think the above is limiting, eg the small operator who is not multi-homed, and only really needs a /22

For better or worse, the community has advised ISPs needing less than a /22 who are single homed to obtain their space from their upstream provider.

> 
>> 
>>> If an org wants larger than a /22 they need to be able to demonstrate in a reasonable way that they are a larger org with a network size that justifies a larger allocation.  The first way is what allocation do they already have?  If they have say a /19  or equivalent maybe they can demonstrate they need say another /19 by furnishing to ARIN maybe their financials and the investment they have actually made to justify another /19 or whatever.  (I'm just using the /19 as an example.)
> 
> ah.. reasonable way... that is the rub.. I see hosting companies with throw away domains occupying the whole /19 using it as justification for getting another /19 of fresh IP(s) they can rent out.. not to disrupt the thread.. ARIN has a tough time.. what is a legitimate use to one person is maybe not to another.. I am never sure if IP(s) used to generate outbound traffic is a good justification, there are other ways to share an IP Address for outbound.. I think a priority should be somehow worded in that 'inbound' destinations take priority over outbound sources.. eg, you have to advertise a public service that it accessible.. it should take precedence over say someone that uses their IP(s) to generate bulk outbound traffic ..

Since this is commentary on something I quoted, not something I wrote, I?ll not comment further.

Owen



From jaymartin926 at gmail.com  Fri Apr  4 21:33:27 2014
From: jaymartin926 at gmail.com (Jay Martin)
Date: Sat, 5 Apr 2014 09:33:27 +0800
Subject: [arin-ppml] Update: 2014-1 Out of Region Use
In-Reply-To: <CAMDXq5NLusAn3N_B7VusROyWT1hyFQfv6wdbC6KpbdVh66HuVw@mail.gmail.com>
References: <5335AFF6.2060507@umn.edu>
	<87f821b26ba1410bb718278161a9c529@DM2PR03MB398.namprd03.prod.outlook.com>
	<CA+Ld8r8irr5GkBnz-WWaiESRSjD5RjDXY1=JtqzOz+EVYf2j1A@mail.gmail.com>
	<CAMDXq5NDbG3zanfDAZfdvy-BAsu+n9aY9thjC5sKzC0GL3vppg@mail.gmail.com>
	<CAMDXq5NLusAn3N_B7VusROyWT1hyFQfv6wdbC6KpbdVh66HuVw@mail.gmail.com>
Message-ID: <CALJtNOa5gP6q_=5pa2gjrr4ZZjR25MzHfyXxE7yfUvnLJuy8pA@mail.gmail.com>

this is a kind of another bureau policy to add to ARIN current bureau
policy.

like the IPv4 leasing ( even there is no policy defining on this lease
topic but it has been existing since the very beginning of internet born),
  the phenomena of  out-of-region use  is ubiquitous,   there has already
had many guys using its ARIN ips out of region.   there also has those
policy masters who says the Afrinic and Lacnic etc IPs can be used
everywhere in the world.

those policy masters clearly know the policy ( cited from NRO.ORG) below.
However, they can manipulate the sale of IPs in Afrinic and Lacnnic via a
disguised M/A purchase to avoid the restriction of no sale of addresses in
afrinic and Lacnnic.  After the "sale" of the ips,  those masters market
that those ips can be used everywhere in the wordd.




  AFRINIC

Does not allow sale of addresses, but recognises name changes and transfers
of tangible assets associated with addresses. Requires submission of legal
documents. Utilization is verified. May require new agreement.

LACNIC

Does not allow sale of addresses, but recognizes name changes and transfers
of tangible assets associated with addresses. Requires submission of legal
documents. Utilization is verified. May require new agreement. Once LACNIC
or any of its NIRs becomes unable, for the first time, to cover an IPv4
block allocation or assignment because of lack of resources, LIRs and/or
End Users within the LACNIC region will be allowed to transfer IPv4 blocks.



I would like to understand the reasons behind such a proposal.   it is just
another ways for some big firm to justify their "out-of-region'' and  this
proposal can also help those firm to avoid the 8.2,8.3/8.4 transfer to have
their IPs ( either old and new ) to be used in AP or other regions.   this
is quite similar to how the UN works before UN want to impose sanction on
some countries, UN need have a policy or reason to support such a
sanction.  and this proposal like the one "anti-flipping language" is try
to pave the way for such a kind of no restriction on "IPv4 transfer".



Let use A as one of the example,  suppose this proposal has been passed.
how will ARIN evaluate its request of A to decide how much percentage or
how large of a block can be used out of region? furthermore, considering A
has an APNIC account and have many IPv4,  how ARIN know its real
utilisation rate of A' other RIR account so as to approve A's  block size
which can be used out of region.


I have done some research and find that  Akamai has a total of 225,280 IPv4
in AP region.  If Akamai is the one who send request to ARIN for asking a
out-of-region use,  please tell me how will ARIN decide the utilisation
rate of that 225280 IPv4 in the other region?   previously Akamai had
receive a /12+/14 from ARIN, how many IPv4 from that /12+/14 can be used
out of region ?


Jay



On Sat, Apr 5, 2014 at 8:14 AM, Martin Hannigan <hannigan at gmail.com> wrote:

>
> Oops, buffer overflow. Wrong thread. Simply, +1 for this thread.
>
>
>
> On Friday, April 4, 2014, Martin Hannigan <hannigan at gmail.com> wrote:
>
>>
>> Same, +1.
>>
>> Which isn't Section 11 a better place to address this?
>>
>> Best,
>>
>> -M<
>>
>>
>> On Fri, Mar 28, 2014 at 1:55 PM, David Huberman <
>> David.Huberman at microsoft.com> wrote:
>> > Support in principle, strongly opposed as written.
>> >
>> > ARIN is a registry, not a regulator.  Networks with global reach should
>> not have regulatory rules placed on them by ARIN whose job is primarily to
>> record number assignments, not make rules which affect network topology.
>> Thus I support the idea that numbers should not be bound to arbitrary
>> political boundaries.
>> >
>> > I oppose this draft as written, however, because it adds hundreds of
>> words to NRPM where only a few are needed to address the stated goal.  The
>> problem statement indicates: " The next logical option is to discuss a
>> proposal that clearly permits out of region use without limits".  Well ok.
>>  If you wanted to do that explicitly in policy, how about:
>> >
>> >         Section 1.x -  ARIN-issued number resources may be used on
>> equipment located anywhere.
>> >
>> > All the rest of the text that I see in this draft come down to, "if you
>> have resources in other RIRs, we'll audit them to ensure you aren't double
>> dipping." Policy already allows that:
>> >
>> >         "ISPs must have efficiently utilized all previous allocations
>> and at least 80% of their most recent allocation
>> >          in order to receive additional space."
>> >
>> >         " In order to justify an additional assignment, end-users must
>> have efficiently utilized at least 80% of all
>> >         previous assignments, and must provide ARIN with utilization
>> details"
>> >
>> > We need to simplify NRPM and start peeling back a lot of this
>> over-regulatory policy.  To do so, let's write clearer and more concise
>> policy proposals, please.
>> >
>> > David R Huberman
>> > Microsoft Corporation
>> > Senior IT/OPS Program Manager (GFS)
>> >
>> >
>> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
>> On Behalf Of David Farmer
>> > Sent: Friday, March 28, 2014 10:23 AM
>> > To: ARIN PPML
>> > Subject: [arin-ppml] Update: 2014-1 Out of Region Use
>> >
>> > Based on the discussion at the PPC in Atlanta (link below), the
>> following changes are proposed.
>> >
>> >
>> https://www.arin.net/participate/meetings/reports/ppc_nanog60/webcast/2014-1.mov
>> >
>> > There is a summary of the changes and a red-lined version of the policy
>> text with new and deleted text highlighted following the complete Draft
>> Policy.
>> >
>> > ----
>> >
>> > Draft Policy ARIN-2014-1
>> > Out of Region Use
>> >
>> > Date: 28 March 2014
>> >
>> > Problem statement:
>> >
>> > Current policy neither clearly forbids nor clearly permits out or
>> region use of ARIN registered resources. This has created confusion and
>> controversy within the ARIN community for some time. Earlier work on this
>> issue has explored several options to restrict or otherwise limit out of
>> region use. None of these options have gained consensus within the
>> community. The next logical option is to discuss a proposal that clearly
>> permits out of region use without limits, beyond those already existing in
>> policy.
>> >
>> > Permitting out of region use, however, poses issues that have to be
>> addressed by policy and adjustments to operational practice. Out of region
>> use needs a clear definition and any operational practices based on that
>> definition must not be unnecessarily burdensome. It is significantly more
>> difficult and costly for ARIN Staff to independently verify the
>> justification and utilization of resources that are reassigned or otherwise
>> used outside of the ARIN service region. There needs to be recognition of
>> this difference in policy and associated operational practices, especially
>> the cost differential when there is more than an incidental amount of out
>> of region use.
>> >
>> > Policy statement:
>> >
>> > Create new Section X;
>> >
>> > X. Out of Region Use
>> >
>> > ARIN registered resources may be used outside the ARIN service region
>> and such use is valid justification for new or additional resources.
>> Resources are considered to be used outside the region if the user or
>> customer service address or the technical infrastructure address, such as
>> the point of presence (POP), data center, or other similar location, are
>> outside the ARIN service region.
>> >
>> > There is a general presumption that requesting resources from ARIN for
>> use within another RIR's service region duplicates any resources held by
>> the organization with that other RIR.  Therefore, the organization should,
>> not hold any resources with the other RIR, or demonstrate that all such
>> resources held are utilized based on ARIN policy requirements, or provide
>> an operational justification clarifying how the resources from ARIN will
>> not duplicate any underutilize
>
>
> _______________________________________________
> 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/20140405/f5ea99f3/attachment.htm>

From nikiyangxf at gmail.com  Fri Apr  4 22:19:08 2014
From: nikiyangxf at gmail.com (xiaofan yang)
Date: Sat, 5 Apr 2014 10:19:08 +0800
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
Message-ID: <CAPhL6MqdByzKy+HkRwt-fKto32NPRbMagJ_XqwLL8XgkTiLd_w@mail.gmail.com>

Hi Kevin,

I am quite confused by John's explanation too.
It seems ARIN always provides plenty of information meaning nothing.
Same happens to ask HM, HM will always  reply neutrally and I still cannot
know it is yes or no!

However, in basis of john's reply i will rephrase his explanation as the
following meaning:

I will try my best to transfer the two /16 to third party via 8.3/8.4
transfer immediately after a 8.2 transfer instead of reserving one /16 for
another future sale in case of the other /16 to return to ARIN free pool or
 rejecting for our second /16 transfer in future.

Niki



*Hi John,*

*In basis of your reply, if the block is underutilised,ARIN will either ask
the company to return the IPs or transfer to other third party via 8.3
transfer after our 8.2 transfer.*

*Correct.*

*Say we have two /16 after this 8.2 transfer, what if we only transfer one
/16 to the other third party via 8.3 transfer, meanwhile, we keep the other
/16 left unused after our 8.2 transfer for quiet a while. Will ARIN ask us
to return the remained /16 to the free pool? furthmore, how long will ARIN
allow us to keep the other /16 unused before we transfer it to the third
party via 8.3 transfer ?*

*Niki -*

*ARIN will continue to work with you as needed, so long as you are still
working*
*in good faith towards compliance with policy. For more information on your*
*particular circumstances, please contact <hostmaster at arin.net
<hostmaster at arin.net><mailto:hostmaster at arin.net <hostmaster at arin.net>>>.*

*Thanks!*
*/John*

*John Curran*
*President and CEO*
*ARIN*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140405/c3e7720a/attachment.htm>

From jcurran at arin.net  Fri Apr  4 22:29:59 2014
From: jcurran at arin.net (John Curran)
Date: Sat, 5 Apr 2014 02:29:59 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <CAPhL6MqdByzKy+HkRwt-fKto32NPRbMagJ_XqwLL8XgkTiLd_w@mail.gmail.com>
References: <CAPhL6MqdByzKy+HkRwt-fKto32NPRbMagJ_XqwLL8XgkTiLd_w@mail.gmail.com>
Message-ID: <70DF690B-E283-4C58-B5C3-B97A237A291B@arin.net>

On Apr 4, 2014, at 10:19 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:

> However, in basis of john's reply i will rephrase his explanation as the following meaning:
> 
> I will try my best to transfer the two /16 to third party via 8.3/8.4 transfer immediately after a 8.2 transfer instead of reserving one /16 for another future sale in case of the other /16 to return to ARIN free pool or  rejecting for our second /16 transfer in future. 

Niki - 

If your second transfer (the 8.3 or 8.4 one) was not approved, you would be again be asked
to either return the excess address space or pursue another transfer request to bring your 
utilization in line with policy.

FYI,
/John

John Curran
President and CEO
ARIN



From jaymartin926 at gmail.com  Fri Apr  4 22:41:04 2014
From: jaymartin926 at gmail.com (Jay Martin)
Date: Fri, 4 Apr 2014 19:41:04 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
Message-ID: <CALJtNObriexj+m0-V5kXwsPTG0u8q+tO2GU-S8v3zAcTb7=vMA@mail.gmail.com>

Message: 2

Date: Fri, 4 Apr 2014 09:55:48 -0500

From: Kevin Kargel <kkargel at polartel.com>

To: "arin-ppml at arin.net" <arin-ppml at arin.net>

Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

Message-ID:

<8695009A81378E48879980039EEDAD28013645561D at MAIL1.polartel.local>

Content-Type: text/plain; charset="us-ascii"


Agreed. ARIN should be a registry and as such absolutely should be
non-competitive and blind to the market. The registry should not be
configured to support the market. IMHO ARIN should not be participating in
or catering to the market in any form.

Kevin



From: David Huberman
[mailto:David.Huberman at microsoft.com<David.Huberman at microsoft.com>
]

Sent: Friday, April 04, 2014 9:31 AM

To: Kevin Kargel; arin-ppml at arin.net

Subject: RE: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8



ARIN is a registry, not a regulator. The more you guys want to


build in rules that are anti-competitive and blind to the market


reality, the more inaccurate Whois gets.


Hi David,


you must witness so many inaccurate whois info during those 11 years
working as the Hm in ARIN.   It will be better for you to tell the truth or
to justify your above claim through solid information otherwise this
becomes lack of persuasion.





Upon v4 exhaustion, we should remove needs basis from


transfers, remove the RSA text that makes the signer disclaim


property rights, and motivate registrants to keep Whois accurate


so that network operators can get good information about their


traffic.



Why  do you think  remove needs test will be enhance  a more accurate whois?

if removed it will be easier for microsoft to buy more IPv4?


Why do you think having a property right will bring out a more accurate
whois?

because your employer has bought too many and spend quite a lot and you
want a policy to protect its benefits?



Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140404/452318c7/attachment.htm>

From nikiyangxf at gmail.com  Fri Apr  4 22:51:05 2014
From: nikiyangxf at gmail.com (xiaofan yang)
Date: Sat, 5 Apr 2014 10:51:05 +0800
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <70DF690B-E283-4C58-B5C3-B97A237A291B@arin.net>
References: <CAPhL6MqdByzKy+HkRwt-fKto32NPRbMagJ_XqwLL8XgkTiLd_w@mail.gmail.com>
	<70DF690B-E283-4C58-B5C3-B97A237A291B@arin.net>
Message-ID: <CAPhL6MoErqG9Gto4Ls32B3Jai3vjGpOceDVBenYFu1yfqVCyaA@mail.gmail.com>

Hi John,

Please explain  what do you mean by  " pursue another transfer request to
bring your
utilization in line with policy." ?

what does this "another transfer "refer to ?  which policy should we based
on?


furthermore, i am afraid of ARIN rejecting the 8.2 transfer , not even to
mention the second 8.3/8.4 transfer.
However, based on your reply,  no matter what happens, ARIN will definitely
approve the 8.2 transfer and ARIN will only impose "restriction" on
8.3/8.4 transfer ?   and the utilisation rate in 8.2 transfer is just  a
paper tiger ?


What if our 8.2 and then 8.3/8.4 transfer  is rejected by ARIN and i find
others has been approved ?
as for the approved transfer, what if i can approve they are not compatible
with policy. somehow ARIN approve theirs and reject ours?

Niki










On Sat, Apr 5, 2014 at 10:29 AM, John Curran <jcurran at arin.net> wrote:

> On Apr 4, 2014, at 10:19 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:
>
> > However, in basis of john's reply i will rephrase his explanation as the
> following meaning:
> >
> > I will try my best to transfer the two /16 to third party via 8.3/8.4
> transfer immediately after a 8.2 transfer instead of reserving one /16 for
> another future sale in case of the other /16 to return to ARIN free pool or
>  rejecting for our second /16 transfer in future.
>
> Niki -
>
> If your second transfer (the 8.3 or 8.4 one) was not approved, you would
> be again be asked
> to either return the excess address space or pursue another transfer
> request to bring your
> utilization in line with policy.
>
> FYI,
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140405/ca8e18c9/attachment.htm>

From jcurran at arin.net  Fri Apr  4 22:58:06 2014
From: jcurran at arin.net (John Curran)
Date: Sat, 5 Apr 2014 02:58:06 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <CAPhL6MoErqG9Gto4Ls32B3Jai3vjGpOceDVBenYFu1yfqVCyaA@mail.gmail.com>
References: <CAPhL6MqdByzKy+HkRwt-fKto32NPRbMagJ_XqwLL8XgkTiLd_w@mail.gmail.com>
	<70DF690B-E283-4C58-B5C3-B97A237A291B@arin.net>
	<CAPhL6MoErqG9Gto4Ls32B3Jai3vjGpOceDVBenYFu1yfqVCyaA@mail.gmail.com>
Message-ID: <999A51B9-1ACA-4641-BD40-D253CF553CEF@arin.net>

On Apr 4, 2014, at 10:51 PM, xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>> wrote:
Please explain  what do you mean by  " pursue another transfer request to bring your
utilization in line with policy." ?

what does this "another transfer "refer to ?  which policy should we based on?

You indicated that "in case of the other /16 to return to ARIN free pool or  rejecting for our second /16 transfer in future." -
if that were to occur, ARIN would indicate that you should return address space or pursue another 8.3/8.4 transfer.

furthermore, i am afraid of ARIN rejecting the 8.2 transfer , not even to mention the second 8.3/8.4 transfer.
However, based on your reply,  no matter what happens, ARIN will definitely approve the 8.2 transfer and ARIN will only impose "restriction" on 8.3/8.4 transfer ?   and the utilisation rate in 8.2 transfer is just  a paper tiger ?

No.  Your M&A transfer may indeed be rejected if you do not have adequate
documentation; see my prior email regarding list of acceptable documents.

It would be best if you contact Hostmaster at arin.net<mailto:Hostmaster at arin.net> with any questions specific
to your situation.  The PPML mailing list is for policy development discussions,
not registry policy administration.

Thanks!
/John

John Curran
President and CEO
ARIN

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

From David.Huberman at microsoft.com  Fri Apr  4 23:32:23 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Sat, 5 Apr 2014 03:32:23 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <CAPhL6MqdByzKy+HkRwt-fKto32NPRbMagJ_XqwLL8XgkTiLd_w@mail.gmail.com>
References: <CAPhL6MqdByzKy+HkRwt-fKto32NPRbMagJ_XqwLL8XgkTiLd_w@mail.gmail.com>
Message-ID: <ad6ee937609e4505baf2fbb9405bf13f@DM2PR03MB398.namprd03.prod.outlook.com>

"Niki",



I'm confused by the questions, because the answers seem obvious, don't they?



Did you buy a company that has two /16s?  Just keep company X operating as company X! Find a buyer for one /16, and have the company you bought - company X - do an 8.3 transfer to the buyer.  It's not relevant to the process that your main company bought company X - it just adds unnecessary complexity to the ARIN process.  Then find a second buyer for a second /16 and repeat.



I guess it's possible it's too late - that company X is already closed and all of its assets are legally owned by your main company.  If that happened to me, then I would just find a buyer who wants the first /16. Then I'd submit an 8.3 transfer to sell it to them.  During the 8.3 transfer, ARIN will ask you for documentation that shows you own the company X that has the Whois registrations today.  You show them the legal documentation, then you move on to the 8.3 part of the transfer.  I'm not sure why you're worried about ARIN taking back the second /16 which isn't sold yet. RSA paragraph 6 says they can't do that.



N.B. I am not your lawyer, and I am not providing you with legal advice. I am not providing you advice on behalf of my employer, and I do not speak for my employer.



/david









________________________________

From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of xiaofan yang <nikiyangxf at gmail.com>
Sent: Friday, April 4, 2014 7:19 PM
To: kkargel at polartel.com
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

Hi Kevin,

I am quite confused by John's explanation too.
It seems ARIN always provides plenty of information meaning nothing.
Same happens to ask HM, HM will always  reply neutrally and I still cannot know it is yes or no!

However, in basis of john's reply i will rephrase his explanation as the following meaning:

I will try my best to transfer the two /16 to third party via 8.3/8.4 transfer immediately after a 8.2 transfer instead of reserving one /16 for another future sale in case of the other /16 to return to ARIN free pool or  rejecting for our second /16 transfer in future.

Niki



Hi John,

In basis of your reply, if the block is underutilised,ARIN will either ask the company to return the IPs or transfer to other third party via 8.3 transfer after our 8.2 transfer.

Correct.

Say we have two /16 after this 8.2 transfer, what if we only transfer one /16 to the other third party via 8.3 transfer, meanwhile, we keep the other /16 left unused after our 8.2 transfer for quiet a while. Will ARIN ask us to return the remained /16 to the free pool? furthmore, how long will ARIN allow us to keep the other /16 unused before we transfer it to the third party via 8.3 transfer ?

Niki -

ARIN will continue to work with you as needed, so long as you are still working
in good faith towards compliance with policy. For more information on your
particular circumstances, please contact <hostmaster at arin.net<mailto:hostmaster at arin.net><mailto:hostmaster at arin.net>>.

Thanks!
/John

John Curran
President and CEO
ARIN

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

From nikiyangxf at gmail.com  Sat Apr  5 00:36:16 2014
From: nikiyangxf at gmail.com (xiaofan yang)
Date: Sat, 5 Apr 2014 12:36:16 +0800
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <999A51B9-1ACA-4641-BD40-D253CF553CEF@arin.net>
References: <CAPhL6MqdByzKy+HkRwt-fKto32NPRbMagJ_XqwLL8XgkTiLd_w@mail.gmail.com>
	<70DF690B-E283-4C58-B5C3-B97A237A291B@arin.net>
	<CAPhL6MoErqG9Gto4Ls32B3Jai3vjGpOceDVBenYFu1yfqVCyaA@mail.gmail.com>
	<999A51B9-1ACA-4641-BD40-D253CF553CEF@arin.net>
Message-ID: <CAPhL6Mp7rpv93hcn69CiuLFNQ9haLUej7HMK2q-jgovr1YFF3Q@mail.gmail.com>

Hi John

 Your M&A transfer may indeed be rejected if you do not have adequate
documentation; see my prior email regarding list of acceptable documents.


As refer to your list of acceptable documents,  please help to resend the
list to me cos i cannot find your previous email.

thanks,
Niki



On Sat, Apr 5, 2014 at 10:58 AM, John Curran <jcurran at arin.net> wrote:

>  On Apr 4, 2014, at 10:51 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:
>
>  Please explain  what do you mean by  " pursue another transfer request
> to bring your
> utilization in line with policy." ?
>
>  what does this "another transfer "refer to ?  which policy should we
> based on?
>
>
>  You indicated that "in case of the other /16 to return to ARIN free pool
> or  rejecting for our second /16 transfer in future." -
> if that were to occur, ARIN would indicate that you should return address
> space or pursue another 8.3/8.4 transfer.
>
>
>   furthermore, i am afraid of ARIN rejecting the 8.2 transfer , not even
> to mention the second 8.3/8.4 transfer.
> However, based on your reply,  no matter what happens, ARIN
> will definitely approve the 8.2 transfer and ARIN will only impose
> "restriction" on 8.3/8.4 transfer ?   and the utilisation rate in 8.2
> transfer is just  a paper tiger ?
>
>
>  No.  Your M&A transfer may indeed be rejected if you do not have adequate
> documentation; see my prior email regarding list of acceptable documents.
>
>  It would be best if you contact Hostmaster at arin.net with any questions
> specific
> to your situation.  The PPML mailing list is for policy development
> discussions,
> not registry policy administration.
>
>  Thanks!
> /John
>
>  John Curran
> President and CEO
> ARIN
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140405/7276e53b/attachment.htm>

From nikiyangxf at gmail.com  Sat Apr  5 00:37:52 2014
From: nikiyangxf at gmail.com (xiaofan yang)
Date: Sat, 5 Apr 2014 12:37:52 +0800
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <ad6ee937609e4505baf2fbb9405bf13f@DM2PR03MB398.namprd03.prod.outlook.com>
References: <CAPhL6MqdByzKy+HkRwt-fKto32NPRbMagJ_XqwLL8XgkTiLd_w@mail.gmail.com>
	<ad6ee937609e4505baf2fbb9405bf13f@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAPhL6Mop4Enu2LjsoV3wrqP5OTDqVzLKNQP=VGfRoeYzsTQDeQ@mail.gmail.com>

Hi David,

thanks for your advise.

Niki


On Sat, Apr 5, 2014 at 11:32 AM, David Huberman <
David.Huberman at microsoft.com> wrote:

>  "Niki",
>
>
>
> I'm confused by the questions, because the answers seem obvious, don't
> they?
>
>
>
> Did you buy a company that has two /16s?  Just keep company X operating as
> company X! Find a buyer for one /16, and have the company you bought -
> company X - do an 8.3 transfer to the buyer.  It's not relevant to the
> process that your main company bought company X - it just adds unnecessary
> complexity to the ARIN process.  Then find a second buyer for a second /16
> and repeat.
>
>
>
> I guess it's possible it's too late - that company X is already closed and
> all of its assets are legally owned by your main company.  If that happened
> to me, then I would just find a buyer who wants the first /16. Then I'd
> submit an 8.3 transfer to sell it to them.  During the 8.3 transfer, ARIN
> will ask you for documentation that shows you own the company X that has
> the Whois registrations today.  You show them the legal documentation, then
> you move on to the 8.3 part of the transfer.  I'm not sure why you're
> worried about ARIN taking back the second /16 which isn't sold yet.
> RSA paragraph 6 says they can't do that.
>
>
>
> N.B. I am not your lawyer, and I am not providing you with legal advice. I
> am not providing you advice on behalf of my employer, and I do not speak
> for my employer.
>
>
>
> /david
>
>
>
>
>
>
>
>
>
> ------------------------------
>
>  *From:* arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on
> behalf of xiaofan yang <nikiyangxf at gmail.com>
> *Sent:* Friday, April 4, 2014 7:19 PM
> *To:* kkargel at polartel.com
> *Cc:* arin-ppml at arin.net
>
> *Subject:* Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
>
>   Hi Kevin,
>
>  I am quite confused by John's explanation too.
> It seems ARIN always provides plenty of information meaning nothing.
> Same happens to ask HM, HM will always  reply neutrally and I still cannot
> know it is yes or no!
>
>  However, in basis of john's reply i will rephrase his explanation as the
> following meaning:
>
>  I will try my best to transfer the two /16 to third party via 8.3/8.4
> transfer immediately after a 8.2 transfer instead of reserving one /16 for
> another future sale in case of the other /16 to return to ARIN free pool or
>  rejecting for our second /16 transfer in future.
>
>  Niki
>
>
>
>  *Hi John,*
>
>  *In basis of your reply, if the block is underutilised,ARIN will either
> ask the company to return the IPs or transfer to other third party via 8.3
> transfer after our 8.2 transfer.*
>
>  *Correct.*
>
>  *Say we have two /16 after this 8.2 transfer, what if we only transfer
> one /16 to the other third party via 8.3 transfer, meanwhile, we keep the
> other /16 left unused after our 8.2 transfer for quiet a while. Will ARIN
> ask us to return the remained /16 to the free pool? furthmore, how long
> will ARIN allow us to keep the other /16 unused before we transfer it to
> the third party via 8.3 transfer ?*
>
>  *Niki -*
>
>  *ARIN will continue to work with you as needed, so long as you are still
> working*
> *in good faith towards compliance with policy. For more information on
> your*
> *particular circumstances, please contact <hostmaster at arin.net
> <hostmaster at arin.net><mailto:hostmaster at arin.net <hostmaster at arin.net>>>.*
>
>  *Thanks!*
> */John*
>
>  *John Curran*
> *President and CEO*
> *ARIN*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140405/6de05a5b/attachment.htm>

From nikiyangxf at gmail.com  Sat Apr  5 00:55:23 2014
From: nikiyangxf at gmail.com (xiaofan yang)
Date: Sat, 5 Apr 2014 12:55:23 +0800
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <CAPhL6Mop4Enu2LjsoV3wrqP5OTDqVzLKNQP=VGfRoeYzsTQDeQ@mail.gmail.com>
References: <CAPhL6MqdByzKy+HkRwt-fKto32NPRbMagJ_XqwLL8XgkTiLd_w@mail.gmail.com>
	<ad6ee937609e4505baf2fbb9405bf13f@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAPhL6Mop4Enu2LjsoV3wrqP5OTDqVzLKNQP=VGfRoeYzsTQDeQ@mail.gmail.com>
Message-ID: <CAPhL6MoXo5=GSuR=5OUuRrb+yEfcGHCoqH8OKm6nDYkXHJemJg@mail.gmail.com>

Hi David,

There is problem here.  the buyer who is interested in our first /16 want
us to update ARIN whois records before we sell it to the buyer.    we have
brought the company X and  this is the reason why we ask ARIN if ARIN could
do the 8.2 transfer first then followed by the 8.3 transfer next.  I am
afraid of providing too much confidential information to ARIN for such a
8.2 transfer  and i am also afraid of the utilisation  descriptions in the
8.2 policy.

Have you had any further  advises?
thanks,
Niki


On Sat, Apr 5, 2014 at 12:37 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:

> Hi David,
>
> thanks for your advise.
>
> Niki
>
>
> On Sat, Apr 5, 2014 at 11:32 AM, David Huberman <
> David.Huberman at microsoft.com> wrote:
>
>>  "Niki",
>>
>>
>>
>> I'm confused by the questions, because the answers seem obvious, don't
>> they?
>>
>>
>>
>> Did you buy a company that has two /16s?  Just keep company X operating
>> as company X! Find a buyer for one /16, and have the company you bought -
>> company X - do an 8.3 transfer to the buyer.  It's not relevant to the
>> process that your main company bought company X - it just adds unnecessary
>> complexity to the ARIN process.  Then find a second buyer for a second /16
>> and repeat.
>>
>>
>>
>> I guess it's possible it's too late - that company X is already closed
>> and all of its assets are legally owned by your main company.  If that
>> happened to me, then I would just find a buyer who wants the first
>> /16. Then I'd submit an 8.3 transfer to sell it to them.  During the 8.3
>> transfer, ARIN will ask you for documentation that shows you own the
>> company X that has the Whois registrations today.  You show them the legal
>> documentation, then you move on to the 8.3 part of the transfer.  I'm not
>> sure why you're worried about ARIN taking back the second /16 which isn't
>> sold yet. RSA paragraph 6 says they can't do that.
>>
>>
>>
>> N.B. I am not your lawyer, and I am not providing you with legal advice.
>> I am not providing you advice on behalf of my employer, and I do not speak
>> for my employer.
>>
>>
>>
>> /david
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>>  *From:* arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on
>> behalf of xiaofan yang <nikiyangxf at gmail.com>
>> *Sent:* Friday, April 4, 2014 7:19 PM
>> *To:* kkargel at polartel.com
>> *Cc:* arin-ppml at arin.net
>>
>> *Subject:* Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
>>
>>   Hi Kevin,
>>
>>  I am quite confused by John's explanation too.
>> It seems ARIN always provides plenty of information meaning nothing.
>> Same happens to ask HM, HM will always  reply neutrally and I still
>> cannot know it is yes or no!
>>
>>  However, in basis of john's reply i will rephrase his explanation as
>> the following meaning:
>>
>>  I will try my best to transfer the two /16 to third party via 8.3/8.4
>> transfer immediately after a 8.2 transfer instead of reserving one /16 for
>> another future sale in case of the other /16 to return to ARIN free pool or
>>  rejecting for our second /16 transfer in future.
>>
>>  Niki
>>
>>
>>
>>  *Hi John,*
>>
>>  *In basis of your reply, if the block is underutilised,ARIN will either
>> ask the company to return the IPs or transfer to other third party via 8.3
>> transfer after our 8.2 transfer.*
>>
>>  *Correct.*
>>
>>  *Say we have two /16 after this 8.2 transfer, what if we only transfer
>> one /16 to the other third party via 8.3 transfer, meanwhile, we keep the
>> other /16 left unused after our 8.2 transfer for quiet a while. Will ARIN
>> ask us to return the remained /16 to the free pool? furthmore, how long
>> will ARIN allow us to keep the other /16 unused before we transfer it to
>> the third party via 8.3 transfer ?*
>>
>>  *Niki -*
>>
>>  *ARIN will continue to work with you as needed, so long as you are
>> still working*
>> *in good faith towards compliance with policy. For more information on
>> your*
>> *particular circumstances, please contact <hostmaster at arin.net
>> <hostmaster at arin.net><mailto:hostmaster at arin.net <hostmaster at arin.net>>>.*
>>
>>  *Thanks!*
>> */John*
>>
>>  *John Curran*
>> *President and CEO*
>> *ARIN*
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140405/f95d8af0/attachment.htm>

From jcurran at arin.net  Sat Apr  5 00:59:12 2014
From: jcurran at arin.net (John Curran)
Date: Sat, 5 Apr 2014 04:59:12 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <CAPhL6Mp7rpv93hcn69CiuLFNQ9haLUej7HMK2q-jgovr1YFF3Q@mail.gmail.com>
References: <CAPhL6MqdByzKy+HkRwt-fKto32NPRbMagJ_XqwLL8XgkTiLd_w@mail.gmail.com>
	<70DF690B-E283-4C58-B5C3-B97A237A291B@arin.net>
	<CAPhL6MoErqG9Gto4Ls32B3Jai3vjGpOceDVBenYFu1yfqVCyaA@mail.gmail.com>
	<999A51B9-1ACA-4641-BD40-D253CF553CEF@arin.net>
	<CAPhL6Mp7rpv93hcn69CiuLFNQ9haLUej7HMK2q-jgovr1YFF3Q@mail.gmail.com>
Message-ID: <C6948082-2862-4586-8E42-041F71956DE7@arin.net>

On Apr 5, 2014, at 12:36 AM, xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>> wrote:

Hi John

 Your M&A transfer may indeed be rejected if you do not have adequate
documentation; see my prior email regarding list of acceptable documents.


As refer to your list of acceptable documents,  please help to resend the list to me cos i cannot find your previous email.

Niki -

  The previous email is attached.   As noted therein, the transfer documentation requirements
  can be found here:  <https://www.arin.net/resources/request/transfers_8_2.html>

  I now ask that you pursue further questions with hostmaster at arin.net<mailto:hostmaster at arin.net>, as the PPML mailing
  list is for policy development not for routine registry request processing.

Thanks!
/John

John Curran
President and CEO
ARIN

===
Begin forwarded message:

From: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements
Date: April 2, 2014 at 7:59:20 PM EDT
To: xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>

On Apr 2, 2014, at 4:27 PM, xiaofan yang <nikiyangxf at gmail.com<mailto:nikiyangxf at gmail.com>> wrote:

Hi John,

I have further enquiry about ARIN 8.2 process.

Number one:I am also worried about the costs of doing a 8.2 transfer followed by a 8.3 transfer.  I wonder if I will have to involve the legal help to deal with ARIN legal.  In my case I bought a company that now is out of business. How complicated does ARIN make this process?  I want some assurance that I will be treated equally to any other companies whether it is  a big company or a small company like us.

Niki -

You will be treated equally, but in truth I'm not certain that is actually what you want...
(for example, a process which seems routine for a large organization could still pose
a disproportionate burden to a smaller organization since organization size is not a
factor in the verification process.)

The first and foremost activity is to make sure that we have your organization registered
as the rightful address holder, and that will require an NRPM 8.2 transfer.  It can actually
be relatively straightforward process, as long as you have clear documentation of the
purchase of the company.  Review the instructions here for additional information about
what is accepted - <https://www.arin.net/resources/request/transfers_8_2.html>

Number two:  If we do a 8.2 transfer followed by a 8.3 transfer, will the stated purpose for our number resources remains the same?? I am afraid of that ARIN will not approve our transfer.

If you are the clear party with the rights after your purchase, ARIN will approve your
transfer.  We may note that you have more addresses than you now need, and thus
we expect you to return or transfer the remainder (but that would seem to line up with
your intentions in any case.)

If you have purchased a company without adequate documentation, or if multiple
parties purchased multiple pieces of the company, or if there some question about
what was purchased based on the documentation, then it can be more challenging
to get the resources appropriately listed with you as the rightful holder.  You will need
to apply for the transfer and work with the ARIN Hostmaster to determine if there is
any issue in your particular case.

Number three:  As we have bought the company,  do we have the property right on those IPs?  in our past agreement and future agreement arranged for 8.3,  we would like to have some kinds of property right on those IPs,  will that conflict with ARIN policy?

Wonderful question - it is ARIN's position that you have a specific set of rights to the
address blocks in the registry (as defined by the registration services agreement that
you enter with ARIN), and these rights include:

   (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;
   (2) The right to use the Included Number Resources within the ARIN database; and
   (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.

ARIN registration services agreement includes a specific disclaimer of property rights
in the address blocks, as it is inconsistent with the ability to manage the address blocks
in accordance with community-developed policy in the region.  If you have other beliefs
with respect to your rights, that would probably be an area for you to seek legal advice.

I hope this helps; please do not hesitate to ask if you have any additional questions.

Thanks!
/John

John Curran
President and CEO
ARIN

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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/20140405/cd1e6d1e/attachment.htm>

From David.Huberman at microsoft.com  Sat Apr  5 00:59:59 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Sat, 5 Apr 2014 04:59:59 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <CAPhL6MoXo5=GSuR=5OUuRrb+yEfcGHCoqH8OKm6nDYkXHJemJg@mail.gmail.com>
References: <CAPhL6MqdByzKy+HkRwt-fKto32NPRbMagJ_XqwLL8XgkTiLd_w@mail.gmail.com>
	<ad6ee937609e4505baf2fbb9405bf13f@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAPhL6Mop4Enu2LjsoV3wrqP5OTDqVzLKNQP=VGfRoeYzsTQDeQ@mail.gmail.com>,
	<CAPhL6MoXo5=GSuR=5OUuRrb+yEfcGHCoqH8OKm6nDYkXHJemJg@mail.gmail.com>
Message-ID: <67ccf46e44ab468fa528b839f6cd14eb@DM2PR03MB398.namprd03.prod.outlook.com>

You wrote:  "the buyer who is interested in our first /16 want us to update ARIN whois records before we sell it to the buyer. "



Perhaps if you solve that problem with your buyer, the rest of your issues become moot.  ARIN policy and procedure can only go so far. Private parties have to put forth effort, too.


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

From hannigan at gmail.com  Sat Apr  5 05:16:48 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Sat, 5 Apr 2014 05:16:48 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
In-Reply-To: <67ccf46e44ab468fa528b839f6cd14eb@DM2PR03MB398.namprd03.prod.outlook.com>
References: <CAPhL6MqdByzKy+HkRwt-fKto32NPRbMagJ_XqwLL8XgkTiLd_w@mail.gmail.com>
	<ad6ee937609e4505baf2fbb9405bf13f@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAPhL6Mop4Enu2LjsoV3wrqP5OTDqVzLKNQP=VGfRoeYzsTQDeQ@mail.gmail.com>
	<CAPhL6MoXo5=GSuR=5OUuRrb+yEfcGHCoqH8OKm6nDYkXHJemJg@mail.gmail.com>
	<67ccf46e44ab468fa528b839f6cd14eb@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <BCD73EC9-FD20-469D-BCB6-C5AE4F1ED080@gmail.com>


May also be wise to use an address broker or market maker who can escrow funds with completion guarantees. They generally know the process. Sounds like it might be a useful service here.    

Pick one: 

Addrex -  Expert knowledge. Know where the bodies are hidden 

Hilco - Boutique/chapter 7/11 transactions 

Kalorama - Good money guys 

I know I forgot a few corp names. Apologies. (Mike Burns)


Best, 

Martin 



> On Apr 5, 2014, at 0:59, David Huberman <David.Huberman at microsoft.com> wrote:
> 
> You wrote:  "the buyer who is interested in our first /16 want us to update ARIN whois records before we sell it to the buyer. "
> 
>  
> 
> Perhaps if you solve that problem with your buyer, the rest of your issues become moot.  ARIN policy and procedure can only go so far. Private parties have to put forth effort, too.
> 
>  
> 
> _______________________________________________
> 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/20140405/58326b2c/attachment.htm>

From nikiyangxf at gmail.com  Sat Apr  5 21:53:00 2014
From: nikiyangxf at gmail.com (xiaofan yang)
Date: Sun, 6 Apr 2014 09:53:00 +0800
Subject: [arin-ppml]  ARIN-PPML Digest, Vol 106, Issue 8/Fraud Report
Message-ID: <CAPhL6MrmHdLbc=gYxqi9t6y5fQ+MujSJZxF3hG8yMk5QybtPVA@mail.gmail.com>

Message: 1
Date: Fri, 4 Apr 2014 15:34:22 -0700
From: Owen DeLong <owen at delong.com>
To: David Huberman <David.Huberman at microsoft.com>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
Message-ID: <CBC5D4D5-FF0C-4B66-8B60-395667AE194C at delong.com>
Content-Type: text/plain; charset=us-ascii

I find this very interesting considering that both Stephen and I wrote NRPM
12 as an effort to prevent ARIN from over-reaching on enforcement and to
provide reassurance to the community that ARIN was focused on providing
appropriate protections of community resources and not merely bureaucracy
for the sake of bureaucracy.

I do not believe that the existing provisions in NRPM 4 or NRPM 6 for the
prevention of fraud and/or gaming of the system are unnecessary or obviated
by what is contained in section 12. Indeed, in order to function at all,
section 12 depends on those policies to provide guidance as to how and when
the enforcement mechanisms defined in section 12 are to be used.

Owen

On Apr 4, 2014, at 9:57 AM, David Huberman <David.Huberman at microsoft.com>
wrote:


In my message you are replying to, I accidentally forgot to address the
hijacking issue. (Last message from me on list today, I promise!)


I think Owen DeLong and Stephen Sprunk did a really good job addressing the
whole hijacking and scamming problem when they authored NRPM section 12.
Between ARIN's legal protections in the RSA and as a business incorporated
in, and operating in, the United States, and the policy levers that NRPM 12
give, I think that whole issue is well covered by policy. In general, I do
not agree with section 4, 6, or 6 policy that tries to account for
scammers. We should make policy for the 99%, not the 1%. Let ARIN as a
business, and ARIN as an enforcer of NRPM 12, deal with that -- and report
back to us any deficiencies in tools.





*Hi Guys, *


*I have noticed a fraud application and had reported
tkt [ARIN-20140107-F1419] to ARIN long time ago. What i can have from ARIN
when i am asking an update is that  it is still under the investigation or
rely something meaning nothing. *


*I agree with both of your guys opinions here( refer to NRPM 12). However,
when a the fraud happens, ARIN should work as the enforcer to reclaim the
IPv4 back.   as i have already provided enough  evidences to approve the
fraud behaviour without receiving any solid reply from ARIN.   I will have
to choose to disclose all the evidences to the community in basis of which
the following conditions come first.*


*Condition 1: ARIN run out of its free pool or ARIN keeps allocating
another /15 to this Fraud.*

*Condition 2: Wait for another 3months.  Then totally ARIN has 6 months to
finalise  the Fraud investigation.  maybe as a bureau organisation  6-month
is too short for ARIN to finalise a Fraud investigation?*



*Niki*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140406/11853c2e/attachment.htm>

From sandrabrown at ipv4marketgroup.com  Sun Apr  6 11:49:46 2014
From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com)
Date: Sun, 06 Apr 2014 08:49:46 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
Message-ID: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>


------------------------------
Date: Fri, 4 Apr 2014 19:41:04 -0700
From: Jay Martin <jaymartin926 at gmail.com>
To: David.Huberman at microsoft.com
Cc: "arin-ppml at arin.net" <ARIN-PPML at arin.net>
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
Message-ID:
 <CALJtNObriexj+m0-V5kXwsPTG0u8q+tO2GU-S8v3zAcTb7=vMA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"


Hi David,

<snip>

Why do you think remove needs test will be enhance a more accurate
whois?

<snip>

Jay



Hi Jay:

Most instances where the whois is incorrect are cases of legacy IPv4
addresses.  Knowledgeable legacy IPv4 holders believe they have property
rights to their IPv4 addresses.

If they approach ARIN to bring the registry up to date, ARIN will
instruct them to sign an LRSA.  The LRSA contains text that explicitly
forces them to admit they have no property rights.

It they do not approach ARIN, and they keep their assumed property
rights, they hope in the future, for the benefit of being able to do
whatever they want with their IP's, 
such as transfer to any buyer in North America, Europe , or Asia without
ARIN permission.  It has never been proven in any court that ARIN
approval of a legacy transfer without an agreement
is necessary; however  for ~$400,000-500,000 it is hardly worthwhile for
a /16 owner to risk taking on ARIN in court to fight for its property
rights. 

Perhaps at some point some party with more at stake, will force the
property right issue in court, and this is why there is low uptake on
signing LRSA's by legacy IP address holders.

It is possible that RIPE NCC will implement an inter-RIR policy, and
RIPE has no-needs justification.  What will ARIN do, if a legacy company
based in North America, with no ARIN
 agreement, transfers its IP's to a RIPE NCC member?  If RIPE registers
the IP's, will ARIN refuse to un-register the IPS, when the legacy
holder has no contract with them?  

Consider a similar situation where a company has legacy IP's in North
America and is an LIR in RIPE NCC and has no ARIN agreement.  What if it
wishes to transfer the IP's from its North 
American operations to its European operations?   It would ask the RIPE
NCC to register its IPs, and ARIN to unregister, and it has no agreement
with ARIN.  Would ARIN refuse?

This all comes back to the needs test and the LRSA.  If both were
removed, we would have a more accurate whois.

I believe it benefits whois accuracy and legacy IPv4 holders more than
it benefits anyone, including large companies.  My experience as an IPv4
broker, having completed
 more than 80 transactions globally,  is that large successful companies
have a lot of IP's and IPv6 that are registered with ARIN.   They want
to continue that 
relationship with ARIN and value that relationship more than removal of
needs justification.  I believe Mr. Huberman is speaking for the benefit
of the community at large 
based on his experience working at ARIN, and because he sees the bigger
picture of how inaccurate the registry is, and realizes these bigger
issues, and is merely pointing
 out that removal of needs justification will fix part of the problem.  
I have never met Mr. Huberman but I certainly agree with the views he
has presented here for the community's benefit,
and I think we should thank him for his guidance.

Sandra Brown speaking as 
President, IPv4 Market Group


From jcurran at arin.net  Sun Apr  6 12:33:08 2014
From: jcurran at arin.net (John Curran)
Date: Sun, 6 Apr 2014 16:33:08 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
Message-ID: <F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>

PPML community - 

Without speaking for or against any given policy proposal, it is 
necessary to respond to several of Sandra's remarks as they do not 
reflect the actual structure of the Internet Number Registry System....

On Apr 6, 2014, at 11:49 AM, sandrabrown at ipv4marketgroup.com wrote:
> It they do not approach ARIN, and they keep their assumed property
> rights, they hope in the future, for the benefit of being able to do
> whatever they want with their IP's, 
> ...

To the extent that the community feels that registry policy should be
applicable in general to the management of address blocks in the region,
then the rights afforded to address holders must definitely be a subset 
of what most folks would consider "property rights."  In particular, 
to the extent that it is desirable to have community-developed policy 
applicable to the _administration_ of IPv4 address space rather than 
simply to the _assignment_ of address space is a question worthy of 
discussion given the imminent depletion of the regional IPv4 free pool), 
but absent any change in direction, ARIN must hold to the position set 
at its establishment and its in foundational documents that all address 
space in the registry is subject to community-develop number resource 
policy.

> Perhaps at some point some party with more at stake, will force the
> property right issue in court,


That actually could be quite beneficial, as would help in providing
further certainty regarding the ability of ARIN to maintain the registry
per the wishes and policies developed by the community.  Parties without
any agreement with ARIN asserting rights against particular entries in 
the registry have a rather interesting task before them, however, so it 
may take some time before this particular event occurs...

ARIN is part of a Internet number registry system which includes the IANA 
and the other regional registries; we collectively administer one registry 
of address space with each block associated with a single address holder, 
i.e. each block is globally unique; one important aspect of this is that 
an address block within a given regional registry remains within that 
registry unless there is a mutual agreement that it is administered by 
another RIR.  Parties that undertake transfers would be well-advised to 
read the policy documents of the Regional Internet registries which 
reflect these same principles.

Thanks!
/John

John Curran
President and CEO
ARIN




From joelja at bogus.com  Sun Apr  6 14:22:55 2014
From: joelja at bogus.com (joel jaeggli)
Date: Sun, 06 Apr 2014 11:22:55 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <66E414654AD098469738606C8E7B03B03D25F65BC0@P1MBX03.HMC1.COMCAST.NET>
References: <5331CA99.2000806@arin.net>	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>	<5334711E.1000808@umn.edu>	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>	<CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>	<CAC6JZKQuN8gzPR6utNrBVYougW5qtiS3u+YadUBnXKWBHGFr_w@mail.gmail.com>
	<66E414654AD098469738606C8E7B03B03D25F65BC0@P1MBX03.HMC1.COMCAST.NET>
Message-ID: <53419B7F.6030507@bogus.com>

On 3/28/14, 9:57 AM, Bill Buhler wrote:
> So if my understanding is correct, they basically performed a routing
> man in the middle attack on live IPv6 prefixes. Pardon my
> understanding level, but how did they keep from creating routing
> loops and service interruptions. I'm also a little concerned about
> performance and link loads. Are my concerns legitimate and inline?

if you withdraw your prefix entirely then the covering aggregate would
attract the traffic.

otherwise longest match wins.

> Thanks,
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140406/6beb1cbb/attachment.sig>

From mueller at syr.edu  Mon Apr  7 10:17:36 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 7 Apr 2014 14:17:36 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
Message-ID: <c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>



> -----Original Message-----
> 
> To the extent that the community feels that registry policy should be
> applicable in general to the management of address blocks in the region,
> then the rights afforded to address holders must definitely be a subset of
> what most folks would consider "property rights."  In particular, to the extent

I think the real issue is whether ARIN has any rights claims over number block holders it does not have a contract with. RIPE seems to have foregone any such claims. The sky has not fallen in Europe.

> absent any change in
> direction, ARIN must hold to the position set at its establishment and its in
> foundational documents that all address space in the registry is subject to
> community-develop number resource policy.

Not sure I buy the assertion that these principles were in the foundational documents; why did you need to add this language later? The 'no property rights' language came very late in the day.

> > Perhaps at some point some party with more at stake, will force the
> > property right issue in court,
> 
> That actually could be quite beneficial, as would help in providing further
> certainty regarding the ability of ARIN to maintain the registry per the wishes
> and policies developed by the community.  Parties without any agreement

I think it would be easier for everyone if ARIN would just ease its needs-assessment requirements for transfers. The whole threat of litigation could be dissipated in a week if this happened. 



From cja at daydream.com  Mon Apr  7 10:37:06 2014
From: cja at daydream.com (CJ Aronson)
Date: Mon, 7 Apr 2014 08:37:06 -0600
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
Message-ID: <CAC6JZKTDertmBY5d8A+fkPQGj7XfidhWDFJLgmHe5w7tV1_Ykw@mail.gmail.com>

Milton if someone wants "ARIN to ease it's needs assessment requirements
for transfers" then there has to be a policy proposal submitted that gains
community support.  ARIN can't just change this without the process being
followed.  In the past the policies to ease needs assessment have not
gained community support but things change so who knows.

----Cathy


On Mon, Apr 7, 2014 at 8:17 AM, Milton L Mueller <mueller at syr.edu> wrote:

>
>
> > -----Original Message-----
> >
> > To the extent that the community feels that registry policy should be
> > applicable in general to the management of address blocks in the region,
> > then the rights afforded to address holders must definitely be a subset
> of
> > what most folks would consider "property rights."  In particular, to the
> extent
>
> I think the real issue is whether ARIN has any rights claims over number
> block holders it does not have a contract with. RIPE seems to have foregone
> any such claims. The sky has not fallen in Europe.
>
> > absent any change in
> > direction, ARIN must hold to the position set at its establishment and
> its in
> > foundational documents that all address space in the registry is subject
> to
> > community-develop number resource policy.
>
> Not sure I buy the assertion that these principles were in the
> foundational documents; why did you need to add this language later? The
> 'no property rights' language came very late in the day.
>
> > > Perhaps at some point some party with more at stake, will force the
> > > property right issue in court,
> >
> > That actually could be quite beneficial, as would help in providing
> further
> > certainty regarding the ability of ARIN to maintain the registry per the
> wishes
> > and policies developed by the community.  Parties without any agreement
>
> I think it would be easier for everyone if ARIN would just ease its
> needs-assessment requirements for transfers. The whole threat of litigation
> could be dissipated in a week if this happened.
>
> _______________________________________________
> 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/20140407/189f0de0/attachment.htm>

From David.Huberman at microsoft.com  Mon Apr  7 10:44:57 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 7 Apr 2014 14:44:57 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <CAC6JZKTDertmBY5d8A+fkPQGj7XfidhWDFJLgmHe5w7tV1_Ykw@mail.gmail.com>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>,
	<CAC6JZKTDertmBY5d8A+fkPQGj7XfidhWDFJLgmHe5w7tV1_Ykw@mail.gmail.com>
Message-ID: <ecb1c7511ea94a748541c6477b00582e@DM2PR03MB398.namprd03.prod.outlook.com>

2014-9 (about resolving the conflict between NRPM 8.2 and the RSA) is the first step towards this goal.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)
________________________________
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of CJ Aronson <cja at daydream.com>
Sent: Monday, April 7, 2014 7:37:06 AM
To: Milton L Mueller
Cc: John Curran; arin-ppml at arin.net; sandrabrown at ipv4marketgroup.com
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)

Milton if someone wants "ARIN to ease it's needs assessment requirements for transfers" then there has to be a policy proposal submitted that gains community support.  ARIN can't just change this without the process being followed.  In the past the policies to ease needs assessment have not gained community support but things change so who knows.

----Cathy


On Mon, Apr 7, 2014 at 8:17 AM, Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>> wrote:


> -----Original Message-----
>
> To the extent that the community feels that registry policy should be
> applicable in general to the management of address blocks in the region,
> then the rights afforded to address holders must definitely be a subset of
> what most folks would consider "property rights."  In particular, to the extent

I think the real issue is whether ARIN has any rights claims over number block holders it does not have a contract with. RIPE seems to have foregone any such claims. The sky has not fallen in Europe.

> absent any change in
> direction, ARIN must hold to the position set at its establishment and its in
> foundational documents that all address space in the registry is subject to
> community-develop number resource policy.

Not sure I buy the assertion that these principles were in the foundational documents; why did you need to add this language later? The 'no property rights' language came very late in the day.

> > Perhaps at some point some party with more at stake, will force the
> > property right issue in court,
>
> That actually could be quite beneficial, as would help in providing further
> certainty regarding the ability of ARIN to maintain the registry per the wishes
> and policies developed by the community.  Parties without any agreement

I think it would be easier for everyone if ARIN would just ease its needs-assessment requirements for transfers. The whole threat of litigation could be dissipated in a week if this happened.

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto: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/20140407/b54f932d/attachment.htm>

From jcurran at arin.net  Mon Apr  7 11:05:38 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 7 Apr 2014 15:05:38 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
Message-ID: <B2786520-D464-4DE2-85C0-DCCB848BB9A4@arin.net>

On Apr 7, 2014, at 10:17 AM, Milton L Mueller <mueller at syr.edu> wrote:
>> To the extent that the community feels that registry policy should be
>> applicable in general to the management of address blocks in the region,
>> then the rights afforded to address holders must definitely be a subset of
>> what most folks would consider "property rights."  In particular, to the extent
> 
> I think the real issue is whether ARIN has any rights claims over number block holders it does not have a contract with. ...

ARIN has does have the right to manage the all of the address blocks 
in the registry in accordance with the community-developed policy (and 
we have doing so since inception); ergo the responsibility lies with 
those who assert otherwise to build and argue a meaningful case.

>> absent any change in
>> direction, ARIN must hold to the position set at its establishment and its in
>> foundational documents that all address space in the registry is subject to
>> community-develop number resource policy.
> 
> Not sure I buy the assertion that these principles were in the foundational documents; ...

For example: <https://www.nsf.gov/news/news_summ.jsp?cntn_id=102819> -
"Creation of ARIN will give the users of IP numbers (mostly Internet 
service providers, corporations and other large institutions) a voice 
in the policies by which they are _managed and allocated_ [emphasis
added] within the North American region."  ARIN's incorporation is 
another example, noting a purpose to "manage and help conserve scarce 
Internet protocol resources" As another example,  RFC 2050 was most 
certainly definitive at the time and is quite explicit on the matter - 
"The transfer of IP addresses from one party to another must be 
approved by the regional registries.  The party trying to obtain the 
IP address must meet the same criteria as if they were requesting an 
IP address directly from the IR."

I believe that the community is free to change the applicable number 
resource policy in this area, but it would be rather difficult to argue 
that the application of community-developed policy (to transfers of 
already issued resources in the region) has not been position that 
has been in existence since the establishment of ARIN.

> I think it would be easier for everyone if ARIN would just ease its needs-assessment requirements for transfers. The whole threat of litigation could be dissipated in a week if this happened. 

It is certainly possible for the community to end up with policies 
which no longer require needs-assessment with respect to transfers;
ARIN would follow such policies with respect to the management of 
all resources in the registry, i.e. while such a change may address
timely concerns held by some, that would not result in any change to
the position that the ARIN community can establish policies applicable 
to the management of all number resources in the registry.

FYI,
/John

John Curran
President and CEO
ARIN






From mueller at syr.edu  Mon Apr  7 11:48:42 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 7 Apr 2014 15:48:42 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <CAC6JZKTDertmBY5d8A+fkPQGj7XfidhWDFJLgmHe5w7tV1_Ykw@mail.gmail.com>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
	<CAC6JZKTDertmBY5d8A+fkPQGj7XfidhWDFJLgmHe5w7tV1_Ykw@mail.gmail.com>
Message-ID: <c8abc90c47a94730965d162e981bc18a@EX13-MBX-13.ad.syr.edu>

Cathy,
Of course policy changes require policy proposals. I will assume that you do not think I am an idiot and that you made this observation for some other reason. But I don't know what it is.
More to the point, we have several proposals on the table that offer to mitigate some of the worst aspects of needs assessments. Let's see how they fare in Chicago.
--MM

From: CJ Aronson [mailto:cja at daydream.com]
Sent: Monday, April 07, 2014 10:37 AM
To: Milton L Mueller
Cc: John Curran; sandrabrown at ipv4marketgroup.com; arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)

Milton if someone wants "ARIN to ease it's needs assessment requirements for transfers" then there has to be a policy proposal submitted that gains community support.  ARIN can't just change this without the process being followed.  In the past the policies to ease needs assessment have not gained community support but things change so who knows.

----Cathy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140407/71ad5882/attachment.htm>

From cja at daydream.com  Mon Apr  7 11:56:12 2014
From: cja at daydream.com (CJ Aronson)
Date: Mon, 7 Apr 2014 09:56:12 -0600
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <c8abc90c47a94730965d162e981bc18a@EX13-MBX-13.ad.syr.edu>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
	<CAC6JZKTDertmBY5d8A+fkPQGj7XfidhWDFJLgmHe5w7tV1_Ykw@mail.gmail.com>
	<c8abc90c47a94730965d162e981bc18a@EX13-MBX-13.ad.syr.edu>
Message-ID: <CAC6JZKS3xv3Sazy0Px1_yCBo0N2om4L2_0fvsJukf0+8JZKs1Q@mail.gmail.com>

Milton I am terribly sorry.  The way your note was worded it looked to me
like you were asking ARIN to make a change that they can't without a policy
change to the NRPM.

Have a great weekend!
----Cathy


On Mon, Apr 7, 2014 at 9:48 AM, Milton L Mueller <mueller at syr.edu> wrote:

>  Cathy,
>
> Of course policy changes require policy proposals. I will assume that you
> do not think I am an idiot and that you made this observation for some
> other reason. But I don't know what it is.
>
> More to the point, we have several proposals on the table that offer to
> mitigate some of the worst aspects of needs assessments. Let's see how they
> fare in Chicago.
>
> --MM
>
>
>
> *From:* CJ Aronson [mailto:cja at daydream.com]
> *Sent:* Monday, April 07, 2014 10:37 AM
> *To:* Milton L Mueller
> *Cc:* John Curran; sandrabrown at ipv4marketgroup.com; arin-ppml at arin.net
>
> *Subject:* Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra
> Brown)
>
>
>
> Milton if someone wants "ARIN to ease it's needs assessment requirements
> for transfers" then there has to be a policy proposal submitted that gains
> community support.  ARIN can't just change this without the process being
> followed.  In the past the policies to ease needs assessment have not
> gained community support but things change so who knows.
>
>
>
> ----Cathy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140407/9af157b8/attachment.htm>

From cja at daydream.com  Mon Apr  7 12:10:31 2014
From: cja at daydream.com (CJ Aronson)
Date: Mon, 7 Apr 2014 10:10:31 -0600
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <CAC6JZKS3xv3Sazy0Px1_yCBo0N2om4L2_0fvsJukf0+8JZKs1Q@mail.gmail.com>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
	<CAC6JZKTDertmBY5d8A+fkPQGj7XfidhWDFJLgmHe5w7tV1_Ykw@mail.gmail.com>
	<c8abc90c47a94730965d162e981bc18a@EX13-MBX-13.ad.syr.edu>
	<CAC6JZKS3xv3Sazy0Px1_yCBo0N2om4L2_0fvsJukf0+8JZKs1Q@mail.gmail.com>
Message-ID: <CAC6JZKQxup-Cw7hunSE6g2LuCQHP6SnLSHko1_2O374q15HUEQ@mail.gmail.com>

Wow it's going to be one of those Mondays.. I meant this to say Hope you
had a great weekend!

Anyway sorry for my confusion about your post.  I think I'll just go have
some more coffee and maybe that will help.

Thanks!
-----Cathy


On Mon, Apr 7, 2014 at 9:56 AM, CJ Aronson <cja at daydream.com> wrote:

> Milton I am terribly sorry.  The way your note was worded it looked to me
> like you were asking ARIN to make a change that they can't without a policy
> change to the NRPM.
>
> Have a great weekend!
> ----Cathy
>
>
>
> On Mon, Apr 7, 2014 at 9:48 AM, Milton L Mueller <mueller at syr.edu> wrote:
>
>>  Cathy,
>>
>> Of course policy changes require policy proposals. I will assume that you
>> do not think I am an idiot and that you made this observation for some
>> other reason. But I don't know what it is.
>>
>> More to the point, we have several proposals on the table that offer to
>> mitigate some of the worst aspects of needs assessments. Let's see how they
>> fare in Chicago.
>>
>> --MM
>>
>>
>>
>> *From:* CJ Aronson [mailto:cja at daydream.com]
>> *Sent:* Monday, April 07, 2014 10:37 AM
>> *To:* Milton L Mueller
>> *Cc:* John Curran; sandrabrown at ipv4marketgroup.com; arin-ppml at arin.net
>>
>> *Subject:* Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra
>> Brown)
>>
>>
>>
>> Milton if someone wants "ARIN to ease it's needs assessment requirements
>> for transfers" then there has to be a policy proposal submitted that gains
>> community support.  ARIN can't just change this without the process being
>> followed.  In the past the policies to ease needs assessment have not
>> gained community support but things change so who knows.
>>
>>
>>
>> ----Cathy
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140407/797184b7/attachment.htm>

From bill at herrin.us  Mon Apr  7 12:59:32 2014
From: bill at herrin.us (William Herrin)
Date: Mon, 7 Apr 2014 12:59:32 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <B2786520-D464-4DE2-85C0-DCCB848BB9A4@arin.net>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
	<B2786520-D464-4DE2-85C0-DCCB848BB9A4@arin.net>
Message-ID: <CAP-guGUD+hL9ZDD6AFYi2qVwU4yVBiSi9gyK6M6WuYhLCiCWqA@mail.gmail.com>

On Mon, Apr 7, 2014 at 11:05 AM, John Curran <jcurran at arin.net> wrote:
> On Apr 7, 2014, at 10:17 AM, Milton L Mueller <mueller at syr.edu> wrote:

>>> absent any change in
>>> direction, ARIN must hold to the position set at its establishment and its in
>>> foundational documents that all address space in the registry is subject to
>>> community-develop number resource policy.
>>
>> Not sure I buy the assertion that these principles were in the foundational documents; ...


That's because John has misstated the language, discussion and
agreements surrounding ARIN's creation. Replace "address space in the
registry" with "address space subsequently assigned by the registry"
and the above would be accurate.


> For example: <https://www.nsf.gov/news/news_summ.jsp?cntn_id=102819> -
> "Creation of ARIN will give the users of IP numbers (mostly Internet
> service providers, corporations and other large institutions) a voice
> in the policies by which they are _managed and allocated_ [emphasis
> added] within the North American region."  ARIN's incorporation is

For example: http://archive.psg.com/970414.fncac.pdf

quoting from page 9:

"Current and old allocations and their DNS will be maintained with no
policy changes"

This was a sample the promises made and repeated publicly during
ARIN's creation, regardless of what was done behind the scenes. This
particular one was made to the federal government board which had to
approve ARIN's creation. What's more, ARIN has honored this promise in
every substantive respect for the better part of two decades, so by
now laches surely applies.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jcurran at arin.net  Mon Apr  7 13:29:17 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 7 Apr 2014 17:29:17 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <CAP-guGUD+hL9ZDD6AFYi2qVwU4yVBiSi9gyK6M6WuYhLCiCWqA@mail.gmail.com>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
	<B2786520-D464-4DE2-85C0-DCCB848BB9A4@arin.net>
	<CAP-guGUD+hL9ZDD6AFYi2qVwU4yVBiSi9gyK6M6WuYhLCiCWqA@mail.gmail.com>
Message-ID: <7B241487-C9C8-457B-A584-B5FF75D9086A@arin.net>

On Apr 7, 2014, at 12:59 PM, William Herrin <bill at herrin.us> wrote:

> "Current and old allocations and their DNS will be maintained with no
> policy changes"

Bill - 

Note that RFC 2050 was operative at that time, with language requiring the
recipient to meet the same criteria as when qualifying to receive space; i.e.
Even under your assertions above, legacy holders doing transfers would be 
still be subject to needs qualification of the recipient.  What _would_ be 
prevented is the community making a change to policy today regarding transfers 
to reflect changing circumstances...  That is obviously an outcome neither 
desirable nor reflecting the NSF and USG announcements supporting community-
developed policy for management of IP addresses in the region.

Thanks!
/John

John Curran
President and CEO
ARIN



From dogwallah at gmail.com  Mon Apr  7 13:33:32 2014
From: dogwallah at gmail.com (McTim)
Date: Mon, 7 Apr 2014 13:33:32 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
Message-ID: <CACAaNxjYRgRwuP1xWVoEcz1jNPvS_kTmXtj_UkurxYFW7U8LrA@mail.gmail.com>

On Sun, Apr 6, 2014 at 11:49 AM,  <sandrabrown at ipv4marketgroup.com> wrote:
>
> ------------------------------
> Date: Fri, 4 Apr 2014 19:41:04 -0700
> From: Jay Martin <jaymartin926 at gmail.com>
> To: David.Huberman at microsoft.com
> Cc: "arin-ppml at arin.net" <ARIN-PPML at arin.net>
> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
> Message-ID:
>  <CALJtNObriexj+m0-V5kXwsPTG0u8q+tO2GU-S8v3zAcTb7=vMA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Hi David,
>
> <snip>
>
> Why do you think remove needs test will be enhance a more accurate
> whois?
>
> <snip>
>
> Jay
>
>
>
> Hi Jay:
>
> Most instances where the whois is incorrect are cases of legacy IPv4
> addresses.


I do not believe this is an accurate statement of fact.  I believe
that most inaccuracies in RIR databases are due to either ignorance of
requirements of assignment registration or willfully not following
these requirements for a variety of reasons.

While I didn't spend a decade as a RIR Hostmaster, I did spend several
years as one, and conducted many training courses on LIR
responsibilities vis a vis the regiatry.  When folks understand what
they are supposed to do, they normally do it.

In addition, I authored a current policy in the AFRINIC region which
does not allow for reverse delegation to be done by the RIR until
assignments are made under the allocation.  Since this is a new
policy, there are no numbers available yet to determine if this will
have any impact on registry accuracy.


-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel


From mueller at syr.edu  Mon Apr  7 15:31:34 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 7 Apr 2014 19:31:34 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <CAP-guGUD+hL9ZDD6AFYi2qVwU4yVBiSi9gyK6M6WuYhLCiCWqA@mail.gmail.com>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
	<B2786520-D464-4DE2-85C0-DCCB848BB9A4@arin.net>
	<CAP-guGUD+hL9ZDD6AFYi2qVwU4yVBiSi9gyK6M6WuYhLCiCWqA@mail.gmail.com>
Message-ID: <64f295ca68154e2eb973242313f9d2a1@EX13-MBX-13.ad.syr.edu>

Thanks, Bill,
Always nice to have some institiutional memory brought to bear.

> -----Original Message-----
> 
> For example: http://archive.psg.com/970414.fncac.pdf
> 
> quoting from page 9:
> 
> "Current and old allocations and their DNS will be maintained with no policy
> changes"
> 
> This was a sample the promises made and repeated publicly during ARIN's
> creation, regardless of what was done behind the scenes. This particular one
> was made to the federal government board which had to approve ARIN's
> creation. What's more, ARIN has honored this promise in every substantive
> respect for the better part of two decades, so by now laches surely applies.
> 
> Regards,
> Bill Herrin
> 
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA
> 22042-3004


From jcurran at arin.net  Mon Apr  7 15:53:22 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 7 Apr 2014 19:53:22 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <64f295ca68154e2eb973242313f9d2a1@EX13-MBX-13.ad.syr.edu>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
	<B2786520-D464-4DE2-85C0-DCCB848BB9A4@arin.net>
	<CAP-guGUD+hL9ZDD6AFYi2qVwU4yVBiSi9gyK6M6WuYhLCiCWqA@mail.gmail.com>
	<64f295ca68154e2eb973242313f9d2a1@EX13-MBX-13.ad.syr.edu>
Message-ID: <8DFADA13-43BE-4B6B-A1B2-A91FA89EDC6D@arin.net>

On Apr 7, 2014, at 3:31 PM, Milton L Mueller <mueller at syr.edu> wrote:

> Thanks, Bill,
> Always nice to have some institiutional memory brought to bear.
> 
>> -----Original Message-----
>> 
>> For example: http://archive.psg.com/970414.fncac.pdf
>> 
>> quoting from page 9:
>> 
>> "Current and old allocations and their DNS will be maintained with no policy
>> changes"


Milton -

As noted, that "institutional memory" would permanently enshrine the very 
explicit RFC 2050 policy of requiring needs-based qualification in order 
to be the recipient of a transfer.  Luckily, the actual documentation of 
the formation of ARIN and NSF announcement of same are far more useful in 
this respect than the slidedeck that was used to to pitch the concept.

Thanks!
/John

John Curran
President and CEO
ARIN

From bill at herrin.us  Mon Apr  7 18:07:26 2014
From: bill at herrin.us (William Herrin)
Date: Mon, 7 Apr 2014 18:07:26 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <7B241487-C9C8-457B-A584-B5FF75D9086A@arin.net>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
	<B2786520-D464-4DE2-85C0-DCCB848BB9A4@arin.net>
	<CAP-guGUD+hL9ZDD6AFYi2qVwU4yVBiSi9gyK6M6WuYhLCiCWqA@mail.gmail.com>
	<7B241487-C9C8-457B-A584-B5FF75D9086A@arin.net>
Message-ID: <CAP-guGWSxFTtDARkUXO94mtXMgYZyNSqZeW1qgNtUTYJDAUvwQ@mail.gmail.com>

On Mon, Apr 7, 2014 at 1:29 PM, John Curran <jcurran at arin.net> wrote:
> On Apr 7, 2014, at 12:59 PM, William Herrin <bill at herrin.us> wrote:
>
>> "Current and old allocations and their DNS will be maintained with no
>> policy changes"
>
> Note that RFC 2050 was operative at that time, with language requiring the
> recipient to meet the same criteria as when qualifying to receive space; i.e.
> Even under your assertions above, legacy holders doing transfers would be
> still be subject to needs qualification of the recipient.

Hi John,

I don't recall being asked to reference or agree to RFC 2050 in the
template I submitted for my legacy block. Doubtless in part because
RFC 2050 hadn't yet been written. RFC2050 really isn't informative in
the manner you imply.

As I recollect the operative procedures of the day, it was: resend the
template with the new information which, as an existing registration
submitting a template from an authorized source, was honored without
further review. Does your recollection of the pre-ARIN administrative
procedures for transferring a block of network addresses differ?

This is a messy, messy court case if the matter ever comes to a head.
Does article 1 section 8 bar the existence of a intangible property
that congress hasn't defined? If it can exist, the registration
documents and process looked pretty permanent -- exactly as you'd
expect for a grant of property. But they didn't directly speak to the
question, either for or against. Highfalutin' and late-to-the-game
RFCs notwithstanding. But even if legacy addresses are property, does
ARIN have a perpetual obligation to _record_ changes to ownership? And
provide RDNS for free? But if ARIN obstructs anyone else from
providing RDNS, does that unlawfully encroach the property? And if
addresses are property, what are the antitrust implications for ARIN
asserting ownership of all the addresses it allocated since its
inception? Leasehold property is un-American; it was a major driver
(beside religion) in the population's original exodus from Europe. Our
law tends to view it with suspicion.

Messy. Best bet for everyone involved is to arrange for the matter to
never come to a head. Let the eventual deployment of IPv6 render it
moot.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jaymartin926 at gmail.com  Mon Apr  7 21:12:43 2014
From: jaymartin926 at gmail.com (Jay Martin)
Date: Mon, 7 Apr 2014 18:12:43 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <ecb1c7511ea94a748541c6477b00582e@DM2PR03MB398.namprd03.prod.outlook.com>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
	<CAC6JZKTDertmBY5d8A+fkPQGj7XfidhWDFJLgmHe5w7tV1_Ykw@mail.gmail.com>
	<ecb1c7511ea94a748541c6477b00582e@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CALJtNOZfFQwxkN38B6K1fE0AuYhXOXuDVvydA1oiTtw3At=9JQ@mail.gmail.com>

Hi David,


I disagree with you. Like your 2014-2,  2014-9 (about resolving the
conflict between NRPM 8.2 and the RSA) is one of the  step(or excuse) to
avoid 8.2 then 8.3/8.4 transfer policy to have IPv4 transferred everywhere,
which may cause the inaccurate of ARIN whois.


The unfair  RIR system has already favoured those who have cashed up
and this 2014-09 and 201402 will further  worsen this and "the rich becomes
more richer and the poor becomes more poorer" the community policy need to
balance "the poorer and the richer".  Normally Speculator comes more from
the "richer". I strong suggest to keep the 8.2 unchanged and against your
2014-02.  I have the evidences about some of the speculators who actively
comment in this PPML.


I doubt you write this on behalf of your employer and maybe MS is plotting
another big move( e.g transfer a /10 to Asia Pacific Region or out of use
IPs in RIPE region or M/A some dissolved companies with plenty of unused
IPv4 and would like to easy your own process of 8.2 without the utilisation
rate test etc However, I am sure there must have something happening under
the ground ).


Jay



On Mon, Apr 7, 2014 at 7:44 AM, David Huberman <David.Huberman at microsoft.com
> wrote:

>  2014-9 (about resolving the conflict between NRPM 8.2 and the RSA) is the
> first step towards this goal.
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> ------------------------------
> *From:* arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf
> of CJ Aronson <cja at daydream.com>
> *Sent:* Monday, April 7, 2014 7:37:06 AM
> *To:* Milton L Mueller
> *Cc:* John Curran; arin-ppml at arin.net; sandrabrown at ipv4marketgroup.com
> *Subject:* Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra
> Brown)
>
>  Milton if someone wants "ARIN to ease it's needs assessment requirements
> for transfers" then there has to be a policy proposal submitted that gains
> community support.  ARIN can't just change this without the process being
> followed.  In the past the policies to ease needs assessment have not
> gained community support but things change so who knows.
>
>  ----Cathy
>
>
> On Mon, Apr 7, 2014 at 8:17 AM, Milton L Mueller <mueller at syr.edu> wrote:
>
>>
>>
>> > -----Original Message-----
>> >
>> > To the extent that the community feels that registry policy should be
>> > applicable in general to the management of address blocks in the region,
>> > then the rights afforded to address holders must definitely be a subset
>> of
>> > what most folks would consider "property rights."  In particular, to
>> the extent
>>
>>  I think the real issue is whether ARIN has any rights claims over number
>> block holders it does not have a contract with. RIPE seems to have foregone
>> any such claims. The sky has not fallen in Europe.
>>
>> > absent any change in
>> > direction, ARIN must hold to the position set at its establishment and
>> its in
>> > foundational documents that all address space in the registry is
>> subject to
>> > community-develop number resource policy.
>>
>>  Not sure I buy the assertion that these principles were in the
>> foundational documents; why did you need to add this language later? The
>> 'no property rights' language came very late in the day.
>>
>> > > Perhaps at some point some party with more at stake, will force the
>> > > property right issue in court,
>> >
>> > That actually could be quite beneficial, as would help in providing
>> further
>> > certainty regarding the ability of ARIN to maintain the registry per
>> the wishes
>> > and policies developed by the community.  Parties without any agreement
>>
>>  I think it would be easier for everyone if ARIN would just ease its
>> needs-assessment requirements for transfers. The whole threat of litigation
>> could be dissipated in a week if this happened.
>>
>> _______________________________________________
>> 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/20140407/8f021416/attachment.htm>

From jcurran at arin.net  Tue Apr  8 03:54:16 2014
From: jcurran at arin.net (John Curran)
Date: Tue, 8 Apr 2014 07:54:16 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <CAP-guGWSxFTtDARkUXO94mtXMgYZyNSqZeW1qgNtUTYJDAUvwQ@mail.gmail.com>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
	<B2786520-D464-4DE2-85C0-DCCB848BB9A4@arin.net>
	<CAP-guGUD+hL9ZDD6AFYi2qVwU4yVBiSi9gyK6M6WuYhLCiCWqA@mail.gmail.com>
	<7B241487-C9C8-457B-A584-B5FF75D9086A@arin.net>
	<CAP-guGWSxFTtDARkUXO94mtXMgYZyNSqZeW1qgNtUTYJDAUvwQ@mail.gmail.com>
Message-ID: <985E5E83-ED63-479B-956B-8767BE6CE773@arin.net>

On Apr 7, 2014, at 6:07 PM, William Herrin <bill at herrin.us> wrote:

>> Note that RFC 2050 was operative at that time, with language requiring the
>> recipient to meet the same criteria as when qualifying to receive space; i.e.
>> Even under your assertions above, legacy holders doing transfers would be
>> still be subject to needs qualification of the recipient.
> 
> Hi John,
> 
> I don't recall being asked to reference or agree to RFC 2050 in the
> template I submitted for my legacy block. Doubtless in part because
> RFC 2050 hadn't yet been written. RFC2050 really isn't informative in
> the manner you imply.

Bill - 
 
You referenced the "promise" that '"Current and old allocations and 
their DNS will be maintained with no policy changes"'...

Given the statement made at the time that (once formed) ARIN would be 
maintaining old allocations with no policy _changes_, then there has 
to be policy applicable to those old allocations, and RFC2050, having 
just been written by the current InterNIC and RIR folks (as well as 
the IANA) would be the definitive reference.  It is not credible to 
say that the maintenance of old allocations was not subject to any 
policy when the presentation mades plain that there will be (upon 
ARIN's formation) no policy changes for maintenance of old allocations.

> As I recollect the operative procedures of the day, it was: resend the
> template with the new information which, as an existing registration
> submitting a template from an authorized source, was honored without
> further review. Does your recollection of the pre-ARIN administrative
> procedures for transferring a block of network addresses differ?

Probably best to refer to RFC 2050, since your resources were managed
by the InterNIC at that time, and RFC 2050 states: "This document 
describes the IP assignment policies currently used by the Regional 
Registries to implement the guidelines developed by the IANA."  That
does seem to answer your question regarding the operative procedures
of the day.

You first argued that ARIN promised to maintain old allocations with 
no policy changes, and subsequently (upon seeing that the actual policy 
directly supports needs-assessment for transfers) changed your argument 
to say that no policy at all is applicable to old resources...  I am 
fairly you can't argue both sides at the same time, so which is it?

> This is a messy, messy court case if the matter ever comes to a head.

Actually, it's rather straightforward from ARIN's perspective (but your
argument would probably be less messy if it were only arguing a single 
side of "applicable policy for old resources" at a time...)

> Messy. Best bet for everyone involved is to arrange for the matter to
> never come to a head. Let the eventual deployment of IPv6 render it
> moot.

That is one approach, but as noted earlier on the the list, there might 
be some incidental benefit out of a party pursuing its alleged property 
rights, as it would provide certainty regarding ARIN's ability to maintain 
the registry per the wishes and policies developed by the community.  

Thanks!
/John

John Curran
President and CEO
ARIN



From bill at herrin.us  Tue Apr  8 06:21:08 2014
From: bill at herrin.us (William Herrin)
Date: Tue, 8 Apr 2014 06:21:08 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <985E5E83-ED63-479B-956B-8767BE6CE773@arin.net>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
	<B2786520-D464-4DE2-85C0-DCCB848BB9A4@arin.net>
	<CAP-guGUD+hL9ZDD6AFYi2qVwU4yVBiSi9gyK6M6WuYhLCiCWqA@mail.gmail.com>
	<7B241487-C9C8-457B-A584-B5FF75D9086A@arin.net>
	<CAP-guGWSxFTtDARkUXO94mtXMgYZyNSqZeW1qgNtUTYJDAUvwQ@mail.gmail.com>
	<985E5E83-ED63-479B-956B-8767BE6CE773@arin.net>
Message-ID: <CAP-guGUN9cChVRR7k5r7LnE+1KTswaF6Xny9EQQizydWFzERAw@mail.gmail.com>

On Tue, Apr 8, 2014 at 3:54 AM, John Curran <jcurran at arin.net> wrote:
> Probably best to refer to RFC 2050, since your resources were managed
> by the InterNIC at that time, and RFC 2050 states: "This document
> describes the IP assignment policies currently used by the Regional
> Registries to implement the guidelines developed by the IANA."  That
> does seem to answer your question regarding the operative procedures
> of the day.

Hi John,

Not really, no. My question was about procedures followed in practice,
not policies that might or might not have been derived from RFC2050
and might or might not have been followed by NSI acting as Internic
(not an RIR) in the last few months leading up to ARIN's inception.


> You first argued that ARIN promised to maintain old allocations with
> no policy changes, and subsequently (upon seeing that the actual policy
> directly supports needs-assessment for transfers) changed your argument
> to say that no policy at all is applicable to old resources...  I am
> fairly you can't argue both sides at the same time, so which is it?

Your honor, my client has never even touched a gun and if he has he
didn't shoot anybody and if he did it was surely self defense.

ARIN has no authority to regulate the legacy registrations. If it did,
that authority would be constrained to a conservative reading of the
template and process used to register those addresses or, at the
absolute most, a reading of RFC 2050 with all ambiguity construed in
the registrants' most favorable light.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jcurran at arin.net  Tue Apr  8 06:33:14 2014
From: jcurran at arin.net (John Curran)
Date: Tue, 8 Apr 2014 10:33:14 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <CAP-guGUN9cChVRR7k5r7LnE+1KTswaF6Xny9EQQizydWFzERAw@mail.gmail.com>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
	<B2786520-D464-4DE2-85C0-DCCB848BB9A4@arin.net>
	<CAP-guGUD+hL9ZDD6AFYi2qVwU4yVBiSi9gyK6M6WuYhLCiCWqA@mail.gmail.com>
	<7B241487-C9C8-457B-A584-B5FF75D9086A@arin.net>
	<CAP-guGWSxFTtDARkUXO94mtXMgYZyNSqZeW1qgNtUTYJDAUvwQ@mail.gmail.com>
	<985E5E83-ED63-479B-956B-8767BE6CE773@arin.net>
	<CAP-guGUN9cChVRR7k5r7LnE+1KTswaF6Xny9EQQizydWFzERAw@mail.gmail.com>
Message-ID: <8E42869E-2C39-467C-B4DC-748EF3F04071@arin.net>

On Apr 8, 2014, at 6:21 AM, William Herrin <bill at herrin.us> wrote:

> .... or, at the absolute most, a reading of RFC 2050 with all ambiguity construed in the registrants' most favorable light.

Accepting the point above for sake of argument, here's the relevant 
section of RFC 2050 - 

  " 7. The transfer of IP addresses from one party to another must be
       approved by the regional registries.  The party trying to obtain
       the IP address must meet the same criteria as if they were
       requesting an IP address directly from the IR."

I do not see a lot of ambiguity here with respect to requiring those
receiving addresses to meet the same criteria as those being issued
address space, nor with respect to the requirement that the RIRs must
approve the transfer.  Please elucidate and construe is you see fit.

Thanks!
/John

John Curran
President and CEO
ARIN




From farmer at umn.edu  Tue Apr  8 10:04:43 2014
From: farmer at umn.edu (David Farmer)
Date: Tue, 08 Apr 2014 09:04:43 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <184A5AF5-1CDA-4AE8-B744-223083E3692F@delong.com>
References: <531633BD.1010109@arin.net>	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>	<F3735387-F28E-48D5-8003-E72D596516C2@twcable.com>	<CAMDXq5PeOcM90q3A5CmatP2HAhE-mg0wKVF-nLu93WLWi-APiw@mail.gmail.com>	<532BD7D6.4000901@matthew.at>	<CDA64243-36FD-407D-8707-2440E5A7C86B@arin.net>
	<CAMfXtQw9Kyqsbn3F8oZAU9WMjjcYunsOw90=nruaTU8cWQU1Zg@mail.gmail.com>
	<532CC259.5020605@umn.edu>
	<184A5AF5-1CDA-4AE8-B744-223083E3692F@delong.com>
Message-ID: <534401FB.5080309@umn.edu>

On 3/24/14, 13:08 , Owen DeLong wrote:
>
> On Mar 21, 2014, at 15:51 , David Farmer <farmer at umn.edu> wrote:
>
>> On 3/21/14, 09:10 , Gary Buhrmaster wrote:
>>> <soapbox>
>>>
>>> Any M&A, or organization changes, have a cost
>>> regarding business records, and it is incumbent
>>> on the organization to be prepared to pay that cost
>>> for changes.  Updating ARIN records (and the cost
>>> of doing so) is no different, and should not have a
>>> special "out" just because it can be take time or
>>> the people involved did/do not want to invest that
>>> effort.  The days of informal handshake number
>>> deals are (or should be) long over.  Get over it, and
>>> do the (boring, painful, but necessary) work.
>>>
>>> </soapbox>
>>
>> I very much agree, there is and almost certainly should be work involved.
>>
>> So, yes with any M&A, or other organization change, you should have to the "Business Office" part of documenting business records associated with the change.  The rationale for this "Business Office" part is clear.  Its necessary to prevent fraudulent changes to resources, and ARIN has a clear fiduciary responsibility to ensure this happens correctly.
>>
>> However, I do think it is a reasonable question to ask, should you also have to do the "technical" documentation that the paragraph in question requires as well?  Frequently, such an organizational change implies little to no technical change.  So, what is the rational for doing this "technical" reporting?  Let me be clear, I'm not saying there isn't a valid rationale, but I personally can't articulate it.  So, I'd appreciate it if someone would articulate a valid rationale for this "technical" reporting.
>
> 1.	To raise the visibility when an 8.3 transfer is being attempted through structures designed to disguise it as an 8.2 transfer.
> 2.	For consideration in cases where the 8.2 transfer is a transfer of underutilized resources which would not otherwise get reviewed.
> 	While the RSA protects the current resource holder from reclamation due to underutilization, during an 8.2 transfer, I see no
> 	reason that the amount transferred should not at the time be right-sized to fit the infrastructure also being transferred. The policy
> 	as written is generous about allowing staff to find ways to work with the new resource holder to accommodate that process and
> 	provides ample time and great flexibility on extensions to that time, if needed.
> 3.	Related to point 1, to prevent 8.2 from becoming a target vehicle for end-runs to the needs-basis tests in 8.3.
>
> Owen

I believe #2 to be punitive to those that are properly updating their 
records as a result of a legitimate transaction.  Policy should 
encourage proper updates to records, this seems to discourage it, or at 
least provide a disincentive.

I think #1 and #3 are legitimate issues of concern.  But I think these 
concerns can be addresses in other ways without creating a disincentive 
for legitimate updates to records created by requiring a resource review 
to complete a 8.2 transfer.

Basically, 8.2 transfers should only apply if other asset of value are 
involved in a transaction and the Internet number resources are not the 
primary asset of value involved in the transaction.  If these are not 
true then 8.3 should apply.

I would support removal of the paragraph as suggested by this policy, if 
language like above were included to prevent creative contracting to 
make what should be a 8.3 transfer look like a 8.2 transfer.

Without some kind of language to prevent an end run around 8.3, I would 
only support removing the words "reclaim" and "aggregate" from the 
current text.

Thanks.

-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================


From bill at herrin.us  Tue Apr  8 11:31:10 2014
From: bill at herrin.us (William Herrin)
Date: Tue, 8 Apr 2014 11:31:10 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <8E42869E-2C39-467C-B4DC-748EF3F04071@arin.net>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
	<B2786520-D464-4DE2-85C0-DCCB848BB9A4@arin.net>
	<CAP-guGUD+hL9ZDD6AFYi2qVwU4yVBiSi9gyK6M6WuYhLCiCWqA@mail.gmail.com>
	<7B241487-C9C8-457B-A584-B5FF75D9086A@arin.net>
	<CAP-guGWSxFTtDARkUXO94mtXMgYZyNSqZeW1qgNtUTYJDAUvwQ@mail.gmail.com>
	<985E5E83-ED63-479B-956B-8767BE6CE773@arin.net>
	<CAP-guGUN9cChVRR7k5r7LnE+1KTswaF6Xny9EQQizydWFzERAw@mail.gmail.com>
	<8E42869E-2C39-467C-B4DC-748EF3F04071@arin.net>
Message-ID: <CAP-guGVrW0y5ZELO1VhHLsjg1yY6bgfMB96HxG+UwfGcHuwQKA@mail.gmail.com>

On Tue, Apr 8, 2014 at 6:33 AM, John Curran <jcurran at arin.net> wrote:
> On Apr 8, 2014, at 6:21 AM, William Herrin <bill at herrin.us> wrote:
>
>> .... or, at the absolute most, a reading of RFC 2050 with all ambiguity construed in the registrants' most favorable light.
>
> Accepting the point above for sake of argument, here's the relevant
> section of RFC 2050 -
>
>   " 7. The transfer of IP addresses from one party to another must be
>        approved by the regional registries.  The party trying to obtain
>        the IP address must meet the same criteria as if they were
>        requesting an IP address directly from the IR."
>
> I do not see a lot of ambiguity here with respect to requiring those
> receiving addresses to meet the same criteria as those being issued
> address space, nor with respect to the requirement that the RIRs must
> approve the transfer.  Please elucidate and construe is you see fit.


Hi John,

Plenty of ambiguity. Which criteria must be met for the legacy
registration? The current RIR criteria? The criteria as practiced by
InterNIC when ARIN made its promise? The criteria as practiced by
InterNIC when the legacy registration was made? Some criteria laid out
directly in RFC2050? If you accept RFC 2050 as controlling, one of the
RIRs must approve the transfer. Not necessarily ARIN. But in the
context of ARIN's promise regarding legacy registrations, it's not
obvious which criteria ARIN is expected to apply when evaluating the
request. And at least some of the candidates boil down to: are you
really you? Ok. Transfer approved.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From billdarte at gmail.com  Tue Apr  8 11:55:55 2014
From: billdarte at gmail.com (Bill Darte)
Date: Tue, 8 Apr 2014 10:55:55 -0500
Subject: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8 (Sandra Brown)
In-Reply-To: <CAP-guGVrW0y5ZELO1VhHLsjg1yY6bgfMB96HxG+UwfGcHuwQKA@mail.gmail.com>
References: <20140406084945.ec289651d84890fcbef5f195936e1217.96c1ac5f2c.wbe@email17.secureserver.net>
	<F225E272-B62F-4036-B69A-9C25F02313FD@arin.net>
	<c1dce62aa05f4d8888b6abb4fb9e0b96@EX13-MBX-13.ad.syr.edu>
	<B2786520-D464-4DE2-85C0-DCCB848BB9A4@arin.net>
	<CAP-guGUD+hL9ZDD6AFYi2qVwU4yVBiSi9gyK6M6WuYhLCiCWqA@mail.gmail.com>
	<7B241487-C9C8-457B-A584-B5FF75D9086A@arin.net>
	<CAP-guGWSxFTtDARkUXO94mtXMgYZyNSqZeW1qgNtUTYJDAUvwQ@mail.gmail.com>
	<985E5E83-ED63-479B-956B-8767BE6CE773@arin.net>
	<CAP-guGUN9cChVRR7k5r7LnE+1KTswaF6Xny9EQQizydWFzERAw@mail.gmail.com>
	<8E42869E-2C39-467C-B4DC-748EF3F04071@arin.net>
	<CAP-guGVrW0y5ZELO1VhHLsjg1yY6bgfMB96HxG+UwfGcHuwQKA@mail.gmail.com>
Message-ID: <CAMApp375MgH0sgcfKdmj4rYY3agCGSkZ_uohS9U29PKr_Op0zw@mail.gmail.com>

All these arguments are most interesting, but of course nothing is certain
until the LAST judge says so...I for one would be/have been anxious to see
these principles tried in court.  If I were a betting man, I would believe
that whatever argument seemed to establish the greatest order and stability
for the Internet as a whole would win out...in the end. But then again,
almost everyone has more legal perspective and experience than I do.....

bd


On Tue, Apr 8, 2014 at 10:31 AM, William Herrin <bill at herrin.us> wrote:

> On Tue, Apr 8, 2014 at 6:33 AM, John Curran <jcurran at arin.net> wrote:
> > On Apr 8, 2014, at 6:21 AM, William Herrin <bill at herrin.us> wrote:
> >
> >> .... or, at the absolute most, a reading of RFC 2050 with all ambiguity
> construed in the registrants' most favorable light.
> >
> > Accepting the point above for sake of argument, here's the relevant
> > section of RFC 2050 -
> >
> >   " 7. The transfer of IP addresses from one party to another must be
> >        approved by the regional registries.  The party trying to obtain
> >        the IP address must meet the same criteria as if they were
> >        requesting an IP address directly from the IR."
> >
> > I do not see a lot of ambiguity here with respect to requiring those
> > receiving addresses to meet the same criteria as those being issued
> > address space, nor with respect to the requirement that the RIRs must
> > approve the transfer.  Please elucidate and construe is you see fit.
>
>
> Hi John,
>
> Plenty of ambiguity. Which criteria must be met for the legacy
> registration? The current RIR criteria? The criteria as practiced by
> InterNIC when ARIN made its promise? The criteria as practiced by
> InterNIC when the legacy registration was made? Some criteria laid out
> directly in RFC2050? If you accept RFC 2050 as controlling, one of the
> RIRs must approve the transfer. Not necessarily ARIN. But in the
> context of ARIN's promise regarding legacy registrations, it's not
> obvious which criteria ARIN is expected to apply when evaluating the
> request. And at least some of the candidates boil down to: are you
> really you? Ok. Transfer approved.
>
> Regards,
> Bill Herrin
>
>
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> 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/20140408/dd4325e5/attachment.htm>

From jaymartin926 at gmail.com  Wed Apr  9 22:03:19 2014
From: jaymartin926 at gmail.com (Jay Martin)
Date: Wed, 9 Apr 2014 19:03:19 -0700
Subject: [arin-ppml] Oppose to 2014-02 anti-flip language and 2014-09
Message-ID: <CALJtNOa6z5D57b4aqavNZS-_sR=5=gUPx2URgcmf=Bg5MCMZ1g@mail.gmail.com>

Hi John and community,


one of the reasons why the community should oppose the 2014-02 and 2014-09
as follows, The unfair system only benefits some big firms.


Recently, there is one inter-rir transfer  and i would like to discuss the
story behind the scene.

*ipv4|167.220.224.0/19|American <http://167.220.224.0/19|American> Registry
for Internet Numbers/MOPL|AP|ARIN|20140109|Microsoft Singapore Pte.
Ltd.|SG|APNIC|20140408*


1. it's original parent block is 167.220.0.0/16 ( now has been split into
smaller blocks) and has been announced by as3598 and as8071 but this one
has  been used in Singapore ( out of region use.) and its ARIN whois regi
info shows country code:SG.    I guess no wondering David is so caring
about the Out of Region policy too.  Even without this policy, Big firm can
always do what they want to do.


2.  Let's talk about 2014-02 anti flip language,    this inter-rir
transferred /19 belongs to MICROSOFT-GP-NET.    I guess this account of
miscrosoft has not received any ARIN IPv4 in the previous 12months.
otherwise, ARIN will not approve this transfer.  Hello community, please
help to recheck to see if MICROSOFT-GP-NET has been allocated ARIN IPv4
within the past 12months.


Besides this account,  Miscrosft has MSFT  which has just received
23.96.0.0/13 from ARIN free pool    and has  MICROSOFT  this maybe the one
who buy large amount of IPs from the bankruptcy organisation.     ( they
also have other ARIN accounts and the above two works as the examples
here)


No wondering David so cares about 2014-02 and 2014-09 to get rid of  policy
restriction to have their IPs either in account MSFT and account MICROSOFT
to be transferred into Microsoft Singapore Pte. Ltd. ( i guess its apnic
account is miscrosoft-ap or something similar)


The ARIN 33 is just at the corner,  we should seriously discuss  this
2014-2 and 2014-09  and I think the policy should not be established to
favour someone specific, policy should favour the whole community and
balance the benefits of all shareholders in ARIN region.


Jay





Sample IPs belongs to MICROSOFT as follows,


  137.116.0.0/16


 Microsoft Corp

legacy




  137.117.0.0/16


 Microsoft Corp

legacy




  137.135.0.0/16


 Microsoft Corp

legacy




  138.91.0.0/16


 Microsoft Corp

legacy




  141.251.0.0/16


 Microsoft Corp

legacy




    131.253.1.0/24


 Microsoft Corp

legacy










 131.253.128.0/17


 Microsoft Corp

legacy




  132.245.0.0/16


 Microsoft Corp

legacy




  134.170.0.0/16


 Microsoft Corp

legacy




  134.177.0.0/16


 Microsoft Corp

legacy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140409/36bbc776/attachment.htm>

From jcurran at arin.net  Thu Apr 10 05:42:55 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 10 Apr 2014 09:42:55 +0000
Subject: [arin-ppml] Oppose to 2014-02 anti-flip language and 2014-09
In-Reply-To: <CALJtNOa6z5D57b4aqavNZS-_sR=5=gUPx2URgcmf=Bg5MCMZ1g@mail.gmail.com>
References: <CALJtNOa6z5D57b4aqavNZS-_sR=5=gUPx2URgcmf=Bg5MCMZ1g@mail.gmail.com>
Message-ID: <7849BFD8-335E-48BB-84AA-4DD538617584@arin.net>

On Apr 9, 2014, at 10:03 PM, Jay Martin <jaymartin926 at gmail.com<mailto:jaymartin926 at gmail.com>> wrote:

Hi John and community,

one of the reasons why the community should oppose the 2014-02 and 2014-09 as follows, The unfair system only benefits some big firms.

Thank you for making your opinion known.

With regards to specific requests/allocations/assignments, it is neither desirable nor
productive to discuss them on the PPML mailing list, as the necessary detail regarding
the request is private to the requester.  If you have insight into information that causes
you to believe that resources were obtained fraudulently, please report it to ARIN here:
<https://www.arin.net/resources/fraud/index.html>

The ARIN 33 is just at the corner,  we should seriously discuss  this 2014-2 and 2014-09  and I think the policy should not be established to favour someone specific, policy should favour the whole community and balance the benefits of all shareholders in ARIN region.

Discussion of these draft policies is very important, as it provides the input necessary for the
ARIN AC to update the proposals accordingly.  We also will be discussing both of these draft
policies during the Public Policy Meeting, and that will be available to both onsite and remote
participants.

Thanks!
/John

John Curran
President and CEO
ARIN

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

From billdarte at gmail.com  Thu Apr 10 07:22:35 2014
From: billdarte at gmail.com (Bill Darte)
Date: Thu, 10 Apr 2014 06:22:35 -0500
Subject: [arin-ppml] Oppose to 2014-02 anti-flip language and 2014-09
In-Reply-To: <CALJtNOa6z5D57b4aqavNZS-_sR=5=gUPx2URgcmf=Bg5MCMZ1g@mail.gmail.com>
References: <CALJtNOa6z5D57b4aqavNZS-_sR=5=gUPx2URgcmf=Bg5MCMZ1g@mail.gmail.com>
Message-ID: <CAMApp37iYhst4vVFJ7+auJ_n-2EpG5HV4XN7EjN0XHL2EZCFSQ@mail.gmail.com>

Thank you for reiterating your opposition to 2014-2 Improving 8.4 Anti-Flip
Language.  I hope others opposed or in support of the Draft Policy will
also post or better yet come to the ARIN 33 in Chicago this coming week.
 There we(AC) will present the draft and ask for guidance on whether to
advance the Draft to Recommended Draft or to modify it accordance with
suggestions received, or simply abandon it for lack of support.

I will say, it is not unreasonable for Draft Policy to emerge which seems
to benefit and individual organization.  It is the right of anyone in the
community to try to shape policy that is favorable to their perceived
needs.  It is however the community's responsibility to review these drafts
and to determine if they believe they are in the larger interest of the
community and therefore worthy of advancing. Thanks to all that make this
process work.

See you in Chicago!

Bill Darte
AC Shepherd 2014-2


On Wed, Apr 9, 2014 at 9:03 PM, Jay Martin <jaymartin926 at gmail.com> wrote:

> Hi John and community,
>
>
> one of the reasons why the community should oppose the 2014-02 and 2014-09
> as follows, The unfair system only benefits some big firms.
>
>
> Recently, there is one inter-rir transfer  and i would like to discuss the
> story behind the scene.
>
> *ipv4|167.220.224.0/19|American <http://167.220.224.0/19%7CAmerican>
> Registry for Internet Numbers/MOPL|AP|ARIN|20140109|Microsoft Singapore
> Pte. Ltd.|SG|APNIC|20140408*
>
>
> 1. it's original parent block is 167.220.0.0/16 ( now has been split into
> smaller blocks) and has been announced by as3598 and as8071 but this one
> has  been used in Singapore ( out of region use.) and its ARIN whois regi
> info shows country code:SG.    I guess no wondering David is so caring
> about the Out of Region policy too.  Even without this policy, Big firm can
> always do what they want to do.
>
>
> 2.  Let's talk about 2014-02 anti flip language,    this inter-rir
> transferred /19 belongs to MICROSOFT-GP-NET.    I guess this account of
> miscrosoft has not received any ARIN IPv4 in the previous 12months.
> otherwise, ARIN will not approve this transfer.  Hello community, please
> help to recheck to see if MICROSOFT-GP-NET has been allocated ARIN IPv4
> within the past 12months.
>
>
> Besides this account,  Miscrosft has MSFT  which has just received
> 23.96.0.0/13 from ARIN free pool    and has  MICROSOFT  this maybe the
> one who buy large amount of IPs from the bankruptcy organisation.     (
> they also have other ARIN accounts and the above two works as the examples
> here)
>
>
> No wondering David so cares about 2014-02 and 2014-09 to get rid of
> policy restriction to have their IPs either in account MSFT and account
> MICROSOFT to be transferred into Microsoft Singapore Pte. Ltd. ( i guess
> its apnic account is miscrosoft-ap or something similar)
>
>
> The ARIN 33 is just at the corner,  we should seriously discuss  this
> 2014-2 and 2014-09  and I think the policy should not be established to
> favour someone specific, policy should favour the whole community and
> balance the benefits of all shareholders in ARIN region.
>
>
> Jay
>
>
>
>
>
> Sample IPs belongs to MICROSOFT as follows,
>
>
>   137.116.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>   137.117.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>   137.135.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>   138.91.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>   141.251.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>     131.253.1.0/24
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>
>
>
>
>
>
>  131.253.128.0/17
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>   132.245.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>   134.170.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>   134.177.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20140410/86bd7801/attachment.htm>

From jay-ARIN at tp.org  Thu Apr 10 09:23:15 2014
From: jay-ARIN at tp.org (Jay Moran (AOL))
Date: Thu, 10 Apr 2014 09:23:15 -0400
Subject: [arin-ppml] Oppose to 2014-02 anti-flip language and 2014-09
In-Reply-To: <CAMApp37iYhst4vVFJ7+auJ_n-2EpG5HV4XN7EjN0XHL2EZCFSQ@mail.gmail.com>
References: <CALJtNOa6z5D57b4aqavNZS-_sR=5=gUPx2URgcmf=Bg5MCMZ1g@mail.gmail.com>
	<CAMApp37iYhst4vVFJ7+auJ_n-2EpG5HV4XN7EjN0XHL2EZCFSQ@mail.gmail.com>
Message-ID: <CA+Ld8r_gOac1vO98eD1O3f03AnRt3X7FOCsTSOSvgKHzDT4+Lg@mail.gmail.com>

Re-affirming my previous support for option #3 listed in 2014-2.

For 2014-9, I strongly support the removal of the utilization request
during 8.2 transfers. Keeping accurate registry information is vital for
all of us. Knowing internal corporate council as well as I do, they
themselves can make an 8.2 internal transfer process quite painful for
those of running the technologies of a company if they see anything that
they interpret as risk to the continued operations of the business. To them
an external party seeking information about internal operations (such as
utilization levels of any resource relied on to do business) is a potential
risk either on an immediate or future basis, whether there are direct
actions such as reclamation currently allowed or not.

Section 6 of the RSA is certainly interpreted by myself and others as net
new addresses being transferred (or allocated) into an organization and not
for 8.2 transfers that should be to clean up registry information as
corporate structure change. Just because an organization (let's say AOL for
a random example) merged with Time Warner, Inc. (with 60% of the shares
going to AOL shareholders, BTW) and then later the new entity spins the
independent AOL subsidary back out as a standalone company, does not mean
that the new standalone AOL entity is in anyway requesting additional
addresses through transfer (or new allocation) when they simple try and
update their records from their legacy name/entity to their new name/entity
via a Name Change and/or then an 8.2 transfer.

I understand some companies may use the process of spinning of an entity,
bundling assets within that entity, and then selling it and requesting an
8.2 transfer; but it isn't like this is a new concept solely for the
transfer of IP addresses. Whether it is for the other IP (Intellectual
Property, patents, publishing rights, etc) or other assets (manufacturing
plants, distribution networks, etc) this isn't exactly an uncommon
occurrence in the world of corporate structure and finance.

If the ARIN community is still concerned that we need to place some limits
on buying companies with nothing but IP addresses in them, then I would
also support a re-definition of "Name Change" for organizations that makes
it clear that a Name Change can be used if the vast majority of assets are
transferred along with the actual merger, acquisition, or divestiture. Then
using the same example of AOL & Time Warner, just because AOL didn't keep
their private jets on the spin out, everything else transfers. It also
didn't change what AOL was before, during, or after the years in the
wilderness with Time Warner.

These views are my own and I believe they benefit/apply to the entire
community, but certainly my insights have been derived from my own personal
experiences.

Jay Moran
AOL Inc.
--
Jay Moran
http://linkedin.com/in/jaycmoran


On Thu, Apr 10, 2014 at 7:22 AM, Bill Darte <billdarte at gmail.com> wrote:

> Thank you for reiterating your opposition to 2014-2 Improving 8.4
> Anti-Flip Language.  I hope others opposed or in support of the Draft
> Policy will also post or better yet come to the ARIN 33 in Chicago this
> coming week.  There we(AC) will present the draft and ask for guidance on
> whether to advance the Draft to Recommended Draft or to modify it
> accordance with suggestions received, or simply abandon it for lack of
> support.
>
> I will say, it is not unreasonable for Draft Policy to emerge which seems
> to benefit and individual organization.  It is the right of anyone in the
> community to try to shape policy that is favorable to their perceived
> needs.  It is however the community's responsibility to review these drafts
> and to determine if they believe they are in the larger interest of the
> community and therefore worthy of advancing. Thanks to all that make this
> process work.
>
> See you in Chicago!
>
> Bill Darte
> AC Shepherd 2014-2
>
>
> On Wed, Apr 9, 2014 at 9:03 PM, Jay Martin <jaymartin926 at gmail.com> wrote:
>
>> Hi John and community,
>>
>>
>> one of the reasons why the community should oppose the 2014-02 and
>> 2014-09 as follows, The unfair system only benefits some big firms.
>>
>>
>> Recently, there is one inter-rir transfer  and i would like to discuss
>> the story behind the scene.
>>
>> *ipv4|167.220.224.0/19|American <http://167.220.224.0/19%7CAmerican>
>> Registry for Internet Numbers/MOPL|AP|ARIN|20140109|Microsoft Singapore
>> Pte. Ltd.|SG|APNIC|20140408*
>>
>>
>> 1. it's original parent block is 167.220.0.0/16 ( now has been split
>> into smaller blocks) and has been announced by as3598 and as8071 but this
>> one has  been used in Singapore ( out of region use.) and its ARIN whois
>> regi info shows country code:SG.    I guess no wondering David is so caring
>> about the Out of Region policy too.  Even without this policy, Big firm can
>> always do what they want to do.
>>
>>
>> 2.  Let's talk about 2014-02 anti flip language,    this inter-rir
>> transferred /19 belongs to MICROSOFT-GP-NET.    I guess this account of
>> miscrosoft has not received any ARIN IPv4 in the previous 12months.
>> otherwise, ARIN will not approve this transfer.  Hello community, please
>> help to recheck to see if MICROSOFT-GP-NET has been allocated ARIN IPv4
>> within the past 12months.
>>
>>
>> Besides this account,  Miscrosft has MSFT  which has just received
>> 23.96.0.0/13 from ARIN free pool    and has  MICROSOFT  this maybe the
>> one who buy large amount of IPs from the bankruptcy organisation.     (
>> they also have other ARIN accounts and the above two works as the examples
>> here)
>>
>>
>> No wondering David so cares about 2014-02 and 2014-09 to get rid of
>> policy restriction to have their IPs either in account MSFT and account
>> MICROSOFT to be transferred into Microsoft Singapore Pte. Ltd. ( i guess
>> its apnic account is miscrosoft-ap or something similar)
>>
>>
>> The ARIN 33 is just at the corner,  we should seriously discuss  this
>> 2014-2 and 2014-09  and I think the policy should not be established to
>> favour someone specific, policy should favour the whole community and
>> balance the benefits of all shareholders in ARIN region.
>>
>>
>> Jay
>>
>>
>>
>>
>>
>> Sample IPs belongs to MICROSOFT as follows,
>>
>>
>>   137.116.0.0/16
>>
>>
>>  Microsoft Corp
>>
>> legacy
>>
>>
>>
>>
>>   137.117.0.0/16
>>
>>
>>  Microsoft Corp
>>
>> legacy
>>
>>
>>
>>
>>   137.135.0.0/16
>>
>>
>>  Microsoft Corp
>>
>> legacy
>>
>>
>>
>>
>>   138.91.0.0/16
>>
>>
>>  Microsoft Corp
>>
>> legacy
>>
>>
>>
>>
>>   141.251.0.0/16
>>
>>
>>  Microsoft Corp
>>
>> legacy
>>
>>
>>
>>
>>     131.253.1.0/24
>>
>>
>>  Microsoft Corp
>>
>> legacy
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  131.253.128.0/17
>>
>>
>>  Microsoft Corp
>>
>> legacy
>>
>>
>>
>>
>>   132.245.0.0/16
>>
>>
>>  Microsoft Corp
>>
>> legacy
>>
>>
>>
>>
>>   134.170.0.0/16
>>
>>
>>  Microsoft Corp
>>
>> legacy
>>
>>
>>
>>
>>   134.177.0.0/16
>>
>>
>>  Microsoft Corp
>>
>> legacy
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20140410/23adfd02/attachment.htm>

From hannigan at gmail.com  Thu Apr 10 21:36:08 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 10 Apr 2014 18:36:08 -0700
Subject: [arin-ppml] Oppose to 2014-02 anti-flip language and 2014-09
In-Reply-To: <CALJtNOa6z5D57b4aqavNZS-_sR=5=gUPx2URgcmf=Bg5MCMZ1g@mail.gmail.com>
References: <CALJtNOa6z5D57b4aqavNZS-_sR=5=gUPx2URgcmf=Bg5MCMZ1g@mail.gmail.com>
Message-ID: <CAMDXq5MsOaLFgZX=oOCr4Pc4MW+eciDg=0Mpp64-0WWqkskhFQ@mail.gmail.com>

Hmm. That prefix appears to be part of a pre ARIN "acquisition conspiracy"

Any details?

Best,

-M<


On Wednesday, April 9, 2014, Jay Martin <jaymartin926 at gmail.com> wrote:

> Hi John and community,
>
>
> one of the reasons why the community should oppose the 2014-02 and 2014-09
> as follows, The unfair system only benefits some big firms.
>
>
> Recently, there is one inter-rir transfer  and i would like to discuss the
> story behind the scene.
>
> *ipv4|167.220.224.0/19|American <http://167.220.224.0/19%7CAmerican>
> Registry for Internet Numbers/MOPL|AP|ARIN|20140109|Microsoft Singapore
> Pte. Ltd.|SG|APNIC|20140408*
>
>
> 1. it's original parent block is 167.220.0.0/16 ( now has been split into
> smaller blocks) and has been announced by as3598 and as8071 but this one
> has  been used in Singapore ( out of region use.) and its ARIN whois regi
> info shows country code:SG.    I guess no wondering David is so caring
> about the Out of Region policy too.  Even without this policy, Big firm can
> always do what they want to do.
>
>
> 2.  Let's talk about 2014-02 anti flip language,    this inter-rir
> transferred /19 belongs to MICROSOFT-GP-NET.    I guess this account of
> miscrosoft has not received any ARIN IPv4 in the previous 12months.
> otherwise, ARIN will not approve this transfer.  Hello community, please
> help to recheck to see if MICROSOFT-GP-NET has been allocated ARIN IPv4
> within the past 12months.
>
>
> Besides this account,  Miscrosft has MSFT  which has just received
> 23.96.0.0/13 from ARIN free pool    and has  MICROSOFT  this maybe the
> one who buy large amount of IPs from the bankruptcy organisation.     (
> they also have other ARIN accounts and the above two works as the examples
> here)
>
>
> No wondering David so cares about 2014-02 and 2014-09 to get rid of
> policy restriction to have their IPs either in account MSFT and account
> MICROSOFT to be transferred into Microsoft Singapore Pte. Ltd. ( i guess
> its apnic account is miscrosoft-ap or something similar)
>
>
> The ARIN 33 is just at the corner,  we should seriously discuss  this
> 2014-2 and 2014-09  and I think the policy should not be established to
> favour someone specific, policy should favour the whole community and
> balance the benefits of all shareholders in ARIN region.
>
>
> Jay
>
>
>
>
>
> Sample IPs belongs to MICROSOFT as follows,
>
>
>   137.116.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>   137.117.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>   137.135.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>   138.91.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>   141.251.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>     131.253.1.0/24
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>
>
>
>
>
>
>  131.253.128.0/17
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>   132.245.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>   134.170.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
>
>
>   134.177.0.0/16
>
>
>  Microsoft Corp
>
> legacy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140410/28c19db7/attachment.htm>

From jaymartin926 at gmail.com  Thu Apr 10 22:07:41 2014
From: jaymartin926 at gmail.com (Jay Martin)
Date: Thu, 10 Apr 2014 19:07:41 -0700
Subject: [arin-ppml] Oppose to 2014-02 anti-flip language and 2014-09
In-Reply-To: <CA+Ld8r_gOac1vO98eD1O3f03AnRt3X7FOCsTSOSvgKHzDT4+Lg@mail.gmail.com>
References: <CALJtNOa6z5D57b4aqavNZS-_sR=5=gUPx2URgcmf=Bg5MCMZ1g@mail.gmail.com>
	<CAMApp37iYhst4vVFJ7+auJ_n-2EpG5HV4XN7EjN0XHL2EZCFSQ@mail.gmail.com>
	<CA+Ld8r_gOac1vO98eD1O3f03AnRt3X7FOCsTSOSvgKHzDT4+Lg@mail.gmail.com>
Message-ID: <CALJtNOb_Qs-2EcFNT0VmNnkzn8hinX3uxb=q--3AAPqo0rVnBQ@mail.gmail.com>

Hi Moran,



On Thu, Apr 10, 2014 at 6:23 AM, Jay Moran (AOL) <jay-ARIN at tp.org> wrote:

> Re-affirming my previous support for option #3 listed in 2014-2.
>
> For 2014-9, I strongly support the removal of the utilization request
> during 8.2 transfers. Keeping accurate registry information is vital for
> all of us. Knowing internal corporate council as well as I do, they
> themselves can make an 8.2 internal transfer process quite painful for
> those of running the technologies of a company if they see anything that
> they interpret as risk to the continued operations of the business. To them
> an external party seeking information about internal operations (such as
> utilization levels of any resource relied on to do business) is a potential
> risk either on an immediate or future basis, whether there are direct
> actions such as reclamation currently allowed or not.
>
> Section 6 of the RSA is certainly interpreted by myself and others as net
> new addresses being transferred (or allocated) into an organization and not
> for 8.2 transfers that should be to clean up registry information as
> corporate structure change. Just because an organization (let's say AOL for
> a random example) merged with Time Warner, Inc. (with 60% of the shares
> going to AOL shareholders, BTW) and then later the new entity spins the
> independent AOL subsidary back out as a standalone company, does not mean
> that the new standalone AOL entity is in anyway requesting additional
> addresses through transfer (or new allocation) when they simple try and
> update their records from their legacy name/entity to their new name/entity
> via a Name Change and/or then an 8.2 transfer.
>
>

Can you specify which blocks do you refer to?   Even i disagree with your
opinions on supporting on 2014-02 and 2014-09, the community may help  to
solve your problems if you can specify the blocks you would like to have
the name change.

172.210.0.0/16;172.211.0.0/16;62.51.0.0/17;62.78.0.0/19;64.12.0.0/16;64.236.0.0/16;66.185.128.0/19;149.174.0.0/16;152.163.0.0/16;172.128.0.0/10;172.128.0.0/16;172.129.0.0/16;172.130.0.0/16;172.131.0.0/16;172.132.0.0/16;172.133.0.0/16;172.134.0.0/16;172.135.0.0/16;172.136.0.0/16;172.137.0.0/16;172.138.0.0/16;172.139.0.0/16;172.140.0.0/16;172.158.0.0/16;172.160.0.0/16;172.161.0.0/16;172.162.0.0/16;172.163.0.0/16;172.164.0.0/16;172.165.0.0/16;172.166.0.0/16;172.167.0.0/16;172.168.0.0/16;172.169.0.0/16172.170.0.0/16;172.171.0.0/16;172.172.0.0/16;172.173.0.0/16;172.174.0.0/16;172.175.0.0/16;172.176.0.0/16;172.177.0.0/16;172.178.0.0/16;172.180.0.0/16
;172.192.0.0/13








> I understand some companies may use the process of spinning of an entity,
> bundling assets within that entity, and then selling it and requesting an
> 8.2 transfer; but it isn't like this is a new concept solely for the
> transfer of IP addresses. Whether it is for the other IP (Intellectual
> Property, patents, publishing rights, etc) or other assets (manufacturing
> plants, distribution networks, etc) this isn't exactly an uncommon
> occurrence in the world of corporate structure and finance.
>


> If the ARIN community is still concerned that we need to place some limits
> on buying companies with nothing but IP addresses in them, then I would
> also support a re-definition of "Name Change" for organizations that makes
> it clear that a Name Change can be used if the vast majority of assets are
> transferred along with the actual merger, acquisition, or divestiture. Then
> using the same example of AOL & Time Warner, just because AOL didn't keep
> their private jets on the spin out, everything else transfers. It also
> didn't change what AOL was before, during, or after the years in the
> wilderness with Time Warner.
>

I agree with you on this. However,  what if a 8.2 transfer is planned
purely for a 8.3/8.4 transfer later. It seems that such an arrangement is
just like what you said here(buying IPs with  no real assets acquired).
 Besides place some limits on buying companies with nothing, it should also
place some limits on 8.2 transfer  which the receiver does not plan to use
them(buying IPs without real assets acquired or buying/Selling IPs has been
disguised as a M/A).
The utilisation test required under 8.2 transfer may try to stop someone
avoiding the 8.3/8.4 transfer and disguise a 8.3/8.4 transfer as a 8.2
transfer. Furthermore, why not directly do a 8.3/8.4 transfer  instead of
wasting time on argue this 2014-02 and 2014-09 if your purpose is try to do
a 8.3/8.4 transfer.  There is someone who might come across the same
problems as you. maybe your guys should exchange your opinions here.


Jay







>
> These views are my own and I believe they benefit/apply to the entire
> community, but certainly my insights have been derived from my own personal
> experiences.
>
> Jay Moran
> AOL Inc.
> --
> Jay Moran
> http://linkedin.com/in/jaycmoran
>
>
> On Thu, Apr 10, 2014 at 7:22 AM, Bill Darte <billdarte at gmail.com> wrote:
>
>> Thank you for reiterating your opposition to 2014-2 Improving 8.4
>> Anti-Flip Language.  I hope others opposed or in support of the Draft
>> Policy will also post or better yet come to the ARIN 33 in Chicago this
>> coming week.  There we(AC) will present the draft and ask for guidance on
>> whether to advance the Draft to Recommended Draft or to modify it
>> accordance with suggestions received, or simply abandon it for lack of
>> support.
>>
>> I will say, it is not unreasonable for Draft Policy to emerge which seems
>> to benefit and individual organization.  It is the right of anyone in the
>> community to try to shape policy that is favorable to their perceived
>> needs.  It is however the community's responsibility to review these drafts
>> and to determine if they believe they are in the larger interest of the
>> community and therefore worthy of advancing. Thanks to all that make this
>> process work.
>>
>> See you in Chicago!
>>
>> Bill Darte
>> AC Shepherd 2014-2
>>
>>
>> On Wed, Apr 9, 2014 at 9:03 PM, Jay Martin <jaymartin926 at gmail.com>wrote:
>>
>>> Hi John and community,
>>>
>>>
>>> one of the reasons why the community should oppose the 2014-02 and
>>> 2014-09 as follows, The unfair system only benefits some big firms.
>>>
>>>
>>> Recently, there is one inter-rir transfer  and i would like to discuss
>>> the story behind the scene.
>>>
>>> *ipv4|167.220.224.0/19|American <http://167.220.224.0/19%7CAmerican>
>>> Registry for Internet Numbers/MOPL|AP|ARIN|20140109|Microsoft Singapore
>>> Pte. Ltd.|SG|APNIC|20140408*
>>>
>>>
>>> 1. it's original parent block is 167.220.0.0/16 ( now has been split
>>> into smaller blocks) and has been announced by as3598 and as8071 but this
>>> one has  been used in Singapore ( out of region use.) and its ARIN whois
>>> regi info shows country code:SG.    I guess no wondering David is so caring
>>> about the Out of Region policy too.  Even without this policy, Big firm can
>>> always do what they want to do.
>>>
>>>
>>> 2.  Let's talk about 2014-02 anti flip language,    this inter-rir
>>> transferred /19 belongs to MICROSOFT-GP-NET.    I guess this account of
>>> miscrosoft has not received any ARIN IPv4 in the previous 12months.
>>> otherwise, ARIN will not approve this transfer.  Hello community, please
>>> help to recheck to see if MICROSOFT-GP-NET has been allocated ARIN IPv4
>>> within the past 12months.
>>>
>>>
>>> Besides this account,  Miscrosft has MSFT  which has just received
>>> 23.96.0.0/13 from ARIN free pool    and has  MICROSOFT  this maybe the
>>> one who buy large amount of IPs from the bankruptcy organisation.     (
>>> they also have other ARIN accounts and the above two works as the examples
>>> here)
>>>
>>>
>>> No wondering David so cares about 2014-02 and 2014-09 to get rid of
>>> policy restriction to have their IPs either in account MSFT and account
>>> MICROSOFT to be transferred into Microsoft Singapore Pte. Ltd. ( i guess
>>> its apnic account is miscrosoft-ap or something similar)
>>>
>>>
>>> The ARIN 33 is just at the corner,  we should seriously discuss  this
>>> 2014-2 and 2014-09  and I think the policy should not be established to
>>> favour someone specific, policy should favour the whole community and
>>> balance the benefits of all shareholders in ARIN region.
>>>
>>>
>>> Jay
>>>
>>>
>>>
>>>
>>>
>>> Sample IPs belongs to MICROSOFT as follows,
>>>
>>>
>>>   137.116.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>   137.117.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>   137.135.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>   138.91.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>   141.251.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>     131.253.1.0/24
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  131.253.128.0/17
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>   132.245.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>   134.170.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>   134.177.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20140410/ede56f41/attachment.htm>

From narten at us.ibm.com  Fri Apr 11 00:53:02 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 11 Apr 2014 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201404110453.s3B4r2SA007279@rotala.raleigh.ibm.com>

Total of 72 messages in the last 7 days.
 
script run at: Fri Apr 11 00:53:02 EDT 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 18.06% |   13 |  8.35% |   110579 | jcurran at arin.net
  8.33% |    6 | 10.85% |   143684 | david.huberman at microsoft.com
  2.78% |    2 | 15.56% |   206077 | kkargel at polartel.com
  6.94% |    5 | 10.53% |   139371 | jaymartin926 at gmail.com
  8.33% |    6 |  6.49% |    85878 | nikiyangxf at gmail.com
  5.56% |    4 |  8.39% |   111088 | hannigan at gmail.com
  2.78% |    2 | 10.76% |   142500 | scottleibrand at gmail.com
  8.33% |    6 |  4.18% |    55409 | owen at delong.com
  5.56% |    4 |  2.37% |    31385 | mueller at syr.edu
  5.56% |    4 |  2.29% |    30387 | bill at herrin.us
  1.39% |    1 |  5.62% |    74445 | rockymm8 at gmail.com
  4.17% |    3 |  2.62% |    34742 | cja at daydream.com
  2.78% |    2 |  3.63% |    48002 | billdarte at gmail.com
  4.17% |    3 |  2.13% |    28260 | sryerse at eclipse-networks.com
  4.17% |    3 |  1.64% |    21718 | timothy.s.morizot at irs.gov
  2.78% |    2 |  0.98% |    13009 | dogwallah at gmail.com
  1.39% |    1 |  0.80% |    10598 | farmer at umn.edu
  1.39% |    1 |  0.61% |     8111 | narten at us.ibm.com
  1.39% |    1 |  0.60% |     7997 | michael at linuxmagic.com
  1.39% |    1 |  0.60% |     7905 | sandrabrown at ipv4marketgroup.com
  1.39% |    1 |  0.51% |     6794 | joelja at bogus.com
  1.39% |    1 |  0.47% |     6218 | csquat at ccsd.net
--------+------+--------+----------+------------------------
100.00% |   72 |100.00% |  1324157 | Total



From lsawyer at gci.com  Fri Apr 11 12:18:37 2014
From: lsawyer at gci.com (Leif Sawyer)
Date: Fri, 11 Apr 2014 08:18:37 -0800
Subject: [arin-ppml] ARIN33 Chicago  travel pooling
Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102C70EDCEC@fnb1mbx01.gci.com>

I'll be arriving Sunday morning at  8:30, O'Hare.

I'll most likely take the train into town, and then bus to the Drake - unless
there are others arriving near that time that would like to pool up.


On the departure side, I need to be at O'Hare  Thursday morning at 7:30,
if there are folks looking for return-trip pooling.




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

From hannigan at gmail.com  Fri Apr 11 14:37:11 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 11 Apr 2014 11:37:11 -0700
Subject: [arin-ppml] ARIN33 Chicago travel pooling
In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102C70EDCEC@fnb1mbx01.gci.com>
References: <18B2C6E38A3A324986B392B2D18ABC5102C70EDCEC@fnb1mbx01.gci.com>
Message-ID: <CAMDXq5N2G1C_yTcERCZO9wz2YzYBZf1teRh0z0EVS9G=x=b6Tw@mail.gmail.com>

Good idea, but will probably wreak a small amount of havoc on this
list if we try and coordinate others this way.

I setup a doodle poll where you can pick a suitable time. Two hour
increments seemed reasonable with a day before and a day after as
well.

        http://doodle.com/eczkn9tc8gdnzqke

I'm pretty certain folks can either hint at emails or use names to
find people, the weakness of Doodle I suppose. [ hah, someone should
write an app to do this I suppose ]

Let me know what you think off-list.


Best,

-M<




On Fri, Apr 11, 2014 at 9:18 AM, Leif Sawyer <lsawyer at gci.com> wrote:
> I'll be arriving Sunday morning at  8:30, O'Hare.
>
>
>
> I'll most likely take the train into town, and then bus to the Drake -
> unless
>
> there are others arriving near that time that would like to pool up.
>
>
>
>
>
> On the departure side, I need to be at O'Hare  Thursday morning at 7:30,
>
> if there are folks looking for return-trip pooling.
>
>
>
>
>
>
> _______________________________________________
> 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.


From Marla.Azinger at FTR.com  Mon Apr 14 11:06:39 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Mon, 14 Apr 2014 15:06:39 +0000
Subject: [arin-ppml] =?windows-1252?q?No_support_for_=95ARIN-2013-7=3A_NRP?=
 =?windows-1252?q?M_4_=28IPv4=29_Policy_Cleanup?=
Message-ID: <d1869e4bd8b74806b4a15090baf6b247@BY2PR06MB488.namprd06.prod.outlook.com>

-Remove section 4.1.1 Routability -  No Support, it leaves a clue as to how things can be done and there will always be v4 circling about
-Update section 4.1.5 Determination of resource requests  -  No support. Current text is sufficient.  New text would work in addition to current text.  This is an example of things getting word preferenced picked over.  waste of time
-Remove section 4.1.7 RFC2050 -No support, Replace it with RFC 7020 and a reference to the section of NRPM with the adopted RIR principles.  Im more comfortable with IETF references than ARIN policy since ARIN policy is a constantly moving target.
-Remove section 4.1.9 Returned IPv4 Addresses   No support-  Where did the details and reason go?
-Replace and retitle section 4.2.4.3 Subscriber Members Less Than One Year   Maybe support.  If you fix it.  Should say AND not OR.  A business can purchase a business set in the same year they need to do a market transfer of addresses.  this should not be limited to either or as that is ignorant of how organizations can function.  Replace with: (4.2.4.3 Request size) "ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 "AND" 8.4 transfer."
-Remove section 4.2.4.4. Subscriber Members After One Year  NO support-  Let Knew Entities grow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140414/253ad1fc/attachment.htm>

From owen at delong.com  Mon Apr 14 11:18:52 2014
From: owen at delong.com (Owen DeLong)
Date: Mon, 14 Apr 2014 08:18:52 -0700
Subject: [arin-ppml]
 =?windows-1252?q?No_support_for_=95ARIN-2013-7=3A_NRP?=
 =?windows-1252?q?M_4_=28IPv4=29_Policy_Cleanup?=
In-Reply-To: <d1869e4bd8b74806b4a15090baf6b247@BY2PR06MB488.namprd06.prod.outlook.com>
References: <d1869e4bd8b74806b4a15090baf6b247@BY2PR06MB488.namprd06.prod.outlook.com>
Message-ID: <98E44C57-E12D-4A7E-A59C-FA50568793BC@delong.com>

> -Remove section 4.1.7 RFC2050 -No support, Replace it with RFC 7020 and a reference to the section of NRPM with the adopted RIR principles.  Im more comfortable with IETF references than ARIN policy since ARIN policy is a constantly moving target. 

IETF Documents are also an equally constant moving target.

> -Replace and retitle section 4.2.4.3 Subscriber Members Less Than One Year   Maybe support.  If you fix it.  Should say AND not OR.  A business can purchase a business set in the same year they need to do a market transfer of addresses.  this should not be limited to either or as that is ignorant of how organizations can function.  Replace with: (4.2.4.3 Request size) "ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 "AND" 8.4 transfer.?

I believe you are conflating 8.2 and 8.4. Section 8.4 is inter-RIR version of 8.3. Acquisitions (8.2) are not subject to this at all.

> -Remove section 4.2.4.4. Subscriber Members After One Year  NO support-  Let Knew Entities grow.

Not sure what you mean by this. Removing 4.2.4.4 and replacing it as proposed would not negatively impact the growth of new entities.

Owen

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

From Marla.Azinger at FTR.com  Mon Apr 14 12:21:07 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Mon, 14 Apr 2014 16:21:07 +0000
Subject: [arin-ppml] =?windows-1252?q?No_Support__ARIN-prop-2014-4_=96_=93?=
 =?windows-1252?q?Remove_4=2E2=2E5_Web_Hosting_Policy=94?=
Message-ID: <cc70883bb604483999a4ca3da38e75f4@BY2PR06MB488.namprd06.prod.outlook.com>

No support. Right now I don't think it confuses anyone as stated in the rational and it just clarifies something ARIN staff will ask for.  They ask some companies for detailed router output (which in some cases is not even possible) and they won?t take time to analyze domain details?  Which btw if they are legitimate they are very easy to provide.

Additionally I use this policy to beat back bogus IP Requests for domains.  This has cut back on BS requested subnet size alot in the ISP world.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140414/4800cdd5/attachment.htm>

From Marla.Azinger at FTR.com  Mon Apr 14 12:23:46 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Mon, 14 Apr 2014 16:23:46 +0000
Subject: [arin-ppml] Yes support Draft Policy ARIN-2014-7 Section 4.4 Micro
 Allocation Conservation Update
Message-ID: <ac0f696210ee4dc4afa904744da5f2de@BY2PR06MB488.namprd06.prod.outlook.com>

Draft Policy ARIN-2014-7 Section 4.4 Micro Allocation Conservation Update-
Yes,I support this.  Operationally and technically this makes good sense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140414/bcbfc81b/attachment.htm>

From springer at inlandnet.com  Mon Apr 14 14:33:09 2014
From: springer at inlandnet.com (John Springer)
Date: Mon, 14 Apr 2014 11:33:09 -0700 (PDT)
Subject: [arin-ppml] =?utf-8?q?No_Support__ARIN-prop-2014-4_=E2=80=93_?=
	=?utf-8?b?4oCcUmVtb3ZlIDQuMi41IFdlYiBIb3N0aW5nIFBvbGljeeKAnQ==?=
In-Reply-To: <cc70883bb604483999a4ca3da38e75f4@BY2PR06MB488.namprd06.prod.outlook.com>
References: <cc70883bb604483999a4ca3da38e75f4@BY2PR06MB488.namprd06.prod.outlook.com>
Message-ID: <alpine.BSF.2.00.1404140940170.45610@mail.inlandnet.com>

I'm confused.

On Mon, 14 Apr 2014, Azinger, Marla wrote:

> 
> No support. Right now I don't think it confuses anyone as stated in the rational

I'm not finding a reference to confusion in the documentation for this 
Recommended Draft Policy. Could you please share the link?

> and it just clarifies something ARIN staff will ask
> for.?

It was stated that ARIN staff are not asking for this information 
regarding virtual web hosting. What is being clarified here?

> They ask some companies for detailed router output (which in some cases 
> is not even possible) and they won?t take time to analyze
> domain details?? Which btw if they are legitimate they are very easy to provide.

I'm sorry, but I don't get the relevance of what staff may or may not do 
WRT unrelated policies when considering the merits of a proposal.

> Additionally I use this policy to beat back bogus IP Requests for domains.? This has cut back on BS requested subnet size alot in the
> ISP world.

It seems to me that fraudulent requests would be fraudulent with or 
without this section, and if not fraudulent, they wouldn't be bogus, but 
legitimate.

After all, the existing wording specifies that the information provided is 
for informational purposes only. If anything the removal of this text 
would strengthen the ability to use a corporate policy emphasizing the use 
of name based resolution.

As I said, I'm confused, can you help clarify?

John Springer


From Marla.Azinger at FTR.com  Mon Apr 14 14:42:53 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Mon, 14 Apr 2014 18:42:53 +0000
Subject: [arin-ppml] Yes Support -Draft Policy ARIN-2014-10 Remove Sections
	4.6 and 4.7
Message-ID: <c1fa3b41d78c4ab5b7f8b077776abb6c@BY2PR06MB488.namprd06.prod.outlook.com>

YES support.  This cant be supported any longer due to run out and the need or use of it is poor plan due to the Addressing Market.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140414/9ac8b671/attachment.htm>

From Marla.Azinger at FTR.com  Mon Apr 14 14:49:29 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Mon, 14 Apr 2014 18:49:29 +0000
Subject: [arin-ppml] Yes support -Draft Policy ARIN-2014-10 Remove Sections
	4.6 and 4.7
Message-ID: <f24f73085df745fa9710db1ba9653404@BY2PR06MB488.namprd06.prod.outlook.com>

YES support.  This cant be supported any longer due to run out and the need or use of it is poor plan due to the Addressing Market.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140414/298b9dcb/attachment.htm>

From Marla.Azinger at FTR.com  Mon Apr 14 16:44:08 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Mon, 14 Apr 2014 20:44:08 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-6 Remove 7.1
Message-ID: <0b7df02c886847328dea2228156533e3@BY2PR06MB488.namprd06.prod.outlook.com>

No support.  Im not comfortable with removing things from NRPM until ARIN creates an Operational Document and publishes it.  Then I would support this
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140414/60ad19ec/attachment.htm>

From Marla.Azinger at FTR.com  Mon Apr 14 17:25:48 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Mon, 14 Apr 2014 21:25:48 +0000
Subject: [arin-ppml] =?windows-1252?q?Yes_support_ARIN-prop-2014-5_=96_=93?=
 =?windows-1252?q?Remove_7=2E2_Lame_Delegations=94?=
Message-ID: <94c8b4b53e434909ba8c83ae5d1ea61d@BY2PR06MB488.namprd06.prod.outlook.com>

I support this however, Ignoring how addressing is affected by these things is not beneficial.  This needs to go in a different Operational Document that needs publishing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140414/e7bfafc8/attachment.htm>

From Marla.Azinger at FTR.com  Tue Apr 15 10:47:30 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Tue, 15 Apr 2014 14:47:30 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-3 Remove 8.2 and 8.3 and 8.4
 Minimum IPv4 Block Size Requirements
Message-ID: <aa7a2876ef264b00884dd032032413dc@BY2PR06MB488.namprd06.prod.outlook.com>

No Support at this time.   I have concerns regarding route table growth.  However, it might be good to review if some exceptions where appropriate can be made.  Although, in the long run operators decide what to route.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140415/64056cc0/attachment.htm>

From Jose.Alvarado at allstream.com  Tue Apr 15 10:58:42 2014
From: Jose.Alvarado at allstream.com (Alvarado, Jose)
Date: Tue, 15 Apr 2014 14:58:42 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-3 Remove 8.2 and 8.3 and 8.4
 Minimum IPv4 Block Size Requirements
In-Reply-To: <aa7a2876ef264b00884dd032032413dc@BY2PR06MB488.namprd06.prod.outlook.com>
References: <aa7a2876ef264b00884dd032032413dc@BY2PR06MB488.namprd06.prod.outlook.com>
Message-ID: <EB8AFA74FFC07045AE55825002F34294DD0F55BA@tj1exg02.mtsallstream.com>

As an ISP planner and operator, the concern is with tying to accommodate exceptions as most of our Transit providers have rules that deny >/24 on their route filters. Yes, exceptions can be made but the administration of those exceptions are somewhat cumbersome to keep track of. Agree that ARIN may not be is a position to block or otherwise stipulate the prefix limit, but will be more of a consensus from the global carriers out there.


Regard,


Jose Alvarado
Sr Engineering Specialist, | Technology Operations, Internet & Security  |Customer Operations | * Tel: 416.642.4036 | *Cell: 416.315.4364| * email: jose.alvarado at allstream.com<mailto:jose.alvarado at allstream.com>
MTS Allstream Inc

[sig8]

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Azinger, Marla
Sent: Tuesday, April 15, 2014 10:48 AM
To: ARIN PPML (ppml at arin.net)
Subject: [arin-ppml] Draft Policy ARIN-2014-3 Remove 8.2 and 8.3 and 8.4 Minimum IPv4 Block Size Requirements

No Support at this time.   I have concerns regarding route table growth.  However, it might be good to review if some exceptions where appropriate can be made.  Although, in the long run operators decide what to route.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140415/9a63517f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 17613 bytes
Desc: image001.png
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140415/9a63517f/attachment.png>

From Marla.Azinger at FTR.com  Tue Apr 15 11:46:50 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Tue, 15 Apr 2014 15:46:50 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9 Resolve Conflict Between RSA
 and 8.2 Utilization Requirements
Message-ID: <cd6ace54d4804fd682eba33b1b02f4e6@BY2PR06MB488.namprd06.prod.outlook.com>

YES support.  This policy never should have existed.
As someone who has personally handled 5 different network purchases and integration of those networks, this policy is problematic. The process of integration requires more address space than what is ever currently in use with a purchase. If you are lucky there is more address space than currently in use so that you can easily conduct integration requirements like a lab, upgrades, rolls and more.


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

From Marla.Azinger at FTR.com  Tue Apr 15 13:11:10 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Tue, 15 Apr 2014 17:11:10 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-2 Improving 8.4 Anti-Flip
	Language
Message-ID: <b78b5a72e7f546ab857d6688598478a6@BY2PR06MB488.namprd06.prod.outlook.com>

I support adding an exclusion that says ORG's can conduct inter RIR transfers to their own Organization or subsidiaries.  no time frame limit
There are Global Companies that do their best to manage how much address space gets transferred to what RIR, but there are cases where they realize a chunk needs to be used in a different region. If its address space they brought in out of a Transfer, they should not be limited on how they use it in their organization

Routing Addresses in other Registries works out just fine. However, its requires more coordination with other organizations to ensure reachability is reliable. Additionally, everyone wants WHOIS to be reflective of where IP's are in use. This would help that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140415/e6af24c0/attachment.htm>

From Marla.Azinger at FTR.com  Tue Apr 15 14:54:12 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Tue, 15 Apr 2014 18:54:12 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-8 Alignment of 8.3 Needs
 Requirements to Reality of Business-
Message-ID: <c1a0fe3a05f14620b11a6069f9bd81f7@BY2PR06MB488.namprd06.prod.outlook.com>

I support working on this.

However, I don't believe the second sentence clarifies anything.  "The transferred block(s) plus the amount of free addresses currently registered to the organization, must together not be larger than the demonstrated need."  This does not remove the 30 day immediate use problem.  This just adds another distinct restriction.

 I suggest you remove that sentence and add "transferred blocks are excluded from complying with the 30 day immediate use criteria".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140415/35161e35/attachment.htm>

From Marla.Azinger at FTR.com  Tue Apr 15 15:30:43 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Tue, 15 Apr 2014 19:30:43 +0000
Subject: [arin-ppml] No Support Draft Policy ARIN-2014-11 Improved Registry
 Accuracy Proposal
Message-ID: <390bf338acac406ba33e50131f6403d9@BY2PR06MB488.namprd06.prod.outlook.com>

-Draft Policy ARIN-2014-11 Improved Registry Accuracy Proposal-
I don't support this.  I don't see this as a simple innocent change.
I don't entirely see how this is geared to improve registry use.  In addition your definitions will end up effecting policy and agreements.  Due to this, I would like to see how this would affect exactly which policies and which agreements and with details on how they would be effected .  You can't post haste add definitions without it effecting items already in place.
I don't see this as particularly helpful for companies using Legacy Space.
In regards to some specific bullets:
Fairness- This is impossible to guarantee.  It doesn't happen today and it likely never will.  This is why there is some variation in address policy today.
Mutual Benefit - No Support.  There are legitimate business reasons for Legacy space.  Additionally, dissolving contracts is particularly troublesome and is an act that would be sure to end up in expensive litigation.
Legacy Internet Resource definition is written so that it purposely excludes transferred addresses from retaining Legacy status.
This proposal is not a simple "accuracy change".  Its written in a manner that appears be created for putting the pinch on companies that have to use newer alternative processes.  These changes would not help companies struggling due to ARIN policy that falls short of supporting all members equally.

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

From jaymartin926 at gmail.com  Tue Apr 15 22:25:43 2014
From: jaymartin926 at gmail.com (Jay Martin)
Date: Wed, 16 Apr 2014 10:25:43 +0800
Subject: [arin-ppml] Draft Policy ARIN-2014-9 Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <cd6ace54d4804fd682eba33b1b02f4e6@BY2PR06MB488.namprd06.prod.outlook.com>
References: <cd6ace54d4804fd682eba33b1b02f4e6@BY2PR06MB488.namprd06.prod.outlook.com>
Message-ID: <CALJtNOZj6G4nc55ys_-br53MLE5Ntw4O_GCi6wz2VVRiR529mQ@mail.gmail.com>

Hi Azinger,

My standpoint to this proposal is neutral.   Someone inside ARIN told that
AOL has done  the 8.2 transfer recently.  The so-called conflict and
utilisation rate test is just some bureau language left there without
preventing this transfer.

ARIN is so nice to talk and assist on the 8.2 transfer request and has
paved out the way for AOL's next 8.3 transfer to anyone interested in
purchase.  There is no real issues to be resolved by this 2014-9 Proposal.
 I suggest to withdraw this proposal.

Furthermore, the good news is that  there are many ZERO utilisation blocks
for Sale now.  Is there anyone interested to join me to form a consortium
to buy some IPv4?

172.210.0.0/16;172.211.0.0/16;62.51.0.0/17;62.78.0.0/19;64.12.0.0/16;64.236.0.0/16;66.185.128.0/19;149.174.0.0/16;152.163.0.0/16;172.128.0.0/10;172.128.0.0/16;172.129.0.0/16;172.130.0.0/16;172.131.0.0/16;172.132.0.0/16;172.133.0.0/16;172.134.0.0/16;172.135.0.0/16;172.136.0.0/16;172.137.0.0/16;172.138.0.0/16;172.139.0.0/16;172.140.0.0/16;172.158.0.0/16;172.160.0.0/16;172.161.0.0/16;172.162.0.0/16;172.163.0.0/16;172.164.0.0/16;172.165.0.0/16;172.166.0.0/16;172.167.0.0/16;172.168.0.0/16;172.169.0.0/16172.170.0.0/16;172.171.0.0/16;172.172.0.0/16;172.173.0.0/16;172.174.0.0/16;172.175.0.0/16;172.176.0.0/16;172.177.0.0/16;172.178.0.0/16;172.180.0.0/16
;


Jay










On Tue, Apr 15, 2014 at 11:46 PM, Azinger, Marla <Marla.Azinger at ftr.com>wrote:

>  YES support.  This policy never should have existed.
>
> As someone who has personally handled 5 different network purchases and
> integration of those networks, this policy is problematic. The process of
> integration requires more address space than what is ever currently in use
> with a purchase. If you are lucky there is more address space than
> currently in use so that you can easily conduct integration requirements
> like a lab, upgrades, rolls and more.
>
>
>
>
>
> _______________________________________________
> 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/20140416/6a8ad7a4/attachment.htm>

From jay-ARIN at tp.org  Tue Apr 15 22:36:48 2014
From: jay-ARIN at tp.org (Jay Moran (AOL))
Date: Tue, 15 Apr 2014 22:36:48 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-9 Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <CALJtNOZj6G4nc55ys_-br53MLE5Ntw4O_GCi6wz2VVRiR529mQ@mail.gmail.com>
References: <cd6ace54d4804fd682eba33b1b02f4e6@BY2PR06MB488.namprd06.prod.outlook.com>
	<CALJtNOZj6G4nc55ys_-br53MLE5Ntw4O_GCi6wz2VVRiR529mQ@mail.gmail.com>
Message-ID: <CA+Ld8r8DSne2G9wp+iNLdnVHoDzW=PcxvFSCnj=OctFYrYHawg@mail.gmail.com>

My former email on this subject still stands. There should NOT be
utilization language in the 8.2 transfers, for all the reasons I listed
before, and with potential options if there is dread of some type of abuse
of 8.2.

Whether or not and 8.2 transfer occurs is not the point, the point is the
language goes against the RSA and it causes un-needed legal reviews and
risk analysis by many teams in corporations fearful of their inability to
continue operations as-is. Those are what prevent some (myself included)
from undertaking the 8.2 transfers in order to accurately update the
registry.

Now excuse me while I go find my corporate credit card to pay a fee in the
next few days.

Jay Moran, AOL

--
Jay Moran
http://tp.org/jay


On Tue, Apr 15, 2014 at 10:25 PM, Jay Martin <jaymartin926 at gmail.com> wrote:

> Hi Azinger,
>
> My standpoint to this proposal is neutral.   Someone inside ARIN told that
> AOL has done  the 8.2 transfer recently.  The so-called conflict and
> utilisation rate test is just some bureau language left there without
> preventing this transfer.
>
> ARIN is so nice to talk and assist on the 8.2 transfer request and has
> paved out the way for AOL's next 8.3 transfer to anyone interested in
> purchase.  There is no real issues to be resolved by this 2014-9 Proposal.
>  I suggest to withdraw this proposal.
>
> Furthermore, the good news is that  there are many ZERO utilisation blocks
> for Sale now.  Is there anyone interested to join me to form a consortium
> to buy some IPv4?
>
>
> 172.210.0.0/16;172.211.0.0/16;62.51.0.0/17;62.78.0.0/19;64.12.0.0/16;64.236.0.0/16;66.185.128.0/19;149.174.0.0/16;152.163.0.0/16;172.128.0.0/10;172.128.0.0/16;172.129.0.0/16;172.130.0.0/16;172.131.0.0/16;172.132.0.0/16;172.133.0.0/16;172.134.0.0/16;172.135.0.0/16;172.136.0.0/16;172.137.0.0/16;172.138.0.0/16;172.139.0.0/16;172.140.0.0/16;172.158.0.0/16;172.160.0.0/16;172.161.0.0/16;172.162.0.0/16;172.163.0.0/16;172.164.0.0/16;172.165.0.0/16;172.166.0.0/16;172.167.0.0/16;172.168.0.0/16;172.169.0.0/16172.170.0.0/16;172.171.0.0/16;172.172.0.0/16;172.173.0.0/16;172.174.0.0/16;172.175.0.0/16;172.176.0.0/16;172.177.0.0/16;172.178.0.0/16;172.180.0.0/16
> ;
>
>
> Jay
>
>
>
>
>
>
>
>
>
>
> On Tue, Apr 15, 2014 at 11:46 PM, Azinger, Marla <Marla.Azinger at ftr.com>wrote:
>
>>  YES support.  This policy never should have existed.
>>
>> As someone who has personally handled 5 different network purchases and
>> integration of those networks, this policy is problematic. The process of
>> integration requires more address space than what is ever currently in use
>> with a purchase. If you are lucky there is more address space than
>> currently in use so that you can easily conduct integration requirements
>> like a lab, upgrades, rolls and more.
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20140415/0b6d969f/attachment.htm>

From scottleibrand at gmail.com  Wed Apr 16 10:21:24 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 16 Apr 2014 07:21:24 -0700
Subject: [arin-ppml] APNIC implements AS number transfer policy (including
	inter-RIR ASN transfers)
Message-ID: <CAGkMwz4jRS2L3_Ze42JFx_n7g_jkGcc1gXiiVcc-5FxONOMxuw@mail.gmail.com>

In July 2013, the ARIN AC abandoned draft policy ARIN-2013-1 "Section 8.4
Inter-RIR Transfers of ASNs", because "The feedback from the community
indicated that many people felt the policy was unnecessary as it would have
no effect until/unless another RIR expresses interest in allowing Inter-RIR
ASN transfers as well." -
http://lists.arin.net/pipermail/arin-ppml/2013-July/027028.html

Per the forwarded message below, that is no longer true: APNIC has
implemented an inter-RIR ASN transfer policy.   If anyone thinks it would
be useful to support such transfers to/from the ARIN region, I would be
happy to work with you on.a new (or simply reintroduced) inter-RIR ASN
transfer policy proposal.

-Scott (speaking only for myself)

---------- Forwarded message ----------
From: Adam Gosling <adam at apnic.net>
Date: Tue, Apr 15, 2014 at 8:33 PM
Subject: [sig-policy] Implementation of prop-107: AS number transfer policy
proposal
To: Policy Mailing List <sig-policy at apnic.net>



 _________________________________________________

 Transfer of AS Numbers now possible with new APNIC policy
_________________________________________________

 Today, 16 April 2014, APNIC implemented a change in Autonomous System
Numbers policy which will permit the transfer of AS Numbers between
APNIC account holders. The proposal reached consensus during APNIC 36 in
Xi'An, China in August 2013.

 The policy proposal implemented is:

     - prop-107: AS number transfer policy proposal

       This policy would permit the transfer of Autonomous System Numbers
      (ASNs) within the APNIC region and between regions with compatible
      inter-regional ASN transfer policies.

       http://www.apnic.net/policy/proposals/prop-107

 No other Regional Internet Registry currently has an inter-RIR ASN
transfer policy that would permit the transfer of ASNs between regions.

 The policy change required edits to two documents. The comment period
for the draft documents incorporating these policies ended on 10 January
2014. The following updated documents are now officially active:

     - Policies for Autonomous System number management in the Asia
      Pacific region
    - APNIC transfer, merger, acquisition, and takeover policy

 For more information on the history of APNIC policy proposals, see the
Policy Proposals page.

     http://www.apnic.net/community/policy/proposals

 Regards

 --
Adam Gosling
Internet Policy Development Consultant     email:    adam at apnic.net
APNIC
 sip:    adam at voip.apnic.net
http://www.apnic.net                                   phone:     +61 7
3858 3100
________________________________________________________________________
 * Sent by email to save paper. Print only if necessary.

*              sig-policy:  APNIC SIG on resource management policy
  *
_______________________________________________
sig-policy mailing list
sig-policy at lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140416/7600eb03/attachment.htm>

From narten at us.ibm.com  Fri Apr 18 00:53:03 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 18 Apr 2014 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201404180453.s3I4r3Kn032408@rotala.raleigh.ibm.com>

Total of 23 messages in the last 7 days.
 
script run at: Fri Apr 18 00:53:03 EDT 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 52.17% |   12 | 38.76% |   109879 | marla.azinger at ftr.com
  8.70% |    2 | 21.09% |    59799 | jay-arin at tp.org
  4.35% |    1 | 13.88% |    39346 | jose.alvarado at allstream.com
  8.70% |    2 |  4.68% |    13280 | hannigan at gmail.com
  4.35% |    1 |  4.93% |    13966 | scottleibrand at gmail.com
  4.35% |    1 |  4.50% |    12748 | jaymartin926 at gmail.com
  4.35% |    1 |  3.87% |    10985 | owen at delong.com
  4.35% |    1 |  3.32% |     9408 | lsawyer at gci.com
  4.35% |    1 |  2.54% |     7187 | narten at us.ibm.com
  4.35% |    1 |  2.43% |     6892 | springer at inlandnet.com
--------+------+--------+----------+------------------------
100.00% |   23 |100.00% |   283490 | Total



From jschiller at google.com  Fri Apr 18 16:21:26 2014
From: jschiller at google.com (Jason Schiller)
Date: Fri, 18 Apr 2014 16:21:26 -0400
Subject: [arin-ppml] 2-byte and 4-byte ASNs
Message-ID: <CAC4yj2XUpkMa0LFfrhO7drEHmYmqj2WucdgMmGgLEi_g2Z73CA@mail.gmail.com>

I wanted to summarize what I heard at the open mic and give the wider
community a chance to comment.

Questions:

1. Is it in the best interest of the Internet for ARIN to give out 2-byte
ASNs by default?

Should we use up the 2-byte ASNs, or try to conserve them for those who
need them?

2. Should an RIR be forced to burn through 2-byte ASNs in order to qualify
to get additional ASNs?

Should an RIR that has used all the 2-byte ASN be prevented from getting
more ASNs until their total utilization is higher from giving out more
4-byte ASNs?

3.  There are just under 500 2-byte ASNs left in the IANA pool.  Should the
RIRs each get 99 of these?  Or should the next requestor take all of the
2-byte ASNs and the balance of the block of 1024 in four-byte ASNs?

Answers:

The ARIN community continues to suggest there is no hardware reason that
would prevent support of 4-byte ASNs.  The community desires that we use up
the 2-byte ASNs and continue to send a message that code upgrades to
support 4-byte ASNs are now required.

There was some support for giving each RIR (who wants it) an equal share of
the remaining 2-byte ASNs.


Background:

Global policy for the Allocation of ASN Blocks to Regional Internet
Registries

https://www.icann.org/en/resources/policy/global-addressing/global-policy-asn-blocks-21sep10-en.htm

Starting in 2011, this policy requires IANA and the RIRs to maintain a
single 32-bit ASN pool and not differentiate between ASN below or above
65535.

ARIN practice is to suggest organizations that request an ASN to choose a
four byte ASN if practical and will otherwise get a 2-byte ASN.  (There was
a brief period where ARIN reversed the default giving out 4-byte ASNs
unless a 2-byte was specifically requested).

Leslie has thrice advised the community that 4-byte ASNs continue to get
returned due to the inability for the requester or their upstream to
support 4-byte ASNs.

Each time the ARIN community has responded that there is no hardware based
technical issue why 4-byte ASNs cannot be supported, and that the community
wants to send the message that everyone needs to complete the appropriate
code upgrades and support 4-byte ASNs.

This means in the ARIN region, we will likely deplete 2-byte ASNs and still
have available 4-byte ASNs.  If the number of available 4-byte ASNs is
large enough, the total ASN utilization will be below 80% and ARIN will not
qualify to get additional ASNs from the IANA, until more 4-byte ASNs are
utilized.

In regions where 4-byte ASN usage is greater then 2-byte ASN usage, these
RIRs may find they have assigned all of their available 4-byte ASN and due
to under utilized 2-byte ASNs may not qualify to get additional 4-bye ASNs.
 In this case they may be forced to assign 2-byte ASNs to organizations who
could otherwise use a 4-byte ASN.


It is also possible that the next requestor could take all of the available
2-byte ASNs.

The ASO AC provided advice that a block of 1024 could consist of a
non-contiguous rage of ASNs below the value of 65525 and above the value of
65525.  This was based on community input, a desire to not strand 2-byte
ASNs in the IANA, and the understanding that there is no aggregation
benefit from round numbers.  This advice was provided in the context of
using up the 2-byte ASNs.  LACNIC asked for half of their block to be
2-byte and half to be 4-byte, and IANA complied.

It is now possible the same advice will be leveraged to allow the RIR to
request only 99 2-byte ASNs and the balance in 4-byte ASNs, allowing IANA
to hold back one last round of 2-byte ASNs for each RIR upon their next
request.

Thanks,

__Jason

-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140418/3071fcd5/attachment.htm>

From bill at herrin.us  Fri Apr 18 16:32:08 2014
From: bill at herrin.us (William Herrin)
Date: Fri, 18 Apr 2014 16:32:08 -0400
Subject: [arin-ppml] 2-byte and 4-byte ASNs
In-Reply-To: <CAC4yj2XUpkMa0LFfrhO7drEHmYmqj2WucdgMmGgLEi_g2Z73CA@mail.gmail.com>
References: <CAC4yj2XUpkMa0LFfrhO7drEHmYmqj2WucdgMmGgLEi_g2Z73CA@mail.gmail.com>
Message-ID: <CAP-guGX0bBr4XE_um_7tiWEVfeFX_H3sqWLqLi2DoOaiSxnzhw@mail.gmail.com>

On Fri, Apr 18, 2014 at 4:21 PM, Jason Schiller <jschiller at google.com> wrote:
> The ARIN community continues to suggest there is no hardware reason that
> would prevent support of 4-byte ASNs.  The community desires that we use up
> the 2-byte ASNs and continue to send a message that code upgrades to support
> 4-byte ASNs are now required.


Question:

Large ISPs implement BGP communities with a convention of 16-bit ASN
followed by 16-bits of locally defined meaning, such as set local pref
to 80.

Does a comparable convention exist when dealing with 32-bit ASNs? If
not, what's the plan?

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jschiller at google.com  Fri Apr 18 16:44:29 2014
From: jschiller at google.com (Jason Schiller)
Date: Fri, 18 Apr 2014 16:44:29 -0400
Subject: [arin-ppml] 2-byte and 4-byte ASNs
In-Reply-To: <CAP-guGX0bBr4XE_um_7tiWEVfeFX_H3sqWLqLi2DoOaiSxnzhw@mail.gmail.com>
References: <CAC4yj2XUpkMa0LFfrhO7drEHmYmqj2WucdgMmGgLEi_g2Z73CA@mail.gmail.com>
	<CAP-guGX0bBr4XE_um_7tiWEVfeFX_H3sqWLqLi2DoOaiSxnzhw@mail.gmail.com>
Message-ID: <CAC4yj2UyEBkJrjGV03vGjzLXigModRe8HvUp5bzhn+MQEWkFGw@mail.gmail.com>

This was brought up at the open mic, and people just shrugged.

I agree that this does not sound like a solution, but at the same
time it did not move the community to reconsider their direction.

__Jason


On Fri, Apr 18, 2014 at 4:32 PM, William Herrin <bill at herrin.us> wrote:

> On Fri, Apr 18, 2014 at 4:21 PM, Jason Schiller <jschiller at google.com>
> wrote:
> > The ARIN community continues to suggest there is no hardware reason that
> > would prevent support of 4-byte ASNs.  The community desires that we use
> up
> > the 2-byte ASNs and continue to send a message that code upgrades to
> support
> > 4-byte ASNs are now required.
>
>
> Question:
>
> Large ISPs implement BGP communities with a convention of 16-bit ASN
> followed by 16-bits of locally defined meaning, such as set local pref
> to 80.
>
> Does a comparable convention exist when dealing with 32-bit ASNs? If
> not, what's the plan?
>
> Regards,
> Bill Herrin
>
>
>
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140418/1b4a86c1/attachment.htm>

From dmiller at tiggee.com  Fri Apr 18 17:07:44 2014
From: dmiller at tiggee.com (David Miller)
Date: Fri, 18 Apr 2014 17:07:44 -0400
Subject: [arin-ppml] 2-byte and 4-byte ASNs
In-Reply-To: <CAP-guGX0bBr4XE_um_7tiWEVfeFX_H3sqWLqLi2DoOaiSxnzhw@mail.gmail.com>
References: <CAC4yj2XUpkMa0LFfrhO7drEHmYmqj2WucdgMmGgLEi_g2Z73CA@mail.gmail.com>
	<CAP-guGX0bBr4XE_um_7tiWEVfeFX_H3sqWLqLi2DoOaiSxnzhw@mail.gmail.com>
Message-ID: <53519420.1060506@tiggee.com>



On 4/18/2014 4:32 PM, William Herrin wrote:
> On Fri, Apr 18, 2014 at 4:21 PM, Jason Schiller <jschiller at google.com> wrote:
>> The ARIN community continues to suggest there is no hardware reason that
>> would prevent support of 4-byte ASNs.  The community desires that we use up
>> the 2-byte ASNs and continue to send a message that code upgrades to support
>> 4-byte ASNs are now required.
> 
> 
> Question:
> 
> Large ISPs implement BGP communities with a convention of 16-bit ASN
> followed by 16-bits of locally defined meaning, such as set local pref
> to 80.
> 
> Does a comparable convention exist when dealing with 32-bit ASNs? If
> not, what's the plan?
> 
> Regards,
> Bill Herrin
> 
> 
> 

RFC 5668 - 4-Octet AS Specific BGP Extended Community
http://tools.ietf.org/html/rfc5668

-DMM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140418/49646b40/attachment.sig>

From jlewis at lewis.org  Fri Apr 18 17:46:07 2014
From: jlewis at lewis.org (Jon Lewis)
Date: Fri, 18 Apr 2014 17:46:07 -0400 (EDT)
Subject: [arin-ppml] 2-byte and 4-byte ASNs
In-Reply-To: <CAC4yj2UyEBkJrjGV03vGjzLXigModRe8HvUp5bzhn+MQEWkFGw@mail.gmail.com>
References: <CAC4yj2XUpkMa0LFfrhO7drEHmYmqj2WucdgMmGgLEi_g2Z73CA@mail.gmail.com>
	<CAP-guGX0bBr4XE_um_7tiWEVfeFX_H3sqWLqLi2DoOaiSxnzhw@mail.gmail.com>
	<CAC4yj2UyEBkJrjGV03vGjzLXigModRe8HvUp5bzhn+MQEWkFGw@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.1404181713290.10544@soloth.lewis.org>

Wouldn't these routing policies just need to be rewritten/modernized to 
use extended communities instead of the old 32-bit communities?  64-bits 
of ext-community ought to be enough for community-type, a 32-bit ASN, and 
some policy instruction.  Whether any routers support this, and in a 
user-friendly display format, is the next question...and if not now, how 
soon?

On Fri, 18 Apr 2014, Jason Schiller wrote:

> This was brought up at the open mic, and people just shrugged.
>
> I agree that this does not sound like a solution, but at the same
> time it did not move the community to reconsider their direction.

>> Question:
>>
>> Large ISPs implement BGP communities with a convention of 16-bit ASN
>> followed by 16-bits of locally defined meaning, such as set local pref
>> to 80.
>>
>> Does a comparable convention exist when dealing with 32-bit ASNs? If
>> not, what's the plan?
>>
>> Regards,
>> Bill Herrin

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
                              |  therefore you are
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From farmer at umn.edu  Fri Apr 18 18:38:42 2014
From: farmer at umn.edu (David Farmer)
Date: Fri, 18 Apr 2014 17:38:42 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <5331CA99.2000806@arin.net>
References: <5331CA99.2000806@arin.net>
Message-ID: <5351A972.6000702@umn.edu>


Draft Policy ARIN-2014-12 "Anti-hijack Policy," was discussed at ARIN 33 
in Chicago this week, it was generally supported.  However, there were 
two modifications to the Policy Text suggested;

1.  In the first paragraph; change "previously" to "currently".

2.  Remove the last sentence of the second paragraph;  This sentence 
implies that ARIN should issue an LOA, where as ARIN should NOT issue 
any LOA at all, expect for resources assigned to ARIN for its 
operational use. ARIN should record the allocation to the receiving 
organization in its public database, then the organization with the 
allocation may issue any LOA necessary.

Are there any additional comments or suggestions for the AC to consider?

Otherwise, the AC will consider the advancement of the modified text to 
Recommended Draft Policy status.

-----

Draft Policy ARIN-2014-12
Anti-hijack Policy

Problem Statement:

ARIN should not give research organizations permission to hijack 
prefixes that have already been allocated. Research organizations 
announcing lit aggregates may receive sensitive production traffic 
belonging to live networks during periods of instability.

Section 11.7 describes more than allocation size therefore updating the 
section heading to something more accurate is appropriate.

Policy statement:

Modify the section 11.7 heading to be more accurate. Modify the first 
sentence to prohibit overlapping assignments. Add text at the end to 
define how research allocations should be designated and prohibit LOA's 
without allocations.

Annotated text

11.7 Policy Text for NRPM
Original 2014-12 Policy Text
Proposed Changes to 2014-12 Policy Text

11.7 Resource Allocation SizeGuidelines


The Numbering Resources requested come from the global Internet Resource 
space, do not overlap previouslycurrentlyassigned space, and are not 
from private or other non-routable Internet Resource space. The 
allocation size should be consistent with the existing ARIN minimum 
allocation sizes, unless small allocations are intended to be explicitly 
part of the experiment. If an organization requires more resource than 
stipulated by the minimum allocation sizes in force at the time of their 
request, their experimental documentation should have clearly described 
and justified why this is required.

All research allocations must be registered publicly in whois. Each 
research allocation will be designated as a research allocation with a 
comment indicating when the allocation will end. ARIN will not issue a 
Letter of Authority (LOA) to route a research prefix unless the 
allocation is properly registered in whois.

-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

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

From lsawyer at gci.com  Fri Apr 18 19:01:55 2014
From: lsawyer at gci.com (Leif Sawyer)
Date: Fri, 18 Apr 2014 15:01:55 -0800
Subject: [arin-ppml] 2-byte and 4-byte ASNs
In-Reply-To: <CAC4yj2XUpkMa0LFfrhO7drEHmYmqj2WucdgMmGgLEi_g2Z73CA@mail.gmail.com>
References: <CAC4yj2XUpkMa0LFfrhO7drEHmYmqj2WucdgMmGgLEi_g2Z73CA@mail.gmail.com>
Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102C741A64D@fnb1mbx01.gci.com>

Jason -

My responses out-of-order to the questions (ignoring your answers)

2/3:   I would be in support of policy that provided  IANA with direction to equally distribute the remaining 2-byte ASNs to the RIRs.
     Once that has taken place, it can be left to the individual RIR to adapt policy as they see fit.


1:  If my memory serves, current ARIN (operational) policy is to  "Offer 4-byte first, when no preference is given,  and offer a fall-back to 2-byte"
and if that is correct, I see no need to change this policy.

-Leif



From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason Schiller
Sent: Friday, April 18, 2014 12:21 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] 2-byte and 4-byte ASNs

I wanted to summarize what I heard at the open mic and give the wider community a chance to comment.

Questions:

1. Is it in the best interest of the Internet for ARIN to give out 2-byte ASNs by default?

Should we use up the 2-byte ASNs, or try to conserve them for those who need them?

2. Should an RIR be forced to burn through 2-byte ASNs in order to qualify to get additional ASNs?

Should an RIR that has used all the 2-byte ASN be prevented from getting more ASNs until their total utilization is higher from giving out more 4-byte ASNs?

3.  There are just under 500 2-byte ASNs left in the IANA pool.  Should the RIRs each get 99 of these?  Or should the next requestor take all of the 2-byte ASNs and the balance of the block of 1024 in four-byte ASNs?


_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com<mailto:jschiller at google.com>|571-266-0006



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

From owen at delong.com  Fri Apr 18 20:05:24 2014
From: owen at delong.com (Owen DeLong)
Date: Fri, 18 Apr 2014 17:05:24 -0700
Subject: [arin-ppml] 2-octet and 4-octet ASNs
In-Reply-To: <Pine.LNX.4.61.1404181713290.10544@soloth.lewis.org>
References: <CAC4yj2XUpkMa0LFfrhO7drEHmYmqj2WucdgMmGgLEi_g2Z73CA@mail.gmail.com>
	<CAP-guGX0bBr4XE_um_7tiWEVfeFX_H3sqWLqLi2DoOaiSxnzhw@mail.gmail.com>
	<CAC4yj2UyEBkJrjGV03vGjzLXigModRe8HvUp5bzhn+MQEWkFGw@mail.gmail.com>
	<Pine.LNX.4.61.1404181713290.10544@soloth.lewis.org>
Message-ID: <2D85D8DC-17F3-4456-9DEA-325AC64F1A41@delong.com>

As I understand it, the perceived issue is:

RIRs issuing primarily 4-octet ASNs are running out of 4-octet ASNs and want to get more 4-octet ASNs from IANA without having to first exhaust their 2-octet pools.

Now, for my opinion on the matter:

IMHO, the intent of the current policy was to achieve 4-octet adoption and provide a predictable path to 2-octet ASN exhaustion.

The current circumstance appears to be an unintended consequence of 4-octet adoption exceeding expectations at least in some regions. As such, I suggest the following:

(Hopefully uncontroversial):
1.	Authorize IANA to distribute 4-octet ASN pools to the RIRs without regard to their consumption of 2-octet ASNs

(Probably controversial, but hopefully not too controversial):
2.	Distribute the remaining 2-octet ASNs in the IANA pool to the RIRs on an even basis with any remainder being distributed in descending
	order of number of 4-octet ASNs issued by the RIR in calendar year 2013.

	(IOW, if N%5==3, the 3 RIRs that issued the most 4-octet ASNs would receive 1 each).

However, I believe that both of the above possibilities would require global policy in order for IANA to act on them and I'm not sure such can be achieved prior to being overtaken by events.

Thoughts?

Owen





From billdarte at gmail.com  Sat Apr 19 08:03:25 2014
From: billdarte at gmail.com (Bill Darte)
Date: Sat, 19 Apr 2014 07:03:25 -0500
Subject: [arin-ppml] Draft Policy ARIN 2014-2 Improving Anti-Flip Language
Message-ID: <CAMApp35gdhAY2=vjSqvxKBUNh0aCwDAbCo0T-un-64uL75gMWQ@mail.gmail.com>

The Draft Policy ARIN 2014-2 Improving Anti-Flip Language was discussed at
the ARIN 33 Public Policy Meeting in Chicago last week and while there was
no consensus for the Draft using current language, the community encouraged
the AC to continue work on it as there was sympathy for the problem
statement. https://www.arin.net/policy/proposals/2014_2.html

Draft Policy Issue:
Simply, the author wishes the Anti-Flip language currently used in the NRPM
to be relaxed, allowing an Inter-RIR transfer within their own organization
of previously existing addresses....though they may have received a new
allocation or assignment within the last 12 months.

Current draft language states that the organization may do such a transfer,
but may not use the actual addresses which were received from ARIN (or
through transfer) in the previous 12 months.  But they could therefore
transfer other resources holdings.

Request for feedback:
In order to further this discussion and gain a consensus, I would like to
once again ask the community to speak in favor or against this Draft Policy
so that it may be presented and discussed at our next Public Policy
Consultation at NANOG in June.

1. Yes or No.  Should the community relax existing policy which attempts to
limit the transfer of ARIN resources out of region, in order to allow an
organization flexibility to move address blocks to another portion of their
own organization in another region, even though they might have received
different addresses within ARIN in the last 12 months?

(Note current policy would still restrict availability of new addresses to
the organization for a period of 12 months after the transfer and is not
being changed by this draft).

2.  If YES above, are there any other qualifications or limits that should
be imposed on the resources transferred or the organization?

(Note that a vote of NO to question #1 would essentially ask the Advisory
Council to abandon this draft policy leaving existing policy in place.)

Thanks to all who continue to work within the community to exercise their
right and duty to craft appropriate policy guiding ARIN's important role in
Internet number resource management.

Bill Darte
Policy Shepherd for 2014-2
ARIN Advisory Council
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140419/1396b971/attachment.htm>

From hannigan at gmail.com  Sat Apr 19 13:21:47 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Sat, 19 Apr 2014 13:21:47 -0400
Subject: [arin-ppml] 2-byte and 4-byte ASNs
In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102C741A64D@fnb1mbx01.gci.com>
References: <CAC4yj2XUpkMa0LFfrhO7drEHmYmqj2WucdgMmGgLEi_g2Z73CA@mail.gmail.com>
	<18B2C6E38A3A324986B392B2D18ABC5102C741A64D@fnb1mbx01.gci.com>
Message-ID: <CAMDXq5Mn17xsFBObbUsyQjYYffJYtM7BNbKKyHV1YMiL22Dqhg@mail.gmail.com>

I don't believe that they need a policy (at the IANA and for the RIR')
to take less, previous policy at the IANA was recommended by the RIR's
to be interpreted as maximums vs. absolute and this would be likely be
acceptable here as well based on the precedent and the fact that
people are asking about it. Whether that is right or wrong, thats how
it works.

Interesting that we're still talking about this:

    http://lists.arin.net/pipermail/arin-ppml/2005-December/004264.html

My interpretation of the meeting interest was largely apathy and "stay
the course".

Best,

-M<


On Fri, Apr 18, 2014 at 7:01 PM, Leif Sawyer <lsawyer at gci.com> wrote:
> Jason -
>
>
>
> My responses out-of-order to the questions (ignoring your answers)
>
>
>
> 2/3:   I would be in support of policy that provided  IANA with direction to
> equally distribute the remaining 2-byte ASNs to the RIRs.
>
>      Once that has taken place, it can be left to the individual RIR to
> adapt policy as they see fit.
>
>
>
>
>
> 1:  If my memory serves, current ARIN (operational) policy is to  "Offer
> 4-byte first, when no preference is given,  and offer a fall-back to 2-byte"
>
> and if that is correct, I see no need to change this policy.
>
>
>
> -Leif
>
>
>
>
>
>
>
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Jason Schiller
> Sent: Friday, April 18, 2014 12:21 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] 2-byte and 4-byte ASNs
>
>
>
> I wanted to summarize what I heard at the open mic and give the wider
> community a chance to comment.
>
>
>
> Questions:
>
>
>
> 1. Is it in the best interest of the Internet for ARIN to give out 2-byte
> ASNs by default?
>
>
>
> Should we use up the 2-byte ASNs, or try to conserve them for those who need
> them?
>
>
>
> 2. Should an RIR be forced to burn through 2-byte ASNs in order to qualify
> to get additional ASNs?
>
>
>
> Should an RIR that has used all the 2-byte ASN be prevented from getting
> more ASNs until their total utilization is higher from giving out more
> 4-byte ASNs?
>
>
>
> 3.  There are just under 500 2-byte ASNs left in the IANA pool.  Should the
> RIRs each get 99 of these?  Or should the next requestor take all of the
> 2-byte ASNs and the balance of the block of 1024 in four-byte ASNs?
>
>
>
>
>
> _______________________________________________________
>
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>
>
>
>
> _______________________________________________
> 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.


From bill at herrin.us  Sun Apr 20 01:12:31 2014
From: bill at herrin.us (William Herrin)
Date: Sun, 20 Apr 2014 01:12:31 -0400
Subject: [arin-ppml] Draft Policy ARIN 2014-2 Improving Anti-Flip
	Language
In-Reply-To: <CAMApp35gdhAY2=vjSqvxKBUNh0aCwDAbCo0T-un-64uL75gMWQ@mail.gmail.com>
References: <CAMApp35gdhAY2=vjSqvxKBUNh0aCwDAbCo0T-un-64uL75gMWQ@mail.gmail.com>
Message-ID: <CAP-guGVBCPEvXPybTnu-uCZiH066gGQUPVu6ZbDOo6pOSojBPA@mail.gmail.com>

On Sat, Apr 19, 2014 at 8:03 AM, Bill Darte <billdarte at gmail.com> wrote:
> Request for feedback:
> 1. Yes or No.  Should the community relax existing policy which attempts to
> limit the transfer of ARIN resources out of region?

No.

Regards,
Bill Herrin




-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From mpetach at netflight.com  Sun Apr 20 03:08:58 2014
From: mpetach at netflight.com (Matthew Petach)
Date: Sun, 20 Apr 2014 00:08:58 -0700
Subject: [arin-ppml] 2-octet and 4-octet ASNs
In-Reply-To: <2D85D8DC-17F3-4456-9DEA-325AC64F1A41@delong.com>
References: <CAC4yj2XUpkMa0LFfrhO7drEHmYmqj2WucdgMmGgLEi_g2Z73CA@mail.gmail.com>
	<CAP-guGX0bBr4XE_um_7tiWEVfeFX_H3sqWLqLi2DoOaiSxnzhw@mail.gmail.com>
	<CAC4yj2UyEBkJrjGV03vGjzLXigModRe8HvUp5bzhn+MQEWkFGw@mail.gmail.com>
	<Pine.LNX.4.61.1404181713290.10544@soloth.lewis.org>
	<2D85D8DC-17F3-4456-9DEA-325AC64F1A41@delong.com>
Message-ID: <CAEmG1=qAzomAuPjj6nHvWtfRm1cVpG=jawb_L4wvMZTCwnA9HQ@mail.gmail.com>

On Fri, Apr 18, 2014 at 5:05 PM, Owen DeLong <owen at delong.com> wrote:

> As I understand it, the perceived issue is:
>
>
> [...]

>
> (Hopefully uncontroversial):
> 1.      Authorize IANA to distribute 4-octet ASN pools to the RIRs without
> regard to their consumption of 2-octet ASNs
>
>
I'd support that, no concerns.

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140420/923ccafa/attachment.htm>

From nikiyangxf at gmail.com  Sun Apr 20 21:46:56 2014
From: nikiyangxf at gmail.com (xiaofan yang)
Date: Mon, 21 Apr 2014 09:46:56 +0800
Subject: [arin-ppml] Draft Policy ARIN 2014-2 Improving Anti-Flip
	Language
In-Reply-To: <CAMApp35gdhAY2=vjSqvxKBUNh0aCwDAbCo0T-un-64uL75gMWQ@mail.gmail.com>
References: <CAMApp35gdhAY2=vjSqvxKBUNh0aCwDAbCo0T-un-64uL75gMWQ@mail.gmail.com>
Message-ID: <CAPhL6MrrRJPfD1NES1rP95xDKQV-uVNX9aU-Mxtw5=ZsHR1Vug@mail.gmail.com>

Hi Bill,

Thanks for your update and summary.

My answer is to tick option 1 with answer of NO. As ARIN still has the free
pool, there is no need to further discuss this proposal.  I would like to
suggest to abandon this draft.

Regards,

Niki






On Sat, Apr 19, 2014 at 8:03 PM, Bill Darte <billdarte at gmail.com> wrote:

> The Draft Policy ARIN 2014-2 Improving Anti-Flip Language was discussed at
> the ARIN 33 Public Policy Meeting in Chicago last week and while there was
> no consensus for the Draft using current language, the community encouraged
> the AC to continue work on it as there was sympathy for the problem
> statement. https://www.arin.net/policy/proposals/2014_2.html
>
> Draft Policy Issue:
> Simply, the author wishes the Anti-Flip language currently used in the
> NRPM to be relaxed, allowing an Inter-RIR transfer within their own
> organization of previously existing addresses....though they may have
> received a new allocation or assignment within the last 12 months.
>
> Current draft language states that the organization may do such a
> transfer, but may not use the actual addresses which were received from
> ARIN (or through transfer) in the previous 12 months.  But they could
> therefore transfer other resources holdings.
>
> Request for feedback:
> In order to further this discussion and gain a consensus, I would like to
> once again ask the community to speak in favor or against this Draft Policy
> so that it may be presented and discussed at our next Public Policy
> Consultation at NANOG in June.
>
> 1. Yes or No.  Should the community relax existing policy which attempts
> to limit the transfer of ARIN resources out of region, in order to allow an
> organization flexibility to move address blocks to another portion of their
> own organization in another region, even though they might have received
> different addresses within ARIN in the last 12 months?
>
> (Note current policy would still restrict availability of new addresses to
> the organization for a period of 12 months after the transfer and is not
> being changed by this draft).
>
> 2.  If YES above, are there any other qualifications or limits that should
> be imposed on the resources transferred or the organization?
>
> (Note that a vote of NO to question #1 would essentially ask the Advisory
> Council to abandon this draft policy leaving existing policy in place.)
>
> Thanks to all who continue to work within the community to exercise their
> right and duty to craft appropriate policy guiding ARIN's important role in
> Internet number resource management.
>
> Bill Darte
> Policy Shepherd for 2014-2
> ARIN Advisory Council
>
> _______________________________________________
> 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/20140421/5220301b/attachment.htm>

From info at arin.net  Mon Apr 21 14:32:31 2014
From: info at arin.net (ARIN)
Date: Mon, 21 Apr 2014 14:32:31 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - April 2014
Message-ID: <5355643F.6040005@arin.net>

In accordance with the ARIN Policy Development Process the ARIN Advisory
Council (AC) held a meeting on 16 April 2014.

The AC moved the following Recommended Draft Policies to last call (to 
be posted separately to last call):

   Recommended Draft Policy ARIN-2014-4: Remove 4.2.5 Web Hosting Policy
   Recommended Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation 
Conservation
   Recommended Draft Policy ARIN-2014-10: Remove Sections 4.6 and 4.7

Having found the following Draft Policy to be fully developed and
meeting ARIN's Principles of Internet Number Resource Policy, the AC
recommended it for adoption (to be posted separately for discussion as a 
Recommended Draft Policy):

   Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations

The AC is continuing to work on the following:

   Recommended Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup
   Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple 
Discrete Networks
   Draft Policy ARIN-2014-1: Out of Region Use
   Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip Language
   Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and 8.4 Minimum IPv4 
Block Size Requirements
   Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs]
   Draft Policy ARIN-2014-8: Alignment of 8.3 Needs Requirements to 
Reality of Business
   Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 
Utilization Requirements
   Draft Policy ARIN-2014-11: Improved Registry Accuracy Proposal
   Draft Policy ARIN-2414-12: Anti-hijack Policy

Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)



From info at arin.net  Mon Apr 21 14:32:47 2014
From: info at arin.net (ARIN)
Date: Mon, 21 Apr 2014 14:32:47 -0400
Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-4: Remove
 4.2.5 Web Hosting Policy
Message-ID: <5355644F.1000903@arin.net>

The ARIN Advisory Council (AC) met on 16 April 2014 and decided to
send the following to last call:

   Recommended Draft Policy ARIN-2014-4: Remove 4.2.5 Web Hosting Policy

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. This last call will
expire on 5 May 2014. After last call the AC will conduct their
last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Recommended Draft Policy ARIN-2014-4
Remove 4.2.5 Web Hosting Policy

Date: 25 March 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

"Draft Policy ARIN-2014-4: Remove 4.2.5 Web Hosting Policy enables fair 
and impartial number resource administration by removing a 
no-longer-relevant section of the NRPM. The change in this draft policy 
has proven
uncontroversial thus far, consisting of one statement of support
and no opposition."

Problem Statement:

Section 4.2.5 is technology-specific language that is not current with 
modern network operation needs and practices. We should remove it to 
make NRPM clearer.

Policy statement:

Remove section 4.2.5.

Comments:
a.Timetable for implementation: Immediate
b.Anything else:

4.2.5. Web Hosting Policy

When an ISP submits a request for IP address space to be used for 
IP-based web hosting, it will supply (for informational purposes only) 
its technical justification for this practice. ARIN will analyze this 
data continuously, evaluating the need for future policy change.

##########

ARIN Staff and Legal Assessment

ARIN-prop-2014-4 ???? ????Remove 4.2.5 Web Hosting Policy????

Date of Assessment:

1. Summary (Staff Understanding)

This proposal would remove existing policy NRPM 4.2.5 as it is 
????technology specific language???? that is obsolete and not in sync 
with current network practices.

2. Comments

A. ARIN Staff Comments

???? If this policy were removed from NRPM, ARIN staff would still be 
able to require technical justification for web hosting based on the 
overall requirement to show efficient use as outlined in NRPM section 4.

???? This proposal could be implemented as written.

B. ARIN General Counsel - Legal Assessment

The policy does not create legal concerns.

3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect. It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:

???? Updated guidelines and internal procedures

???? Staff training

4. Proposal Text

Problem Statement:

Section 4.2.5 is technology-specific language that is not current with 
modern network operation needs and practices. We should remove it to 
make NRPM clearer.

Policy statement:

Remove section 4.2.5.

Comments: a.Timetable for implementation: Immediate b.Anything else:

4.2.5. Web Hosting Policy

When an ISP submits a request for IP address space to be used for 
IP-based web hosting, it will supply (for informational purposes only) 
its technical justification for this practice. ARIN will analyze this 
data continuously, evaluating the need for future policy change.



From info at arin.net  Mon Apr 21 14:33:00 2014
From: info at arin.net (ARIN)
Date: Mon, 21 Apr 2014 14:33:00 -0400
Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-7:
 Section 4.4 Micro Allocation Conservation Update
Message-ID: <5355645C.1080107@arin.net>

The ARIN Advisory Council (AC) met on 16 April 2014 and decided to
send the following to last call:

   Recommended Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation 
Conservation Update

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. This last call will
expire on 5 May 2014. After last call the AC will conduct their
last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Recommended Draft Policy ARIN-2014-7
Section 4.4 Micro Allocation Conservation Update

Date: 25 March 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

"Section 4.4 Micro Allocation Conservation Update enables fair and
impartial number resource administration by updating the requirements
for an IXP to obtain a micro allocation. The changes are a precise
change (2->3 IXP members) to existing policy. The policy is technically
sound and meets the overarching technical requirements of conservation,
aggregation, and registration. This policy has received a number of
statements in support of this proposal on the mailing list and in Nanog
Atlanta PPC."

Problem Statement:

Two networks interconnecting are generally considered to be private 
peers. The current policy allows an IXP to receive a micro-allocation 
with only two devices. Given IPv4 exhaustion and the growth of IXPs in 
North America it is prudent to raise the minimum criteria so that 
micro-allocation space is not wasted.

Policy statement:

Change the following sentence in Section 4.4 from:

Exchange point operators must provide justification for the allocation, 
including: connection policy, location, other participants (minimum of 
two total), ASN, and contact information.

To:

Exchange point operators must provide justification for the allocation, 
including: connection policy, location, other participants (minimum of 
three total), ASN, and contact information.

Comments:
a.Timetable for implementation: Immediate
b.Anything else:

##########

ARIN Staff and Legal Assessment

ARIN-prop-2014-7 ?????? ??????Section 4.4 Micro Allocation 
Conservation Update??????

Date of Assessment: 04 Mar 2014

1. Summary (Staff Understanding)

This proposal would modify existing NRPM section 4.4 to require Exchange 
Point Operators to have a minimum of three participants. The rationale 
for this change is that with more IXPs being formed and IPv4 depletion 
imminent, there is a need to conserve the limited micro-allocation 
reserved space.

2. Comments

A. ARIN Staff Comments

This proposal would have no operational impact and could be implemented 
as written.

B. ARIN General Counsel - Legal Assessment

The policy does not create legal concerns.

3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect. It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:

???? Updated guidelines and internal procedures

???? Staff training

4. Proposal Text

Problem Statement:

Two networks interconnecting are generally considered to be private 
peers. The current policy allows an IXP to receive a micro-allocation 
with only two devices. Given IPv4 exhaustion and the growth of IXPs in 
North America it is prudent to raise the minimum criteria so that 
micro-allocation space is not wasted.

Policy statement:

Change the following paragraph in Section 4.4 from:
Exchange point operators must provide justification for the allocation, 
including: connection policy, location, other participants (minimum of 
two total), ASN, and contact information.

To:

Exchange point operators must provide justification for the allocation, 
including: connection policy, location, other participants (minimum of 
three total), ASN, and contact information.



From info at arin.net  Mon Apr 21 14:33:14 2014
From: info at arin.net (ARIN)
Date: Mon, 21 Apr 2014 14:33:14 -0400
Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-10:
 Remove Sections 4.6 and 4.7
Message-ID: <5355646A.8000405@arin.net>

The ARIN Advisory Council (AC) met on 16 April 2014 and decided to
send the following to last call:

   Recommended Draft Policy ARIN-2014-10: Remove Sections 4.6 and 4.7

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. This last call will
expire on 5 May 2014. After last call the AC will conduct their
last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Recommended Draft Policy ARIN-2014-10
Remove Sections 4.6 and 4.7

Date: 25 March 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

"Draft Policy ARIN-2014-10: Remove Sections 4.6 and 4.7 - This proposal
will permanently remove suspended NRPM policies 4.6 and 4.7, due to the
potential for abuse by large requests. The ARIN staff has noted that
these two policies have rarely been used by the community since their
implementation and have not been used at all in the past 6 years. 
Removing these Policies has received support from the community and is 
technically sound."

Problem Statement:

The ARIN Board of Trustees has suspended sections 4.6 and 4.7 of the 
Number Resource Policy Manual at their January 6, 2014 meeting. This was 
done in response to the potential for abuse of these sections as the 
IPv4 free pool approaches runout.

The last request to use section 4.6, amnesty and aggregation requests, 
was in 2004. The last request to use section 4.7, aggregation requests, 
was in 2008. These sections have not been used to request resources in 
more than five years.

There are a number of organizations who could use these sections as 
justification to request an allocation or assignment that could deplete 
the remaining ARIN IPv4 free pool. This could have unintended 
consequences with ARIN running out so unexpectedly, that outweigh the 
intended benefits the sections were meant to provide.

These sections could also be used to justify large transfers, that would 
put ARIN in an undesirable position trying to reclaim previous 
resources, when the IPv4 pool is depleted. This risk also outweighs the 
intended benefits the sections were meant to provide.

Efforts could be made to patch these sections, and provide additional 
measures to limit abuse. There does not appear to be a need, however, 
given how little the sections have been utilized. As we become aware of 
other implications it may be best to try and deal with them through a 
separate, independent proposal.

Policy statement:

Remove sections 4.6 and 4.7.

Comments:
a.Timetable for implementation: Immediate
b.Anything else:

4.6. Amnesty and Aggregation Requests

4.6.1 Intent of this policy

This policy is intended to allow the community and ARIN staff to work
together with holders of address resources in the best interests of the
community by facilitating the return of unused address space and the
aggregation of existing space in a manner which is in the best interests
of both parties.

All transactions under this policy must either create greater
aggregation (a reduction in the number of prefixes) or the return of
address space. Transactions should only be accepted under this policy if
they are in the interests of the community (e.g. they improve
aggregation or result in a net reclamation of space).

4.6.2 No penalty for returning or aggregating

ARIN shall seek to make the return of address space as convenient and
risk-free to the returning organization as possible. An organization
with several non-contiguous blocks seeking to aggregate and return space
at the same time should be accommodated if possible. If it is possible
to expand one block, for example, to facilitate the return of other
blocks, ARIN should do that.

4.6.3 Return should not force renumbering

An organization shall be allowed to return a partial block of any size
to ARIN. For any return larger than a /24, ARIN shall not require that
the non-returned portion of the block be renumbered unless the returning
organization wishes to do so.

4.6.4 Timeframe for return

Any organization which is returning addresses under this policy shall
negotiate with ARIN an appropriate timeframe in which to return the
addresses after any new resources are received under this policy. In the
case of a simple return, the timeframe shall be immediate. In the case
where renumbering into new addresses out of existing addresses to be
returned is required, the returning organization shall sign a contract
with ARIN which stipulates a final return date not less than 6 months
nor more than 18 months after the receipt of new addresses. If an
organization misses this return date, but, ARIN believes the
organization is working in good faith to complete the renumbering, ARIN
may grant a single extension of 6-12 months as staff deems appropriate
to the situation. Such an extension must be requested in writing (email
to hostmaster at arin.net) by the organization at least 15 days prior to
the original expiration date.

4.6.5 RSA Required if new addresses received

Any organization which receives any additional addresses under this
policy shall be required to sign an ARIN RSA which will apply to all new
addresses issued and to any retained blocks which are expanded under
this policy.

4.6.6 Annual contact required

Any organization which participates in this policy shall be required to
sign an agreement stipulating that ARIN will attempt contact at least
once per year via the contact mechanisms registered for the organization
in Whois. Should ARIN fail to make contact, after reasonable effort the
organization shall be flagged as "unreachable" in Whois. After six
months in "unreachable" status, the organization agrees that ARIN may
consider all resources held by the organization to be abandoned and
reclaim such resources. Should the organization make contact with ARIN
prior to the end of the aforementioned six month period and update their
contact information appropriately, ARIN shall remove the "unreachable"
status and the annual contact cycle shall continue as normal. If the
organization pays annual fees to ARIN, the payment of annual fees shall
be considered sufficient contact.

4.7. Aggregation Requests

If an organization, whether a member or non-member, ISP or end-user,
relinquishes a group of portable, non-aggregatable address blocks to
ARIN, they shall be allowed to receive a block in exchange, /24 or
larger, but no more than the largest block that could contain all of the
returned blocks. Exchanged space shall be returned within 12 months. If
the gain in the number of addresses is greater than 4096, the
aggregation request must be evaluated by the ARIN in accordance with the
current IPv4 allocation policy. If all of the previous address blocks
were maintained in the ARIN database without maintenance fees, the
replacement space shall be as well, but if any one of the returned
blocks had associated maintenance fees, then the replacement block shall
also be subject to maintenance fees.

##########

ARIN Staff and Legal Assessment

ARIN-prop-2014-10 ???? ????Remove Sections 4.6 and 4.7????

Date of Assessment: 04 Mar 2014

1. Summary (Staff Understanding)

This proposal seeks to permanently remove suspended NRPM policies 4.6 
and 4.7 based on the rationale that any number of large organizations 
could potentially abuse these policies and request enough IPv4 address 
space to completely deplete ARIN????s available pool of addresses in one 
request.

2. Comments

A. ARIN Staff Comments

???? These two policies have rarely been used by the community since 
their implementation and in fact, have not been used at all in the past 
6 years.
o The last request to use section 4.6, amnesty and aggregation requests, 
was in 2004.
o The last request to use section 4.7, aggregation requests, was in 2008.
???? Customers wishing to return resources to ARIN have always been able 
to, and can continue to do so, by simply submitting a request ticket to 
hostmaster at arin.net. Staff then does the requisite verification of the 
request for the return of space.
o The ARIN website has recently been updated to more clearly outline the 
procedure for returning address space to ARIN.
???? This proposal could be implemented as written and would have no 
operational impact.

B. ARIN General Counsel - Legal Assessment

The policy does not create legal concerns.

3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect. It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:

???? Updated guidelines

4. Proposal Text

Problem Statement:

The ARIN Board of Trustees has suspended sections 4.6 and 4.7 of the 
Number Resource Policy Manual at their January 6, 2014 meeting. This was 
done in response to the potential for abuse of these sections as the 
IPv4 free pool approaches runout.

The last request to use section 4.6, amnesty and aggregation requests, 
was in 2004. The last request to use section 4.7, aggregation requests, 
was in 2008. These sections have not been used to request resources in 
more than five years.

There are a number of organizations who could use these sections as 
justification to request an allocation or assignment that could deplete 
the remaining ARIN IPv4 free pool. This could have unintended 
consequences with ARIN running out so unexpectedly, that outweigh the 
intended benefits the sections were meant to provide.

These sections could also be used to justify large transfers, that would 
put ARIN in an undesirable position trying to reclaim previous 
resources, when the IPv4 pool is depleted. This risk also outweighs the 
intended benefits the sections were meant to provide.

Efforts could be made to patch these sections, and provide additional 
measures to limit abuse. There does not appear to be a need, however, 
given how little the sections have been utilized. As we become aware of 
other implications it may be best to try and deal with them through a 
separate, independent proposal.

Policy statement:

Remove sections 4.6 and 4.7.



From billdarte at gmail.com  Mon Apr 21 14:40:02 2014
From: billdarte at gmail.com (Bill Darte)
Date: Mon, 21 Apr 2014 13:40:02 -0500
Subject: [arin-ppml] Draft Policy ARIN 2014-2 Improving Anti-Flip
	Language
In-Reply-To: <CAPhL6MrrRJPfD1NES1rP95xDKQV-uVNX9aU-Mxtw5=ZsHR1Vug@mail.gmail.com>
References: <CAMApp35gdhAY2=vjSqvxKBUNh0aCwDAbCo0T-un-64uL75gMWQ@mail.gmail.com>
	<CAPhL6MrrRJPfD1NES1rP95xDKQV-uVNX9aU-Mxtw5=ZsHR1Vug@mail.gmail.com>
Message-ID: <CAMApp35O7Y97SOoUhbJsK-xTF13Jjsjv16=kf=R_HkuueTWfpA@mail.gmail.com>

Niki,

Thank you for your feedback.  But, I am unsure how you are relating the
existence of a continuing supply of addresses in ARIN's free pool to the
problem statement....which is...."Current policy prevents an organization
that receives BLOCK A in the previous 12 months from transferring to their
own organization in another RIR a different block, BLOCK B, though it may
have been issued years ago."

Perhaps you could clarify your position.....thanks again.

bd





On Sun, Apr 20, 2014 at 8:46 PM, xiaofan yang <nikiyangxf at gmail.com> wrote:

> Hi Bill,
>
> Thanks for your update and summary.
>
> My answer is to tick option 1 with answer of NO. As ARIN still has the
> free pool, there is no need to further discuss this proposal.  I would like
> to suggest to abandon this draft.
>
> Regards,
>
> Niki
>
>
>
>
>
>
> On Sat, Apr 19, 2014 at 8:03 PM, Bill Darte <billdarte at gmail.com> wrote:
>
>> The Draft Policy ARIN 2014-2 Improving Anti-Flip Language was discussed
>> at the ARIN 33 Public Policy Meeting in Chicago last week and while there
>> was no consensus for the Draft using current language, the community
>> encouraged the AC to continue work on it as there was sympathy for the
>> problem statement. https://www.arin.net/policy/proposals/2014_2.html
>>
>> Draft Policy Issue:
>> Simply, the author wishes the Anti-Flip language currently used in the
>> NRPM to be relaxed, allowing an Inter-RIR transfer within their own
>> organization of previously existing addresses....though they may have
>> received a new allocation or assignment within the last 12 months.
>>
>> Current draft language states that the organization may do such a
>> transfer, but may not use the actual addresses which were received from
>> ARIN (or through transfer) in the previous 12 months.  But they could
>> therefore transfer other resources holdings.
>>
>> Request for feedback:
>> In order to further this discussion and gain a consensus, I would like to
>> once again ask the community to speak in favor or against this Draft Policy
>> so that it may be presented and discussed at our next Public Policy
>> Consultation at NANOG in June.
>>
>> 1. Yes or No.  Should the community relax existing policy which attempts
>> to limit the transfer of ARIN resources out of region, in order to allow an
>> organization flexibility to move address blocks to another portion of their
>> own organization in another region, even though they might have received
>> different addresses within ARIN in the last 12 months?
>>
>> (Note current policy would still restrict availability of new addresses
>> to the organization for a period of 12 months after the transfer and is not
>> being changed by this draft).
>>
>> 2.  If YES above, are there any other qualifications or limits that
>> should be imposed on the resources transferred or the organization?
>>
>> (Note that a vote of NO to question #1 would essentially ask the Advisory
>> Council to abandon this draft policy leaving existing policy in place.)
>>
>> Thanks to all who continue to work within the community to exercise their
>> right and duty to craft appropriate policy guiding ARIN's important role in
>> Internet number resource management.
>>
>> Bill Darte
>> Policy Shepherd for 2014-2
>> ARIN Advisory Council
>>
>> _______________________________________________
>> 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/20140421/7f40a700/attachment.htm>

From info at arin.net  Mon Apr 21 14:43:26 2014
From: info at arin.net (ARIN)
Date: Mon, 21 Apr 2014 14:43:26 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame
	Delegations
Message-ID: <535566CE.6010906@arin.net>

Recommended Draft Policy ARIN-2014-5
Remove 7.2 Lame Delegations

On 16 April 2014 the ARIN Advisory Council (AC) recommended
ARIN-2014-5 for adoption, making it a Recommended Draft Policy.

ARIN-2014-5 is below and can be found at:
https://www.arin.net/policy/proposals/2014_5.html

You are encouraged to discuss Draft Policy 2014-5 on the PPML prior to
the upcoming ARIN Public Policy Consultation at NANOG 61. Both the 
discussion on the list and at the meeting will be used by the ARIN 
Advisory Council to determine the community consensus for adopting this 
as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Recommended Draft Policy ARIN-2014-5
Remove 7.2 Lame Delegations

21 April 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

"ARIN-2014-5: Remove 7.2 Lame Delegations enables fair and impartial 
number resource administration by removing a no-longer-relevant section 
of the NRPM. All of the changes in this draft policy have proven 
uncontroversial thus far, with substantially more hands for the policy 
than against."

Problem Statement:

Section 7.2, asking ARIN to resolve Lame Delegations in in-addr.arpa, 
was established almost 10 years ago. While there may be real lameness 
problems in the in-addr.arpa tree, this should no longer be part of ARIN 
policy for two reasons:

1) NRPM should primarily be used to determine when requestors do, and do 
not, qualify for number resources because that's what ARIN's purpose is 
relevant to. ARIN is not an operational technical body, and its policy 
should only regulate activities ARIN is designed to participate in.

1a) We don't put text about how to operate Whois or RWhois or IRR in 
NRPM, so we should not put in text about how to operate DNS.

2) ARIN has never effectively implemented this. If there's still a need, 
it should be addressed directly with ARIN management and staff for 
prioritization.

Policy statement:

Remove section 7.2

Comments:
a.Timetable for implementation: Immediate
b.Anything else:

7.2. Lame Delegations in IN-ADDR.ARPA

ARIN will actively identify lame DNS name server(s) for reverse address 
delegations associated with address blocks allocated, assigned or 
administered by ARIN. Upon identification of a lame delegation, ARIN 
shall attempt to contact the POC for that resource and resolve the 
issue. If, following due diligence, ARIN is unable to resolve the lame 
delegation, ARIN will update the Whois database records resulting in the 
removal of lame servers.

##########

ARIN Staff and Legal Assessment

ARIN-prop-2014-5 ? ?Remove 7.2 Lame Delegations?

Date of Assessment: 04 Mar 2014

1. Summary (Staff Understanding)

This proposal would remove NRPM section 7.2 because it is out of scope 
for ARIN and because ARIN has never effectively implemented this policy.

2. Comments

A. ARIN Staff Comments

? This proposal would not change current operational practice. When ARIN 
switched over to per-zone DNS management, we ran into some significant 
issues with lame detection and remediation and as a result, lame 
delegation testing was suspended.
o Issues included the lack of a clear definition of what a lame DNS 
server was, and the potential risk of removing misconfigured, but 
working reverse DNS servers.

? This proposal could be implemented as written.

B. ARIN General Counsel - Legal Assessment

The policy does not create legal concerns.

3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect. It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:

? Updated guidelines

4. Proposal Text

Problem Statement:

Section 7.2, asking ARIN to resolve Lame Delegations in in-addr.arpa, 
was established almost 10 years ago. While there may be real lameness 
problems in the in-addr.arpa tree, this should no longer be part of ARIN 
policy for two reasons:

1) NRPM should primarily be used to determine when requestors do, and do 
not, qualify for number resources because that's what ARIN's purpose is 
relevant to. ARIN is not an operational technical body, and its policy 
should only regulate activities ARIN is designed to participate in.

1a) We don't put text about how to operate Whois or RWhois or IRR in 
NRPM, so we should not put in text about how to operate DNS.

2) ARIN has never effectively implemented this. If there's still a need, 
it should be addressed directly with ARIN management and staff for 
prioritization.

Policy statement:

Remove section 7.2

Comments: a.Timetable for implementation: Immediate b.Anything else:


From narten at us.ibm.com  Fri Apr 25 00:53:03 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 25 Apr 2014 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201404250453.s3P4r3SR015059@rotala.raleigh.ibm.com>

Total of 20 messages in the last 7 days.
 
script run at: Fri Apr 25 00:53:03 EDT 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 25.00% |    5 | 22.55% |    46560 | info at arin.net
 10.00% |    2 | 12.68% |    26167 | billdarte at gmail.com
 10.00% |    2 | 12.52% |    25839 | jschiller at google.com
  5.00% |    1 | 12.11% |    24996 | farmer at umn.edu
 10.00% |    2 |  5.79% |    11957 | bill at herrin.us
  5.00% |    1 |  7.28% |    15036 | lsawyer at gci.com
  5.00% |    1 |  6.42% |    13260 | nikiyangxf at gmail.com
  5.00% |    1 |  3.96% |     8167 | hannigan at gmail.com
  5.00% |    1 |  3.63% |     7502 | dmiller at tiggee.com
  5.00% |    1 |  3.54% |     7298 | mpetach at netflight.com
  5.00% |    1 |  3.29% |     6796 | owen at delong.com
  5.00% |    1 |  3.21% |     6635 | narten at us.ibm.com
  5.00% |    1 |  3.01% |     6222 | jlewis at lewis.org
--------+------+--------+----------+------------------------
100.00% |   20 |100.00% |   206435 | Total



From derekc at cnets.net  Mon Apr 28 19:33:04 2014
From: derekc at cnets.net (Derek Calanchini)
Date: Mon, 28 Apr 2014 16:33:04 -0700
Subject: [arin-ppml] Ip allocation
Message-ID: <535EE530.6040108@cnets.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/277272f3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cnslogo1.bmp
Type: image/bmp
Size: 72774 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/277272f3/attachment.bmp>

From michael at linuxmagic.com  Mon Apr 28 19:45:20 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Mon, 28 Apr 2014 16:45:20 -0700
Subject: [arin-ppml] Ip allocation
In-Reply-To: <535EE530.6040108@cnets.net>
References: <535EE530.6040108@cnets.net>
Message-ID: <535EE810.1060303@linuxmagic.com>

Actually, this is timely, and you probably started at the right place, 
what would be needed though is for someone to write up a draft 
resolution to this affect, to change current policies.

I was just talking to several parties regarding the same issue, and 
while there might have been justification in the past, when routing 
issues were a greater concern than running out of IPv4 space, but given 
the current situation, maybe it is time to rethink this policy.

In the mean time, you are faced in getting two upstream providers to 
route to your prospective /22.  I know, it doesn't make too much sense 
that the small guy should bear the burden of extra costs etc.. for being 
honest about his projected requirements..

Any other support out there for policy changes in this area?

On 14-04-28 04:33 PM, Derek Calanchini wrote:
> Hello all, I will be brief as possible.  I need assistance with either
> requesting a policy change or an appeal/exception to current policy.
>
> I started business in 1995 with 4 Class C's assigned from Integra ( /22
> ).  I am a full service IT provider offering pretty much everything but
> connectivity.  Over the years I have developed my network such that I am
> using my IP's very efficiently.  Host headers on most web sites,
> internal IP's whenever possible, and of course certain thing must be
> static, single IP's on a host.
>
> I am moving in less then a year to a new office, and taking the
> opportunity to get on the ATT fiber backbone rather then 4 bonded T-1's
> from Integra (which is very expensive)  Integra tells me I can not take
> my IP's with me, and ATT tells me the largest block they will give me is
> a single class C.
>
> So I went out to Arin and setup my account and requested a /22 which was
> denied because the smallest block they will give a single homed ISP is a
> /20 (4096 ip's)
>
> I feel like I am being penalized for using my IP's efficiently!!  As I
> see it, I only have one option:  Rework my network so every site I host
> uses it's own dedicated IP so that I can justify needing a /20...in
> which case I feel I would be doing the internet community a disservice.
>
> Can anyone provided feedback on how to better resolve this?  How do I
> start getting the policy changed?  Is there a process I can go through
> to get an exemption?  Would excalation my request be of any use?
>
> With the IP 4 space dwindling, wouldn't it be a better policy to allow
> small business to get only what they need?
>
>
> --
>   Best regards,
>
>     Derek Calanchini
>     Owner
>     Creative Network Solutions
>     Phone: 916-852-2890
>     Fax: 916-852-2899
>
> "Adopt the metric system!"
>
> CNS LOGO
>
>
> ------------------------------------------------------------------------
> <http://www.avast.com/> 	
>
> This email is free from viruses and malware because avast! Antivirus
> <http://www.avast.com/> protection is active.
>
>
>
>
> _______________________________________________
> 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.
>



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From hannigan at gmail.com  Mon Apr 28 19:56:18 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 28 Apr 2014 19:56:18 -0400
Subject: [arin-ppml] Ip allocation
In-Reply-To: <535EE530.6040108@cnets.net>
References: <535EE530.6040108@cnets.net>
Message-ID: <05542791-ECBB-417F-AEA9-0A840DA1AD57@gmail.com>


Did you sign L/RSA? 1995 means legacy. Right? 

What was the logic to deny you?

Best, 

Martin 

> On Apr 28, 2014, at 19:33, Derek Calanchini <derekc at cnets.net> wrote:
> 
> Hello all, I will be brief as possible.  I need assistance with either requesting a policy change or an appeal/exception to current policy.
> 
> I started business in 1995 with 4 Class C's assigned from Integra ( /22 ).  I am a full service IT provider offering pretty much everything but connectivity.  Over the years I have developed my network such that I am using my IP's very efficiently.  Host headers on most web sites, internal IP's whenever possible, and of course certain thing must be static, single IP's on a host.
> 
> I am moving in less then a year to a new office, and taking the opportunity to get on the ATT fiber backbone rather then 4 bonded T-1's from Integra (which is very expensive)  Integra tells me I can not take my IP's with me, and ATT tells me the largest block they will give me is a single class C.
> 
> So I went out to Arin and setup my account and requested a /22 which was denied because the smallest block they will give a single homed ISP is a /20 (4096 ip's)
> 
> I feel like I am being penalized for using my IP's efficiently!!  As I see it, I only have one option:  Rework my network so every site I host uses it's own dedicated IP so that I can justify needing a /20...in which case I feel I would be doing the internet community a disservice. 
> 
> Can anyone provided feedback on how to better resolve this?  How do I start getting the policy changed?  Is there a process I can go through to get an exemption?  Would excalation my request be of any use?
> 
> With the IP 4 space dwindling, wouldn't it be a better policy to allow small business to get only what they need?
> 
> 
> -- 
>  Best regards,
> 
>    Derek Calanchini
>    Owner
>    Creative Network Solutions
>    Phone: 916-852-2890
>    Fax: 916-852-2899
> 
> "Adopt the metric system!"
> 
> <cnslogo1.bmp>
> 
> 
>  	
> This email is free from viruses and malware because avast! Antivirus protection is active.
> 
> 
> _______________________________________________
> 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/20140428/a1529b04/attachment.htm>

From David.Huberman at microsoft.com  Mon Apr 28 20:12:49 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Tue, 29 Apr 2014 00:12:49 +0000
Subject: [arin-ppml] Ip allocation
In-Reply-To: <535EE810.1060303@linuxmagic.com>
References: <535EE530.6040108@cnets.net>,<535EE810.1060303@linuxmagic.com>
Message-ID: <92ccb6f0f4b4473d951fe854dad751c1@DM2PR03MB398.namprd03.prod.outlook.com>

Full support.  Making a single ISP initial allocation criteria that opens a /22 (or more!) to all first timers would be about 10 years past due, but still helpful to the community ARIN serves.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

________________________________________
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of Michael Peddemors <michael at linuxmagic.com>
Sent: Monday, April 28, 2014 4:45:20 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Ip allocation

Actually, this is timely, and you probably started at the right place,
what would be needed though is for someone to write up a draft
resolution to this affect, to change current policies.

I was just talking to several parties regarding the same issue, and
while there might have been justification in the past, when routing
issues were a greater concern than running out of IPv4 space, but given
the current situation, maybe it is time to rethink this policy.

In the mean time, you are faced in getting two upstream providers to
route to your prospective /22.  I know, it doesn't make too much sense
that the small guy should bear the burden of extra costs etc.. for being
honest about his projected requirements..

Any other support out there for policy changes in this area?

On 14-04-28 04:33 PM, Derek Calanchini wrote:
> Hello all, I will be brief as possible.  I need assistance with either
> requesting a policy change or an appeal/exception to current policy.
>
> I started business in 1995 with 4 Class C's assigned from Integra ( /22
> ).  I am a full service IT provider offering pretty much everything but
> connectivity.  Over the years I have developed my network such that I am
> using my IP's very efficiently.  Host headers on most web sites,
> internal IP's whenever possible, and of course certain thing must be
> static, single IP's on a host.
>
> I am moving in less then a year to a new office, and taking the
> opportunity to get on the ATT fiber backbone rather then 4 bonded T-1's
> from Integra (which is very expensive)  Integra tells me I can not take
> my IP's with me, and ATT tells me the largest block they will give me is
> a single class C.
>
> So I went out to Arin and setup my account and requested a /22 which was
> denied because the smallest block they will give a single homed ISP is a
> /20 (4096 ip's)
>
> I feel like I am being penalized for using my IP's efficiently!!  As I
> see it, I only have one option:  Rework my network so every site I host
> uses it's own dedicated IP so that I can justify needing a /20...in
> which case I feel I would be doing the internet community a disservice.
>
> Can anyone provided feedback on how to better resolve this?  How do I
> start getting the policy changed?  Is there a process I can go through
> to get an exemption?  Would excalation my request be of any use?
>
> With the IP 4 space dwindling, wouldn't it be a better policy to allow
> small business to get only what they need?
>
>
> --
>   Best regards,
>
>     Derek Calanchini
>     Owner
>     Creative Network Solutions
>     Phone: 916-852-2890
>     Fax: 916-852-2899
>
> "Adopt the metric system!"
>
> CNS LOGO
>
>
> ------------------------------------------------------------------------
> <http://www.avast.com/>
>
> This email is free from viruses and malware because avast! Antivirus
> <http://www.avast.com/> protection is active.
>
>
>
>
> _______________________________________________
> 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.
>



--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
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.


From SRyerse at eclipse-networks.com  Mon Apr 28 20:16:32 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Tue, 29 Apr 2014 00:16:32 +0000
Subject: [arin-ppml] Ip allocation
In-Reply-To: <92ccb6f0f4b4473d951fe854dad751c1@DM2PR03MB398.namprd03.prod.outlook.com>
References: <535EE530.6040108@cnets.net>,<535EE810.1060303@linuxmagic.com>
	<92ccb6f0f4b4473d951fe854dad751c1@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201529A9983@ENI-MAIL.eclipse-networks.com>

I agree it is past time to do this as it is ARIN's reason to exist to allocate.  


Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
www.eclipse-networks.com
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?
             
-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman
Sent: Monday, April 28, 2014 8:13 PM
To: Michael Peddemors; arin-ppml at arin.net
Subject: Re: [arin-ppml] Ip allocation

Full support.  Making a single ISP initial allocation criteria that opens a /22 (or more!) to all first timers would be about 10 years past due, but still helpful to the community ARIN serves.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

________________________________________
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of Michael Peddemors <michael at linuxmagic.com>
Sent: Monday, April 28, 2014 4:45:20 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Ip allocation

Actually, this is timely, and you probably started at the right place, what would be needed though is for someone to write up a draft resolution to this affect, to change current policies.

I was just talking to several parties regarding the same issue, and while there might have been justification in the past, when routing issues were a greater concern than running out of IPv4 space, but given the current situation, maybe it is time to rethink this policy.

In the mean time, you are faced in getting two upstream providers to route to your prospective /22.  I know, it doesn't make too much sense that the small guy should bear the burden of extra costs etc.. for being honest about his projected requirements..

Any other support out there for policy changes in this area?

On 14-04-28 04:33 PM, Derek Calanchini wrote:
> Hello all, I will be brief as possible.  I need assistance with either 
> requesting a policy change or an appeal/exception to current policy.
>
> I started business in 1995 with 4 Class C's assigned from Integra ( 
> /22 ).  I am a full service IT provider offering pretty much 
> everything but connectivity.  Over the years I have developed my 
> network such that I am using my IP's very efficiently.  Host headers 
> on most web sites, internal IP's whenever possible, and of course 
> certain thing must be static, single IP's on a host.
>
> I am moving in less then a year to a new office, and taking the 
> opportunity to get on the ATT fiber backbone rather then 4 bonded 
> T-1's from Integra (which is very expensive)  Integra tells me I can 
> not take my IP's with me, and ATT tells me the largest block they will 
> give me is a single class C.
>
> So I went out to Arin and setup my account and requested a /22 which 
> was denied because the smallest block they will give a single homed 
> ISP is a
> /20 (4096 ip's)
>
> I feel like I am being penalized for using my IP's efficiently!!  As I 
> see it, I only have one option:  Rework my network so every site I 
> host uses it's own dedicated IP so that I can justify needing a 
> /20...in which case I feel I would be doing the internet community a disservice.
>
> Can anyone provided feedback on how to better resolve this?  How do I 
> start getting the policy changed?  Is there a process I can go through 
> to get an exemption?  Would excalation my request be of any use?
>
> With the IP 4 space dwindling, wouldn't it be a better policy to allow 
> small business to get only what they need?
>
>
> --
>   Best regards,
>
>     Derek Calanchini
>     Owner
>     Creative Network Solutions
>     Phone: 916-852-2890
>     Fax: 916-852-2899
>
> "Adopt the metric system!"
>
> CNS LOGO
>
>
> ----------------------------------------------------------------------
> --
> <http://www.avast.com/>
>
> This email is free from viruses and malware because avast! Antivirus 
> <http://www.avast.com/> protection is active.
>
>
>
>
> _______________________________________________
> 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.
>



--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.
_______________________________________________
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.

From hannigan at gmail.com  Mon Apr 28 20:20:47 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 28 Apr 2014 20:20:47 -0400
Subject: [arin-ppml] Ip allocation
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201529A9983@ENI-MAIL.eclipse-networks.com>
References: <535EE530.6040108@cnets.net> <535EE810.1060303@linuxmagic.com>
	<92ccb6f0f4b4473d951fe854dad751c1@DM2PR03MB398.namprd03.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201529A9983@ENI-MAIL.eclipse-networks.com>
Message-ID: <CAMDXq5Oa8bLg03t2B6TpPuNf089mUuQtESGdawLLQtCOvUP6DA@mail.gmail.com>

Should the board step in?

By the time this gets turned from beef to chicken in the "process" and
then brought forward it will have already caused more damage than ever
before.

Support.

Best,

-M<


On Monday, April 28, 2014, Steven Ryerse <SRyerse at eclipse-networks.com>
wrote:

> I agree it is past time to do this as it is ARIN's reason to exist to
> allocate.
>
>
> Steven Ryerse
> President
> 100 Ashford Center North, Suite 110, Atlanta, GA  30338
> www.eclipse-networks.com
> 770.656.1460 - Cell
> 770.399.9099- Office
>
> ? Eclipse Networks, Inc.
>                      Conquering Complex Networks?
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Huberman
> Sent: Monday, April 28, 2014 8:13 PM
> To: Michael Peddemors; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Ip allocation
>
> Full support.  Making a single ISP initial allocation criteria that opens
> a /22 (or more!) to all first timers would be about 10 years past due, but
> still helpful to the community ARIN serves.
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> ________________________________________
> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf
> of Michael Peddemors <michael at linuxmagic.com>
> Sent: Monday, April 28, 2014 4:45:20 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Ip allocation
>
> Actually, this is timely, and you probably started at the right place,
> what would be needed though is for someone to write up a draft resolution
> to this affect, to change current policies.
>
> I was just talking to several parties regarding the same issue, and while
> there might have been justification in the past, when routing issues were a
> greater concern than running out of IPv4 space, but given the current
> situation, maybe it is time to rethink this policy.
>
> In the mean time, you are faced in getting two upstream providers to route
> to your prospective /22.  I know, it doesn't make too much sense that the
> small guy should bear the burden of extra costs etc.. for being honest
> about his projected requirements..
>
> Any other support out there for policy changes in this area?
>
> On 14-04-28 04:33 PM, Derek Calanchini wrote:
> > Hello all, I will be brief as possible.  I need assistance with either
> > requesting a policy change or an appeal/exception to current policy.
> >
> > I started business in 1995 with 4 Class C's assigned from Integra (
> > /22 ).  I am a full service IT provider offering pretty much
> > everything but connectivity.  Over the years I have developed my
> > network such that I am using my IP's very efficiently.  Host headers
> > on most web sites, internal IP's whenever possible, and of course
> > certain thing must be static, single IP's on a host.
> >
> > I am moving in less then a year to a new office, and taking the
> > opportunity to get on the ATT fiber backbone rather then 4 bonded
> > T-1's from Integra (which is very expensive)  Integra tells me I can
> > not take my IP's with me, and ATT tells me the largest block they will
> > give me is a single class C.
> >
> > So I went out to Arin and setup my account and requested a /22 which
> > was denied because the smallest block they will give a single homed
> > ISP is a
> > /20 (4096 ip's)
> >
> > I feel like I am being penalized for using my IP's efficiently!!  As I
> > see it, I only have one option:  Rework my network so every site I
> > host uses it's own dedicated IP so that I can justify needing a
> > /20...in which case I feel I would be doing the internet community a
> disservice.
> >
> > Can anyone provided feedback on how to better resolve this?  How do I
> > start getting the policy changed?  Is there a process I can go through
> > to get an exemption?  Would excalation my request be of any use?
> >
> > With the IP 4 space dwindling, wouldn't it be a better policy to allow
> > small business to get only what they need?
> >
> >
> > --
> >   Best regards,
> >
> >     Derek Calanchini
> >     Owner
> >     Creative Network Solutions
> >     Phone: 916-852-2890
> >     Fax: 916-852-2899
> >
> > "Adopt the metric system!"
> >
> > CNS LOGO
> >
> >
> > ----------------------------------------------------------------------
> > --
> > <http://www.avast.com/>
> >
> > This email is free from viruses and malware because avast! Antivirus
> > <ht <http://www.avast.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/89b17c45/attachment.htm>

From drc at virtualized.org  Mon Apr 28 20:25:50 2014
From: drc at virtualized.org (David Conrad)
Date: Mon, 28 Apr 2014 17:25:50 -0700
Subject: [arin-ppml] Ip allocation
In-Reply-To: <05542791-ECBB-417F-AEA9-0A840DA1AD57@gmail.com>
References: <535EE530.6040108@cnets.net>
	<05542791-ECBB-417F-AEA9-0A840DA1AD57@gmail.com>
Message-ID: <EBE64FF2-52C5-4142-88D1-2235075E693B@virtualized.org>

Martin,

On Apr 28, 2014, at 4:56 PM, Martin Hannigan <hannigan at gmail.com> wrote:
> Did you sign L/RSA? 1995 means legacy. Right? 

I don't think that matters since, by my reading, the address space was Integra's.

> What was the logic to deny you?

Integra's logic? I'm guessing because they actually listened to the CIDR/ALE working groups and the RIRs.

ARIN's logic? Because that's what the current policy (section 4.3.2.1 specifically) says. And since their upstream has said "nope!", it sounds like Derek is sort of screwed.

It looks like the possible answers are:

a) lie
b) pay more money for a second connection and get address space via 4.3.2.2
c) pay more money for address space from the market
d) try to get the policy revised (magically before ARIN's IPv4 pool runs out, assuming consensus can be reached)

Am I missing any options?

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/5a795fd2/attachment.sig>

From andrew.dul at quark.net  Mon Apr 28 20:37:10 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Mon, 28 Apr 2014 17:37:10 -0700
Subject: [arin-ppml] Ip allocation
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201529A9983@ENI-MAIL.eclipse-networks.com>
References: <535EE530.6040108@cnets.net>,
	<535EE810.1060303@linuxmagic.com>	<92ccb6f0f4b4473d951fe854dad751c1@DM2PR03MB398.namprd03.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201529A9983@ENI-MAIL.eclipse-networks.com>
Message-ID: <535EF436.3020005@quark.net>

A proposal has been submitted into the PDP process based upon feedback
and breakout discussions that occurred at the last meeting.  I believe
this proposal may help with the issue which started this thread.

https://www.arin.net/policy/proposals/ARIN_prop_207_orig.html

There is also another group of folks working on a proposal to update
section 4.2.2 based upon feedback received at the meeting and the policy
experience report
(https://www.arin.net/participate/meetings/reports/ARIN_33/PDF/monday/nobile_policy.pdf)
presented at the meeting.  I suspect we will also have another proposal
submitted to the policy development process shortly.

Andrew


On 4/28/2014 5:16 PM, Steven Ryerse wrote:
> I agree it is past time to do this as it is ARIN's reason to exist to allocate.  
>
>
> Steven Ryerse
> President
> 100 Ashford Center North, Suite 110, Atlanta, GA  30338
> www.eclipse-networks.com
> 770.656.1460 - Cell
> 770.399.9099- Office
>
> ? Eclipse Networks, Inc.
>                      Conquering Complex Networks?
>              
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman
> Sent: Monday, April 28, 2014 8:13 PM
> To: Michael Peddemors; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Ip allocation
>
> Full support.  Making a single ISP initial allocation criteria that opens a /22 (or more!) to all first timers would be about 10 years past due, but still helpful to the community ARIN serves.
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> ________________________________________
> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of Michael Peddemors <michael at linuxmagic.com>
> Sent: Monday, April 28, 2014 4:45:20 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Ip allocation
>
> Actually, this is timely, and you probably started at the right place, what would be needed though is for someone to write up a draft resolution to this affect, to change current policies.
>
> I was just talking to several parties regarding the same issue, and while there might have been justification in the past, when routing issues were a greater concern than running out of IPv4 space, but given the current situation, maybe it is time to rethink this policy.
>
> In the mean time, you are faced in getting two upstream providers to route to your prospective /22.  I know, it doesn't make too much sense that the small guy should bear the burden of extra costs etc.. for being honest about his projected requirements..
>
> Any other support out there for policy changes in this area?
>
> On 14-04-28 04:33 PM, Derek Calanchini wrote:
>> Hello all, I will be brief as possible.  I need assistance with either 
>> requesting a policy change or an appeal/exception to current policy.
>>
>> I started business in 1995 with 4 Class C's assigned from Integra ( 
>> /22 ).  I am a full service IT provider offering pretty much 
>> everything but connectivity.  Over the years I have developed my 
>> network such that I am using my IP's very efficiently.  Host headers 
>> on most web sites, internal IP's whenever possible, and of course 
>> certain thing must be static, single IP's on a host.
>>
>> I am moving in less then a year to a new office, and taking the 
>> opportunity to get on the ATT fiber backbone rather then 4 bonded 
>> T-1's from Integra (which is very expensive)  Integra tells me I can 
>> not take my IP's with me, and ATT tells me the largest block they will 
>> give me is a single class C.
>>
>> So I went out to Arin and setup my account and requested a /22 which 
>> was denied because the smallest block they will give a single homed 
>> ISP is a
>> /20 (4096 ip's)
>>
>> I feel like I am being penalized for using my IP's efficiently!!  As I 
>> see it, I only have one option:  Rework my network so every site I 
>> host uses it's own dedicated IP so that I can justify needing a 
>> /20...in which case I feel I would be doing the internet community a disservice.
>>
>> Can anyone provided feedback on how to better resolve this?  How do I 
>> start getting the policy changed?  Is there a process I can go through 
>> to get an exemption?  Would excalation my request be of any use?
>>
>> With the IP 4 space dwindling, wouldn't it be a better policy to allow 
>> small business to get only what they need?
>>
>>
>> --
>>   Best regards,
>>
>>     Derek Calanchini
>>     Owner
>>     Creative Network Solutions
>>     Phone: 916-852-2890
>>     Fax: 916-852-2899
>>
>> "Adopt the metric system!"
>>
>> CNS LOGO
>>
>>
>> ----------------------------------------------------------------------
>> --
>> <http://www.avast.com/>
>>
>> This email is free from viruses and malware because avast! Antivirus 
>> <http://www.avast.com/> protection is active.
>>
>>
>>
>>
>> _______________________________________________
>> 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.
>>
>
>
> --
> "Catch the Magic of Linux..."
> ------------------------------------------------------------------------
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> ------------------------------------------------------------------------
> A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> ------------------------------------------------------------------------
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.
> _______________________________________________
> 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.



From jcurran at arin.net  Mon Apr 28 20:38:14 2014
From: jcurran at arin.net (John Curran)
Date: Tue, 29 Apr 2014 00:38:14 +0000
Subject: [arin-ppml] Ip allocation
In-Reply-To: <CAMDXq5Oa8bLg03t2B6TpPuNf089mUuQtESGdawLLQtCOvUP6DA@mail.gmail.com>
References: <535EE530.6040108@cnets.net> <535EE810.1060303@linuxmagic.com>
	<92ccb6f0f4b4473d951fe854dad751c1@DM2PR03MB398.namprd03.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201529A9983@ENI-MAIL.eclipse-networks.com>
	<CAMDXq5Oa8bLg03t2B6TpPuNf089mUuQtESGdawLLQtCOvUP6DA@mail.gmail.com>
Message-ID: <9794C9C4-E8ED-4C60-8FDA-B187F9A2087B@arin.net>

On Apr 28, 2014, at 8:20 PM, Martin Hannigan <hannigan at gmail.com<mailto:hannigan at gmail.com>> wrote:

Should the board step in?

By the time this gets turned from beef to chicken in the "process" and then brought forward it will have already caused more damage than ever before.

Support.

Best,

-M<

On Monday, April 28, 2014, Steven Ryerse <SRyerse at eclipse-networks.com<mailto:SRyerse at eclipse-networks.com>> wrote:
I agree it is past time to do this as it is ARIN's reason to exist to allocate.

Given the clear problem statement, it shouldn't be hard to make a policy proposal that
very quickly results in clear policy text for the change.   Combine that with evidence of
solid community support and dwindling IPv4 free pool, and it would be feasible to ask
for Board intervention, if needed.  Note that even under our standard timelines, this
could be adopted immediately after the ARIN Public Policy Consultation at NANOG 61
if recommended beforehand and well supported at that meeting.

FYI,
/John

John Curran
President and CEO
ARIN

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

From sandrabrown at ipv4marketgroup.com  Mon Apr 28 22:57:43 2014
From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com)
Date: Mon, 28 Apr 2014 19:57:43 -0700
Subject: [arin-ppml] Ip allocation
Message-ID: <20140428195743.ec289651d84890fcbef5f195936e1217.3b8ed7d2ac.wbe@email17.secureserver.net>

Hello Andrew and Derek,

I attended ARIN33 and met with Andrew Dul and three other members of the
AC to discuss the need for IPv4 numbers for new entrants following ARIN
runout.  As a result of this issue, we have collaborated to create a
draft policy 

https://www.arin.net/policy/proposals/ARIN_prop_207_orig.html

to solve the problem as indicated by Andrew Dul.  This policy will solve
three problems that I can see:

1) sets up a pool of IP's, size /10, for new entrants, once ARIN runs
out.  My interpretation is that, now that
ARIN is down to a /8, this leaves 4 /10's.  ARIN will chew through 3
/10's and when it hits the 4th, this /10 will
be used for new entrants and companies like Derek's to get additional
IP's;

2) it sets the obtainable block size at a minimum of a /28, with a
maximum of a /22, for an entity;

3) it is a one time allocation;  once a company makes a claim for
resources under this policy, it cannot make a second claim.

I commend Andrew Dul for his speed, accuracy, and effectiveness in
getting this draft out.  Great job!  Although the policy is not perfect
in terms of content, (I would normally be opposed to the needs
language), it is an emergency situation, and an excellent compromise
that meets most requirements of progressive internet thinkers.

I support this policy and encourage immediate adoption.

Best Regards,
Sandra Brown
IPv4 Market Group

___________________________________________________________________________


A proposal has been submitted into the PDP process based upon feedback
and breakout discussions that occurred at the last meeting. I believe
this proposal may help with the issue which started this thread.

https://www.arin.net/policy/proposals/ARIN_prop_207_orig.html

There is also another group of folks working on a proposal to update
section 4.2.2 based upon feedback received at the meeting and the policy
experience report
(https://www.arin.net/participate/meetings/reports/ARIN_33/PDF/monday/nobile_policy.pdf)
presented at the meeting. I suspect we will also have another proposal
submitted to the policy development process shortly.

Andrew


On 4/28/2014 5:16 PM, Steven Ryerse wrote:
> I agree it is past time to do this as it is ARIN's reason to exist to allocate. 
>
>
> Steven Ryerse
> President
> 100 Ashford Center North, Suite 110, Atlanta, GA 30338
> www.eclipse-networks.com
> 770.656.1460 - Cell
> 770.399.9099- Office
>
> ? Eclipse Networks, Inc.
> Conquering Complex Networks?
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman
> Sent: Monday, April 28, 2014 8:13 PM
> To: Michael Peddemors; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Ip allocation
>
> Full support. Making a single ISP initial allocation criteria that opens a /22 (or more!) to all first timers would be about 10 years past due, but still helpful to the community ARIN serves.
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> ________________________________________
> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of Michael Peddemors <michael at linuxmagic.com>
> Sent: Monday, April 28, 2014 4:45:20 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Ip allocation
>
> Actually, this is timely, and you probably started at the right place, what would be needed though is for someone to write up a draft resolution to this affect, to change current policies.
>
> I was just talking to several parties regarding the same issue, and while there might have been justification in the past, when routing issues were a greater concern than running out of IPv4 space, but given the current situation, maybe it is time to rethink this policy.
>
> In the mean time, you are faced in getting two upstream providers to route to your prospective /22. I know, it doesn't make too much sense that the small guy should bear the burden of extra costs etc.. for being honest about his projected requirements..
>
> Any other support out there for policy changes in this area?
>
> On 14-04-28 04:33 PM, Derek Calanchini wrote:
>> Hello all, I will be brief as possible. I need assistance with either 
>> requesting a policy change or an appeal/exception to current policy.
>>
>> I started business in 1995 with 4 Class C's assigned from Integra ( 
>> /22 ). I am a full service IT provider offering pretty much 
>> everything but connectivity. Over the years I have developed my 
>> network such that I am using my IP's very efficiently. Host headers 
>> on most web sites, internal IP's whenever possible, and of course 
>> certain thing must be static, single IP's on a host.
>>
>> I am moving in less then a year to a new office, and taking the 
>> opportunity to get on the ATT fiber backbone rather then 4 bonded 
>> T-1's from Integra (which is very expensive) Integra tells me I can 
>> not take my IP's with me, and ATT tells me the largest block they will 
>> give me is a single class C.
>>
>> So I went out to Arin and setup my account and requested a /22 which 
>> was denied because the smallest block they will give a single homed 
>> ISP is a
>> /20 (4096 ip's)
>>
>> I feel like I am being penalized for using my IP's efficiently!! As I 
>> see it, I only have one option: Rework my network so every site I 
>> host uses it's own dedicated IP so that I can justify needing a 
>> /20...in which case I feel I would be doing the internet community a disservice.
>>
>> Can anyone provided feedback on how to better resolve this? How do I 
>> start getting the policy changed? Is there a process I can go through 
>> to get an exemption? Would excalation my request be of any use?
>>
>> With the IP 4 space dwindling, wouldn't it be a better policy to allow 
>> small business to get only what they need?
>>
>>
>> --
>> Best regards,
>>
>> Derek Calanchini
>> Owner
>> Creative Network Solutions
______________________________________________________________________________


From george.herbert at gmail.com  Mon Apr 28 23:09:59 2014
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 28 Apr 2014 20:09:59 -0700
Subject: [arin-ppml] Ip allocation
In-Reply-To: <535EF436.3020005@quark.net>
References: <535EE530.6040108@cnets.net> <535EE810.1060303@linuxmagic.com>
	<92ccb6f0f4b4473d951fe854dad751c1@DM2PR03MB398.namprd03.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201529A9983@ENI-MAIL.eclipse-networks.com>
	<535EF436.3020005@quark.net>
Message-ID: <CAK__KztsWcPqB74RVepRjW48V3nzP9gO0Z_i61yaYbv2nUAttg@mail.gmail.com>

I support prop 207, but would like some further discussion.  Hopefully
rapidly; Derek sounds like his org deserves the space under the conditions.

-george william herbert
george.herbert at gmail.com


On Mon, Apr 28, 2014 at 5:37 PM, Andrew Dul <andrew.dul at quark.net> wrote:

> A proposal has been submitted into the PDP process based upon feedback
> and breakout discussions that occurred at the last meeting.  I believe
> this proposal may help with the issue which started this thread.
>
> https://www.arin.net/policy/proposals/ARIN_prop_207_orig.html
>
> There is also another group of folks working on a proposal to update
> section 4.2.2 based upon feedback received at the meeting and the policy
> experience report
> (
> https://www.arin.net/participate/meetings/reports/ARIN_33/PDF/monday/nobile_policy.pdf
> )
> presented at the meeting.  I suspect we will also have another proposal
> submitted to the policy development process shortly.
>
> Andrew
>
>
> On 4/28/2014 5:16 PM, Steven Ryerse wrote:
> > I agree it is past time to do this as it is ARIN's reason to exist to
> allocate.
> >
> >
> > Steven Ryerse
> > President
> > 100 Ashford Center North, Suite 110, Atlanta, GA  30338
> > www.eclipse-networks.com
> > 770.656.1460 - Cell
> > 770.399.9099- Office
> >
> > ? Eclipse Networks, Inc.
> >                      Conquering Complex Networks?
> >
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Huberman
> > Sent: Monday, April 28, 2014 8:13 PM
> > To: Michael Peddemors; arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Ip allocation
> >
> > Full support.  Making a single ISP initial allocation criteria that
> opens a /22 (or more!) to all first timers would be about 10 years past
> due, but still helpful to the community ARIN serves.
> >
> > David R Huberman
> > Microsoft Corporation
> > Senior IT/OPS Program Manager (GFS)
> >
> > ________________________________________
> > From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf
> of Michael Peddemors <michael at linuxmagic.com>
> > Sent: Monday, April 28, 2014 4:45:20 PM
> > To: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Ip allocation
> >
> > Actually, this is timely, and you probably started at the right place,
> what would be needed though is for someone to write up a draft resolution
> to this affect, to change current policies.
> >
> > I was just talking to several parties regarding the same issue, and
> while there might have been justification in the past, when routing issues
> were a greater concern than running out of IPv4 space, but given the
> current situation, maybe it is time to rethink this policy.
> >
> > In the mean time, you are faced in getting two upstream providers to
> route to your prospective /22.  I know, it doesn't make too much sense that
> the small guy should bear the burden of extra costs etc.. for being honest
> about his projected requirements..
> >
> > Any other support out there for policy changes in this area?
> >
> > On 14-04-28 04:33 PM, Derek Calanchini wrote:
> >> Hello all, I will be brief as possible.  I need assistance with either
> >> requesting a policy change or an appeal/exception to current policy.
> >>
> >> I started business in 1995 with 4 Class C's assigned from Integra (
> >> /22 ).  I am a full service IT provider offering pretty much
> >> everything but connectivity.  Over the years I have developed my
> >> network such that I am using my IP's very efficiently.  Host headers
> >> on most web sites, internal IP's whenever possible, and of course
> >> certain thing must be static, single IP's on a host.
> >>
> >> I am moving in less then a year to a new office, and taking the
> >> opportunity to get on the ATT fiber backbone rather then 4 bonded
> >> T-1's from Integra (which is very expensive)  Integra tells me I can
> >> not take my IP's with me, and ATT tells me the largest block they will
> >> give me is a single class C.
> >>
> >> So I went out to Arin and setup my account and requested a /22 which
> >> was denied because the smallest block they will give a single homed
> >> ISP is a
> >> /20 (4096 ip's)
> >>
> >> I feel like I am being penalized for using my IP's efficiently!!  As I
> >> see it, I only have one option:  Rework my network so every site I
> >> host uses it's own dedicated IP so that I can justify needing a
> >> /20...in which case I feel I would be doing the internet community a
> disservice.
> >>
> >> Can anyone provided feedback on how to better resolve this?  How do I
> >> start getting the policy changed?  Is there a process I can go through
> >> to get an exemption?  Would excalation my request be of any use?
> >>
> >> With the IP 4 space dwindling, wouldn't it be a better policy to allow
> >> small business to get only what they need?
> >>
> >>
> >> --
> >>   Best regards,
> >>
> >>     Derek Calanchini
> >>     Owner
> >>     Creative Network Solutions
> >>     Phone: 916-852-2890
> >>     Fax: 916-852-2899
> >>
> >> "Adopt the metric system!"
> >>
> >> CNS LOGO
> >>
> >>
> >> ----------------------------------------------------------------------
> >> --
> >> <http://www.avast.com/>
> >>
> >> This email is free from viruses and malware because avast! Antivirus
> >> <http://www.avast.com/> protection is active.
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> 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.
> >>
> >
> >
> > --
> > "Catch the Magic of Linux..."
> > ------------------------------------------------------------------------
> > Michael Peddemors, President/CEO LinuxMagic Inc.
> > Visit us at http://www.linuxmagic.com @linuxmagic
> > ------------------------------------------------------------------------
> > A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a
> Registered TradeMark of Wizard Tower TechnoServices Ltd.
> > ------------------------------------------------------------------------
> > 604-682-0300 Beautiful British Columbia, Canada
> >
> > This email and any electronic data contained are confidential and
> intended solely for the use of the individual or entity to which they are
> addressed.
> > Please note that any views or opinions presented in this email are
> solely those of the author and are not intended to represent those of the
> company.
> > _______________________________________________
> > 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.
>
> _______________________________________________
> 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.
>



-- 
-george william herbert
george.herbert at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/7fc22409/attachment.htm>

From hannigan at gmail.com  Mon Apr 28 23:26:47 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 28 Apr 2014 23:26:47 -0400
Subject: [arin-ppml] Ip allocation
In-Reply-To: <20140428195743.ec289651d84890fcbef5f195936e1217.3b8ed7d2ac.wbe@email17.secureserver.net>
References: <20140428195743.ec289651d84890fcbef5f195936e1217.3b8ed7d2ac.wbe@email17.secureserver.net>
Message-ID: <CAMDXq5Pw7fZ+EyQvrQ24oOfPUcS+4iW2ey30w-68mPiX4n-_YQ@mail.gmail.com>

The original topic of this thread requires anequivalent  "one word" change.
 /20 to N in one place in the NRPM.

That has support. 207 will hopefully receive "vigorous" opposition.

Emergencies should demand simple non controversial changes. This isn't it.

Best,

-M<



On Monday, April 28, 2014, <sandrabrown at ipv4marketgroup.com> wrote:

> Hello Andrew and Derek,
>
> I attended ARIN33 and met with Andrew Dul and three other members of the
> AC to discuss the need for IPv4 numbers for new entrants following ARIN
> runout.  As a result of this issue, we have collaborated to create a
> draft policy
>
> https://www.arin.net/policy/proposals/ARIN_prop_207_orig.html
>
> to solve the problem as indicated by Andrew Dul.  This policy will solve
> three problems that I can see:
>
> 1) sets up a pool of IP's, size /10, for new entrants, once ARIN runs
> out.  My interpretation is that, now that
> ARIN is down to a /8, this leaves 4 /10's.  ARIN will chew through 3
> /10's and when it hits the 4th, this /10 will
> be used for new entrants and companies like Derek's to get additional
> IP's;
>
> 2) it sets the obtainable block size at a minimum of a /28, with a
> maximum of a /22, for an entity;
>
> 3) it is a one time allocation;  once a company makes a claim for
> resources under this policy, it cannot make a second claim.
>
> I commend Andrew Dul for his speed, accuracy, and effectiveness in
> getting this draft out.  Great job!  Although the policy is not perfect
> in terms of content, (I would normally be opposed to the needs
> language), it is an emergency situation, and an excellent compromise
> that meets most requirements of progressive internet thinkers.
>
> I support this policy and encourage immediate adoption.
>
> Best Regards,
> Sandra Brown
> IPv4 Market Group
>
> ___________________________________________________________________________
>
>
> A proposal has been submitted into the PDP process based upon feedback
> and breakout discussions that occurred at the last meeting. I believe
> this proposal may help with the issue which started this thread.
>
> https://www.arin.net/policy/proposals/ARIN_prop_207_orig.html
>
> There is also another group of folks working on a proposal to update
> section 4.2.2 based upon feedback received at the meeting and the policy
> experience report
> (
> https://www.arin.net/participate/meetings/reports/ARIN_33/PDF/monday/nobile_policy.pdf
> )
> presented at the meeting. I suspect we will also have another proposal
> submitted to the policy development process shortly.
>
> Andrew
>
>
> On 4/28/2014 5:16 PM, Steven Ryerse wrote:
> > I agree it is past time to do this as it is ARIN's reason to exist to
> allocate.
> >
> >
> > Steven Ryerse
> > President
> > 100 Ashford Center North, Suite 110, Atlanta, GA 30338
> > www.eclipse-networks.com
> > 770.656.1460 - Cell
> > 770.399.9099- Office
> >
> > ? Eclipse Networks, Inc.
> > Conquering Complex Networks?
> >
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net <javascript:;> [mailto:
> arin-ppml-bounces at arin.net <javascript:;>] On Behalf Of David Huberman
> > Sent: Monday, April 28, 2014 8:13 PM
> > To: Michael Peddemors; arin-ppml at arin.net <javascript:;>
> > Subject: Re: [arin-ppml] Ip allocation
> >
> > Full support. Making a single ISP initial allocation criteria that opens
> a /22 (or more!) to all first timers would be about 10 years past due, but
> still helpful to the community ARIN serves.
> >
> > David R Huberman
> > Microsoft Corporation
> > Senior IT/OPS Program Manager (GFS)
> >
> > ________________________________________
> > From: arin-ppml-bounces at arin.net <javascript:;> <
> arin-ppml-bounces at arin.net <javascript:;>> on behalf of Michael Peddemors
> <michael at linuxmagic.com <javascript:;>>
> > Sent: Monday, April 28, 2014 4:45:20 PM
> > To: arin-ppml at arin.net <javascript:;>
> > Subject: Re: [arin-ppml] Ip allocation
> >
> > Actually, this is timely, and you probably started at the right place,
> what would be needed though is for someone to write up a draft resolution
> to this affect, to change current policies.
> >
> > I was just talking to several parties regarding the same issue, and
> while there might have been justification in the past, when routing issues
> were a greater concern than running out of IPv4 space, but given the
> current situation, maybe it is time to rethink this policy.
> >
> > In the mean time, you are faced in getting two upstream providers to
> route to your prospective /22. I know, it doesn't make too much sense that
> the small guy should bear the burden of extra costs etc.. for being honest
> about his projected requirements..
> >
> > Any other support out there for policy changes in this area?
> >
> > On 14-04-28 04:33 PM, Derek Calanchini wrote:
> >> Hello all, I will be brief as possible. I need assistance with either
> >> requesting a policy change or an appeal/exception to current policy.
> >>
> >> I started business in 1995 with 4 Class C's assigned from Integra (
> >> /22 ). I am a full service IT provider offering pretty much
> >> everything but connectivity. Over the years I have developed my
> >> network such that I am using my IP's very efficiently. Host headers
> >> on most web sites, internal IP's whenever possible, and of course
> >> certain thing must be static, single IP's on a host.
> >>
> >> I am moving in less then a year to a new office, and taking the
> >> opportunity to get on the ATT fiber backbone rather then 4 bonded
> >> T-1's from Integra (which is very expensive) Integra tells me I can
> >> not take my IP's with me, and ATT tells me the largest block they will
> >> give me is a single class C.
> >>
> >> So I went out to Arin and setup my account and requested a /22 which
> >> was denied because the smallest block they will give a single homed
> >> ISP is a
> >> /20 (4096 ip's)
> >>
> >> I feel like I am being penalized for using my IP's efficiently!! As I
> >> see it, I only have one option: Rework my network so every site I
> >> host uses it's own dedicated IP so that I can justify needing a
> >> /20...in which case I feel I would be doing the internet community a
> disservice.
> >>
> >> Can anyone provided feedback on how to better resolve this? How do I
> >> start getting the policy changed? Is there a process I can go through
> >> to get an exemption? Would excalation my request be of any use?
> >>
> >> With the IP 4 space dwindling, wouldn't it be a better policy to allow
> >> small business to get only what they need?
> >>
> >>
> >> --
> >> Best regards,
> >>
> >> Derek Calanchini
> >> Owner
> >> Creative Network Solutions
>
> ______________________________________________________________________________
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/1c9e5693/attachment.htm>

From matthew at matthew.at  Mon Apr 28 23:26:57 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 28 Apr 2014 20:26:57 -0700
Subject: [arin-ppml] Ip allocation
In-Reply-To: <535EE530.6040108@cnets.net>
References: <535EE530.6040108@cnets.net>
Message-ID: <535F1C01.9030406@matthew.at>

Dual-home with a provider with no term commitment. No matter how painful 
that is, it'll be less painful than a policy change.

Matthew Kaufman

On 4/28/14, 4:33 PM, Derek Calanchini wrote:
> Hello all, I will be brief as possible.  I need assistance with either 
> requesting a policy change or an appeal/exception to current policy.
>
> I started business in 1995 with 4 Class C's assigned from Integra ( 
> /22 ).  I am a full service IT provider offering pretty much 
> everything but connectivity.  Over the years I have developed my 
> network such that I am using my IP's very efficiently.  Host headers 
> on most web sites, internal IP's whenever possible, and of course 
> certain thing must be static, single IP's on a host.
>
> I am moving in less then a year to a new office, and taking the 
> opportunity to get on the ATT fiber backbone rather then 4 bonded 
> T-1's from Integra (which is very expensive)  Integra tells me I can 
> not take my IP's with me, and ATT tells me the largest block they will 
> give me is a single class C.
>
> So I went out to Arin and setup my account and requested a /22 which 
> was denied because the smallest block they will give a single homed 
> ISP is a /20 (4096 ip's)
>
> I feel like I am being penalized for using my IP's efficiently!! As I 
> see it, I only have one option:  Rework my network so every site I 
> host uses it's own dedicated IP so that I can justify needing a 
> /20...in which case I feel I would be doing the internet community a 
> disservice.
>
> Can anyone provided feedback on how to better resolve this?  How do I 
> start getting the policy changed?  Is there a process I can go through 
> to get an exemption?  Would excalation my request be of any use?
>
> With the IP 4 space dwindling, wouldn't it be a better policy to allow 
> small business to get only what they need?
>
>
> -- 
>  Best regards,
>
>    Derek Calanchini
>    Owner
>    Creative Network Solutions
>    Phone: 916-852-2890
>    Fax: 916-852-2899
>
> "Adopt the metric system!"
>
> CNS LOGO
>
>
> ------------------------------------------------------------------------
> <http://www.avast.com/> 	
>
> This email is free from viruses and malware because avast! Antivirus 
> <http://www.avast.com/> protection is active.
>
>
>
>
> _______________________________________________
> 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/20140428/5787f599/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/bmp
Size: 72774 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/5787f599/attachment.bmp>

From george.herbert at gmail.com  Mon Apr 28 23:31:12 2014
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 28 Apr 2014 20:31:12 -0700
Subject: [arin-ppml] Ip allocation
In-Reply-To: <CAMDXq5Pw7fZ+EyQvrQ24oOfPUcS+4iW2ey30w-68mPiX4n-_YQ@mail.gmail.com>
References: <20140428195743.ec289651d84890fcbef5f195936e1217.3b8ed7d2ac.wbe@email17.secureserver.net>
	<CAMDXq5Pw7fZ+EyQvrQ24oOfPUcS+4iW2ey30w-68mPiX4n-_YQ@mail.gmail.com>
Message-ID: <CAK__KztTfJZpTdUTtaaVo981OvcZSiRbbdeRPC4xBus56bMjAw@mail.gmail.com>

Martin, can you file that as a (better, quicker) policy proposal then?


On Mon, Apr 28, 2014 at 8:26 PM, Martin Hannigan <hannigan at gmail.com> wrote:

>
>
> The original topic of this thread requires anequivalent  "one word"
> change.  /20 to N in one place in the NRPM.
>
> That has support. 207 will hopefully receive "vigorous" opposition.
>
> Emergencies should demand simple non controversial changes. This isn't it.
>
> Best,
>
> -M<
>
>
>
>
> On Monday, April 28, 2014, <sandrabrown at ipv4marketgroup.com> wrote:
>
>> Hello Andrew and Derek,
>>
>> I attended ARIN33 and met with Andrew Dul and three other members of the
>> AC to discuss the need for IPv4 numbers for new entrants following ARIN
>> runout.  As a result of this issue, we have collaborated to create a
>> draft policy
>>
>> https://www.arin.net/policy/proposals/ARIN_prop_207_orig.html
>>
>> to solve the problem as indicated by Andrew Dul.  This policy will solve
>> three problems that I can see:
>>
>> 1) sets up a pool of IP's, size /10, for new entrants, once ARIN runs
>> out.  My interpretation is that, now that
>> ARIN is down to a /8, this leaves 4 /10's.  ARIN will chew through 3
>> /10's and when it hits the 4th, this /10 will
>> be used for new entrants and companies like Derek's to get additional
>> IP's;
>>
>> 2) it sets the obtainable block size at a minimum of a /28, with a
>> maximum of a /22, for an entity;
>>
>> 3) it is a one time allocation;  once a company makes a claim for
>> resources under this policy, it cannot make a second claim.
>>
>> I commend Andrew Dul for his speed, accuracy, and effectiveness in
>> getting this draft out.  Great job!  Although the policy is not perfect
>> in terms of content, (I would normally be opposed to the needs
>> language), it is an emergency situation, and an excellent compromise
>> that meets most requirements of progressive internet thinkers.
>>
>> I support this policy and encourage immediate adoption.
>>
>> Best Regards,
>> Sandra Brown
>> IPv4 Market Group
>>
>>
>> ___________________________________________________________________________
>>
>>
>> A proposal has been submitted into the PDP process based upon feedback
>> and breakout discussions that occurred at the last meeting. I believe
>> this proposal may help with the issue which started this thread.
>>
>> https://www.arin.net/policy/proposals/ARIN_prop_207_orig.html
>>
>> There is also another group of folks working on a proposal to update
>> section 4.2.2 based upon feedback received at the meeting and the policy
>> experience report
>> (
>> https://www.arin.net/participate/meetings/reports/ARIN_33/PDF/monday/nobile_policy.pdf
>> )
>> presented at the meeting. I suspect we will also have another proposal
>> submitted to the policy development process shortly.
>>
>> Andrew
>>
>>
>> On 4/28/2014 5:16 PM, Steven Ryerse wrote:
>> > I agree it is past time to do this as it is ARIN's reason to exist to
>> allocate.
>> >
>> >
>> > Steven Ryerse
>> > President
>> > 100 Ashford Center North, Suite 110, Atlanta, GA 30338
>> > www.eclipse-networks.com
>> > 770.656.1460 - Cell
>> > 770.399.9099- Office
>> >
>> > ? Eclipse Networks, Inc.
>> > Conquering Complex Networks?
>> >
>> > -----Original Message-----
>> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
>> On Behalf Of David Huberman
>> > Sent: Monday, April 28, 2014 8:13 PM
>> > To: Michael Peddemors; arin-ppml at arin.net
>> > Subject: Re: [arin-ppml] Ip allocation
>> >
>> > Full support. Making a single ISP initial allocation criteria that
>> opens a /22 (or more!) to all first timers would be about 10 years past
>> due, but still helpful to the community ARIN serves.
>> >
>> > David R Huberman
>> > Microsoft Corporation
>> > Senior IT/OPS Program Manager (GFS)
>> >
>> > ________________________________________
>> > From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on
>> behalf of Michael Peddemors <michael at linuxmagic.com>
>> > Sent: Monday, April 28, 2014 4:45:20 PM
>> > To: arin-ppml at arin.net
>> > Subject: Re: [arin-ppml] Ip allocation
>> >
>> > Actually, this is timely, and you probably started at the right place,
>> what would be needed though is for someone to write up a draft resolution
>> to this affect, to change current policies.
>> >
>> > I was just talking to several parties regarding the same issue, and
>> while there might have been justification in the past, when routing issues
>> were a greater concern than running out of IPv4 space, but given the
>> current situation, maybe it is time to rethink this policy.
>> >
>> > In the mean time, you are faced in getting two upstream providers to
>> route to your prospective /22. I know, it doesn't make too much sense that
>> the small guy should bear the burden of extra costs etc.. for being honest
>> about his projected requirements..
>> >
>> > Any other support out there for policy changes in this area?
>> >
>> > On 14-04-28 04:33 PM, Derek Calanchini wrote:
>> >> Hello all, I will be brief as possible. I need assistance with either
>> >> requesting a policy change or an appeal/exception to current policy.
>> >>
>> >> I started business in 1995 with 4 Class C's assigned from Integra (
>> >> /22 ). I am a full service IT provider offering pretty much
>> >> everything but connectivity. Over the years I have developed my
>> >> network such that I am using my IP's very efficiently. Host headers
>> >> on most web sites, internal IP's whenever possible, and of course
>> >> certain thing must be static, single IP's on a host.
>> >>
>> >> I am moving in less then a year to a new office, and taking the
>> >> opportunity to get on the ATT fiber backbone rather then 4 bonded
>> >> T-1's from Integra (which is very expensive) Integra tells me I can
>> >> not take my IP's with me, and ATT tells me the largest block they will
>> >> give me is a single class C.
>> >>
>> >> So I went out to Arin and setup my account and requested a /22 which
>> >> was denied because the smallest block they will give a single homed
>> >> ISP is a
>> >> /20 (4096 ip's)
>> >>
>> >> I feel like I am being penalized for using my IP's efficiently!! As I
>> >> see it, I only have one option: Rework my network so every site I
>> >> host uses it's own dedicated IP so that I can justify needing a
>> >> /20...in which case I feel I would be doing the internet community a
>> disservice.
>> >>
>> >> Can anyone provided feedback on how to better resolve this? How do I
>> >> start getting the policy changed? Is there a process I can go through
>> >> to get an exemption? Would excalation my request be of any use?
>> >>
>> >> With the IP 4 space dwindling, wouldn't it be a better policy to allow
>> >> small business to get only what they need?
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >>
>> >> Derek Calanchini
>> >> Owner
>> >> Creative Network Solutions
>>
>> ______________________________________________________________________________
>> _______________________________________________
>> 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.
>



-- 
-george william herbert
george.herbert at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/487a71f7/attachment.htm>

From derekc at cnets.net  Mon Apr 28 23:50:19 2014
From: derekc at cnets.net (Derek Calanchini)
Date: Mon, 28 Apr 2014 20:50:19 -0700
Subject: [arin-ppml] Ip allocation
In-Reply-To: <CAMDXq5Pw7fZ+EyQvrQ24oOfPUcS+4iW2ey30w-68mPiX4n-_YQ@mail.gmail.com>
References: <20140428195743.ec289651d84890fcbef5f195936e1217.3b8ed7d2ac.wbe@email17.secureserver.net>
	<CAMDXq5Pw7fZ+EyQvrQ24oOfPUcS+4iW2ey30w-68mPiX4n-_YQ@mail.gmail.com>
Message-ID: <535F217B.6080402@cnets.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/f431ce09/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cnslogo1.bmp
Type: image/bmp
Size: 72774 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/f431ce09/attachment.bmp>

From derekc at cnets.net  Mon Apr 28 23:58:55 2014
From: derekc at cnets.net (Derek Calanchini)
Date: Mon, 28 Apr 2014 20:58:55 -0700
Subject: [arin-ppml] Ip allocation
In-Reply-To: <535F217B.6080402@cnets.net>
References: <20140428195743.ec289651d84890fcbef5f195936e1217.3b8ed7d2ac.wbe@email17.secureserver.net>	<CAMDXq5Pw7fZ+EyQvrQ24oOfPUcS+4iW2ey30w-68mPiX4n-_YQ@mail.gmail.com>
	<535F217B.6080402@cnets.net>
Message-ID: <535F237F.1030003@cnets.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/ce1436e4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cnslogo1.bmp
Type: image/bmp
Size: 72774 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/ce1436e4/attachment.bmp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/bmp
Size: 72774 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/ce1436e4/attachment-0001.bmp>

From drc at virtualized.org  Tue Apr 29 00:36:48 2014
From: drc at virtualized.org (David Conrad)
Date: Mon, 28 Apr 2014 21:36:48 -0700
Subject: [arin-ppml] Ip allocation
In-Reply-To: <535F237F.1030003@cnets.net>
References: <20140428195743.ec289651d84890fcbef5f195936e1217.3b8ed7d2ac.wbe@email17.secureserver.net>	<CAMDXq5Pw7fZ+EyQvrQ24oOfPUcS+4iW2ey30w-68mPiX4n-_YQ@mail.gmail.com>
	<535F217B.6080402@cnets.net> <535F237F.1030003@cnets.net>
Message-ID: <012A9098-2330-4F88-AFA5-9F37EA0BFB57@virtualized.org>

Derek,

On Apr 28, 2014, at 8:58 PM, Derek Calanchini <derekc at cnets.net> wrote:
> Here are some answers you may have missed:
> 1.
> Arin said the smallest I could request was a /20, I was requesting a /22.  My current /22 is currently owned by Integra...I procured them from Electric Lightwave before they got eaten by Integra.
> 
> So what does legacy mean? 

It means it was allocated prior to the requirement of entering into a Registration Services Agreement.

> Arin told me that Integra owned the IP's I am using.  Would it be possible to strong arm them into letting me reassign them to ATT?

Unlikely, but large amounts of money might help convince them. I suspect this approach isn't of interest however.

> 2.
> I did put in the request that I was going to surrender my current /22 after migration to the newly requested /22.

Not relevant. The applicable policy is quite clear: you need to "demonstrate need" for a /20, something that will be a bit challenging for you at this point.

> 3.
> This seems to cover it:
> 
> https://www.arin.net/participate/meetings/reports/ARIN_33/PDF/monday/nobile_policy.pdf
> (is this the draft to prop 207??)

No, that's a presentation that is providing information to the community regarding ARIN staff's experiences in implementing the policies the community has developed. One of the things Leslie (the head of registration services) was pointing out was that there were ... issues with existing policy.

I believe "prop 207" being referenced is https://www.arin.net/policy/proposals/ARIN_prop_207_orig.html.  I'm guessing Martin's concerns is that policy proposal is way more complicated than what you need.  What you appear to need is revising 4.3.2.1 of the NRPM to say /22 instead of /20.

> Is there anything I can do to speed this along?  Seriously, I will do authoring, leg work, make calls...whatever it takes!

To be honest, so far, you are seeing something approaching light speed in the RIR policy world.  IIUC, what some folks are suggesting is that the ARIN Board step in and modify policy to address this particular issue before the next ARIN meeting (in Bellevue, WA in early June).  This would be somewhat similar to tunneling through a wormhole...

Regards,
-drc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/01e8f1b4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/01e8f1b4/attachment.sig>

From springer at inlandnet.com  Tue Apr 29 01:35:31 2014
From: springer at inlandnet.com (John Springer)
Date: Mon, 28 Apr 2014 22:35:31 -0700 (PDT)
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers (fwd)
Message-ID: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>

Hi All,

The following timely policy proposal is presented for your consideration, 
discussion and comment. Will you please comment?

As always, expressions of support or opposition (and their reasons) are given 
slightly more weight than reasons why you might be in neither condition.

John Springer


ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers

Date: 16 April 2014
Problem Statement:
ARIN staff, faced with a surge in near-exhaust allocations and subsequent 
transfer requests and a requirement for team review of these, is spending 
scarce staff time on needs testing of small transfers. This proposal seeks to 
decrease overall ARIN processing time through elimination of that needs test.
Policy statement:
Change the language in NRPM 8.3 after Conditions on the recipient of the 
transfer: from "The recipient must demonstrate the need for up to a 24-month 
supply of IP address resources under current ARIN policies and sign an RSA." to 
"For transfers larger than a /16 equivalent, the recipient must demonstrate the 
need for up to a 24-month supply of IP address resources under current ARIN 
policies and sign an RSA."
Change the language in the third bullet point in NRPM 8.4 after Conditions on 
the recipient of the transfer: from "Recipients within the ARIN region must 
demonstrate the need for up to a 24-month supply of IPv4 address space." to 
"For transfers larger than a /16 equivalent, recipients in the ARIN region must 
demonstrate the need for up to a 24-month supply of IP address resources under 
current ARIN policies and sign an RSA."
Comments:
Needs testing has been maintained for transfers largely because the community 
wishes to ensure protection against hoarding and speculation in the IPv4 
market. This proposal seeks a middle ground between the elimination of needs 
tests for transfers altogether, and the continuance of needs tests for every 
transfer. This should help ARIN staff to reduce transfer processing time, since 
most transfers have been smaller than /16.
Timetable for implementation: Immediate



From matthew at matthew.at  Tue Apr 29 02:11:10 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 28 Apr 2014 23:11:10 -0700
Subject: [arin-ppml] Ip allocation
In-Reply-To: <535F237F.1030003@cnets.net>
References: <20140428195743.ec289651d84890fcbef5f195936e1217.3b8ed7d2ac.wbe@email17.secureserver.net>	<CAMDXq5Pw7fZ+EyQvrQ24oOfPUcS+4iW2ey30w-68mPiX4n-_YQ@mail.gmail.com>	<535F217B.6080402@cnets.net>
	<535F237F.1030003@cnets.net>
Message-ID: <535F427E.3080506@matthew.at>

On 4/28/2014 8:58 PM, Derek Calanchini wrote:
>
> *Is there anything I can do to speed this along? Seriously, I will do 
> authoring, leg work, make calls...whatever it takes!*
>

How about: submit a plan for multihoming and a request for a /22 based 
on your current usage?

Matthew Kaufman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140428/8aa41a2f/attachment.htm>

From jcurran at arin.net  Tue Apr 29 04:20:15 2014
From: jcurran at arin.net (John Curran)
Date: Tue, 29 Apr 2014 08:20:15 +0000
Subject: [arin-ppml] Ip allocation
In-Reply-To: <535F1C01.9030406@matthew.at>
References: <535EE530.6040108@cnets.net> <535F1C01.9030406@matthew.at>
Message-ID: <FACC14B5-4383-43CE-ABDA-B98DC01B04C2@arin.net>

On Apr 28, 2014, at 11:26 PM, Matthew Kaufman <matthew at matthew.at> wrote:

> Dual-home with a provider with no term commitment. No matter how painful that is, it'll be less painful than a policy change.

Matthew - 

   One point to keep in mind is that all of these policies will remain in effect
   (albeit indirectly) even after free pool depletion, to the extent that we still
   have need-basis for transfers in the region.  

   I am not advocating for or against a policy proposal, only noting that the
   present body of number resource policy in the region will continue to have
   lasting effects on number resource management for far longer than many
   folks may otherwise expect...

FYI,
/John

John Curran
President and CEO
ARIN



From dogwallah at gmail.com  Tue Apr 29 06:43:38 2014
From: dogwallah at gmail.com (McTim)
Date: Tue, 29 Apr 2014 05:43:38 -0500
Subject: [arin-ppml] Ip allocation
In-Reply-To: <535EE530.6040108@cnets.net>
References: <535EE530.6040108@cnets.net>
Message-ID: <CACAaNxh5TExALRJ741STQ0Hs+_VaiFqC+AhrX08hxX4Ln9_OSg@mail.gmail.com>

On Mon, Apr 28, 2014 at 6:33 PM, Derek Calanchini <derekc at cnets.net> wrote:

>  Hello all, I will be brief as possible.  I need assistance with either
> requesting a policy change or an appeal/exception to current policy.
>
>
> <snip>

>
> I feel like I am being penalized for using my IP's efficiently!!  As I see
> it, I only have one option:  Rework my network so every site I host uses
> it's own dedicated IP so that I can justify needing a /20...in which case I
> feel I would be doing the internet community a disservice.
>
> Can anyone provided feedback on how to better resolve this?
>


Apologies if I have missed the obvious, but have you thought about applying
for End-User space?  It seems like these resources are for your internal
network.

https://www.arin.net/resources/request/ipv4_initial_assign.html

-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A route
indicates how we get there."  Jon Postel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/a44cc867/attachment.htm>

From billdarte at gmail.com  Tue Apr 29 07:59:09 2014
From: billdarte at gmail.com (Bill Darte)
Date: Tue, 29 Apr 2014 06:59:09 -0500
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (fwd)
In-Reply-To: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>
References: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>
Message-ID: <CAMApp37pQ4eVevjZPFLaYbgD5JS8mDiGb7arw_H9i633=QB6SA@mail.gmail.com>

Hi John,

Couple of questions..... could the solution for staff effort be solved more
directly by modifying the protocol that establishes team testing for each
and every request through exhaustion?  I wonder about the need for these
extraordinary measures.

Is /16 small?  Did you consider a different boundary....say, /20?
How much of a record do we have for transfer requests yet?  Until
exhaustion we don't know what the run rate will be or the average size
block request.  Though I believe the that those metrics should mimic
pre-exhaustion as I see nothing magic affecting network build out and
business demands in the pre-post time frames.

So, I neither support, nor oppose this proposal but hope to inform the
discussion through my questions.

bd




On Tue, Apr 29, 2014 at 12:35 AM, John Springer <springer at inlandnet.com>wrote:

> Hi All,
>
> The following timely policy proposal is presented for your consideration,
> discussion and comment. Will you please comment?
>
> As always, expressions of support or opposition (and their reasons) are
> given slightly more weight than reasons why you might be in neither
> condition.
>
> John Springer
>
>
> ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers
>
> Date: 16 April 2014
> Problem Statement:
> ARIN staff, faced with a surge in near-exhaust allocations and subsequent
> transfer requests and a requirement for team review of these, is spending
> scarce staff time on needs testing of small transfers. This proposal seeks
> to decrease overall ARIN processing time through elimination of that needs
> test.
> Policy statement:
> Change the language in NRPM 8.3 after Conditions on the recipient of the
> transfer: from "The recipient must demonstrate the need for up to a
> 24-month supply of IP address resources under current ARIN policies and
> sign an RSA." to "For transfers larger than a /16 equivalent, the recipient
> must demonstrate the need for up to a 24-month supply of IP address
> resources under current ARIN policies and sign an RSA."
> Change the language in the third bullet point in NRPM 8.4 after Conditions
> on the recipient of the transfer: from "Recipients within the ARIN region
> must demonstrate the need for up to a 24-month supply of IPv4 address
> space." to "For transfers larger than a /16 equivalent, recipients in the
> ARIN region must demonstrate the need for up to a 24-month supply of IP
> address resources under current ARIN policies and sign an RSA."
> Comments:
> Needs testing has been maintained for transfers largely because the
> community wishes to ensure protection against hoarding and speculation in
> the IPv4 market. This proposal seeks a middle ground between the
> elimination of needs tests for transfers altogether, and the continuance of
> needs tests for every transfer. This should help ARIN staff to reduce
> transfer processing time, since most transfers have been smaller than /16.
> Timetable for implementation: Immediate
>
> _______________________________________________
> 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/20140429/4a3c018e/attachment.htm>

From mike at iptrading.com  Tue Apr 29 08:00:06 2014
From: mike at iptrading.com (Mike Burns)
Date: Tue, 29 Apr 2014 08:00:06 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
	IPv4Transfers (fwd)
References: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>
Message-ID: <6DE3536F94C344A3A62341BA948334F5@ncsscfoipoxes4>

Thank you, John.
I proposed this policy change and support it.
As has been pointed out, nothing changes upon exhaust that would affect the 
problems presented here.
If you are not multihomed, whether we have exhausted or not, you can not 
acquire these addresses through the transfer market.
For those "corner cases" this is the answer.
Although the problem statement reflects the increase in ARIN ticket response 
time discussed in Chicago, there are obviously other problems which this 
proposal seeks to ameliorate.

Regards,
Mike Burns

----- Original Message ----- 
From: "John Springer" <springer at inlandnet.com>
To: <arin-ppml at arin.net>
Sent: Tuesday, April 29, 2014 1:35 AM
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small 
IPv4Transfers (fwd)


> Hi All,
>
> The following timely policy proposal is presented for your consideration, 
> discussion and comment. Will you please comment?
>
> As always, expressions of support or opposition (and their reasons) are 
> given slightly more weight than reasons why you might be in neither 
> condition.
>
> John Springer
>
>
> ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers
>
> Date: 16 April 2014
> Problem Statement:
> ARIN staff, faced with a surge in near-exhaust allocations and subsequent 
> transfer requests and a requirement for team review of these, is spending 
> scarce staff time on needs testing of small transfers. This proposal seeks 
> to decrease overall ARIN processing time through elimination of that needs 
> test.
> Policy statement:
> Change the language in NRPM 8.3 after Conditions on the recipient of the 
> transfer: from "The recipient must demonstrate the need for up to a 
> 24-month supply of IP address resources under current ARIN policies and 
> sign an RSA." to "For transfers larger than a /16 equivalent, the 
> recipient must demonstrate the need for up to a 24-month supply of IP 
> address resources under current ARIN policies and sign an RSA."
> Change the language in the third bullet point in NRPM 8.4 after Conditions 
> on the recipient of the transfer: from "Recipients within the ARIN region 
> must demonstrate the need for up to a 24-month supply of IPv4 address 
> space." to "For transfers larger than a /16 equivalent, recipients in the 
> ARIN region must demonstrate the need for up to a 24-month supply of IP 
> address resources under current ARIN policies and sign an RSA."
> Comments:
> Needs testing has been maintained for transfers largely because the 
> community wishes to ensure protection against hoarding and speculation in 
> the IPv4 market. This proposal seeks a middle ground between the 
> elimination of needs tests for transfers altogether, and the continuance 
> of needs tests for every transfer. This should help ARIN staff to reduce 
> transfer processing time, since most transfers have been smaller than /16.
> Timetable for implementation: Immediate
>
> _______________________________________________
> 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.
> 



From mike at iptrading.com  Tue Apr 29 08:44:52 2014
From: mike at iptrading.com (Mike Burns)
Date: Tue, 29 Apr 2014 08:44:52 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers (fwd)
References: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>
	<CAMApp37pQ4eVevjZPFLaYbgD5JS8mDiGb7arw_H9i633=QB6SA@mail.gmail.com>
Message-ID: <6B154FF652B141E0AF82ECF4FD6E6874@ncsscfoipoxes4>

Hi Bill,

I will answer as the author.
I chose /16 as a starting point for discussion, at least, because my experience as a broker demonstrates a distinction in buyers and sellers around that size.
I suppose we could go by ARIN billing policy which has different definitions, but I think a /16 is a medium size.
Most transactions have been at or below this number.
There is a complete record of transfers available at APNIC and ARIN, including the sizes of all transferred blocks.
APNIC's list is a little cluttered with quasi-internal transfers to National Internet Registries, but is available here:
ftp://ftp.apnic.net/public/transfers/apnic/
ARIN here:
https://www.arin.net/knowledge/statistics/transfers.html

Regards,
Mike Burns

  ----- Original Message ----- 
  From: Bill Darte 
  To: John Springer 
  Cc: arin-ppml at arin.net 
  Sent: Tuesday, April 29, 2014 7:59 AM
  Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers (fwd)


  Hi John,


  Couple of questions..... could the solution for staff effort be solved more directly by modifying the protocol that establishes team testing for each and every request through exhaustion?  I wonder about the need for these extraordinary measures.


  Is /16 small?  Did you consider a different boundary....say, /20?
  How much of a record do we have for transfer requests yet?  Until exhaustion we don't know what the run rate will be or the average size block request.  Though I believe the that those metrics should mimic pre-exhaustion as I see nothing magic affecting network build out and business demands in the pre-post time frames.


  So, I neither support, nor oppose this proposal but hope to inform the discussion through my questions.


  bd







  On Tue, Apr 29, 2014 at 12:35 AM, John Springer <springer at inlandnet.com> wrote:

    Hi All,

    The following timely policy proposal is presented for your consideration, discussion and comment. Will you please comment?

    As always, expressions of support or opposition (and their reasons) are given slightly more weight than reasons why you might be in neither condition.

    John Springer


    ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers

    Date: 16 April 2014
    Problem Statement:
    ARIN staff, faced with a surge in near-exhaust allocations and subsequent transfer requests and a requirement for team review of these, is spending scarce staff time on needs testing of small transfers. This proposal seeks to decrease overall ARIN processing time through elimination of that needs test.
    Policy statement:
    Change the language in NRPM 8.3 after Conditions on the recipient of the transfer: from "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." to "For transfers larger than a /16 equivalent, the recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA."
    Change the language in the third bullet point in NRPM 8.4 after Conditions on the recipient of the transfer: from "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." to "For transfers larger than a /16 equivalent, recipients in the ARIN region must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA."
    Comments:
    Needs testing has been maintained for transfers largely because the community wishes to ensure protection against hoarding and speculation in the IPv4 market. This proposal seeks a middle ground between the elimination of needs tests for transfers altogether, and the continuance of needs tests for every transfer. This should help ARIN staff to reduce transfer processing time, since most transfers have been smaller than /16.
    Timetable for implementation: Immediate

    _______________________________________________
    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/20140429/c42ab887/attachment.htm>

From cb.list6 at gmail.com  Tue Apr 29 10:09:06 2014
From: cb.list6 at gmail.com (TheIpv6guy .)
Date: Tue, 29 Apr 2014 07:09:06 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (fwd)
In-Reply-To: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>
References: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>
Message-ID: <CAD6AjGTry7OWZ5emdL1AsUz5WFgTgEQdCuKvh_iEMD=_48G53g@mail.gmail.com>

Opp
On Apr 28, 2014 10:35 PM, "John Springer" <springer at inlandnet.com> wrote:
>
> Hi All,
>
> The following timely policy proposal is presented for your consideration,
discussion and comment. Will you please comment?
>
> As always, expressions of support or opposition (and their reasons) are
given slightly more weight than reasons why you might be in neither
condition.
>
> John Springer
>
>
> ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers
>
> Date: 16 April 2014
> Problem Statement:
> ARIN staff, faced with a surge in near-exhaust allocations and subsequent
transfer requests and a requirement for team review of these, is spending
scarce staff time on needs testing of small transfers. This proposal seeks
to decrease overall ARIN processing time through elimination of that needs
test.
> Policy statement:
> Change the language in NRPM 8.3 after Conditions on the recipient of the
transfer: from "The recipient must demonstrate the need for up to a
24-month supply of IP address resources under current ARIN policies and
sign an RSA." to "For transfers larger than a /16 equivalent, the recipient
must demonstrate the need for up to a 24-month supply of IP address
resources under current ARIN policies and sign an RSA."
> Change the language in the third bullet point in NRPM 8.4 after
Conditions on the recipient of the transfer: from "Recipients within the
ARIN region must demonstrate the need for up to a 24-month supply of IPv4
address space." to "For transfers larger than a /16 equivalent, recipients
in the ARIN region must demonstrate the need for up to a 24-month supply of
IP address resources under current ARIN policies and sign an RSA."
> Comments:
> Needs testing has been maintained for transfers largely because the
community wishes to ensure protection against hoarding and speculation in
the IPv4 market. This proposal seeks a middle ground between the
elimination of needs tests for transfers altogether, and the continuance of
needs tests for every transfer. This should help ARIN staff to reduce
transfer processing time, since most transfers have been smaller than /16.
> Timetable for implementation: Immediate
>

Opposed.

ARIN and the community should focus on deploying ipv6 not pulling the fire
alarm on ppml.

This is not an emergency. These policies and forces have been around for
years.  Clinging to ipv4 is costly.

> _______________________________________________
> 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/20140429/feb767c9/attachment.htm>

From michael at linuxmagic.com  Tue Apr 29 11:06:09 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Tue, 29 Apr 2014 08:06:09 -0700
Subject: [arin-ppml] Ip allocation
In-Reply-To: <CAK__KztsWcPqB74RVepRjW48V3nzP9gO0Z_i61yaYbv2nUAttg@mail.gmail.com>
References: <535EE530.6040108@cnets.net>
	<535EE810.1060303@linuxmagic.com>	<92ccb6f0f4b4473d951fe854dad751c1@DM2PR03MB398.namprd03.prod.outlook.com>	<5B9E90747FA2974D91A54FCFA1B8AD1201529A9983@ENI-MAIL.eclipse-networks.com>	<535EF436.3020005@quark.net>
	<CAK__KztsWcPqB74RVepRjW48V3nzP9gO0Z_i61yaYbv2nUAttg@mail.gmail.com>
Message-ID: <535FBFE1.5090006@linuxmagic.com>

Proposal 207 is novel, but it is meant strictly for those looking to 
'transition' to IPv6, so in this case he might not qualify..

I don't think that 207 is enough yet, and while on it's own I could 
normally support it except for one thing..  30 days is a little to short 
of time for smaller operators trying to work through getting the routing 
all done, and other internals to expect them to get 25% of the IP(s) set 
up in that short of a time frame.

I would support with a '90 day' time frame for them to configure 25% usage.

But again, I think that 207 could be expanded to also include a 
reduction in the size allotments for single homed in general from a /20 
to a /22, and by putting this all in 207, we stand to see it getting 
earlier approval I believe


On 14-04-28 08:09 PM, George Herbert wrote:
> I support prop 207, but would like some further discussion.  Hopefully
> rapidly; Derek sounds like his org deserves the space under the conditions.
>
> -george william herbert
> george.herbert at gmail.com <mailto:george.herbert at gmail.com>
>
>
> On Mon, Apr 28, 2014 at 5:37 PM, Andrew Dul <andrew.dul at quark.net
> <mailto:andrew.dul at quark.net>> wrote:
>
>     A proposal has been submitted into the PDP process based upon feedback
>     and breakout discussions that occurred at the last meeting.  I believe
>     this proposal may help with the issue which started this thread.
>
>     https://www.arin.net/policy/proposals/ARIN_prop_207_orig.html
>
>     There is also another group of folks working on a proposal to update
>     section 4.2.2 based upon feedback received at the meeting and the policy
>     experience report
>     (https://www.arin.net/participate/meetings/reports/ARIN_33/PDF/monday/nobile_policy.pdf)
>     presented at the meeting.  I suspect we will also have another proposal
>     submitted to the policy development process shortly.
>
>     Andrew
>
>
>     On 4/28/2014 5:16 PM, Steven Ryerse wrote:
>      > I agree it is past time to do this as it is ARIN's reason to
>     exist to allocate.
>      >
>      >
>      > Steven Ryerse
>      > President
>      > 100 Ashford Center North, Suite 110, Atlanta, GA  30338
>      > www.eclipse-networks.com <http://www.eclipse-networks.com>
>      > 770.656.1460 <tel:770.656.1460> - Cell
>      > 770.399.9099 <tel:770.399.9099>- Office
>      >
>      > ? Eclipse Networks, Inc.
>      >                      Conquering Complex Networks?
>      >
>      > -----Original Message-----
>      > From: arin-ppml-bounces at arin.net
>     <mailto:arin-ppml-bounces at arin.net>
>     [mailto:arin-ppml-bounces at arin.net
>     <mailto:arin-ppml-bounces at arin.net>] On Behalf Of David Huberman
>      > Sent: Monday, April 28, 2014 8:13 PM
>      > To: Michael Peddemors; arin-ppml at arin.net <mailto:arin-ppml at arin.net>
>      > Subject: Re: [arin-ppml] Ip allocation
>      >
>      > Full support.  Making a single ISP initial allocation criteria
>     that opens a /22 (or more!) to all first timers would be about 10
>     years past due, but still helpful to the community ARIN serves.
>      >
>      > David R Huberman
>      > Microsoft Corporation
>      > Senior IT/OPS Program Manager (GFS)
>      >
>      > ________________________________________
>      > From: arin-ppml-bounces at arin.net
>     <mailto:arin-ppml-bounces at arin.net> <arin-ppml-bounces at arin.net
>     <mailto:arin-ppml-bounces at arin.net>> on behalf of Michael Peddemors
>     <michael at linuxmagic.com <mailto:michael at linuxmagic.com>>
>      > Sent: Monday, April 28, 2014 4:45:20 PM
>      > To: arin-ppml at arin.net <mailto:arin-ppml at arin.net>
>      > Subject: Re: [arin-ppml] Ip allocation
>      >
>      > Actually, this is timely, and you probably started at the right
>     place, what would be needed though is for someone to write up a
>     draft resolution to this affect, to change current policies.
>      >
>      > I was just talking to several parties regarding the same issue,
>     and while there might have been justification in the past, when
>     routing issues were a greater concern than running out of IPv4
>     space, but given the current situation, maybe it is time to rethink
>     this policy.
>      >
>      > In the mean time, you are faced in getting two upstream providers
>     to route to your prospective /22.  I know, it doesn't make too much
>     sense that the small guy should bear the burden of extra costs etc..
>     for being honest about his projected requirements..
>      >
>      > Any other support out there for policy changes in this area?
>      >
>      > On 14-04-28 04:33 PM, Derek Calanchini wrote:
>      >> Hello all, I will be brief as possible.  I need assistance with
>     either
>      >> requesting a policy change or an appeal/exception to current policy.
>      >>
>      >> I started business in 1995 with 4 Class C's assigned from Integra (
>      >> /22 ).  I am a full service IT provider offering pretty much
>      >> everything but connectivity.  Over the years I have developed my
>      >> network such that I am using my IP's very efficiently.  Host headers
>      >> on most web sites, internal IP's whenever possible, and of course
>      >> certain thing must be static, single IP's on a host.
>      >>
>      >> I am moving in less then a year to a new office, and taking the
>      >> opportunity to get on the ATT fiber backbone rather then 4 bonded
>      >> T-1's from Integra (which is very expensive)  Integra tells me I can
>      >> not take my IP's with me, and ATT tells me the largest block
>     they will
>      >> give me is a single class C.
>      >>
>      >> So I went out to Arin and setup my account and requested a /22 which
>      >> was denied because the smallest block they will give a single homed
>      >> ISP is a
>      >> /20 (4096 ip's)
>      >>
>      >> I feel like I am being penalized for using my IP's efficiently!!
>       As I
>      >> see it, I only have one option:  Rework my network so every site I
>      >> host uses it's own dedicated IP so that I can justify needing a
>      >> /20...in which case I feel I would be doing the internet
>     community a disservice.
>      >>
>      >> Can anyone provided feedback on how to better resolve this?  How
>     do I
>      >> start getting the policy changed?  Is there a process I can go
>     through
>      >> to get an exemption?  Would excalation my request be of any use?
>      >>
>      >> With the IP 4 space dwindling, wouldn't it be a better policy to
>     allow
>      >> small business to get only what they need?
>      >>
>      >>
>      >> --
>      >>   Best regards,
>      >>
>      >>     Derek Calanchini
>      >>     Owner
>      >>     Creative Network Solutions
>      >>     Phone: 916-852-2890
>      >>     Fax: 916-852-2899
>      >>
>      >> "Adopt the metric system!"
>      >>
>      >> CNS LOGO
>      >>
>      >>
>      >>
>     ----------------------------------------------------------------------
>      >> --
>      >> <http://www.avast.com/>
>      >>
>      >> This email is free from viruses and malware because avast! Antivirus
>      >> <http://www.avast.com/> protection is active.
>      >>
>      >>
>      >>
>      >>
>      >> _______________________________________________
>      >> PPML
>      >> You are receiving this message because you are subscribed to the
>     ARIN
>      >> Public Policy Mailing List (ARIN-PPML at arin.net
>     <mailto: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 <mailto:info at arin.net> if you
>     experience any issues.
>      >>
>      >
>      >
>      > --
>      > "Catch the Magic of Linux..."
>      >
>     ------------------------------------------------------------------------
>      > Michael Peddemors, President/CEO LinuxMagic Inc.
>      > Visit us at http://www.linuxmagic.com @linuxmagic
>      >
>     ------------------------------------------------------------------------
>      > A Wizard IT Company - For More Info http://www.wizard.ca
>     "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
>      >
>     ------------------------------------------------------------------------
>      > 604-682-0300 <tel:604-682-0300> Beautiful British Columbia, Canada
>      >
>      > This email and any electronic data contained are confidential and
>     intended solely for the use of the individual or entity to which
>     they are addressed.
>      > Please note that any views or opinions presented in this email
>     are solely those of the author and are not intended to represent
>     those of the company.
>      > _______________________________________________
>      > PPML
>      > You are receiving this message because you are subscribed to the
>     ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>     <mailto: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 <mailto: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
>     <mailto: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 <mailto: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
>     <mailto: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 <mailto: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
>     <mailto: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 <mailto:info at arin.net> if you
>     experience any issues.
>
>
>
>
> --
> -george william herbert
> george.herbert at gmail.com <mailto:george.herbert at gmail.com>
>
>
> _______________________________________________
> 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.
>



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From hannigan at gmail.com  Tue Apr 29 11:31:28 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 29 Apr 2014 11:31:28 -0400
Subject: [arin-ppml] Last IPv4 Address Space
Message-ID: <CAMDXq5Ofexvrwm5-GT3s3RZhQ0vo8dxJNMq3FDaG+jvPTbj2OQ@mail.gmail.com>

How about an apolitical last /N policy?



Section N Last IPv4 Addresses Available in Region

Upon receipt of a /11 or up to an equivalent from the IANA, ARIN will
set that prefix, aggregate or longer equivalent aside until a /11 of
inventory is reached and for assignment of a /24 to all existing ARIN
members and all future ARIN members until exhausted.


I believe there is an /11 on deck for each RIR and from returned space
from what I understand. That would provide for 8192 /24.

Thoughts? Better to discuss before sending it in.


Best,


-M<


From derekc at cnets.net  Tue Apr 29 11:42:19 2014
From: derekc at cnets.net (Derek Calanchini)
Date: Tue, 29 Apr 2014 08:42:19 -0700
Subject: [arin-ppml] Ip allocation
In-Reply-To: <08B841C1-4247-4CB9-A4AB-BA2783A67430@cisco.com>
References: <535EE530.6040108@cnets.net>
	<08B841C1-4247-4CB9-A4AB-BA2783A67430@cisco.com>
Message-ID: <535FC85B.7050100@cnets.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/07dffb08/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cnslogo1.bmp
Type: image/bmp
Size: 72774 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/07dffb08/attachment.bmp>

From derekc at cnets.net  Tue Apr 29 11:44:52 2014
From: derekc at cnets.net (Derek Calanchini)
Date: Tue, 29 Apr 2014 08:44:52 -0700
Subject: [arin-ppml] Ip allocation
In-Reply-To: <CACAaNxh5TExALRJ741STQ0Hs+_VaiFqC+AhrX08hxX4Ln9_OSg@mail.gmail.com>
References: <535EE530.6040108@cnets.net>
	<CACAaNxh5TExALRJ741STQ0Hs+_VaiFqC+AhrX08hxX4Ln9_OSg@mail.gmail.com>
Message-ID: <535FC8F4.9030005@cnets.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/c5471e2a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cnslogo1.bmp
Type: image/bmp
Size: 72774 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/c5471e2a/attachment.bmp>

From hannigan at gmail.com  Tue Apr 29 12:04:27 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 29 Apr 2014 12:04:27 -0400
Subject: [arin-ppml] Ip allocation
In-Reply-To: <CAK__KztTfJZpTdUTtaaVo981OvcZSiRbbdeRPC4xBus56bMjAw@mail.gmail.com>
References: <20140428195743.ec289651d84890fcbef5f195936e1217.3b8ed7d2ac.wbe@email17.secureserver.net>
	<CAMDXq5Pw7fZ+EyQvrQ24oOfPUcS+4iW2ey30w-68mPiX4n-_YQ@mail.gmail.com>
	<CAK__KztTfJZpTdUTtaaVo981OvcZSiRbbdeRPC4xBus56bMjAw@mail.gmail.com>
Message-ID: <CAMDXq5OQ1wuvXDAGWguj79vyGGyNtrxo+ztg3BD0-0CLrxiRKw@mail.gmail.com>

Sure, but sending it in without prior discussion will result in
another bride of Frankenstein.

One way to do this in a simple and parse-able way could be to change
the minimum allocation unit in 4.2.1.5 from the reference to a /22 to
a /24.


Best,

-M<









On Mon, Apr 28, 2014 at 11:31 PM, George Herbert
<george.herbert at gmail.com> wrote:
> Martin, can you file that as a (better, quicker) policy proposal then?
>
>
> On Mon, Apr 28, 2014 at 8:26 PM, Martin Hannigan <hannigan at gmail.com> wrote:
>>
>>
>>
>> The original topic of this thread requires anequivalent  "one word"
>> change.  /20 to N in one place in the NRPM.
>>
>> That has support. 207 will hopefully receive "vigorous" opposition.
>>
>> Emergencies should demand simple non controversial changes. This isn't it.
>>
>> Best,
>>
>> -M<
>>
>>
>>
>>
>> On Monday, April 28, 2014, <sandrabrown at ipv4marketgroup.com> wrote:
>>>
>>> Hello Andrew and Derek,
>>>
>>> I attended ARIN33 and met with Andrew Dul and three other members of the
>>> AC to discuss the need for IPv4 numbers for new entrants following ARIN
>>> runout.  As a result of this issue, we have collaborated to create a
>>> draft policy
>>>
>>> https://www.arin.net/policy/proposals/ARIN_prop_207_orig.html
>>>
>>> to solve the problem as indicated by Andrew Dul.  This policy will solve
>>> three problems that I can see:
>>>
>>> 1) sets up a pool of IP's, size /10, for new entrants, once ARIN runs
>>> out.  My interpretation is that, now that
>>> ARIN is down to a /8, this leaves 4 /10's.  ARIN will chew through 3
>>> /10's and when it hits the 4th, this /10 will
>>> be used for new entrants and companies like Derek's to get additional
>>> IP's;
>>>
>>> 2) it sets the obtainable block size at a minimum of a /28, with a
>>> maximum of a /22, for an entity;
>>>
>>> 3) it is a one time allocation;  once a company makes a claim for
>>> resources under this policy, it cannot make a second claim.
>>>
>>> I commend Andrew Dul for his speed, accuracy, and effectiveness in
>>> getting this draft out.  Great job!  Although the policy is not perfect
>>> in terms of content, (I would normally be opposed to the needs
>>> language), it is an emergency situation, and an excellent compromise
>>> that meets most requirements of progressive internet thinkers.
>>>
>>> I support this policy and encourage immediate adoption.
>>>
>>> Best Regards,
>>> Sandra Brown
>>> IPv4 Market Group
>>>
>>>
>>> ___________________________________________________________________________
>>>
>>>
>>> A proposal has been submitted into the PDP process based upon feedback
>>> and breakout discussions that occurred at the last meeting. I believe
>>> this proposal may help with the issue which started this thread.
>>>
>>> https://www.arin.net/policy/proposals/ARIN_prop_207_orig.html
>>>
>>> There is also another group of folks working on a proposal to update
>>> section 4.2.2 based upon feedback received at the meeting and the policy
>>> experience report
>>>
>>> (https://www.arin.net/participate/meetings/reports/ARIN_33/PDF/monday/nobile_policy.pdf)
>>> presented at the meeting. I suspect we will also have another proposal
>>> submitted to the policy development process shortly.
>>>
>>> Andrew
>>>
>>>
>>> On 4/28/2014 5:16 PM, Steven Ryerse wrote:
>>> > I agree it is past time to do this as it is ARIN's reason to exist to
>>> > allocate.
>>> >
>>> >
>>> > Steven Ryerse
>>> > President
>>> > 100 Ashford Center North, Suite 110, Atlanta, GA 30338
>>> > www.eclipse-networks.com
>>> > 770.656.1460 - Cell
>>> > 770.399.9099- Office
>>> >
>>> > ? Eclipse Networks, Inc.
>>> > Conquering Complex Networks?
>>> >
>>> > -----Original Message-----
>>> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>>> > Behalf Of David Huberman
>>> > Sent: Monday, April 28, 2014 8:13 PM
>>> > To: Michael Peddemors; arin-ppml at arin.net
>>> > Subject: Re: [arin-ppml] Ip allocation
>>> >
>>> > Full support. Making a single ISP initial allocation criteria that
>>> > opens a /22 (or more!) to all first timers would be about 10 years past due,
>>> > but still helpful to the community ARIN serves.
>>> >
>>> > David R Huberman
>>> > Microsoft Corporation
>>> > Senior IT/OPS Program Manager (GFS)
>>> >
>>> > ________________________________________
>>> > From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf
>>> > of Michael Peddemors <michael at linuxmagic.com>
>>> > Sent: Monday, April 28, 2014 4:45:20 PM
>>> > To: arin-ppml at arin.net
>>> > Subject: Re: [arin-ppml] Ip allocation
>>> >
>>> > Actually, this is timely, and you probably started at the right place,
>>> > what would be needed though is for someone to write up a draft resolution to
>>> > this affect, to change current policies.
>>> >
>>> > I was just talking to several parties regarding the same issue, and
>>> > while there might have been justification in the past, when routing issues
>>> > were a greater concern than running out of IPv4 space, but given the current
>>> > situation, maybe it is time to rethink this policy.
>>> >
>>> > In the mean time, you are faced in getting two upstream providers to
>>> > route to your prospective /22. I know, it doesn't make too much sense that
>>> > the small guy should bear the burden of extra costs etc.. for being honest
>>> > about his projected requirements..
>>> >
>>> > Any other support out there for policy changes in this area?
>>> >
>>> > On 14-04-28 04:33 PM, Derek Calanchini wrote:
>>> >> Hello all, I will be brief as possible. I need assistance with either
>>> >> requesting a policy change or an appeal/exception to current policy.
>>> >>
>>> >> I started business in 1995 with 4 Class C's assigned from Integra (
>>> >> /22 ). I am a full service IT provider offering pretty much
>>> >> everything but connectivity. Over the years I have developed my
>>> >> network such that I am using my IP's very efficiently. Host headers
>>> >> on most web sites, internal IP's whenever possible, and of course
>>> >> certain thing must be static, single IP's on a host.
>>> >>
>>> >> I am moving in less then a year to a new office, and taking the
>>> >> opportunity to get on the ATT fiber backbone rather then 4 bonded
>>> >> T-1's from Integra (which is very expensive) Integra tells me I can
>>> >> not take my IP's with me, and ATT tells me the largest block they will
>>> >> give me is a single class C.
>>> >>
>>> >> So I went out to Arin and setup my account and requested a /22 which
>>> >> was denied because the smallest block they will give a single homed
>>> >> ISP is a
>>> >> /20 (4096 ip's)
>>> >>
>>> >> I feel like I am being penalized for using my IP's efficiently!! As I
>>> >> see it, I only have one option: Rework my network so every site I
>>> >> host uses it's own dedicated IP so that I can justify needing a
>>> >> /20...in which case I feel I would be doing the internet community a
>>> >> disservice.
>>> >>
>>> >> Can anyone provided feedback on how to better resolve this? How do I
>>> >> start getting the policy changed? Is there a process I can go through
>>> >> to get an exemption? Would excalation my request be of any use?
>>> >>
>>> >> With the IP 4 space dwindling, wouldn't it be a better policy to allow
>>> >> small business to get only what they need?
>>> >>
>>> >>
>>> >> --
>>> >> Best regards,
>>> >>
>>> >> Derek Calanchini
>>> >> Owner
>>> >> Creative Network Solutions
>>>
>>> ______________________________________________________________________________
>>> _______________________________________________
>>> 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.
>
>
>
>
> --
> -george william herbert
> george.herbert at gmail.com


From hannigan at gmail.com  Tue Apr 29 12:12:18 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 29 Apr 2014 12:12:18 -0400
Subject: [arin-ppml] Ip allocation
In-Reply-To: <CAMDXq5OQ1wuvXDAGWguj79vyGGyNtrxo+ztg3BD0-0CLrxiRKw@mail.gmail.com>
References: <20140428195743.ec289651d84890fcbef5f195936e1217.3b8ed7d2ac.wbe@email17.secureserver.net>
	<CAMDXq5Pw7fZ+EyQvrQ24oOfPUcS+4iW2ey30w-68mPiX4n-_YQ@mail.gmail.com>
	<CAK__KztTfJZpTdUTtaaVo981OvcZSiRbbdeRPC4xBus56bMjAw@mail.gmail.com>
	<CAMDXq5OQ1wuvXDAGWguj79vyGGyNtrxo+ztg3BD0-0CLrxiRKw@mail.gmail.com>
Message-ID: <CAMDXq5OyHPHwNtyXkb7_LAoy4jyoQw+--GNaV+4Dxwp4xei0+Q@mail.gmail.com>

I also missed one after thinking about it even more.  Change the /20
reference to a /24 as well.  guess that's two. Ooops. One could be
tempted to completely rewrite. I wouldn't try it.

Best,

-M<


From owen at delong.com  Tue Apr 29 13:15:04 2014
From: owen at delong.com (Owen DeLong)
Date: Tue, 29 Apr 2014 10:15:04 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers (fwd)
In-Reply-To: <CAD6AjGTry7OWZ5emdL1AsUz5WFgTgEQdCuKvh_iEMD=_48G53g@mail.gmail.com>
References: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>
	<CAD6AjGTry7OWZ5emdL1AsUz5WFgTgEQdCuKvh_iEMD=_48G53g@mail.gmail.com>
Message-ID: <12D1F823-8D97-4FB9-B5EA-B35791E0DACB@delong.com>

In general, I think removing needs basis is an utterly bad idea.

However, if we were to do a 1 year trial at /20, to gather data and evaluate the actual impacts of such a policy, I would consider that acceptable.

	+	Does it actually lead to increased whois accuracy as proclaimed by proponents?
	+	Is there a measurable difference in time required to process requests?
	+	How much time is saved per request on average?

Are there other things we would want to learn from such a trial?

Opening the floodgates to /16 seems fool hearty at best IMHO.

Owen

On Apr 29, 2014, at 7:09 AM, TheIpv6guy . <cb.list6 at gmail.com> wrote:

> Opp
> On Apr 28, 2014 10:35 PM, "John Springer" <springer at inlandnet.com> wrote:
> >
> > Hi All,
> >
> > The following timely policy proposal is presented for your consideration, discussion and comment. Will you please comment?
> >
> > As always, expressions of support or opposition (and their reasons) are given slightly more weight than reasons why you might be in neither condition.
> >
> > John Springer
> >
> >
> > ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers
> >
> > Date: 16 April 2014
> > Problem Statement:
> > ARIN staff, faced with a surge in near-exhaust allocations and subsequent transfer requests and a requirement for team review of these, is spending scarce staff time on needs testing of small transfers. This proposal seeks to decrease overall ARIN processing time through elimination of that needs test.
> > Policy statement:
> > Change the language in NRPM 8.3 after Conditions on the recipient of the transfer: from "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." to "For transfers larger than a /16 equivalent, the recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA."
> > Change the language in the third bullet point in NRPM 8.4 after Conditions on the recipient of the transfer: from "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." to "For transfers larger than a /16 equivalent, recipients in the ARIN region must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA."
> > Comments:
> > Needs testing has been maintained for transfers largely because the community wishes to ensure protection against hoarding and speculation in the IPv4 market. This proposal seeks a middle ground between the elimination of needs tests for transfers altogether, and the continuance of needs tests for every transfer. This should help ARIN staff to reduce transfer processing time, since most transfers have been smaller than /16.
> > Timetable for implementation: Immediate
> >
> 
> Opposed.
> 
> ARIN and the community should focus on deploying ipv6 not pulling the fire alarm on ppml. 
> 
> This is not an emergency. These policies and forces have been around for years.  Clinging to ipv4 is costly. 
> 
> 
> > _______________________________________________
> > 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/20140429/4cff5dc7/attachment.htm>

From David.Huberman at microsoft.com  Tue Apr 29 13:28:38 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Tue, 29 Apr 2014 17:28:38 +0000
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
	IPv4	Transfers (fwd)
In-Reply-To: <12D1F823-8D97-4FB9-B5EA-B35791E0DACB@delong.com>
References: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>
	<CAD6AjGTry7OWZ5emdL1AsUz5WFgTgEQdCuKvh_iEMD=_48G53g@mail.gmail.com>
	<12D1F823-8D97-4FB9-B5EA-B35791E0DACB@delong.com>
Message-ID: <12e2900c1bac473389a72356eb171084@DM2PR03MB398.namprd03.prod.outlook.com>

When I studied it for ARIN, 87% of the v4 address space ARIN issued over a 2 year period went to ELEVEN companies.

I'm not speaking directly to prop 204, but in general:  policy has favored big guys at the gross expense of small guys for 15 years.  It's injust.  And the math (at least in the mid-to-late 2000s when I studied it) doesn't support it.

The RIPE/APNIC model of 'everyone starts on an even playing field by getting a /x just by opening an account' is a much fairer way of doing business, in my opinion.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Tuesday, April 29, 2014 10:15 AM
To: TheIpv6guy .
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers (fwd)

In general, I think removing needs basis is an utterly bad idea.

However, if we were to do a 1 year trial at /20, to gather data and evaluate the actual impacts of such a policy, I would consider that acceptable.

            +          Does it actually lead to increased whois accuracy as proclaimed by proponents?
            +          Is there a measurable difference in time required to process requests?
            +          How much time is saved per request on average?

Are there other things we would want to learn from such a trial?

Opening the floodgates to /16 seems fool hearty at best IMHO.

Owen

On Apr 29, 2014, at 7:09 AM, TheIpv6guy . <cb.list6 at gmail.com<mailto:cb.list6 at gmail.com>> wrote:



Opp
On Apr 28, 2014 10:35 PM, "John Springer" <springer at inlandnet.com<mailto:springer at inlandnet.com>> wrote:
>
> Hi All,
>
> The following timely policy proposal is presented for your consideration, discussion and comment. Will you please comment?
>
> As always, expressions of support or opposition (and their reasons) are given slightly more weight than reasons why you might be in neither condition.
>
> John Springer
>
>
> ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers
>
> Date: 16 April 2014
> Problem Statement:
> ARIN staff, faced with a surge in near-exhaust allocations and subsequent transfer requests and a requirement for team review of these, is spending scarce staff time on needs testing of small transfers. This proposal seeks to decrease overall ARIN processing time through elimination of that needs test.
> Policy statement:
> Change the language in NRPM 8.3 after Conditions on the recipient of the transfer: from "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." to "For transfers larger than a /16 equivalent, the recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA."
> Change the language in the third bullet point in NRPM 8.4 after Conditions on the recipient of the transfer: from "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." to "For transfers larger than a /16 equivalent, recipients in the ARIN region must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA."
> Comments:
> Needs testing has been maintained for transfers largely because the community wishes to ensure protection against hoarding and speculation in the IPv4 market. This proposal seeks a middle ground between the elimination of needs tests for transfers altogether, and the continuance of needs tests for every transfer. This should help ARIN staff to reduce transfer processing time, since most transfers have been smaller than /16.
> Timetable for implementation: Immediate
>

Opposed.

ARIN and the community should focus on deploying ipv6 not pulling the fire alarm on ppml.

This is not an emergency. These policies and forces have been around for years.  Clinging to ipv4 is costly.

> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto: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<mailto: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<mailto: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/20140429/7a5a23e9/attachment.htm>

From michael at linuxmagic.com  Tue Apr 29 13:48:02 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Tue, 29 Apr 2014 10:48:02 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (fwd)
In-Reply-To: <12e2900c1bac473389a72356eb171084@DM2PR03MB398.namprd03.prod.outlook.com>
References: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>	<CAD6AjGTry7OWZ5emdL1AsUz5WFgTgEQdCuKvh_iEMD=_48G53g@mail.gmail.com>	<12D1F823-8D97-4FB9-B5EA-B35791E0DACB@delong.com>
	<12e2900c1bac473389a72356eb171084@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <535FE5D2.2040903@linuxmagic.com>

On 14-04-29 10:28 AM, David Huberman wrote:
> When I studied it for ARIN, 87% of the v4 address space ARIN issued over
> a 2 year period went to ELEVEN companies.
>
> I?m not speaking directly to prop 204, but in general:  policy has
> favored big guys at the gross expense of small guys for 15 years.  It?s
> injust. And the math (at least in the mid-to-late 2000s when I studied
> it) doesn?t support it.
>
> The RIPE/APNIC model of ?everyone starts on an even playing field by
> getting a /x just by opening an account? is a much fairer way of doing
> business, in my opinion.
>
> *David R Huberman*
>
> Microsoft Corporation
>
> Senior IT/OPS Program Manager (GFS)
>


Oh, and even worst .. it is what the big guys are using it for ;)
We are working with some of our relationships to show some statistics on 
usage.. Just this morning I was forwarded two /18 ranges that were seen 
recently granted issued the behavior of those networks, (no rwhois 
delegation, fake domains etc) do have to make people stop and think, in 
an age where we are running out of IP Space.

And with no effective mandate for enforcement at ARIN, it does reflect 
that something is broken with the current mandate, when someone can get 
a /18 for 'future' use, while a small player like the one that started 
this thread cannot get a /22 for current use.


-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From owens at nysernet.org  Tue Apr 29 13:54:44 2014
From: owens at nysernet.org (Bill Owens)
Date: Tue, 29 Apr 2014 13:54:44 -0400
Subject: [arin-ppml] NRPM 4.10 - is a /10 large enough?
Message-ID: <20140429175444.GA82885@nysernet.org>

A couple of recent threads here and my general sense of the (lack of) urgency around IPv6 deployment has made me wonder whether setting aside a /10 under NRPM 4.10 - Dedicated IPv4 block to facilitate IPv6 Deployment - is really going to be enough. I was looking at Geoff Huston's graphs (http://www.potaroo.net/tools/ipv4/) and noticed that both RIPE and APNIC, by coincidence, will be using up the first /10 out of their reserved /8s at about the same time, near the end of this year. A naive calculation says that APNIC will go through the /10 in about 3.5 years, and RIPE in about 2.2 years. Of course it is difficult to predict how the runout of the reserved /10 under 4.10 will look, but I think it's reasonable to assume that it won't be any slower than 2-3 years, since unlike RIPE and APNIC there's no limit to how much space an entity can receive under 4.10, only the pace at which it can be handed out; assuming the maximum rate, a /22 can be issued to someone every two years, rather than once and done as with the other two RIRs.

Given that the inventory currently contains one /9 and one /10, we are getting close to the point where any additional set-asides will no longer be possible, so I thought it might be worthwhile at least considering whether the 4.10 pool ought to be enlarged while it still can be. . .

Bill.


From owen at delong.com  Tue Apr 29 13:58:58 2014
From: owen at delong.com (Owen DeLong)
Date: Tue, 29 Apr 2014 10:58:58 -0700
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
	Allocation/Assignment units to /24
Message-ID: <89668261-46F6-4415-B595-032843FC9D68@delong.com>

Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0

	1.	Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24
	2.	Proposal Originator 
		a.	name: Owen DeLong
		b.	email: owen at delong.com
		c.	telephone: 408-890-7992
		d.	organization: Hurricane Electric
	3.	Date: 29 April, 2014
	4.	Problem Statement: 
As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.
	5.	Policy statement:
Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:

4.2.1.5 Change all occurrences of /20 and /22 to /24
4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.
4.3.2.1	Change both occurrences of /20 to /24
4.9	Change /22 to /24
4.9.1	Change all instances of /22 to /24. Remove the reference to 4 /24s.

	6.	Comments:
		a.	Timetable for implementation: Immediate, possibly through board action.
		b.	Anything else

END OF TEMPLATE 

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

From andrew.dul at quark.net  Tue Apr 29 14:13:26 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Tue, 29 Apr 2014 11:13:26 -0700
Subject: [arin-ppml] NRPM 4.10 - is a /10 large enough?
In-Reply-To: <20140429175444.GA82885@nysernet.org>
References: <20140429175444.GA82885@nysernet.org>
Message-ID: <535FEBC6.4030709@quark.net>

On 4/29/2014 10:54 AM, Bill Owens wrote:
> A couple of recent threads here and my general sense of the (lack of) urgency around IPv6 deployment has made me wonder whether setting aside a /10 under NRPM 4.10 - Dedicated IPv4 block to facilitate IPv6 Deployment - is really going to be enough. I was looking at Geoff Huston's graphs (http://www.potaroo.net/tools/ipv4/) and noticed that both RIPE and APNIC, by coincidence, will be using up the first /10 out of their reserved /8s at about the same time, near the end of this year. A naive calculation says that APNIC will go through the /10 in about 3.5 years, and RIPE in about 2.2 years. Of course it is difficult to predict how the runout of the reserved /10 under 4.10 will look, but I think it's reasonable to assume that it won't be any slower than 2-3 years, since unlike RIPE and APNIC there's no limit to how much space an entity can receive under 4.10, only the pace at which it can be handed out; assuming the maximum rate, a /22 can be issued to someone every two years, r
>  ather than once and done as with the other two RIRs.
>
> Given that the inventory currently contains one /9 and one /10, we are getting close to the point where any additional set-asides will no longer be possible, so I thought it might be worthwhile at least considering whether the 4.10 pool ought to be enlarged while it still can be. . .
>
>
Policy proposal 207, suggests that we add to the existing /10 reserved
pool with the fragments that we will get back from IANA shortly.  It
appears ARIN will received somewhere between a /11 and /10 equivalent
when the fragments are distributed.  The proposal also limits the number
of allocations to one per organization.

https://www.arin.net/policy/proposals/ARIN_prop_207_orig.html

https://www.iana.org/assignments/ipv4-recovered-address-space

Andrew



From hannigan at gmail.com  Tue Apr 29 14:15:26 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 29 Apr 2014 14:15:26 -0400
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
Message-ID: <CAMDXq5PmjR5nPUEUp_Hjwrm0icVi=Ec_EzFSK1agOVMXA100jg@mail.gmail.com>

Looks good.


On Tue, Apr 29, 2014 at 1:58 PM, Owen DeLong <owen at delong.com> wrote:
> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>
> 1. Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to
> /24
> 2. Proposal Originator
> a. name: Owen DeLong
> b. email: owen at delong.com
> c. telephone: 408-890-7992
> d. organization: Hurricane Electric
> 3. Date: 29 April, 2014
> 4. Problem Statement:
>
> As we approach runout, more and more end users and smaller ISPs will be
> unable to obtain space from their upstreams and will be seeking space from
> ARIN. In order to meet these needs to the extent possible and to make policy
> more fair to a broader range of the ARIN constituency, we should reduce the
> minimum assignment and allocation units to /24 across the board.
>
> 5. Policy statement:
>
> Change the minimum allocation and assignment unit for all IPv4 single and
> multi homed instances to /20. This would include:
>
>
> 4.2.1.5 Change all occurrences of /20 and /22 to /24
>
> 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24.
> Remove the example about 12 /24s.
>
> 4.3.2.1 Change both occurrences of /20 to /24
>
> 4.9 Change /22 to /24
>
> 4.9.1 Change all instances of /22 to /24. Remove the reference to 4 /24s.
>
>
> 6. Comments:
> a. Timetable for implementation: Immediate, possibly through board action.
> b. Anything else
>
> END OF TEMPLATE
>
>
>
> _______________________________________________
> 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.


From cgrundemann at gmail.com  Tue Apr 29 14:19:37 2014
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 29 Apr 2014 12:19:37 -0600
Subject: [arin-ppml] Last IPv4 Address Space
In-Reply-To: <CAMDXq5Ofexvrwm5-GT3s3RZhQ0vo8dxJNMq3FDaG+jvPTbj2OQ@mail.gmail.com>
References: <CAMDXq5Ofexvrwm5-GT3s3RZhQ0vo8dxJNMq3FDaG+jvPTbj2OQ@mail.gmail.com>
Message-ID: <CAC1-dt=khxXx+ZTtGPa30G39cFm86+vE+wK=0yZenCTxSqL5tQ@mail.gmail.com>

I posit that IP addresses are most efficient when in use on networks and
not when in inventory at an RIR.

----
My android sent this.
On Apr 29, 2014 9:32 AM, "Martin Hannigan" <hannigan at gmail.com> wrote:

> How about an apolitical last /N policy?
>
>
>
> Section N Last IPv4 Addresses Available in Region
>
> Upon receipt of a /11 or up to an equivalent from the IANA, ARIN will
> set that prefix, aggregate or longer equivalent aside until a /11 of
> inventory is reached and for assignment of a /24 to all existing ARIN
> members and all future ARIN members until exhausted.
>
>
> I believe there is an /11 on deck for each RIR and from returned space
> from what I understand. That would provide for 8192 /24.
>
> Thoughts? Better to discuss before sending it in.
>
>
> Best,
>
>
> -M<
> _______________________________________________
> 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/20140429/2640feaf/attachment.htm>

From drc at virtualized.org  Tue Apr 29 14:22:30 2014
From: drc at virtualized.org (David Conrad)
Date: Tue, 29 Apr 2014 11:22:30 -0700
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
	Allocation/Assignment units to /24
In-Reply-To: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
Message-ID: <2FEB6B2D-D7F2-4371-94FE-9F7F700E24C4@virtualized.org>

Support.

Regards,
-drc

On Apr 29, 2014, at 10:58 AM, Owen DeLong <owen at delong.com> wrote:

> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
> 
> 	1.	Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24
> 	2.	Proposal Originator 
> 		a.	name: Owen DeLong
> 		b.	email: owen at delong.com
> 		c.	telephone: 408-890-7992
> 		d.	organization: Hurricane Electric
> 	3.	Date: 29 April, 2014
> 	4.	Problem Statement: 
> As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.
> 	5.	Policy statement:
> Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:
> 
> 4.2.1.5 Change all occurrences of /20 and /22 to /24
> 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.
> 4.3.2.1	Change both occurrences of /20 to /24
> 4.9	Change /22 to /24
> 4.9.1	Change all instances of /22 to /24. Remove the reference to 4 /24s.
> 
> 	6.	Comments:
> 		a.	Timetable for implementation: Immediate, possibly through board action.
> 		b.	Anything else
> 
> END OF TEMPLATE 
> 
> _______________________________________________
> 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/20140429/ae7baf44/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/ae7baf44/attachment.sig>

From ajs at anvilwalrusden.com  Tue Apr 29 14:23:55 2014
From: ajs at anvilwalrusden.com (Andrew Sullivan)
Date: Tue, 29 Apr 2014 14:23:55 -0400
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
Message-ID: <20140429182354.GP1324@mx1.yitter.info>

I support this.

A

On Tue, Apr 29, 2014 at 10:58:58AM -0700, Owen DeLong wrote:
> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
> 
> 	1.	Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24
> 	2.	Proposal Originator 
> 		a.	name: Owen DeLong
> 		b.	email: owen at delong.com
> 		c.	telephone: 408-890-7992
> 		d.	organization: Hurricane Electric
> 	3.	Date: 29 April, 2014
> 	4.	Problem Statement: 
> As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.
> 	5.	Policy statement:
> Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:
> 
> 4.2.1.5 Change all occurrences of /20 and /22 to /24
> 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.
> 4.3.2.1	Change both occurrences of /20 to /24
> 4.9	Change /22 to /24
> 4.9.1	Change all instances of /22 to /24. Remove the reference to 4 /24s.
> 
> 	6.	Comments:
> 		a.	Timetable for implementation: Immediate, possibly through board action.
> 		b.	Anything else
> 
> END OF TEMPLATE 
> 

> _______________________________________________
> 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.


-- 
Andrew Sullivan
ajs at anvilwalrusden.com


From farmer at umn.edu  Tue Apr 29 14:23:56 2014
From: farmer at umn.edu (David Farmer)
Date: Tue, 29 Apr 2014 13:23:56 -0500
Subject: [arin-ppml] NRPM 4.10 - is a /10 large enough?
In-Reply-To: <20140429175444.GA82885@nysernet.org>
References: <20140429175444.GA82885@nysernet.org>
Message-ID: <535FEE3C.8080801@umn.edu>

If I'm not mistaken the reserved /10 for IPv6 deployment and /16 for 
micro-allocations is not included in the counter.  Could staff confirm 
please.

Further, there is an additional approximately /10 that will come from 
the IANA recovered address pool.  I'm comfortable with this being 
reserved for special purposes, if we see fit.

However, I'm not comfortable with reserving more out of the current free 
pool at this point.  We are well past the point where making that kind 
of change can occur without causing potentially bad side effects.  Any 
drastic change in what is available for normal allocations at this point 
is likely create a panic.

We discussed this as a community, there were proposals to reserve larger 
chunks including the whole last /8 as RIPE and APNIC did.  We chose this 
strategy.  In some situations never is better than too late.

My best advice is find your towel and DON'T PANIC!

http://en.wikipedia.org/wiki/Don%27t_Panic_(The_Hitchhiker%27s_Guide_to_the_Galaxy)#Knowing_where_one.27s_towel_is
http://en.wikipedia.org/wiki/Don%27t_Panic_(The_Hitchhiker%27s_Guide_to_the_Galaxy)#Don.27t_Panic 


Thanks

On 4/29/14, 12:54 , Bill Owens wrote:
> A couple of recent threads here and my general sense of the (lack of) urgency around IPv6 deployment has made me wonder whether setting aside a /10 under NRPM 4.10 - Dedicated IPv4 block to facilitate IPv6 Deployment - is really going to be enough. I was looking at Geoff Huston's graphs (http://www.potaroo.net/tools/ipv4/) and noticed that both RIPE and APNIC, by coincidence, will be using up the first /10 out of their reserved /8s at about the same time, near the end of this year. A naive calculation says that APNIC will go through the /10 in about 3.5 years, and RIPE in about 2.2 years. Of course it is difficult to predict how the runout of the reserved /10 under 4.10 will look, but I think it's reasonable to assume that it won't be any slower than 2-3 years, since unlike RIPE and APNIC there's no limit to how much space an entity can receive under 4.10, only the pace at which it can be handed out; assuming the maximum rate, a /22 can be issued to someone every two years,
  r
>   ather than once and done as with the other two RIRs.
>
> Given that the inventory currently contains one /9 and one /10, we are getting close to the point where any additional set-asides will no longer be possible, so I thought it might be worthwhile at least considering whether the 4.10 pool ought to be enlarged while it still can be. . .
>
> Bill.
> _______________________________________________
> 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.
>


-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================


From skylar at crissic.net  Tue Apr 29 14:28:50 2014
From: skylar at crissic.net (Skylar MacMinn)
Date: Tue, 29 Apr 2014 18:28:50 +0000
Subject: [arin-ppml] NRPM 4.10 - is a /10 large enough?
In-Reply-To: <535FEE3C.8080801@umn.edu>
References: <20140429175444.GA82885@nysernet.org> <535FEE3C.8080801@umn.edu>
Message-ID: <35b435b0b0c1467ab538545788cad54b@DM2PR0801MB569.namprd08.prod.outlook.com>

I'd expect the Quick jump from 1.34 to 1.00 with the Cloudflare /12 and the Akamai /10 to have caused enough panic as is. I'd support reserving the IANA recovered address pool for that, but not current available IPv4 space.

Cordially Yours,

Skylar MacMinn
www.crissic.net
Crissic Solutions, LLC

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer
Sent: Tuesday, April 29, 2014 1:24 PM
To: owens at nysernet.org; arin-ppml at arin.net
Subject: Re: [arin-ppml] NRPM 4.10 - is a /10 large enough?

If I'm not mistaken the reserved /10 for IPv6 deployment and /16 for micro-allocations is not included in the counter.  Could staff confirm please.

Further, there is an additional approximately /10 that will come from the IANA recovered address pool.  I'm comfortable with this being reserved for special purposes, if we see fit.

However, I'm not comfortable with reserving more out of the current free pool at this point.  We are well past the point where making that kind of change can occur without causing potentially bad side effects.  Any drastic change in what is available for normal allocations at this point is likely create a panic.

We discussed this as a community, there were proposals to reserve larger chunks including the whole last /8 as RIPE and APNIC did.  We chose this strategy.  In some situations never is better than too late.

My best advice is find your towel and DON'T PANIC!

http://en.wikipedia.org/wiki/Don%27t_Panic_(The_Hitchhiker%27s_Guide_to_the_Galaxy)#Knowing_where_one.27s_towel_is
http://en.wikipedia.org/wiki/Don%27t_Panic_(The_Hitchhiker%27s_Guide_to_the_Galaxy)#Don.27t_Panic 


Thanks

On 4/29/14, 12:54 , Bill Owens wrote:
> A couple of recent threads here and my general sense of the (lack of) 
> urgency around IPv6 deployment has made me wonder whether setting 
> aside a /10 under NRPM 4.10 - Dedicated IPv4 block to facilitate IPv6 
> Deployment - is really going to be enough. I was looking at Geoff 
> Huston's graphs (http://www.potaroo.net/tools/ipv4/) and noticed that 
> both RIPE and APNIC, by coincidence, will be using up the first /10 
> out of their reserved /8s at about the same time, near the end of this 
> year. A naive calculation says that APNIC will go through the /10 in 
> about 3.5 years, and RIPE in about 2.2 years. Of course it is 
> difficult to predict how the runout of the reserved /10 under 4.10 
> will look, but I think it's reasonable to assume that it won't be any 
> slower than 2-3 years, since unlike RIPE and APNIC there's no limit to 
> how much space an entity can receive under 4.10, only the pace at 
> which it can be handed out; assuming the maximum rate, a /22 can be 
> issued to someone every two years,
  r
>   ather than once and done as with the other two RIRs.
>
> Given that the inventory currently contains one /9 and one /10, we are getting close to the point where any additional set-asides will no longer be possible, so I thought it might be worthwhile at least considering whether the 4.10 pool ought to be enlarged while it still can be. . .
>
> Bill.
> _______________________________________________
> 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.
>


--
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952 ================================================
_______________________________________________
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.


From leslien at arin.net  Tue Apr 29 14:29:16 2014
From: leslien at arin.net (Leslie Nobile)
Date: Tue, 29 Apr 2014 18:29:16 +0000
Subject: [arin-ppml] NRPM 4.10 - is a /10 large enough?
In-Reply-To: <535FEE3C.8080801@umn.edu>
Message-ID: <CF85677C.20316%leslien@arin.net>

To confirm, the /10 reserved for IPv6 transition and the /16 reserved for
micro-allocations are not included in the daily IPv4 inventory counter on
the ARIN homepage.

Leslie



On 4/29/14 2:23 PM, "David Farmer" <farmer at umn.edu> wrote:

>If I'm not mistaken the reserved /10 for IPv6 deployment and /16 for
>micro-allocations is not included in the counter.  Could staff confirm
>please.
>
>Further, there is an additional approximately /10 that will come from
>the IANA recovered address pool.  I'm comfortable with this being
>reserved for special purposes, if we see fit.
>
>However, I'm not comfortable with reserving more out of the current free
>pool at this point.  We are well past the point where making that kind
>of change can occur without causing potentially bad side effects.  Any
>drastic change in what is available for normal allocations at this point
>is likely create a panic.
>
>We discussed this as a community, there were proposals to reserve larger
>chunks including the whole last /8 as RIPE and APNIC did.  We chose this
>strategy.  In some situations never is better than too late.
>
>My best advice is find your towel and DON'T PANIC!
>
>http://en.wikipedia.org/wiki/Don%27t_Panic_(The_Hitchhiker%27s_Guide_to_th
>e_Galaxy)#Knowing_where_one.27s_towel_is
>http://en.wikipedia.org/wiki/Don%27t_Panic_(The_Hitchhiker%27s_Guide_to_th
>e_Galaxy)#Don.27t_Panic
>
>
>Thanks
>
>On 4/29/14, 12:54 , Bill Owens wrote:
>> A couple of recent threads here and my general sense of the (lack of)
>>urgency around IPv6 deployment has made me wonder whether setting aside
>>a /10 under NRPM 4.10 - Dedicated IPv4 block to facilitate IPv6
>>Deployment - is really going to be enough. I was looking at Geoff
>>Huston's graphs (http://www.potaroo.net/tools/ipv4/) and noticed that
>>both RIPE and APNIC, by coincidence, will be using up the first /10 out
>>of their reserved /8s at about the same time, near the end of this year.
>>A naive calculation says that APNIC will go through the /10 in about 3.5
>>years, and RIPE in about 2.2 years. Of course it is difficult to predict
>>how the runout of the reserved /10 under 4.10 will look, but I think
>>it's reasonable to assume that it won't be any slower than 2-3 years,
>>since unlike RIPE and APNIC there's no limit to how much space an entity
>>can receive under 4.10, only the pace at which it can be handed out;
>>assuming the maximum rate, a /22 can be issued to someone every two
>>years,
>  r
>>   ather than once and done as with the other two RIRs.
>>
>> Given that the inventory currently contains one /9 and one /10, we are
>>getting close to the point where any additional set-asides will no
>>longer be possible, so I thought it might be worthwhile at least
>>considering whether the 4.10 pool ought to be enlarged while it still
>>can be. . .
>>
>> Bill.
>> _______________________________________________
>> 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.
>>
>
>
>-- 
>================================================
>David Farmer               Email: farmer at umn.edu
>Office of Information Technology
>University of Minnesota
>2218 University Ave SE     Phone: 1-612-626-0815
>Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
>================================================
>_______________________________________________
>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.



From hannigan at gmail.com  Tue Apr 29 14:29:49 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 29 Apr 2014 14:29:49 -0400
Subject: [arin-ppml] NRPM 4.10 - is a /10 large enough?
In-Reply-To: <20140429175444.GA82885@nysernet.org>
References: <20140429175444.GA82885@nysernet.org>
Message-ID: <CAMDXq5NWAka7fHg4r-5EXPx1Fobt_DAYM7GdWcBe8TJEKWTZ1g@mail.gmail.com>

I think the a reserved /11 policy for all and from the IANA frags and
eleasing this back to the free pool would provide for the same
function.

Delete it and return it to the pool.

Best,

-M<



On Tue, Apr 29, 2014 at 1:54 PM, Bill Owens <owens at nysernet.org> wrote:
> A couple of recent threads here and my general sense of the (lack of) urgency around IPv6 deployment has made me wonder whether setting aside a /10 under NRPM 4.10 - Dedicated IPv4 block to facilitate IPv6 Deployment - is really going to be enough. I was looking at Geoff Huston's graphs (http://www.potaroo.net/tools/ipv4/) and noticed that both RIPE and APNIC, by coincidence, will be using up the first /10 out of their reserved /8s at about the same time, near the end of this year. A naive calculation says that APNIC will go through the /10 in about 3.5 years, and RIPE in about 2.2 years. Of course it is difficult to predict how the runout of the reserved /10 under 4.10 will look, but I think it's reasonable to assume that it won't be any slower than 2-3 years, since unlike RIPE and APNIC there's no limit to how much space an entity can receive under 4.10, only the pace at which it can be handed out; assuming the maximum rate, a /22 can be issued to someone every two years, r
>  ather than once and done as with the other two RIRs.
>
> Given that the inventory currently contains one /9 and one /10, we are getting close to the point where any additional set-asides will no longer be possible, so I thought it might be worthwhile at least considering whether the 4.10 pool ought to be enlarged while it still can be. . .
>
> Bill.
> _______________________________________________
> 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.


From rudi.daniel at gmail.com  Tue Apr 29 14:35:34 2014
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Tue, 29 Apr 2014 14:35:34 -0400
Subject: [arin-ppml] policy proposal/min. Allocation/assignment
Message-ID: <CA+uaoiWGZq4ApSug0BdA1pYGAurL2sT_y=WCzv7QLrTyR3e3SQ@mail.gmail.com>

I support this proposal.

Rudi Daniel
(information technologist)
784 430 9235
On Apr 29, 2014 2:30 PM, <arin-ppml-request at arin.net> wrote:

> Send ARIN-PPML mailing list submissions to
>         arin-ppml at arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
>         arin-ppml-request at arin.net
>
> You can reach the person managing the list at
>         arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
>    1. Re: Policy Proposal: Reduce all Minimum   Allocation/Assignment
>       units to /24 (David Conrad)
>    2. Re: Policy Proposal: Reduce all Minimum Allocation/Assignment
>       units to /24 (Andrew Sullivan)
>    3. Re: NRPM 4.10 - is a /10 large enough? (David Farmer)
>    4. Re: NRPM 4.10 - is a /10 large enough? (Skylar MacMinn)
>    5. Re: NRPM 4.10 - is a /10 large enough? (Leslie Nobile)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 29 Apr 2014 11:22:30 -0700
> From: David Conrad <drc at virtualized.org>
> To: Owen DeLong <owen at delong.com>
> Cc: Public Policy Mailing List <ppml at arin.net>, policy at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Reduce all Minimum
>         Allocation/Assignment units to /24
> Message-ID: <2FEB6B2D-D7F2-4371-94FE-9F7F700E24C4 at virtualized.org>
> Content-Type: text/plain; charset="us-ascii"
>
> Support.
>
> Regards,
> -drc
>
> On Apr 29, 2014, at 10:58 AM, Owen DeLong <owen at delong.com> wrote:
>
> > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
> >
> >       1.      Policy Proposal Name: Reduce all Minimum
> Allocation/Assignment units to /24
> >       2.      Proposal Originator
> >               a.      name: Owen DeLong
> >               b.      email: owen at delong.com
> >               c.      telephone: 408-890-7992
> >               d.      organization: Hurricane Electric
> >       3.      Date: 29 April, 2014
> >       4.      Problem Statement:
> > As we approach runout, more and more end users and smaller ISPs will be
> unable to obtain space from their upstreams and will be seeking space from
> ARIN. In order to meet these needs to the extent possible and to make
> policy more fair to a broader range of the ARIN constituency, we should
> reduce the minimum assignment and allocation units to /24 across the board.
> >       5.      Policy statement:
> > Change the minimum allocation and assignment unit for all IPv4 single
> and multi homed instances to /20. This would include:
> >
> > 4.2.1.5 Change all occurrences of /20 and /22 to /24
> > 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1
> /24. Remove the example about 12 /24s.
> > 4.3.2.1       Change both occurrences of /20 to /24
> > 4.9   Change /22 to /24
> > 4.9.1 Change all instances of /22 to /24. Remove the reference to 4 /24s.
> >
> >       6.      Comments:
> >               a.      Timetable for implementation: Immediate, possibly
> through board action.
> >               b.      Anything else
> >
> > END OF TEMPLATE
> >
> > _______________________________________________
> > 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: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20140429/ae7baf44/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 495 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20140429/ae7baf44/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 29 Apr 2014 14:23:55 -0400
> From: Andrew Sullivan <ajs at anvilwalrusden.com>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Reduce all Minimum
>         Allocation/Assignment units to /24
> Message-ID: <20140429182354.GP1324 at mx1.yitter.info>
> Content-Type: text/plain; charset=us-ascii
>
> I support this.
>
> A
>
> On Tue, Apr 29, 2014 at 10:58:58AM -0700, Owen DeLong wrote:
> > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
> >
> >       1.      Policy Proposal Name: Reduce all Minimum
> Allocation/Assignment units to /24
> >       2.      Proposal Originator
> >               a.      name: Owen DeLong
> >               b.      email: owen at delong.com
> >               c.      telephone: 408-890-7992
> >               d.      organization: Hurricane Electric
> >       3.      Date: 29 April, 2014
> >       4.      Problem Statement:
> > As we approach runout, more and more end users and smaller ISPs will be
> unable to obtain space from their upstreams and will be seeking space from
> ARIN. In order to meet these needs to the extent possible and to make
> policy more fair to a broader range of the ARIN constituency, we should
> reduce the minimum assignment and allocation units to /24 across the board.
> >       5.      Policy statement:
> > Change the minimum allocation and assignment unit for all IPv4 single
> and multi homed instances to /20. This would include:
> >
> > 4.2.1.5 Change all occurrences of /20 and /22 to /24
> > 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1
> /24. Remove the example about 12 /24s.
> > 4.3.2.1       Change both occurrences of /20 to /24
> > 4.9   Change /22 to /24
> > 4.9.1 Change all instances of /22 to /24. Remove the reference to 4 /24s.
> >
> >       6.      Comments:
> >               a.      Timetable for implementation: Immediate, possibly
> through board action.
> >               b.      Anything else
> >
> > END OF TEMPLATE
> >
>
> > _______________________________________________
> > 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.
>
>
> --
> Andrew Sullivan
> ajs at anvilwalrusden.com
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 29 Apr 2014 13:23:56 -0500
> From: David Farmer <farmer at umn.edu>
> To: owens at nysernet.org,    arin-ppml at arin.net
> Subject: Re: [arin-ppml] NRPM 4.10 - is a /10 large enough?
> Message-ID: <535FEE3C.8080801 at umn.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> If I'm not mistaken the reserved /10 for IPv6 deployment and /16 for
> micro-allocations is not included in the counter.  Could staff confirm
> please.
>
> Further, there is an additional approximately /10 that will come from
> the IANA recovered address pool.  I'm comfortable with this being
> reserved for special purposes, if we see fit.
>
> However, I'm not comfortable with reserving more out of the current free
> pool at this point.  We are well past the point where making that kind
> of change can occur without causing potentially bad side effects.  Any
> drastic change in what is available for normal allocations at this point
> is likely create a panic.
>
> We discussed this as a community, there were proposals to reserve larger
> chunks including the whole last /8 as RIPE and APNIC did.  We chose this
> strategy.  In some situations never is better than too late.
>
> My best advice is find your towel and DON'T PANIC!
>
>
> http://en.wikipedia.org/wiki/Don%27t_Panic_(The_Hitchhiker%27s_Guide_to_the_Galaxy)#Knowing_where_one.27s_towel_is
>
> http://en.wikipedia.org/wiki/Don%27t_Panic_(The_Hitchhiker%27s_Guide_to_the_Galaxy)#Don.27t_Panic
>
>
> Thanks
>
> On 4/29/14, 12:54 , Bill Owens wrote:
> > A couple of recent threads here and my general sense of the (lack of)
> urgency around IPv6 deployment has made me wonder whether setting aside a
> /10 under NRPM 4.10 - Dedicated IPv4 block to facilitate IPv6 Deployment -
> is really going to be enough. I was looking at Geoff Huston's graphs (
> http://www.potaroo.net/tools/ipv4/) and noticed that both RIPE and APNIC,
> by coincidence, will be using up the first /10 out of their reserved /8s at
> about the same time, near the end of this year. A naive calculation says
> that APNIC will go through the /10 in about 3.5 years, and RIPE in about
> 2.2 years. Of course it is difficult to predict how the runout of the
> reserved /10 under 4.10 will look, but I think it's reasonable to assume
> that it won't be any slower than 2-3 years, since unlike RIPE and APNIC
> there's no limit to how much space an entity can receive under 4.10, only
> the pace at which it can be handed out; assuming the maximum rate, a /22
> can be issued to someone every two years,
>   r
> >   ather than once and done as with the other two RIRs.
> >
> > Given that the inventory currently contains one /9 and one /10, we are
> getting close to the point where any additional set-asides will no longer
> be possible, so I thought it might be worthwhile at least considering
> whether the 4.10 pool ought to be enlarged while it still can be. . .
> >
> > Bill.
> > _______________________________________________
> > 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.
> >
>
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 29 Apr 2014 18:28:50 +0000
> From: Skylar MacMinn <skylar at crissic.net>
> To: David Farmer <farmer at umn.edu>, "owens at nysernet.org"
>         <owens at nysernet.org>,   "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] NRPM 4.10 - is a /10 large enough?
> Message-ID:
>         <
> 35b435b0b0c1467ab538545788cad54b at DM2PR0801MB569.namprd08.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> I'd expect the Quick jump from 1.34 to 1.00 with the Cloudflare /12 and
> the Akamai /10 to have caused enough panic as is. I'd support reserving the
> IANA recovered address pool for that, but not current available IPv4 space.
>
> Cordially Yours,
>
> Skylar MacMinn
> www.crissic.net
> Crissic Solutions, LLC
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Farmer
> Sent: Tuesday, April 29, 2014 1:24 PM
> To: owens at nysernet.org; arin-ppml at arin.net
> Subject: Re: [arin-ppml] NRPM 4.10 - is a /10 large enough?
>
> If I'm not mistaken the reserved /10 for IPv6 deployment and /16 for
> micro-allocations is not included in the counter.  Could staff confirm
> please.
>
> Further, there is an additional approximately /10 that will come from the
> IANA recovered address pool.  I'm comfortable with this being reserved for
> special purposes, if we see fit.
>
> However, I'm not comfortable with reserving more out of the current free
> pool at this point.  We are well past the point where making that kind of
> change can occur without causing potentially bad side effects.  Any drastic
> change in what is available for normal allocations at this point is likely
> create a panic.
>
> We discussed this as a community, there were proposals to reserve larger
> chunks including the whole last /8 as RIPE and APNIC did.  We chose this
> strategy.  In some situations never is better than too late.
>
> My best advice is find your towel and DON'T PANIC!
>
>
> http://en.wikipedia.org/wiki/Don%27t_Panic_(The_Hitchhiker%27s_Guide_to_the_Galaxy)#Knowing_where_one.27s_towel_is
>
> http://en.wikipedia.org/wiki/Don%27t_Panic_(The_Hitchhiker%27s_Guide_to_the_Galaxy)#Don.27t_Panic
>
>
> Thanks
>
> On 4/29/14, 12:54 , Bill Owens wrote:
> > A couple of recent threads here and my general sense of the (lack of)
> > urgency around IPv6 deployment has made me wonder whether setting
> > aside a /10 under NRPM 4.10 - Dedicated IPv4 block to facilitate IPv6
> > Deployment - is really going to be enough. I was looking at Geoff
> > Huston's graphs (http://www.potaroo.net/tools/ipv4/) and noticed that
> > both RIPE and APNIC, by coincidence, will be using up the first /10
> > out of their reserved /8s at about the same time, near the end of this
> > year. A naive calculation says that APNIC will go through the /10 in
> > about 3.5 years, and RIPE in about 2.2 years. Of course it is
> > difficult to predict how the runout of the reserved /10 under 4.10
> > will look, but I think it's reasonable to assume that it won't be any
> > slower than 2-3 years, since unlike RIPE and APNIC there's no limit to
> > how much space an entity can receive under 4.10, only the pace at
> > which it can be handed out; assuming the maximum rate, a /22 can be
> > issued to someone every two years,
>   r
> >   ather than once and done as with the other two RIRs.
> >
> > Given that the inventory currently contains one /9 and one /10, we are
> getting close to the point where any additional set-asides will no longer
> be possible, so I thought it might be worthwhile at least considering
> whether the 4.10 pool ought to be enlarged while it still can be. . .
> >
> > Bill.
> > _______________________________________________
> > 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.
> >
>
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952================================================
> _______________________________________________
> 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.
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 29 Apr 2014 18:29:16 +0000
> From: Leslie Nobile <leslien at arin.net>
> To: David Farmer <farmer at umn.edu>, "owens at nysernet.org"
>         <owens at nysernet.org>,   "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] NRPM 4.10 - is a /10 large enough?
> Message-ID: <CF85677C.20316%leslien at arin.net>
> Content-Type: text/plain; charset="us-ascii"
>
> To confirm, the /10 reserved for IPv6 transition and the /16 reserved for
> micro-allocations are not included in the daily IPv4 inventory counter on
> the ARIN homepage.
>
> Leslie
>
>
>
> On 4/29/14 2:23 PM, "David Farmer" <farmer at umn.edu> wrote:
>
> >If I'm not mistaken the reserved /10 for IPv6 deployment and /16 for
> >micro-allocations is not included in the counter.  Could staff confirm
> >please.
> >
> >Further, there is an additional approximately /10 that will come from
> >the IANA recovered address pool.  I'm comfortable with this being
> >reserved for special purposes, if we see fit.
> >
> >However, I'm not comfortable with reserving more out of the current free
> >pool at this point.  We are well past the point where making that kind
> >of change can occur without causing potentially bad side effects.  Any
> >drastic change in what is available for normal allocations at this point
> >is likely create a panic.
> >
> >We discussed this as a community, there were proposals to reserve larger
> >chunks including the whole last /8 as RIPE and APNIC did.  We chose this
> >strategy.  In some situations never is better than too late.
> >
> >My best advice is find your towel and DON'T PANIC!
> >
> >
> http://en.wikipedia.org/wiki/Don%27t_Panic_(The_Hitchhiker%27s_Guide_to_th
> >e_Galaxy)#Knowing_where_one.27s_towel_is
> >
> http://en.wikipedia.org/wiki/Don%27t_Panic_(The_Hitchhiker%27s_Guide_to_th
> >e_Galaxy)#Don.27t_Panic
> >
> >
> >Thanks
> >
> >On 4/29/14, 12:54 , Bill Owens wrote:
> >> A couple of recent threads here and my general sense of the (lack of)
> >>urgency around IPv6 deployment has made me wonder whether setting aside
> >>a /10 under NRPM 4.10 - Dedicated IPv4 block to facilitate IPv6
> >>Deployment - is really going to be enough. I was looking at Geoff
> >>Huston's graphs (http://www.potaroo.net/tools/ipv4/) and noticed that
> >>both RIPE and APNIC, by coincidence, will be using up the first /10 out
> >>of their reserved /8s at about the same time, near the end of this year.
> >>A naive calculation says that APNIC will go through the /10 in about 3.5
> >>years, and RIPE in about 2.2 years. Of course it is difficult to predict
> >>how the runout of the reserved /10 under 4.10 will look, but I think
> >>it's reasonable to assume that it won't be any slower than 2-3 years,
> >>since unlike RIPE and APNIC there's no limit to how much space an entity
> >>can receive under 4.10, only the pace at which it can be handed out;
> >>assuming the maximum rate, a /22 can be issued to someone every two
> >>years,
> >  r
> >>   ather than once and done as with the other two RIRs.
> >>
> >> Given that the inventory currently contains one /9 and one /10, we are
> >>getting close to the point where any additional set-asides will no
> >>longer be possible, so I thought it might be worthwhile at least
> >>considering whether the 4.10 pool ought to be enlarged while it still
> >>can be. . .
> >>
> >> Bill.
> >> _______________________________________________
> >> 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.
> >>
> >
> >
> >--
> >================================================
> >David Farmer               Email: farmer at umn.edu
> >Office of Information Technology
> >University of Minnesota
> >2218 University Ave SE     Phone: 1-612-626-0815
> >Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> >================================================
> >_______________________________________________
> >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.
>
>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 106, Issue 56
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/142cd666/attachment.htm>

From owens at nysernet.org  Tue Apr 29 14:38:16 2014
From: owens at nysernet.org (Bill Owens)
Date: Tue, 29 Apr 2014 14:38:16 -0400
Subject: [arin-ppml] NRPM 4.10 - is a /10 large enough?
In-Reply-To: <535FEBC6.4030709@quark.net>
References: <20140429175444.GA82885@nysernet.org> <535FEBC6.4030709@quark.net>
Message-ID: <20140429183816.GD78524@nysernet.org>

On Tue, Apr 29, 2014 at 11:13:26AM -0700, Andrew Dul wrote:
> Policy proposal 207, suggests that we add to the existing /10 reserved
> pool with the fragments that we will get back from IANA shortly.  It
> appears ARIN will received somewhere between a /11 and /10 equivalent
> when the fragments are distributed.  The proposal also limits the number
> of allocations to one per organization.

I saw 207 mentioned in the "Ip allocation" thread but thought that it was a parallel of 4.10 for initial assigmnents, not an extension of 4.10. And now that I read it carefully, I am still more confused since it actually seems to be both. I would support the addition of the IANA recovered space to the pool, but not the fundamental change in purpose from being a transition aid to being a source of v4 space only for new entrants. 

Bill.


From Jose.Alvarado at allstream.com  Tue Apr 29 14:45:10 2014
From: Jose.Alvarado at allstream.com (Alvarado, Jose)
Date: Tue, 29 Apr 2014 18:45:10 +0000
Subject: [arin-ppml] Policy Proposal: Reduce all
	Minimum	Allocation/Assignment units to /24
In-Reply-To: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
Message-ID: <EB8AFA74FFC07045AE55825002F34294DD0FDCDC@tj1exg02.mtsallstream.com>

I'm in support of this.

Regards,

Jose Alvarado
Sr Engineering Specialist, | Technology Operations, Internet & Security  |Customer Operations | * Tel: 416.642.4036 | *Cell: 416.315.4364| * email: jose.alvarado at allstream.com<mailto:jose.alvarado at allstream.com>
MTS Allstream Inc

[sig8]

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Tuesday, April 29, 2014 1:59 PM
To: policy at arin.net; ARIN PPML (ppml at arin.net)
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum Allocation/Assignment units to /24


Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0



        1.      Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24

        2.      Proposal Originator

               a.      name: Owen DeLong

               b.      email: owen at delong.com<mailto:owen at delong.com>

               c.      telephone: 408-890-7992

               d.      organization: Hurricane Electric

        3.      Date: 29 April, 2014

        4.      Problem Statement:

As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.

        5.      Policy statement:

Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:



4.2.1.5 Change all occurrences of /20 and /22 to /24

4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.

4.3.2.1 Change both occurrences of /20 to /24

4.9     Change /22 to /24

4.9.1   Change all instances of /22 to /24. Remove the reference to 4 /24s.



        6.      Comments:

               a.      Timetable for implementation: Immediate, possibly through board action.

               b.      Anything else



END OF TEMPLATE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/2113f963/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 17613 bytes
Desc: image001.png
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/2113f963/attachment.png>

From Jose.Alvarado at allstream.com  Tue Apr 29 14:49:12 2014
From: Jose.Alvarado at allstream.com (Alvarado, Jose)
Date: Tue, 29 Apr 2014 18:49:12 +0000
Subject: [arin-ppml] Policy Proposal: Reduce
	all	Minimum	Allocation/Assignment units to /24
In-Reply-To: <EB8AFA74FFC07045AE55825002F34294DD0FDCDC@tj1exg02.mtsallstream.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<EB8AFA74FFC07045AE55825002F34294DD0FDCDC@tj1exg02.mtsallstream.com>
Message-ID: <EB8AFA74FFC07045AE55825002F34294DD0FDD24@tj1exg02.mtsallstream.com>

Also on this, will there be any expected timeframe when the actual policy be publicly announced so that some of our pending customers whom are seeking to go directly to ARIN to request IP addresses can be directed to do so?

Thanks


Jose Alvarado
Sr Engineering Specialist, | Technology Operations, Internet & Security  |Customer Operations | * Tel: 416.642.4036 | *Cell: 416.315.4364| * email: jose.alvarado at allstream.com<mailto:jose.alvarado at allstream.com>
MTS Allstream Inc



From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alvarado, Jose
Sent: Tuesday, April 29, 2014 2:45 PM
To: Owen DeLong; policy at arin.net; ARIN PPML (ppml at arin.net)
Subject: Re: [arin-ppml] Policy Proposal: Reduce all Minimum Allocation/Assignment units to /24

I'm in support of this.

Regards,

Jose Alvarado
Sr Engineering Specialist, | Technology Operations, Internet & Security  |Customer Operations | * Tel: 416.642.4036 | *Cell: 416.315.4364| * email: jose.alvarado at allstream.com<mailto:jose.alvarado at allstream.com>
MTS Allstream Inc

[sig8]

From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Tuesday, April 29, 2014 1:59 PM
To: policy at arin.net<mailto:policy at arin.net>; ARIN PPML (ppml at arin.net<mailto:ppml at arin.net>)
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum Allocation/Assignment units to /24


Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0



        1.      Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24

        2.      Proposal Originator

               a.      name: Owen DeLong

               b.      email: owen at delong.com<mailto:owen at delong.com>

               c.      telephone: 408-890-7992

               d.      organization: Hurricane Electric

        3.      Date: 29 April, 2014

        4.      Problem Statement:

As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.

        5.      Policy statement:

Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:



4.2.1.5 Change all occurrences of /20 and /22 to /24

4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.

4.3.2.1 Change both occurrences of /20 to /24

4.9     Change /22 to /24

4.9.1   Change all instances of /22 to /24. Remove the reference to 4 /24s.



        6.      Comments:

               a.      Timetable for implementation: Immediate, possibly through board action.

               b.      Anything else



END OF TEMPLATE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/a99c19e6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 17613 bytes
Desc: image001.png
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/a99c19e6/attachment.png>

From bill at herrin.us  Tue Apr 29 15:49:10 2014
From: bill at herrin.us (William Herrin)
Date: Tue, 29 Apr 2014 15:49:10 -0400
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
Message-ID: <CAP-guGUndY6s4=+iiKnnVf9-+Hw5cCnE4ogivVFn+PQFCRsk=Q@mail.gmail.com>

On Tue, Apr 29, 2014 at 1:58 PM, Owen DeLong <owen at delong.com> wrote:
> 1. Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to
> /24
> 5. Policy statement:
>
> Change the minimum allocation and assignment unit for all IPv4 single and
> multi homed instances to /20. This would include:

Support.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From derekc at cnets.net  Tue Apr 29 15:59:32 2014
From: derekc at cnets.net (Derek Calanchini)
Date: Tue, 29 Apr 2014 12:59:32 -0700
Subject: [arin-ppml] Ip allocation
In-Reply-To: <CE4774EA-03AD-4703-B841-AA94A0BC211B@delong.com>
References: <535EE530.6040108@cnets.net>
	<CE4774EA-03AD-4703-B841-AA94A0BC211B@delong.com>
Message-ID: <536004A4.9080502@cnets.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/5a7d438c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cnslogo1.bmp
Type: image/bmp
Size: 72774 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/5a7d438c/attachment.bmp>

From george.herbert at gmail.com  Tue Apr 29 16:28:50 2014
From: george.herbert at gmail.com (George Herbert)
Date: Tue, 29 Apr 2014 13:28:50 -0700
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
Message-ID: <CAK__KzsN1HwNeD2_=Vy7MR=LciSNMA9HLQYTovkojDPdWHA+eQ@mail.gmail.com>

Support, but would like to hear any contrary opinions if there are any.


On Tue, Apr 29, 2014 at 10:58 AM, Owen DeLong <owen at delong.com> wrote:

> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>
> 	1.	Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24
> 	2.	Proposal Originator
> 		a.	name: Owen DeLong
> 		b.	email: owen at delong.com
> 		c.	telephone: 408-890-7992
> 		d.	organization: Hurricane Electric
> 	3.	Date: 29 April, 2014
> 	4.	Problem Statement:
>
> As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.
>
> 	5.	Policy statement:
>
> Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:
>
>
> 4.2.1.5 Change all occurrences of /20 and /22 to /24
>
> 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.
>
> 4.3.2.1	Change both occurrences of /20 to /24
>
> 4.9	Change /22 to /24
>
> 4.9.1	Change all instances of /22 to /24. Remove the reference to 4 /24s.
>
>
> 	6.	Comments:
> 		a.	Timetable for implementation: Immediate, possibly through board action.
> 		b.	Anything else
>
> END OF TEMPLATE
>
>
>
> _______________________________________________
> 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.
>



-- 
-george william herbert
george.herbert at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/c9bf632c/attachment.htm>

From Timothy.S.Morizot at irs.gov  Tue Apr 29 16:49:47 2014
From: Timothy.S.Morizot at irs.gov (Morizot Timothy S)
Date: Tue, 29 Apr 2014 20:49:47 +0000
Subject: [arin-ppml] Policy Proposal: Reduce all
	Minimum	Allocation/Assignment units to /24
In-Reply-To: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
Message-ID: <968C470DAC25FB419E0159952F28F0C06A766503@MEM0200CP3XF04.ds.irsnet.gov>

I support this proposal. I don't support any additional pools set aside rather than allocated on an as needed basis.

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Tuesday, April 29, 2014 12:59 PM
To: policy at arin.net; ARIN PPML (ppml at arin.net)
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum Allocation/Assignment units to /24


Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0



        1.      Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24

        2.      Proposal Originator

               a.      name: Owen DeLong

               b.      email: owen at delong.com<mailto:owen at delong.com>

               c.      telephone: 408-890-7992

               d.      organization: Hurricane Electric

        3.      Date: 29 April, 2014

        4.      Problem Statement:

As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.

        5.      Policy statement:

Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:



4.2.1.5 Change all occurrences of /20 and /22 to /24

4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.

4.3.2.1 Change both occurrences of /20 to /24

4.9     Change /22 to /24

4.9.1   Change all instances of /22 to /24. Remove the reference to 4 /24s.



        6.      Comments:

               a.      Timetable for implementation: Immediate, possibly through board action.

               b.      Anything else



END OF TEMPLATE

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

From mje at posix.co.za  Tue Apr 29 17:25:23 2014
From: mje at posix.co.za (Mark Elkins)
Date: Tue, 29 Apr 2014 23:25:23 +0200
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
Message-ID: <1398806723.4806.68.camel@mjelap.posix.co.za>

I like this Policy amendment.
I was quite upset to read Derek Calanchini's e-mail.
I'm also a small ISP.
I'm also distraught to hear people say that something like 87% of of all
space sits with 11 companies...

Perhaps some policy should say you can only ask for (more) space if you
have less than so much...a value which should be reduced according to
what is left, to bias favourably those with less space? Also somehow
throw in "One must already have or also apply for IPv6 at the same
time"?

I'm not trying to extend the lifespan of IPv4, rather pick up and help
along other folk like Derek.

On Tue, 2014-04-29 at 10:58 -0700, Owen DeLong wrote:
> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
> 
> 	1.	Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24
> 	2.	Proposal Originator 
> 		a.	name: Owen DeLong
> 		b.	email: owen at delong.com
> 		c.	telephone: 408-890-7992
> 		d.	organization: Hurricane Electric
> 	3.	Date: 29 April, 2014
> 	4.	Problem Statement: 
> As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.
> 	5.	Policy statement:
> Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:
> 
> 4.2.1.5 Change all occurrences of /20 and /22 to /24
> 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.
> 4.3.2.1	Change both occurrences of /20 to /24
> 4.9	Change /22 to /24
> 4.9.1	Change all instances of /22 to /24. Remove the reference to 4 /24s.
> 
> 	6.	Comments:
> 		a.	Timetable for implementation: Immediate, possibly through board action.
> 		b.	Anything else
> 
> END OF TEMPLATE 
> 
> 
> _______________________________________________
> 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.

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
mje at posix.co.za       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5810 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/d1412b93/attachment.bin>

From SRyerse at eclipse-networks.com  Tue Apr 29 17:35:02 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Tue, 29 Apr 2014 21:35:02 +0000
Subject: [arin-ppml] Policy Proposal: Reduce
	allMinimum	Allocation/Assignment units to /24
In-Reply-To: <968C470DAC25FB419E0159952F28F0C06A766503@MEM0200CP3XF04.ds.irsnet.gov>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<968C470DAC25FB419E0159952F28F0C06A766503@MEM0200CP3XF04.ds.irsnet.gov>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201529ABCFF@ENI-MAIL.eclipse-networks.com>

I support this proposal!!!

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
770.656.1460 - Cell
770.399.9099- Office

[Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc.
        Conquering Complex Networks?

From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Tuesday, April 29, 2014 12:59 PM
To: policy at arin.net<mailto:policy at arin.net>; ARIN PPML (ppml at arin.net<mailto:ppml at arin.net>)
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum Allocation/Assignment units to /24


Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0



        1.      Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24

        2.      Proposal Originator

               a.      name: Owen DeLong

               b.      email: owen at delong.com<mailto:owen at delong.com>

               c.      telephone: 408-890-7992

               d.      organization: Hurricane Electric

        3.      Date: 29 April, 2014

        4.      Problem Statement:

As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.

        5.      Policy statement:

Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:



4.2.1.5 Change all occurrences of /20 and /22 to /24

4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.

4.3.2.1 Change both occurrences of /20 to /24

4.9     Change /22 to /24

4.9.1   Change all instances of /22 to /24. Remove the reference to 4 /24s.



        6.      Comments:

               a.      Timetable for implementation: Immediate, possibly through board action.

               b.      Anything else



END OF TEMPLATE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/14fbcb2a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: image001.jpg
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/14fbcb2a/attachment.jpg>

From paul at iosaz.net  Tue Apr 29 17:56:58 2014
From: paul at iosaz.net (Paul Emmons)
Date: Tue, 29 Apr 2014 14:56:58 -0700
Subject: [arin-ppml] Policy Proposal: Reduce
	allMinimum	Allocation/Assignment units to /24
In-Reply-To: <968C470DAC25FB419E0159952F28F0C06A766503@MEM0200CP3XF04.ds.irsnet.gov>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<968C470DAC25FB419E0159952F28F0C06A766503@MEM0200CP3XF04.ds.irsnet.gov>
Message-ID: <45991FC24DA14360B4EB7AE95C2FA3AF@WINTHSF4VVENH8>

Support as well.

 

Paul Emmons

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Owen DeLong
Sent: Tuesday, April 29, 2014 12:59 PM
To: policy at arin.net; ARIN PPML (ppml at arin.net)
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
Allocation/Assignment units to /24

 

Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
 
        1.      Policy Proposal Name: Reduce all Minimum
Allocation/Assignment units to /24
        2.      Proposal Originator 
               a.      name: Owen DeLong
               b.      email: owen at delong.com
               c.      telephone: 408-890-7992
               d.      organization: Hurricane Electric
        3.      Date: 29 April, 2014
        4.      Problem Statement: 
As we approach runout, more and more end users and smaller ISPs will be
unable to obtain space from their upstreams and will be seeking space from
ARIN. In order to meet these needs to the extent possible and to make policy
more fair to a broader range of the ARIN constituency, we should reduce the
minimum assignment and allocation units to /24 across the board.
        5.      Policy statement:
Change the minimum allocation and assignment unit for all IPv4 single and
multi homed instances to /20. This would include:
 
4.2.1.5 Change all occurrences of /20 and /22 to /24
4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24.
Remove the example about 12 /24s.
4.3.2.1 Change both occurrences of /20 to /24
4.9     Change /22 to /24
4.9.1   Change all instances of /22 to /24. Remove the reference to 4 /24s.
 
        6.      Comments:
               a.      Timetable for implementation: Immediate, possibly
through board action.
               b.      Anything else
 
END OF TEMPLATE 

 

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

From rcarpen at network1.net  Tue Apr 29 17:57:34 2014
From: rcarpen at network1.net (Randy Carpenter)
Date: Tue, 29 Apr 2014 17:57:34 -0400 (EDT)
Subject: [arin-ppml] Policy Proposal: Reduce all
	Minimum	Allocation/Assignment units to /24
In-Reply-To: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
Message-ID: <1298483266.140015.1398808654120.JavaMail.zimbra@network1.net>


I support.

I would want to make sure that someone who needs more than a /24, could still get what they need immediately rather than only getting a /24 (as long as what they need is available). I have worked with several entities that are single-homed, and are using a /22, but need a /21, or are using a /23 and need a /22. They are all unable to get additional space form their upstream. Allowing them to get what they need from ARIN would allow them to return the old space to their upstream. It would benefit all.


thanks,
-Randy


----- Original Message -----
> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
> 
> 	1.	Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to
> 	/24
> 	2.	Proposal Originator
> 		a.	name: Owen DeLong
> 		b.	email: owen at delong.com c.	telephone: 408-890-7992
> 		d.	organization: Hurricane Electric
> 	3.	Date: 29 April, 2014
> 	4.	Problem Statement:
> As we approach runout, more and more end users and smaller ISPs will be
> unable to obtain space from their upstreams and will be seeking space from
> ARIN. In order to meet these needs to the extent possible and to make policy
> more fair to a broader range of the ARIN constituency, we should reduce the
> minimum assignment and allocation units to /24 across the board.
> 5.	Policy statement:
> Change the minimum allocation and assignment unit for all IPv4 single and
> multi homed instances to /20. This would include:
> 
> 4.2.1.5 Change all occurrences of /20 and /22 to /24
> 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24.
> Remove the example about 12 /24s.
> 4.3.2.1 Change both occurrences of /20 to /24
> 4.9 Change /22 to /24
> 4.9.1 Change all instances of /22 to /24. Remove the reference to 4 /24s.
> 
> 6.	Comments:
> 		a.	Timetable for implementation: Immediate, possibly through board action.
> 		b.	Anything else
> 
> END OF TEMPLATE
> 
> 
> _______________________________________________
> 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.


From michael at linuxmagic.com  Tue Apr 29 18:14:36 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Tue, 29 Apr 2014 15:14:36 -0700
Subject: [arin-ppml] Policy Proposal: Reduce all
 Minimum	Allocation/Assignment units to /24
In-Reply-To: <1298483266.140015.1398808654120.JavaMail.zimbra@network1.net>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<1298483266.140015.1398808654120.JavaMail.zimbra@network1.net>
Message-ID: <5360244C.80701@linuxmagic.com>

And I support.. if it wasn't clear..
I mentioned to the author that if this is tough to swallow, we should at 
least go down to a /22 everywhere..

(We have an application going in as well for space, and we would be 
returning 3 /24's back upstream on acceptance as well, it would be nicer 
if we didn't have to pay the expense of a second upstream provider.  So 
I also 'support' getting the board involved to expedite this)

On 14-04-29 02:57 PM, Randy Carpenter wrote:
>
> I support.
>
> I would want to make sure that someone who needs more than a /24, could still get what they need immediately rather than only getting a /24 (as long as what they need is available). I have worked with several entities that are single-homed, and are using a /22, but need a /21, or are using a /23 and need a /22. They are all unable to get additional space form their upstream. Allowing them to get what they need from ARIN would allow them to return the old space to their upstream. It would benefit all.
>
>
> thanks,
> -Randy
>
>
> ----- Original Message -----
>> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>>
>> 	1.	Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to
>> 	/24
>> 	2.	Proposal Originator
>> 		a.	name: Owen DeLong
>> 		b.	email: owen at delong.com c.	telephone: 408-890-7992
>> 		d.	organization: Hurricane Electric
>> 	3.	Date: 29 April, 2014
>> 	4.	Problem Statement:
>> As we approach runout, more and more end users and smaller ISPs will be
>> unable to obtain space from their upstreams and will be seeking space from
>> ARIN. In order to meet these needs to the extent possible and to make policy
>> more fair to a broader range of the ARIN constituency, we should reduce the
>> minimum assignment and allocation units to /24 across the board.
>> 5.	Policy statement:
>> Change the minimum allocation and assignment unit for all IPv4 single and
>> multi homed instances to /20. This would include:
>>
>> 4.2.1.5 Change all occurrences of /20 and /22 to /24
>> 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24.
>> Remove the example about 12 /24s.
>> 4.3.2.1 Change both occurrences of /20 to /24
>> 4.9 Change /22 to /24
>> 4.9.1 Change all instances of /22 to /24. Remove the reference to 4 /24s.
>>
>> 6.	Comments:
>> 		a.	Timetable for implementation: Immediate, possibly through board action.
>> 		b.	Anything else
>>
>> END OF TEMPLATE
>>
>>
>> _______________________________________________
>> 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.
>



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From lsawyer at gci.com  Tue Apr 29 18:17:07 2014
From: lsawyer at gci.com (Leif Sawyer)
Date: Tue, 29 Apr 2014 14:17:07 -0800
Subject: [arin-ppml] Policy Proposal: Reduce all
	Minimum	Allocation/Assignment units to /24
In-Reply-To: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102C779CCC5@fnb1mbx01.gci.com>

Support.

Let's make sure we get the end-user policy as well, though.  (Per Derek's email)



From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Tuesday, April 29, 2014 9:59 AM
To: policy at arin.net; ARIN PPML (ppml at arin.net)
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum Allocation/Assignment units to /24


Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0



  1.      Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24

  2.      Proposal Originator

         a.      name: Owen DeLong

         b.      email: owen at delong.com<mailto:owen at delong.com>

         c.      telephone: 408-890-7992

         d.      organization: Hurricane Electric

  3.      Date: 29 April, 2014

  4.      Problem Statement:

As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.

  5.      Policy statement:

Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:



4.2.1.5 Change all occurrences of /20 and /22 to /24

4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.

4.3.2.1  Change both occurrences of /20 to /24

4.9      Change /22 to /24

4.9.1    Change all instances of /22 to /24. Remove the reference to 4 /24s.



  6.      Comments:

         a.      Timetable for implementation: Immediate, possibly through board action.

         b.      Anything else



END OF TEMPLATE



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

From derekc at cnets.net  Tue Apr 29 18:17:17 2014
From: derekc at cnets.net (Derek Calanchini)
Date: Tue, 29 Apr 2014 15:17:17 -0700
Subject: [arin-ppml] Policy Proposal: Reduce all
 Minimum	Allocation/Assignment units to /24
In-Reply-To: <5360244C.80701@linuxmagic.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>	<1298483266.140015.1398808654120.JavaMail.zimbra@network1.net>
	<5360244C.80701@linuxmagic.com>
Message-ID: <536024ED.2060803@cnets.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/3fd6c09c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cnslogo1.bmp
Type: image/bmp
Size: 72774 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/3fd6c09c/attachment.bmp>

From john.sweeting at twcable.com  Tue Apr 29 18:25:13 2014
From: john.sweeting at twcable.com (Sweeting, John)
Date: Tue, 29 Apr 2014 18:25:13 -0400
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102C779CCC5@fnb1mbx01.gci.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<18B2C6E38A3A324986B392B2D18ABC5102C779CCC5@fnb1mbx01.gci.com>
Message-ID: <CF859EAF.45083%john.sweeting@twcable.com>

Hi Leif,

That is covered under 4.3.2.1.

Thanks,
John

On 4/29/14, 6:17 PM, "Leif Sawyer" <lsawyer at gci.com<mailto:lsawyer at gci.com>> wrote:

Support.

Let's make sure we get the end-user policy as well, though.  (Per Derek's email)



From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Tuesday, April 29, 2014 9:59 AM
To: policy at arin.net<mailto:policy at arin.net>; ARIN PPML (ppml at arin.net<mailto:ppml at arin.net>)
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum Allocation/Assignment units to /24


Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0



  1.      Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24

  2.      Proposal Originator

         a.      name: Owen DeLong

         b.      email: owen at delong.com<mailto:owen at delong.com>

         c.      telephone: 408-890-7992

         d.      organization: Hurricane Electric

  3.      Date: 29 April, 2014

  4.      Problem Statement:

As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.

  5.      Policy statement:

Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:



4.2.1.5 Change all occurrences of /20 and /22 to /24

4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.

4.3.2.1  Change both occurrences of /20 to /24

4.9      Change /22 to /24

4.9.1    Change all instances of /22 to /24. Remove the reference to 4 /24s.



  6.      Comments:

         a.      Timetable for implementation: Immediate, possibly through board action.

         b.      Anything else



END OF TEMPLATE


________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/14dc6ef3/attachment.htm>

From john.sweeting at twcable.com  Tue Apr 29 18:30:04 2014
From: john.sweeting at twcable.com (Sweeting, John)
Date: Tue, 29 Apr 2014 18:30:04 -0400
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <536024ED.2060803@cnets.net>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<1298483266.140015.1398808654120.JavaMail.zimbra@network1.net>
	<5360244C.80701@linuxmagic.com> <536024ED.2060803@cnets.net>
Message-ID: <CF859F11.45087%john.sweeting@twcable.com>

Hi Derek,

In a nutshell the shepherds assigned to this proposal have been asked to worked this to have it available and present it as a ?Recommended Draft Policy? at the PPC at NANOG 60. If it continues to receive the overwhelming support that it has enjoyed today then it could go to ?Last Call? following NANOG. There are a lot of moving pieces but it is definitely doable. You can contact me off list if you would like more specific information.

Thanks,
John

On 4/29/14, 6:17 PM, "Derek Calanchini" <derekc at cnets.net<mailto:derekc at cnets.net>> wrote:

So it appears this is highly supported so far, what needs to happen to move it forward?


 Best regards,

   Derek Calanchini
   Owner
   Creative Network Solutions
   Phone: 916-852-2890
   Fax: 916-852-2899

"Adopt the metric system!"

[cid:part1.04030806.08020706 at cnets.net]
On 4/29/2014 3:14 PM, Michael Peddemors wrote:
And I support.. if it wasn't clear..
I mentioned to the author that if this is tough to swallow, we should at least go down to a /22 everywhere..

(We have an application going in as well for space, and we would be returning 3 /24's back upstream on acceptance as well, it would be nicer if we didn't have to pay the expense of a second upstream provider.  So I also 'support' getting the board involved to expedite this)

On 14-04-29 02:57 PM, Randy Carpenter wrote:

I support.

I would want to make sure that someone who needs more than a /24, could still get what they need immediately rather than only getting a /24 (as long as what they need is available). I have worked with several entities that are single-homed, and are using a /22, but need a /21, or are using a /23 and need a /22. They are all unable to get additional space form their upstream. Allowing them to get what they need from ARIN would allow them to return the old space to their upstream. It would benefit all.


thanks,
-Randy


----- Original Message -----
Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0

    1.    Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to
    /24
    2.    Proposal Originator
        a.    name: Owen DeLong
        b.    email: owen at delong.com<mailto:owen at delong.com> c.    telephone: 408-890-7992
        d.    organization: Hurricane Electric
    3.    Date: 29 April, 2014
    4.    Problem Statement:
As we approach runout, more and more end users and smaller ISPs will be
unable to obtain space from their upstreams and will be seeking space from
ARIN. In order to meet these needs to the extent possible and to make policy
more fair to a broader range of the ARIN constituency, we should reduce the
minimum assignment and allocation units to /24 across the board.
5.    Policy statement:
Change the minimum allocation and assignment unit for all IPv4 single and
multi homed instances to /20. This would include:

4.2.1.5 Change all occurrences of /20 and /22 to /24
4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24.
Remove the example about 12 /24s.
4.3.2.1 Change both occurrences of /20 to /24
4.9 Change /22 to /24
4.9.1 Change all instances of /22 to /24. Remove the reference to 4 /24s.

6.    Comments:
        a.    Timetable for implementation: Immediate, possibly through board action.
        b.    Anything else

END OF TEMPLATE


_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto: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<mailto: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<mailto:info at arin.net> if you experience any issues.







________________________________
[http://static.avast.com/emails/avast-mail-stamp.png]<http://www.avast.com/>

This email is free from viruses and malware because avast! Antivirus<http://www.avast.com/> protection is active.



________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/d186a322/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cnslogo1.bmp
Type: image/bmp
Size: 72774 bytes
Desc: cnslogo1.bmp
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/d186a322/attachment.bmp>

From michael at linuxmagic.com  Tue Apr 29 19:07:48 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Tue, 29 Apr 2014 16:07:48 -0700
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <CF859F11.45087%john.sweeting@twcable.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>	<1298483266.140015.1398808654120.JavaMail.zimbra@network1.net>	<5360244C.80701@linuxmagic.com>
	<536024ED.2060803@cnets.net>
	<CF859F11.45087%john.sweeting@twcable.com>
Message-ID: <536030C4.5070705@linuxmagic.com>

Derek,

Just FYI, this is something that you might consider being 'fast tracked' 
by the supporters..

"NANOG 61 is traveling to Bellevue, Washington for the second time!
,,,,,
NANOG 61 takes place on June 2-4, 2014 and will offer a great 
opportunity to network with colleagues, freshen-up skills, learn 
advanced networking techniques, and discover new network applications. 
NANOG 61 will be hosted by our Premium Sponsor"

So, this could happen very soon..


On 14-04-29 03:30 PM, Sweeting, John wrote:
> Hi Derek,
>
> In a nutshell the shepherds assigned to this proposal have been asked to
> worked this to have it available and present it as a ?Recommended Draft
> Policy? at the PPC at NANOG 60. If it continues to receive the
> overwhelming support that it has enjoyed today then it could go to ?Last
> Call? following NANOG. There are a lot of moving pieces but it is
> definitely doable. You can contact me off list if you would like more
> specific information.
>
> Thanks,
> John
>
> On 4/29/14, 6:17 PM, "Derek Calanchini" <derekc at cnets.net
> <mailto:derekc at cnets.net>> wrote:
>
>     So it appears this is highly supported so far, what needs to happen
>     to move it forward?
>
>
>       Best regards,
>
>         Derek Calanchini
>         Owner
>         Creative Network Solutions
>         Phone: 916-852-2890
>         Fax: 916-852-2899
>
>     "Adopt the metric system!"
>
>     CNS LOGO
>     On 4/29/2014 3:14 PM, Michael Peddemors wrote:
>>     And I support.. if it wasn't clear..
>>     I mentioned to the author that if this is tough to swallow, we
>>     should at least go down to a /22 everywhere..
>>
>>     (We have an application going in as well for space, and we would
>>     be returning 3 /24's back upstream on acceptance as well, it would
>>     be nicer if we didn't have to pay the expense of a second upstream
>>     provider.  So I also 'support' getting the board involved to
>>     expedite this)
>>
>>     On 14-04-29 02:57 PM, Randy Carpenter wrote:
>>>
>>>     I support.
>>>
>>>     I would want to make sure that someone who needs more than a /24,
>>>     could still get what they need immediately rather than only
>>>     getting a /24 (as long as what they need is available). I have
>>>     worked with several entities that are single-homed, and are using
>>>     a /22, but need a /21, or are using a /23 and need a /22. They
>>>     are all unable to get additional space form their upstream.
>>>     Allowing them to get what they need from ARIN would allow them to
>>>     return the old space to their upstream. It would benefit all.
>>>
>>>
>>>     thanks,
>>>     -Randy
>>>
>>>
>>>     ----- Original Message -----
>>>>     Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>>>>
>>>>         1.    Policy Proposal Name: Reduce all Minimum
>>>>     Allocation/Assignment units to
>>>>         /24
>>>>         2.    Proposal Originator
>>>>             a.    name: Owen DeLong
>>>>             b.    email: owen at delong.com c.    telephone: 408-890-7992
>>>>             d.    organization: Hurricane Electric
>>>>         3.    Date: 29 April, 2014
>>>>         4.    Problem Statement:
>>>>     As we approach runout, more and more end users and smaller ISPs
>>>>     will be
>>>>     unable to obtain space from their upstreams and will be seeking
>>>>     space from
>>>>     ARIN. In order to meet these needs to the extent possible and to
>>>>     make policy
>>>>     more fair to a broader range of the ARIN constituency, we should
>>>>     reduce the
>>>>     minimum assignment and allocation units to /24 across the board.
>>>>     5.    Policy statement:
>>>>     Change the minimum allocation and assignment unit for all IPv4
>>>>     single and
>>>>     multi homed instances to /20. This would include:
>>>>
>>>>     4.2.1.5 Change all occurrences of /20 and /22 to /24
>>>>     4.2.2.1.1 Change all occurrences of /20 to /24, and change 16
>>>>     /24s to 1 /24.
>>>>     Remove the example about 12 /24s.
>>>>     4.3.2.1 Change both occurrences of /20 to /24
>>>>     4.9 Change /22 to /24
>>>>     4.9.1 Change all instances of /22 to /24. Remove the reference
>>>>     to 4 /24s.
>>>>
>>>>     6.    Comments:
>>>>             a.    Timetable for implementation: Immediate, possibly
>>>>     through board action.
>>>>             b.    Anything else
>>>>
>>>>     END OF TEMPLATE
>>>>
>>>>
>>>>     _______________________________________________
>>>>     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.
>>>
>>
>>
>>
>
>
>
>     ------------------------------------------------------------------------
>     <http://www.avast.com/> 	
>
>     This email is free from viruses and malware because avast! Antivirus
>     <http://www.avast.com/> protection is active.
>
>
>
> ------------------------------------------------------------------------
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject
> to copyright belonging to Time Warner Cable. This E-mail is intended
> solely for the use of the individual or entity to which it is addressed.
> If you are not the intended recipient of this E-mail, you are hereby
> notified that any dissemination, distribution, copying, or action taken
> in relation to the contents of and attachments to this E-mail is
> strictly prohibited and may be unlawful. If you have received this
> E-mail in error, please notify the sender immediately and permanently
> delete the original and any copy of this E-mail and any printout.
>
>
> _______________________________________________
> 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.
>



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From john.sweeting at twcable.com  Tue Apr 29 19:44:32 2014
From: john.sweeting at twcable.com (Sweeting, John)
Date: Tue, 29 Apr 2014 19:44:32 -0400
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <536030C4.5070705@linuxmagic.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<1298483266.140015.1398808654120.JavaMail.zimbra@network1.net>
	<5360244C.80701@linuxmagic.com> <536024ED.2060803@cnets.net>
	<CF859F11.45087%john.sweeting@twcable.com>
	<536030C4.5070705@linuxmagic.com>
Message-ID: <08CF880A-533A-4BFF-AA29-9DBF8C836217@twcable.com>

Yes I meant 61, sorry

Sent from my iPhone

> On Apr 29, 2014, at 7:07 PM, "Michael Peddemors" <michael at linuxmagic.com> wrote:
>
> Derek,
>
> Just FYI, this is something that you might consider being 'fast tracked'
> by the supporters..
>
> "NANOG 61 is traveling to Bellevue, Washington for the second time!
> ,,,,,
> NANOG 61 takes place on June 2-4, 2014 and will offer a great
> opportunity to network with colleagues, freshen-up skills, learn
> advanced networking techniques, and discover new network applications.
> NANOG 61 will be hosted by our Premium Sponsor"
>
> So, this could happen very soon..
>
>
>> On 14-04-29 03:30 PM, Sweeting, John wrote:
>> Hi Derek,
>>
>> In a nutshell the shepherds assigned to this proposal have been asked to
>> worked this to have it available and present it as a ?Recommended Draft
>> Policy? at the PPC at NANOG 60. If it continues to receive the
>> overwhelming support that it has enjoyed today then it could go to ?Last
>> Call? following NANOG. There are a lot of moving pieces but it is
>> definitely doable. You can contact me off list if you would like more
>> specific information.
>>
>> Thanks,
>> John
>>
>> On 4/29/14, 6:17 PM, "Derek Calanchini" <derekc at cnets.net
>> <mailto:derekc at cnets.net>> wrote:
>>
>>    So it appears this is highly supported so far, what needs to happen
>>    to move it forward?
>>
>>
>>      Best regards,
>>
>>        Derek Calanchini
>>        Owner
>>        Creative Network Solutions
>>        Phone: 916-852-2890
>>        Fax: 916-852-2899
>>
>>    "Adopt the metric system!"
>>
>>    CNS LOGO
>>>    On 4/29/2014 3:14 PM, Michael Peddemors wrote:
>>>    And I support.. if it wasn't clear..
>>>    I mentioned to the author that if this is tough to swallow, we
>>>    should at least go down to a /22 everywhere..
>>>
>>>    (We have an application going in as well for space, and we would
>>>    be returning 3 /24's back upstream on acceptance as well, it would
>>>    be nicer if we didn't have to pay the expense of a second upstream
>>>    provider.  So I also 'support' getting the board involved to
>>>    expedite this)
>>>
>>>>    On 14-04-29 02:57 PM, Randy Carpenter wrote:
>>>>
>>>>    I support.
>>>>
>>>>    I would want to make sure that someone who needs more than a /24,
>>>>    could still get what they need immediately rather than only
>>>>    getting a /24 (as long as what they need is available). I have
>>>>    worked with several entities that are single-homed, and are using
>>>>    a /22, but need a /21, or are using a /23 and need a /22. They
>>>>    are all unable to get additional space form their upstream.
>>>>    Allowing them to get what they need from ARIN would allow them to
>>>>    return the old space to their upstream. It would benefit all.
>>>>
>>>>
>>>>    thanks,
>>>>    -Randy
>>>>
>>>>
>>>>    ----- Original Message -----
>>>>>    Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>>>>>
>>>>>        1.    Policy Proposal Name: Reduce all Minimum
>>>>>    Allocation/Assignment units to
>>>>>        /24
>>>>>        2.    Proposal Originator
>>>>>            a.    name: Owen DeLong
>>>>>            b.    email: owen at delong.com c.    telephone: 408-890-7992
>>>>>            d.    organization: Hurricane Electric
>>>>>        3.    Date: 29 April, 2014
>>>>>        4.    Problem Statement:
>>>>>    As we approach runout, more and more end users and smaller ISPs
>>>>>    will be
>>>>>    unable to obtain space from their upstreams and will be seeking
>>>>>    space from
>>>>>    ARIN. In order to meet these needs to the extent possible and to
>>>>>    make policy
>>>>>    more fair to a broader range of the ARIN constituency, we should
>>>>>    reduce the
>>>>>    minimum assignment and allocation units to /24 across the board.
>>>>>    5.    Policy statement:
>>>>>    Change the minimum allocation and assignment unit for all IPv4
>>>>>    single and
>>>>>    multi homed instances to /20. This would include:
>>>>>
>>>>>    4.2.1.5 Change all occurrences of /20 and /22 to /24
>>>>>    4.2.2.1.1 Change all occurrences of /20 to /24, and change 16
>>>>>    /24s to 1 /24.
>>>>>    Remove the example about 12 /24s.
>>>>>    4.3.2.1 Change both occurrences of /20 to /24
>>>>>    4.9 Change /22 to /24
>>>>>    4.9.1 Change all instances of /22 to /24. Remove the reference
>>>>>    to 4 /24s.
>>>>>
>>>>>    6.    Comments:
>>>>>            a.    Timetable for implementation: Immediate, possibly
>>>>>    through board action.
>>>>>            b.    Anything else
>>>>>
>>>>>    END OF TEMPLATE
>>>>>
>>>>>
>>>>>    _______________________________________________
>>>>>    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.
>>
>>
>>
>>    ------------------------------------------------------------------------
>>    <http://www.avast.com/>
>>
>>    This email is free from viruses and malware because avast! Antivirus
>>    <http://www.avast.com/> protection is active.
>>
>>
>>
>> ------------------------------------------------------------------------
>> This E-mail and any of its attachments may contain Time Warner Cable
>> proprietary information, which is privileged, confidential, or subject
>> to copyright belonging to Time Warner Cable. This E-mail is intended
>> solely for the use of the individual or entity to which it is addressed.
>> If you are not the intended recipient of this E-mail, you are hereby
>> notified that any dissemination, distribution, copying, or action taken
>> in relation to the contents of and attachments to this E-mail is
>> strictly prohibited and may be unlawful. If you have received this
>> E-mail in error, please notify the sender immediately and permanently
>> delete the original and any copy of this E-mail and any printout.
>>
>>
>> _______________________________________________
>> 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.
>
>
>
> --
> "Catch the Magic of Linux..."
> ------------------------------------------------------------------------
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> ------------------------------------------------------------------------
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> ------------------------------------------------------------------------
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
> _______________________________________________
> 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.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

From mysidia at gmail.com  Tue Apr 29 20:13:11 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 29 Apr 2014 19:13:11 -0500
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
Message-ID: <CAAAwwbU5ey6XzBvSxzt2RxANdkAPWTAG3ON+wk_6UuQKKn3Leg@mail.gmail.com>

On Tue, Apr 29, 2014 at 12:58 PM, Owen DeLong <owen at delong.com> wrote:

I support the proposed change as written.

In addition,  since Multihomed ISPs no longer have a different minimum
allocation, I suggest    removing the distinction between Multihomed
and non-Multihomed ISPs:

   o 4.2.1.5     Delete the sentence that says "For multihomed ISPs...."
   Remove multi-homed distinction and requirements for initial
allocations to ISPs.
      o Delete section  4.2.2.1  Standard or non-multihomed  and subsections.

      o Rename section 4.2.2.2 to  remove references to Multihomed

Prepend     "When requesting a  /24,  demonstrate the efficient
utilization of a minimum contiguous or non-contiguous  /27  (two /28s)
from an upstream."

[Regardless if multihomed or not]



> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>
> 1. Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to
> /24
> 2. Proposal Originator
> a. name: Owen DeLong
> b. email: owen at delong.com
> c. telephone: 408-890-7992
> d. organization: Hurricane Electric
> 3. Date: 29 April, 2014
> 4. Problem Statement:
>
> As we approach runout, more and more end users and smaller ISPs will be
> unable to obtain space from their upstreams and will be seeking space from
> ARIN. In order to meet these needs to the extent possible and to make policy
> more fair to a broader range of the ARIN constituency, we should reduce the
> minimum assignment and allocation units to /24 across the board.
>
> 5. Policy statement:
>
> Change the minimum allocation and assignment unit for all IPv4 single and
> multi homed instances to /20. This would include:
>
>
> 4.2.1.5 Change all occurrences of /20 and /22 to /24
>
> 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24.
> Remove the example about 12 /24s.
>
> 4.3.2.1 Change both occurrences of /20 to /24
>
> 4.9 Change /22 to /24
>
> 4.9.1 Change all instances of /22 to /24. Remove the reference to 4 /24s.
>
>
> 6. Comments:
> a. Timetable for implementation: Immediate, possibly through board action.
> b. Anything else
>
> END OF TEMPLATE
>
>
>
> _______________________________________________
> 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.



-- 
-JH


From hannigan at gmail.com  Tue Apr 29 20:15:49 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 29 Apr 2014 20:15:49 -0400
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <CAAAwwbU5ey6XzBvSxzt2RxANdkAPWTAG3ON+wk_6UuQKKn3Leg@mail.gmail.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<CAAAwwbU5ey6XzBvSxzt2RxANdkAPWTAG3ON+wk_6UuQKKn3Leg@mail.gmail.com>
Message-ID: <CAMDXq5P23TN_1EPxwTN+rXO+bSqOTsLt9BbzJEyve5X_PJcrGw@mail.gmail.com>

Owens change is simple and fast. Meddling beyond that is asking for
trouble.  It's a no op. Leave it alone.

Bring that to the PPC at NANOG and this is dead.





On Tuesday, April 29, 2014, Jimmy Hess <mysidia at gmail.com> wrote:

> On Tue, Apr 29, 2014 at 12:58 PM, Owen DeLong <owen at delong.com<javascript:;>>
> wrote:
>
> I support the proposed change as written.
>
> In addition,  since Multihomed ISPs no longer have a different minimum
> allocation, I suggest    removing the distinction between Multihomed
> and non-Multihomed ISPs:
>
>    o 4.2.1.5     Delete the sentence that says "For multihomed ISPs...."
>    Remove multi-homed distinction and requirements for initial
> allocations to ISPs.
>       o Delete section  4.2.2.1  Standard or non-multihomed  and
> subsections.
>
>       o Rename section 4.2.2.2 to  remove references to Multihomed
>
> Prepend     "When requesting a  /24,  demonstrate the efficient
> utilization of a minimum contiguous or non-contiguous  /27  (two /28s)
> from an upstream."
>
> [Regardless if multihomed or not]
>
>
>
> > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
> >
> > 1. Policy Proposal Name: Reduce all Minimum Allocation/Assignment units
> to
> > /24
> > 2. Proposal Originator
> > a. name: Owen DeLong
> > b. email: owen at delong.com <javascript:;>
> > c. telephone: 408-890-7992
> > d. organization: Hurricane Electric
> > 3. Date: 29 April, 2014
> > 4. Problem Statement:
> >
> > As we approach runout, more and more end users and smaller ISPs will be
> > unable to obtain space from their upstreams and will be seeking space
> from
> > ARIN. In order to meet these needs to the extent possible and to make
> policy
> > more fair to a broader range of the ARIN constituency, we should reduce
> the
> > minimum assignment and allocation units to /24 across the board.
> >
> > 5. Policy statement:
> >
> > Change the minimum allocation and assignment unit for all IPv4 single and
> > multi homed instances to /20. This would include:
> >
> >
> > 4.2.1.5 Change all occurrences of /20 and /22 to /24
> >
> > 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1
> /24.
> > Remove the example about 12 /24s.
> >
> > 4.3.2.1 Change both occurrences of /20 to /24
> >
> > 4.9 Change /22 to /24
> >
> > 4.9.1 Change all instances of /22 to /24. Remove the reference to 4 /24s.
> >
> >
> > 6. Comments:
> > a. Timetable for implementation: Immediate, possibly through board
> action.
> > b. Anything else
> >
> > END OF TEMPLATE
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net <javascript:;> if you experience any
> issues.
>
>
>
> --
> -JH
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/561857f1/attachment.htm>

From derekc at cnets.net  Tue Apr 29 21:13:04 2014
From: derekc at cnets.net (Derek Calanchini)
Date: Tue, 29 Apr 2014 18:13:04 -0700
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <CAMDXq5P23TN_1EPxwTN+rXO+bSqOTsLt9BbzJEyve5X_PJcrGw@mail.gmail.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>	<CAAAwwbU5ey6XzBvSxzt2RxANdkAPWTAG3ON+wk_6UuQKKn3Leg@mail.gmail.com>
	<CAMDXq5P23TN_1EPxwTN+rXO+bSqOTsLt9BbzJEyve5X_PJcrGw@mail.gmail.com>
Message-ID: <53604E20.4020503@cnets.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/74e56a5a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cnslogo1.bmp
Type: image/bmp
Size: 72774 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140429/74e56a5a/attachment.bmp>

From David.Huberman at microsoft.com  Tue Apr 29 21:45:42 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Wed, 30 Apr 2014 01:45:42 +0000
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <53604E20.4020503@cnets.net>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<CAAAwwbU5ey6XzBvSxzt2RxANdkAPWTAG3ON+wk_6UuQKKn3Leg@mail.gmail.com>
	<CAMDXq5P23TN_1EPxwTN+rXO+bSqOTsLt9BbzJEyve5X_PJcrGw@mail.gmail.com>,
	<53604E20.4020503@cnets.net>
Message-ID: <aa681e3571a147b281b4a8842ebdc532@DM2PR03MB398.namprd03.prod.outlook.com>

Derek,



Marty can be a bit gruff - it's part of his charm :)  He's actually trying very hard to help you achieve your goals.  His observation you quoted is borne of wisdom of dealing with the policy process for many years.   Some may agree, or may not agree.  I happened to agree strongly with him.



Owen's proposal, without modifications (or at least, not the one proposed so far), has the best chance of succeeding, and doing so quickly.



Just my opinion.



/david

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)
________________________________
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of Derek Calanchini <derekc at cnets.net>
Sent: Tuesday, April 29, 2014 6:13 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Reduce all Minimum Allocation/Assignment units to /24

Martin,

You seem very negative about this, disagreeing for the sake of disagreeing is counter productive.  Perhaps you could explain your concerns giving actual reasons, potential fallout, issues, etc in the hopes of making it better....

 Best regards,

   Derek Calanchini
   Owner
   Creative Network Solutions
   Phone: 916-852-2890
   Fax: 916-852-2899

"Adopt the metric system!"

[CNS LOGO]
On 4/29/2014 5:15 PM, Martin Hannigan wrote:

Owens change is simple and fast. Meddling beyond that is asking for trouble.  It's a no op. Leave it alone.

Bring that to the PPC at NANOG and this is dead.





On Tuesday, April 29, 2014, Jimmy Hess <mysidia at gmail.com<mailto:mysidia at gmail.com>> wrote:
On Tue, Apr 29, 2014 at 12:58 PM, Owen DeLong <owen at delong.com> wrote:

I support the proposed change as written.

In addition,  since Multihomed ISPs no longer have a different minimum
allocation, I suggest    removing the distinction between Multihomed
and non-Multihomed ISPs:

   o 4.2.1.5     Delete the sentence that says "For multihomed ISPs...."
   Remove multi-homed distinction and requirements for initial
allocations to ISPs.
      o Delete section  4.2.2.1  Standard or non-multihomed  and subsections.

      o Rename section 4.2.2.2 to  remove references to Multihomed

Prepend     "When requesting a  /24,  demonstrate the efficient
utilization of a minimum contiguous or non-contiguous  /27  (two /28s)
from an upstream."

[Regardless if multihomed or not]



> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>
> 1. Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to
> /24
> 2. Proposal Originator
> a. name: Owen DeLong
> b. email: owen at delong.com
> c. telephone: 408-890-7992
> d. organization: Hurricane Electric
> 3. Date: 29 April, 2014
> 4. Problem Statement:
>
> As we approach runout, more and more end users and smaller ISPs will be
> unable to obtain space from their upstreams and will be seeking space from
> ARIN. In order to meet these needs to the extent possible and to make policy
> more fair to a broader range of the ARIN constituency, we should reduce the
> minimum assignment and allocation units to /24 across the board.
>
> 5. Policy statement:
>
> Change the minimum allocation and assignment unit for all IPv4 single and
> multi homed instances to /20. This would include:
>
>
> 4.2.1.5 Change all occurrences of /20 and /22 to /24
>
> 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24.
> Remove the example about 12 /24s.
>
> 4.3.2.1 Change both occurrences of /20 to /24
>
> 4.9 Change /22 to /24
>
> 4.9.1 Change all instances of /22 to /24. Remove the reference to 4 /24s.
>
>
> 6. Comments:
> a. Timetable for implementation: Immediate, possibly through board action.
> b. Anything else
>
> END OF TEMPLATE
>
>
>
> _______________________________________________
> 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.



--
-JH
_______________________________________________
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<mailto: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<mailto:info at arin.net> if you experience any issues.



________________________________
[http://static.avast.com/emails/avast-mail-stamp.png] <http://www.avast.com/>

This email is free from viruses and malware because avast! Antivirus<http://www.avast.com/> protection is active.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/6d172f9f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cnslogo1.bmp
Type: image/bmp
Size: 72774 bytes
Desc: cnslogo1.bmp
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/6d172f9f/attachment.bmp>

From mike at nationwideinc.com  Wed Apr 30 10:07:10 2014
From: mike at nationwideinc.com (Mike Burns)
Date: Wed, 30 Apr 2014 10:07:10 -0400
Subject: [arin-ppml] Policy Proposal:
	ReduceallMinimum	Allocation/Assignment units to /24
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201529ABCFF@ENI-MAIL.eclipse-networks.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com><968C470DAC25FB419E0159952F28F0C06A766503@MEM0200CP3XF04.ds.irsnet.gov>
	<5B9E90747FA2974D91A54FCFA1B8AD1201529ABCFF@ENI-MAIL.eclipse-networks.com>
Message-ID: <D6D2FFD7D56B49AC825252216A717D4E@MPC>

Support. We are seeing IPv4 buyers approach us for small blocks due to an inability to get them from upstream providers.

Mike Burns
IPTrading.com

From: Steven Ryerse 
Sent: Tuesday, April 29, 2014 5:35 PM
To: policy at arin.net ; mailto:ppml at arin.net 
Subject: Re: [arin-ppml] Policy Proposal: ReduceallMinimum Allocation/Assignment units to /24

I support this proposal!!!

 

Steven Ryerse

President

100 Ashford Center North, Suite 110, Atlanta, GA  30338

770.656.1460 - Cell

770.399.9099- Office

 

? Eclipse Networks, Inc.

        Conquering Complex Networks?

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Tuesday, April 29, 2014 12:59 PM
To: policy at arin.net; ARIN PPML (ppml at arin.net)
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum Allocation/Assignment units to /24

 

Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0         1.      Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24        2.      Proposal Originator                a.      name: Owen DeLong               b.      email: owen at delong.com               c.      telephone: 408-890-7992               d.      organization: Hurricane Electric        3.      Date: 29 April, 2014        4.      Problem Statement: As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.        5.      Policy statement:Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include: 4.2.1.5 Change all occurrences of /20 and /22 to /244.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.4.3.2.1 Change both occurrences of /20 to /244.9     Change /22 to /244.9.1   Change all instances of /22 to /24. Remove the reference to 4 /24s.         6.      Comments:               a.      Timetable for implementation: Immediate, possibly through board action.               b.      Anything else END OF TEMPLATE  



--------------------------------------------------------------------------------
_______________________________________________
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/20140430/07a60eaa/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/07a60eaa/attachment.jpg>

From tcoffeen at infoblox.com  Wed Apr 30 10:22:57 2014
From: tcoffeen at infoblox.com (Tom Coffeen)
Date: Wed, 30 Apr 2014 14:22:57 +0000
Subject: [arin-ppml] Policy Proposal: Reduce all
	Minimum	Allocation/Assignment units to /24
In-Reply-To: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
Message-ID: <A3D10927-7080-43F3-BF43-CDBC9F195B3E@infoblox.com>

Support.

-------------------
Tom Coffeen
IPv6 Evangelist
Infoblox | Business Agility through Network Automation
(T) +1-408-986-5562 (M) +1-602-810-3343
tcoffeen at infoblox.com<mailto:tcoffeen at infoblox.com>  |  www.infoblox.com<http://www.infoblox.com/>

[cid:B13F52AD-9074-4FDC-BF65-F677FFD29EA4 at inca.infoblox.com]

On Apr 29, 2014, at 10:58 AM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:


Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0

        1.      Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24
        2.      Proposal Originator
                a.      name: Owen DeLong
                b.      email: owen at delong.com<mailto:owen at delong.com>
                c.      telephone: 408-890-7992
                d.      organization: Hurricane Electric
        3.      Date: 29 April, 2014
        4.      Problem Statement:

As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.

        5.      Policy statement:

Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:


4.2.1.5 Change all occurrences of /20 and /22 to /24

4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.

4.3.2.1 Change both occurrences of /20 to /24

4.9     Change /22 to /24

4.9.1   Change all instances of /22 to /24. Remove the reference to 4 /24s.


        6.      Comments:
                a.      Timetable for implementation: Immediate, possibly through board action.
                b.      Anything else

END OF TEMPLATE


_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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/20140430/6954885e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 34708 bytes
Desc: image002.png
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/6954885e/attachment.png>

From jeffrey.lyon at blacklotus.net  Wed Apr 30 10:49:20 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Wed, 30 Apr 2014 23:49:20 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating utilization
Message-ID: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>

Friends, Colleagues,

A couple of years ago I brought up an issue I had run into where the
utilization requirement for new requests is being calculated on a per
allocation basis rather than in aggregate. For example, if an
organization has 4 x /22 and 3 of them are utilized 100% and the
fourth utilized at 75%, that request would be denied. This is a bit
out of balance as an organization with a single /20 utilized at 80%
would have less efficient utilization but would be eligible to request
additional space.

The last time this was discussed it sounded as if the community would
support a policy proposal to change this calculation to be considered
in aggregate vs. per assignment. Does this remain the case?

Thanks,
-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From contact at winterei.se  Wed Apr 30 10:51:13 2014
From: contact at winterei.se (Paul S.)
Date: Wed, 30 Apr 2014 23:51:13 +0900
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <A3D10927-7080-43F3-BF43-CDBC9F195B3E@infoblox.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<A3D10927-7080-43F3-BF43-CDBC9F195B3E@infoblox.com>
Message-ID: <53610DE1.1060405@winterei.se>

Support.

On 4/30/2014 ?? 11:22, Tom Coffeen wrote:
> Support.
>
> *-------------------*
> *Tom Coffeen*
> IPv6 Evangelist
> Infoblox | Business Agility through Network Automation
> (T) +1-408-986-5562 (M) +1-602-810-3343
> tcoffeen at infoblox.com <mailto:tcoffeen at infoblox.com>  | 
> www.infoblox.com <http://www.infoblox.com/>
>
>
> On Apr 29, 2014, at 10:58 AM, Owen DeLong <owen at delong.com 
> <mailto:owen at delong.com>> wrote:
>
>> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>>
>> 	1.	Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24
>> 	2.	Proposal Originator
>> 		a.	name: Owen DeLong
>> 		b.	email:owen at delong.com  <mailto:owen at delong.com>
>> 		c.	telephone: 408-890-7992
>> 		d.	organization: Hurricane Electric
>> 	3.	Date: 29 April, 2014
>> 	4.	Problem Statement:
>> As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.
>> 	5.	Policy statement:
>> Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:
>> 4.2.1.5 Change all occurrences of /20 and /22 to /24
>> 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.
>> 4.3.2.1	Change both occurrences of /20 to /24
>> 4.9	Change /22 to /24
>> 4.9.1	Change all instances of /22 to /24. Remove the reference to 4 /24s.
>> 	6.	Comments:
>> 		a.	Timetable for implementation: Immediate, possibly through board action.
>> 		b.	Anything else
>>
>> END OF TEMPLATE
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net 
>> <mailto: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/20140430/97879e64/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 34708 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/97879e64/attachment.png>

From stu at actusa.net  Wed Apr 30 11:41:05 2014
From: stu at actusa.net (Stuart Sheldon)
Date: Wed, 30 Apr 2014 08:41:05 -0700
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <53610DE1.1060405@winterei.se>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>	<A3D10927-7080-43F3-BF43-CDBC9F195B3E@infoblox.com>
	<53610DE1.1060405@winterei.se>
Message-ID: <53611991.4060807@actusa.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Support

Stuart Sheldon
ACT USA
AS22937


On 04/30/2014 07:51 AM, Paul S. wrote:
> Support.
> 
> On 4/30/2014 ?? 11:22, Tom Coffeen wrote:
>> Support.
>>
>> *-------------------*
>> *Tom Coffeen*
>> IPv6 Evangelist
>> Infoblox | Business Agility through Network Automation
>> (T) +1-408-986-5562 (M) +1-602-810-3343
>> tcoffeen at infoblox.com <mailto:tcoffeen at infoblox.com> 
>> |  www.infoblox.com <http://www.infoblox.com/>
>>
>>
>> On Apr 29, 2014, at 10:58 AM, Owen DeLong <owen at delong.com
>> <mailto:owen at delong.com>> wrote:
>>
>>> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>>>
>>> 	1.	Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24
>>> 	2.	Proposal Originator 
>>> 		a.	name: Owen DeLong
>>> 		b.	email: owen at delong.com <mailto:owen at delong.com>
>>> 		c.	telephone: 408-890-7992
>>> 		d.	organization: Hurricane Electric
>>> 	3.	Date: 29 April, 2014
>>> 	4.	Problem Statement: 
>>> As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.
>>> 	5.	Policy statement:
>>> Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:
>>> 4.2.1.5 Change all occurrences of /20 and /22 to /24
>>> 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.
>>> 4.3.2.1	Change both occurrences of /20 to /24
>>> 4.9	Change /22 to /24
>>> 4.9.1	Change all instances of /22 to /24. Remove the reference to 4 /24s.
>>> 	6.	Comments:
>>> 		a.	Timetable for implementation: Immediate, possibly through board action.
>>> 		b.	Anything else
>>>
>>> END OF TEMPLATE 
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>>> <mailto: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.
> 

- -- 
Poets tell how Pancho fell, and Lefty's living in a cheap hotel
The desert's quiet and Cleveland's cold, And so the story ends we're told
Pancho needs your prayers it's true, but save a few for Lefty too
He only did what he had to do, and now he's growing old.
     -- Willie Nelson and Merle Haggart "Pancho and Lefty"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJTYRmRAAoJEFKVLITDJSGSXeQQALH4JQd/dS29QX3A11TdRNR7
RLh2fGdMnLXxrUq3pU+aq+0tFZK4lIkcSEIoS4RQuDpMe4sLeezmz8OIuqVVc9Gx
bmBaL4UiJJhxKhgf7ntOGH/LYDSLNeX2vxRL7nnr3mw3LOyOjrbB++RqtQS0me+f
FjlkM/jQEwFrXW3cxB1/X0mxPa1zwIVVSUzYc4h/Ld9rogAGHpZGN+2DItUV72Oa
Qi/5LwC9JSnxEGAmDqgoHGXVtnDMatW8onUolR8xU4koeWadaUPNUehdWA+ZmI7o
lnADt7N1wMQXEBNYg8B24og6btopReqwd4Z9AfwFJ5V45JC/3MSpkUqnN4rSzGHU
KIflfjIqIkGccM58UIWCSe/3HGFFJYRAcqnX/80eHsiaaQvLfEioEdpYcpDmKgr4
oIFhfXVaXJ1Ov+tuzDJrX22IXEhbBaLLtQ4V3N+Jjl9BKxFnZ7P3GLkEiLVYSG/t
6L4FyPriLikgKgzj0C3a7/K9br5L1svSxYEvH8YBLh3Y7HdOnkfhe7gbEUd36/49
uLBSFYqf86FbSwLdEt+z5OCsqCRus8UfGWven7MbYVSyNMJk+REwDfhtUObdem8V
E8bj6qEyqY5hatEJToBweNm7xPJLOVaP38gkyydhWAOIWQUDm47IiG9adv1L7w+r
ntj41qjyXsNs0sZ0JOkh
=QkRu
-----END PGP SIGNATURE-----


From scottleibrand at gmail.com  Wed Apr 30 11:44:57 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 30 Apr 2014 08:44:57 -0700
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
Message-ID: <CAGkMwz6BayBeio+J6pNOZj1T3Aumikpv0C05N=p9Gk5jCwoqTA@mail.gmail.com>

This seems to me like a reasonable operational practice for ARIN to use
to help prevent a run on the remaining free pool from organizations with
large quantities of existing space.

Are you trying to change this before free pool runout, or are you concerned
with making needs justification a bit easier for transfers once the free
pool is exhausted? I would support the latter, but not the former.

-Scott

On Wednesday, April 30, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
wrote:

> Friends, Colleagues,
>
> A couple of years ago I brought up an issue I had run into where the
> utilization requirement for new requests is being calculated on a per
> allocation basis rather than in aggregate. For example, if an
> organization has 4 x /22 and 3 of them are utilized 100% and the
> fourth utilized at 75%, that request would be denied. This is a bit
> out of balance as an organization with a single /20 utilized at 80%
> would have less efficient utilization but would be eligible to request
> additional space.
>
> The last time this was discussed it sounded as if the community would
> support a policy proposal to change this calculation to be considered
> in aggregate vs. per assignment. Does this remain the case?
>
> Thanks,
> --
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com <javascript:;> |
> skype: blacklotus.net
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
>


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

From jeffrey.lyon at blacklotus.net  Wed Apr 30 11:50:41 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Thu, 1 May 2014 00:50:41 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CAGkMwz6BayBeio+J6pNOZj1T3Aumikpv0C05N=p9Gk5jCwoqTA@mail.gmail.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
	<CAGkMwz6BayBeio+J6pNOZj1T3Aumikpv0C05N=p9Gk5jCwoqTA@mail.gmail.com>
Message-ID: <CACrmG8eQ2428=ekW0iBozwM=SCvPZTHMNLcb40wGYP2zsusJGw@mail.gmail.com>

Scott,

In my mind this does not have anything to do with free pool or
transfers, rather it is a measure to save time both for the applicant
and ARIN and to fix a disparity between how small organizations
request space versus large. Right now it is easier for organizations
with large allocations to request space. It is very difficult to make
sure every single small allocation is justified to 80% vs. doing the
same if you only had one or two very large allocations. What happens
in practice is that a smaller organization with many small allocations
(eg. /21 and /22) will have to individually justify every assignment
which may put their utilization at 90%+ before they're allowed to
request space where a larger organization will never run into this
problem.

This is something I brought up in 2011 (iirc).

Thanks, Jeff

On Thu, May 1, 2014 at 12:44 AM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> This seems to me like a reasonable operational practice for ARIN to use to
> help prevent a run on the remaining free pool from organizations with large
> quantities of existing space.
>
> Are you trying to change this before free pool runout, or are you concerned
> with making needs justification a bit easier for transfers once the free
> pool is exhausted? I would support the latter, but not the former.
>
> -Scott
>
>
> On Wednesday, April 30, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
> wrote:
>>
>> Friends, Colleagues,
>>
>> A couple of years ago I brought up an issue I had run into where the
>> utilization requirement for new requests is being calculated on a per
>> allocation basis rather than in aggregate. For example, if an
>> organization has 4 x /22 and 3 of them are utilized 100% and the
>> fourth utilized at 75%, that request would be denied. This is a bit
>> out of balance as an organization with a single /20 utilized at 80%
>> would have less efficient utilization but would be eligible to request
>> additional space.
>>
>> The last time this was discussed it sounded as if the community would
>> support a policy proposal to change this calculation to be considered
>> in aggregate vs. per assignment. Does this remain the case?
>>
>> Thanks,
>> --
>> Jeffrey A. Lyon, CISSP-ISSMP
>> Fellow, Black Lotus Communications
>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>> blacklotus.net
>> _______________________________________________
>> 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.
>
>
>
> --
> Scott



-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From jeffrey.lyon at blacklotus.net  Wed Apr 30 11:51:24 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Thu, 1 May 2014 00:51:24 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CAGkMwz6BayBeio+J6pNOZj1T3Aumikpv0C05N=p9Gk5jCwoqTA@mail.gmail.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
	<CAGkMwz6BayBeio+J6pNOZj1T3Aumikpv0C05N=p9Gk5jCwoqTA@mail.gmail.com>
Message-ID: <CACrmG8evXd0EGq_BPM+_whK77Y0NHAWavAq0uiG10vA3A+TtQA@mail.gmail.com>

Scott,

Also, we're already in Phase 4, so isn't it fair to say that the free
pool is essentially exhausted?

Thanks, Jeff

On Thu, May 1, 2014 at 12:44 AM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> This seems to me like a reasonable operational practice for ARIN to use to
> help prevent a run on the remaining free pool from organizations with large
> quantities of existing space.
>
> Are you trying to change this before free pool runout, or are you concerned
> with making needs justification a bit easier for transfers once the free
> pool is exhausted? I would support the latter, but not the former.
>
> -Scott
>
>
> On Wednesday, April 30, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
> wrote:
>>
>> Friends, Colleagues,
>>
>> A couple of years ago I brought up an issue I had run into where the
>> utilization requirement for new requests is being calculated on a per
>> allocation basis rather than in aggregate. For example, if an
>> organization has 4 x /22 and 3 of them are utilized 100% and the
>> fourth utilized at 75%, that request would be denied. This is a bit
>> out of balance as an organization with a single /20 utilized at 80%
>> would have less efficient utilization but would be eligible to request
>> additional space.
>>
>> The last time this was discussed it sounded as if the community would
>> support a policy proposal to change this calculation to be considered
>> in aggregate vs. per assignment. Does this remain the case?
>>
>> Thanks,
>> --
>> Jeffrey A. Lyon, CISSP-ISSMP
>> Fellow, Black Lotus Communications
>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>> blacklotus.net
>> _______________________________________________
>> 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.
>
>
>
> --
> Scott



-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From contact at winterei.se  Wed Apr 30 12:01:42 2014
From: contact at winterei.se (Paul S.)
Date: Thu, 01 May 2014 01:01:42 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CACrmG8evXd0EGq_BPM+_whK77Y0NHAWavAq0uiG10vA3A+TtQA@mail.gmail.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>	<CAGkMwz6BayBeio+J6pNOZj1T3Aumikpv0C05N=p9Gk5jCwoqTA@mail.gmail.com>
	<CACrmG8evXd0EGq_BPM+_whK77Y0NHAWavAq0uiG10vA3A+TtQA@mail.gmail.com>
Message-ID: <53611E66.8050507@winterei.se>

Jeffrey,

While the idea is great, isn't ARIN supposed to already be implementing 
this in one way?

i.e: You get one allocation, and until you can show 80% usage -- 
applying again generally does not get you anywhere.

Going by this, shouldn't all previous allocs ("aggregated / per 
organization allocations") actually be used up? Or am I missing something?

On 5/1/2014 ?? 12:51, Jeffrey Lyon wrote:
> Scott,
>
> Also, we're already in Phase 4, so isn't it fair to say that the free
> pool is essentially exhausted?
>
> Thanks, Jeff
>
> On Thu, May 1, 2014 at 12:44 AM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> This seems to me like a reasonable operational practice for ARIN to use to
>> help prevent a run on the remaining free pool from organizations with large
>> quantities of existing space.
>>
>> Are you trying to change this before free pool runout, or are you concerned
>> with making needs justification a bit easier for transfers once the free
>> pool is exhausted? I would support the latter, but not the former.
>>
>> -Scott
>>
>>
>> On Wednesday, April 30, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
>> wrote:
>>> Friends, Colleagues,
>>>
>>> A couple of years ago I brought up an issue I had run into where the
>>> utilization requirement for new requests is being calculated on a per
>>> allocation basis rather than in aggregate. For example, if an
>>> organization has 4 x /22 and 3 of them are utilized 100% and the
>>> fourth utilized at 75%, that request would be denied. This is a bit
>>> out of balance as an organization with a single /20 utilized at 80%
>>> would have less efficient utilization but would be eligible to request
>>> additional space.
>>>
>>> The last time this was discussed it sounded as if the community would
>>> support a policy proposal to change this calculation to be considered
>>> in aggregate vs. per assignment. Does this remain the case?
>>>
>>> Thanks,
>>> --
>>> Jeffrey A. Lyon, CISSP-ISSMP
>>> Fellow, Black Lotus Communications
>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>>> blacklotus.net
>>> _______________________________________________
>>> 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.
>>
>>
>> --
>> Scott
>
>



From scottleibrand at gmail.com  Wed Apr 30 12:08:40 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 30 Apr 2014 09:08:40 -0700
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CACrmG8evXd0EGq_BPM+_whK77Y0NHAWavAq0uiG10vA3A+TtQA@mail.gmail.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
	<CAGkMwz6BayBeio+J6pNOZj1T3Aumikpv0C05N=p9Gk5jCwoqTA@mail.gmail.com>
	<CACrmG8evXd0EGq_BPM+_whK77Y0NHAWavAq0uiG10vA3A+TtQA@mail.gmail.com>
Message-ID: <C2A4E319-25E2-45F8-A654-C4FB3E42DE7C@gmail.com>

No, but I think it will be before any new policy proposal moving at "normal" speed takes effect. (The /24 minimum allocation size might take effect before then. If so, that will probably accelerate runout further.)

If you think (as I do) that this policy change would still be useful after runout when most requests result in a transfer, you could probably sidestep a lot of potential opposition by specifying that it would only go into effect after free pool runout, or would only affect transfers. 

Scott

> On Apr 30, 2014, at 8:51 AM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
> 
> Scott,
> 
> Also, we're already in Phase 4, so isn't it fair to say that the free
> pool is essentially exhausted?
> 
> Thanks, Jeff
> 
>> On Thu, May 1, 2014 at 12:44 AM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> This seems to me like a reasonable operational practice for ARIN to use to
>> help prevent a run on the remaining free pool from organizations with large
>> quantities of existing space.
>> 
>> Are you trying to change this before free pool runout, or are you concerned
>> with making needs justification a bit easier for transfers once the free
>> pool is exhausted? I would support the latter, but not the former.
>> 
>> -Scott
>> 
>> 
>> On Wednesday, April 30, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
>> wrote:
>>> 
>>> Friends, Colleagues,
>>> 
>>> A couple of years ago I brought up an issue I had run into where the
>>> utilization requirement for new requests is being calculated on a per
>>> allocation basis rather than in aggregate. For example, if an
>>> organization has 4 x /22 and 3 of them are utilized 100% and the
>>> fourth utilized at 75%, that request would be denied. This is a bit
>>> out of balance as an organization with a single /20 utilized at 80%
>>> would have less efficient utilization but would be eligible to request
>>> additional space.
>>> 
>>> The last time this was discussed it sounded as if the community would
>>> support a policy proposal to change this calculation to be considered
>>> in aggregate vs. per assignment. Does this remain the case?
>>> 
>>> Thanks,
>>> --
>>> Jeffrey A. Lyon, CISSP-ISSMP
>>> Fellow, Black Lotus Communications
>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>>> blacklotus.net
>>> _______________________________________________
>>> 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.
>> 
>> 
>> 
>> --
>> Scott
> 
> 
> 
> -- 
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From jeffrey.lyon at blacklotus.net  Wed Apr 30 12:10:22 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Thu, 1 May 2014 01:10:22 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <53611E66.8050507@winterei.se>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
	<CAGkMwz6BayBeio+J6pNOZj1T3Aumikpv0C05N=p9Gk5jCwoqTA@mail.gmail.com>
	<CACrmG8evXd0EGq_BPM+_whK77Y0NHAWavAq0uiG10vA3A+TtQA@mail.gmail.com>
	<53611E66.8050507@winterei.se>
Message-ID: <CACrmG8dbaCvk0eXQnxX9_2zC74M_Vt+1dS4iLnVmjZg7XLAYjQ@mail.gmail.com>

Paul,

The problem I see is in the manner of calculation. Right now each and
every allocation must be individually utilized at 80%. This means I
can have 3 x /22 utilized at 100% and 1 x /22 at 79% and would not be
eligible for more space where an organization with 80% utilization on
a single /20 would not have the same problem.

As a case example, Black Lotus has numerous /21's all utilized at 90%+
and one of them at 80%. ARIN is requesting more documentation on the
80% one to ensure that it is really at 80%. This is fair under current
policy, but it does not make sense when one considers that
organizations with larger contiguous assignments would never run into
this issue. It is an unnecessary time drain for both the requester and
ARIN.

Thanks, Jeff

On Thu, May 1, 2014 at 1:01 AM, Paul S. <contact at winterei.se> wrote:
> Jeffrey,
>
> While the idea is great, isn't ARIN supposed to already be implementing this
> in one way?
>
> i.e: You get one allocation, and until you can show 80% usage -- applying
> again generally does not get you anywhere.
>
> Going by this, shouldn't all previous allocs ("aggregated / per organization
> allocations") actually be used up? Or am I missing something?
>
>
> On 5/1/2014 ?? 12:51, Jeffrey Lyon wrote:
>>
>> Scott,
>>
>> Also, we're already in Phase 4, so isn't it fair to say that the free
>> pool is essentially exhausted?
>>
>> Thanks, Jeff
>>
>> On Thu, May 1, 2014 at 12:44 AM, Scott Leibrand <scottleibrand at gmail.com>
>> wrote:
>>>
>>> This seems to me like a reasonable operational practice for ARIN to use
>>> to
>>> help prevent a run on the remaining free pool from organizations with
>>> large
>>> quantities of existing space.
>>>
>>> Are you trying to change this before free pool runout, or are you
>>> concerned
>>> with making needs justification a bit easier for transfers once the free
>>> pool is exhausted? I would support the latter, but not the former.
>>>
>>> -Scott
>>>
>>>
>>> On Wednesday, April 30, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
>>> wrote:
>>>>
>>>> Friends, Colleagues,
>>>>
>>>> A couple of years ago I brought up an issue I had run into where the
>>>> utilization requirement for new requests is being calculated on a per
>>>> allocation basis rather than in aggregate. For example, if an
>>>> organization has 4 x /22 and 3 of them are utilized 100% and the
>>>> fourth utilized at 75%, that request would be denied. This is a bit
>>>> out of balance as an organization with a single /20 utilized at 80%
>>>> would have less efficient utilization but would be eligible to request
>>>> additional space.
>>>>
>>>> The last time this was discussed it sounded as if the community would
>>>> support a policy proposal to change this calculation to be considered
>>>> in aggregate vs. per assignment. Does this remain the case?
>>>>
>>>> Thanks,
>>>> --
>>>> Jeffrey A. Lyon, CISSP-ISSMP
>>>> Fellow, Black Lotus Communications
>>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>>>> blacklotus.net
>>>> _______________________________________________
>>>> 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.
>>>
>>>
>>>
>>> --
>>> 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.



-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From jeffrey.lyon at blacklotus.net  Wed Apr 30 12:11:47 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Thu, 1 May 2014 01:11:47 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <C2A4E319-25E2-45F8-A654-C4FB3E42DE7C@gmail.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
	<CAGkMwz6BayBeio+J6pNOZj1T3Aumikpv0C05N=p9Gk5jCwoqTA@mail.gmail.com>
	<CACrmG8evXd0EGq_BPM+_whK77Y0NHAWavAq0uiG10vA3A+TtQA@mail.gmail.com>
	<C2A4E319-25E2-45F8-A654-C4FB3E42DE7C@gmail.com>
Message-ID: <CACrmG8e2SdKPhergHKPJzqdn8yH-WAUYgR=s0A31n+FArWZMTQ@mail.gmail.com>

Scott,

How do we define free pool exhaustion? We're already at < 1 x /8 and
RIPE has already stopped issuing new IPv4 space (not sure what APNIC
et al are up to) but the situation is dire enough that I feel we
should consider ourselves at the exhaustion point.

Thanks, Jeff

On Thu, May 1, 2014 at 1:08 AM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> No, but I think it will be before any new policy proposal moving at "normal" speed takes effect. (The /24 minimum allocation size might take effect before then. If so, that will probably accelerate runout further.)
>
> If you think (as I do) that this policy change would still be useful after runout when most requests result in a transfer, you could probably sidestep a lot of potential opposition by specifying that it would only go into effect after free pool runout, or would only affect transfers.
>
> Scott
>
>> On Apr 30, 2014, at 8:51 AM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
>>
>> Scott,
>>
>> Also, we're already in Phase 4, so isn't it fair to say that the free
>> pool is essentially exhausted?
>>
>> Thanks, Jeff
>>
>>> On Thu, May 1, 2014 at 12:44 AM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>>> This seems to me like a reasonable operational practice for ARIN to use to
>>> help prevent a run on the remaining free pool from organizations with large
>>> quantities of existing space.
>>>
>>> Are you trying to change this before free pool runout, or are you concerned
>>> with making needs justification a bit easier for transfers once the free
>>> pool is exhausted? I would support the latter, but not the former.
>>>
>>> -Scott
>>>
>>>
>>> On Wednesday, April 30, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
>>> wrote:
>>>>
>>>> Friends, Colleagues,
>>>>
>>>> A couple of years ago I brought up an issue I had run into where the
>>>> utilization requirement for new requests is being calculated on a per
>>>> allocation basis rather than in aggregate. For example, if an
>>>> organization has 4 x /22 and 3 of them are utilized 100% and the
>>>> fourth utilized at 75%, that request would be denied. This is a bit
>>>> out of balance as an organization with a single /20 utilized at 80%
>>>> would have less efficient utilization but would be eligible to request
>>>> additional space.
>>>>
>>>> The last time this was discussed it sounded as if the community would
>>>> support a policy proposal to change this calculation to be considered
>>>> in aggregate vs. per assignment. Does this remain the case?
>>>>
>>>> Thanks,
>>>> --
>>>> Jeffrey A. Lyon, CISSP-ISSMP
>>>> Fellow, Black Lotus Communications
>>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>>>> blacklotus.net
>>>> _______________________________________________
>>>> 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.
>>>
>>>
>>>
>>> --
>>> Scott
>>
>>
>>
>> --
>> Jeffrey A. Lyon, CISSP-ISSMP
>> Fellow, Black Lotus Communications
>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net



-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From hannigan at gmail.com  Wed Apr 30 13:15:05 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 30 Apr 2014 13:15:05 -0400
Subject: [arin-ppml] Policy discussion - Method of calculating utilization
In-Reply-To: <C2A4E319-25E2-45F8-A654-C4FB3E42DE7C@gmail.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
	<CAGkMwz6BayBeio+J6pNOZj1T3Aumikpv0C05N=p9Gk5jCwoqTA@mail.gmail.com>
	<CACrmG8evXd0EGq_BPM+_whK77Y0NHAWavAq0uiG10vA3A+TtQA@mail.gmail.com>
	<C2A4E319-25E2-45F8-A654-C4FB3E42DE7C@gmail.com>
Message-ID: <CAMDXq5NaY2Shx00O-847Yojrpoj1ZvnMuy5jiLLUS0OyWgh8aw@mail.gmail.com>

I'd support this proposal being implemented post runout. Otherwise,
opposed. This is a pass on the needs test that the rest of us have been
subject to. Do away with all need, not small bits.


Best,

-M<



On Wed, Apr 30, 2014 at 12:08 PM, Scott Leibrand
<scottleibrand at gmail.com<javascript:;>>
wrote:
> No, but I think it will be before any new policy proposal moving at
"normal" speed takes effect. (The /24 minimum allocation size might take
effect before then. If so, that will probably accelerate runout further.)
>
> If you think (as I do) that this policy change would still be useful
after runout when most requests result in a transfer, you could probably
sidestep a lot of potential opposition by specifying that it would only go
into effect after free pool runout, or would only affect transfers.
>
> Scott
>
>> On Apr 30, 2014, at 8:51 AM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net<javascript:;>>
wrote:
>>
>> Scott,
>>
>> Also, we're already in Phase 4, so isn't it fair to say that the free
>> pool is essentially exhausted?
>>
>> Thanks, Jeff
>>
>>> On Thu, May 1, 2014 at 12:44 AM, Scott Leibrand <scottleibrand at gmail.com<javascript:;>>
wrote:
>>> This seems to me like a reasonable operational practice for ARIN to use
to
>>> help prevent a run on the remaining free pool from organizations with
large
>>> quantities of existing space.
>>>
>>> Are you trying to change this before free pool runout, or are you
concerned
>>> with making needs justification a bit easier for transfers once the free
>>> pool is exhausted? I would support the latter, but not the former.
>>>
>>> -Scott
>>>
>>>
>>> On Wednesday, April 30, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net<javascript:;>
>
>>> wrote:
>>>>
>>>> Friends, Colleagues,
>>>>
>>>> A couple of years ago I brought up an issue I had run into where the
>>>> utilization requirement for new requests is being calculated on a per
>>>> allocation basis rather than in aggregate. For example, if an
>>>> organization has 4 x /22 and 3 of them are utilized 100% and the
>>>> fourth utilized at 75%, that request would be denied. This is a bit
>>>> out of balance as an organization with a single /20 utilized at 80%
>>>> would have less efficient utilization but would be eligible to request
>>>> additional space.
>>>>
>>>> The last time this was discussed it sounded as if the community would
>>>> support a policy proposal to change this calculation to be considered
>>>> in aggregate vs. per assignment. Does this remain the case?
>>>>
>>>> Thanks,
>>>> --
>>>> Jeffrey A. Lyon, CISSP-ISSMP
>>>> Fellow, Black Lotus Communications
>>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com <javascript:;>| skype:
>>>> blacklotus.net
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>
).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net <javascript:;> if you experience any
issues.
>>>
>>>
>>>
>>> --
>>> Scott
>>
>>
>>
>> --
>> Jeffrey A. Lyon, CISSP-ISSMP
>> Fellow, Black Lotus Communications
>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com <javascript:;> |
skype: blacklotus.net
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/10f753f0/attachment.htm>

From jeffrey.lyon at blacklotus.net  Wed Apr 30 13:20:05 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Thu, 1 May 2014 02:20:05 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CAMDXq5NaY2Shx00O-847Yojrpoj1ZvnMuy5jiLLUS0OyWgh8aw@mail.gmail.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
	<CAGkMwz6BayBeio+J6pNOZj1T3Aumikpv0C05N=p9Gk5jCwoqTA@mail.gmail.com>
	<CACrmG8evXd0EGq_BPM+_whK77Y0NHAWavAq0uiG10vA3A+TtQA@mail.gmail.com>
	<C2A4E319-25E2-45F8-A654-C4FB3E42DE7C@gmail.com>
	<CAMDXq5NaY2Shx00O-847Yojrpoj1ZvnMuy5jiLLUS0OyWgh8aw@mail.gmail.com>
Message-ID: <CACrmG8cW7hfeFa_NRcdC5BSYV9y0d-ckJvM928x3UWUNgVdX-w@mail.gmail.com>

Martin,

I disagree that this proposal would in any way eliminate needs basis.
The intent is to make sure that all allocations are considered in
aggregate so that those requesting space only have to have 80%
utilization vs. 90%+ that happens in many cases where allocations are
considered independently of each other.

Thanks, Jeff

On Thu, May 1, 2014 at 2:15 AM, Martin Hannigan <hannigan at gmail.com> wrote:
>
> I'd support this proposal being implemented post runout. Otherwise, opposed.
> This is a pass on the needs test that the rest of us have been subject to.
> Do away with all need, not small bits.
>
>
> Best,
>
> -M<
>
>
>
>
> On Wed, Apr 30, 2014 at 12:08 PM, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
>> No, but I think it will be before any new policy proposal moving at
>> "normal" speed takes effect. (The /24 minimum allocation size might take
>> effect before then. If so, that will probably accelerate runout further.)
>>
>> If you think (as I do) that this policy change would still be useful after
>> runout when most requests result in a transfer, you could probably sidestep
>> a lot of potential opposition by specifying that it would only go into
>> effect after free pool runout, or would only affect transfers.
>>
>> Scott
>>
>>> On Apr 30, 2014, at 8:51 AM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
>>> wrote:
>>>
>>> Scott,
>>>
>>> Also, we're already in Phase 4, so isn't it fair to say that the free
>>> pool is essentially exhausted?
>>>
>>> Thanks, Jeff
>>>
>>>> On Thu, May 1, 2014 at 12:44 AM, Scott Leibrand
>>>> <scottleibrand at gmail.com> wrote:
>>>> This seems to me like a reasonable operational practice for ARIN to use
>>>> to
>>>> help prevent a run on the remaining free pool from organizations with
>>>> large
>>>> quantities of existing space.
>>>>
>>>> Are you trying to change this before free pool runout, or are you
>>>> concerned
>>>> with making needs justification a bit easier for transfers once the free
>>>> pool is exhausted? I would support the latter, but not the former.
>>>>
>>>> -Scott
>>>>
>>>>
>>>> On Wednesday, April 30, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
>>>> wrote:
>>>>>
>>>>> Friends, Colleagues,
>>>>>
>>>>> A couple of years ago I brought up an issue I had run into where the
>>>>> utilization requirement for new requests is being calculated on a per
>>>>> allocation basis rather than in aggregate. For example, if an
>>>>> organization has 4 x /22 and 3 of them are utilized 100% and the
>>>>> fourth utilized at 75%, that request would be denied. This is a bit
>>>>> out of balance as an organization with a single /20 utilized at 80%
>>>>> would have less efficient utilization but would be eligible to request
>>>>> additional space.
>>>>>
>>>>> The last time this was discussed it sounded as if the community would
>>>>> support a policy proposal to change this calculation to be considered
>>>>> in aggregate vs. per assignment. Does this remain the case?
>>>>>
>>>>> Thanks,
>>>>> --
>>>>> Jeffrey A. Lyon, CISSP-ISSMP
>>>>> Fellow, Black Lotus Communications
>>>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>>>>> blacklotus.net
>>>>> _______________________________________________
>>>>> 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.
>>>>
>>>>
>>>>
>>>> --
>>>> Scott
>>>
>>>
>>>
>>> --
>>> Jeffrey A. Lyon, CISSP-ISSMP
>>> Fellow, Black Lotus Communications
>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>>> blacklotus.net
>> _______________________________________________
>> 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.
>



-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From hannigan at gmail.com  Wed Apr 30 13:36:44 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 30 Apr 2014 13:36:44 -0400
Subject: [arin-ppml] Policy discussion - Method of calculating utilization
In-Reply-To: <C2A4E319-25E2-45F8-A654-C4FB3E42DE7C@gmail.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
	<CAGkMwz6BayBeio+J6pNOZj1T3Aumikpv0C05N=p9Gk5jCwoqTA@mail.gmail.com>
	<CACrmG8evXd0EGq_BPM+_whK77Y0NHAWavAq0uiG10vA3A+TtQA@mail.gmail.com>
	<C2A4E319-25E2-45F8-A654-C4FB3E42DE7C@gmail.com>
Message-ID: <CAMDXq5MbmLcO=Yk1hjmPmScN5gPTj36OZ3rQzW3kgngsGxCxEQ@mail.gmail.com>

I'd support this proposal being implemented post runout. Otherwise,
opposed. This is a pass on the needs test that the rest of us have been
subject to. Do away with all need, not small bits.


Best,

-M<



On Wed, Apr 30, 2014 at 12:08 PM, Scott Leibrand
<scottleibrand at gmail.com<javascript:;>>
wrote:
> No, but I think it will be before any new policy proposal moving at
"normal" speed takes effect. (The /24 minimum allocation size might take
effect before then. If so, that will probably accelerate runout further.)
>
> If you think (as I do) that this policy change would still be useful
after runout when most requests result in a transfer, you could probably
sidestep a lot of potential opposition by specifying that it would only go
into effect after free pool runout, or would only affect transfers.
>
> Scott
>
>> On Apr 30, 2014, at 8:51 AM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net<javascript:;>>
wrote:
>>
>> Scott,
>>
>> Also, we're already in Phase 4, so isn't it fair to say that the free
>> pool is essentially exhausted?
>>
>> Thanks, Jeff
>>
>>> On Thu, May 1, 2014 at 12:44 AM, Scott Leibrand <scottleibrand at gmail.com<javascript:;>>
wrote:
>>> This seems to me like a reasonable operational practice for ARIN to use
to
>>> help prevent a run on the remaining free pool from organizations with
large
>>> quantities of existing space.
>>>
>>> Are you trying to change this before free pool runout, or are you
concerned
>>> with making needs justification a bit easier for transfers once the free
>>> pool is exhausted? I would support the latter, but not the former.
>>>
>>> -Scott
>>>
>>>
>>> On Wednesday, April 30, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net<javascript:;>
>
>>> wrote:
>>>>
>>>> Friends, Colleagues,
>>>>
>>>> A couple of years ago I brought up an issue I had run into where the
>>>> utilization requirement for new requests is being calculated on a per
>>>> allocation basis rather than in aggregate. For example, if an
>>>> organization has 4 x /22 and 3 of them are utilized 100% and the
>>>> fourth utilized at 75%, that request would be denied. This is a bit
>>>> out of balance as an organization with a single /20 utilized at 80%
>>>> would have less efficient utilization but would be eligible to request
>>>> additional space.
>>>>
>>>> The last time this was discussed it sounded as if the community would
>>>> support a policy proposal to change this calculation to be considered
>>>> in aggregate vs. per assignment. Does this remain the case?
>>>>
>>>> Thanks,
>>>> --
>>>> Jeffrey A. Lyon, CISSP-ISSMP
>>>> Fellow, Black Lotus Communications
>>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com <javascript:;>| skype:
>>>> blacklotus.net
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>
).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net <javascript:;> if you experience any
issues.
>>>
>>>
>>>
>>> --
>>> Scott
>>
>>
>>
>> --
>> Jeffrey A. Lyon, CISSP-ISSMP
>> Fellow, Black Lotus Communications
>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com <javascript:;> |
skype: blacklotus.net
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/ba9448a2/attachment.htm>

From springer at inlandnet.com  Wed Apr 30 14:22:22 2014
From: springer at inlandnet.com (John Springer)
Date: Wed, 30 Apr 2014 11:22:22 -0700 (PDT)
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <aa681e3571a147b281b4a8842ebdc532@DM2PR03MB398.namprd03.prod.outlook.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<CAAAwwbU5ey6XzBvSxzt2RxANdkAPWTAG3ON+wk_6UuQKKn3Leg@mail.gmail.com>
	<CAMDXq5P23TN_1EPxwTN+rXO+bSqOTsLt9BbzJEyve5X_PJcrGw@mail.gmail.com>,
	<53604E20.4020503@cnets.net>
	<aa681e3571a147b281b4a8842ebdc532@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <alpine.BSF.2.00.1404301108190.66806@mail.inlandnet.com>

The analysis by David is, in my opinion, correct. This policy proposal is 
receiving what in my experience is an unprecedented amount of community 
support, _AS_WRITTEN_. Changes to the text require support be reiterated, 
which might be unwanted and harmful to the text speed of the process. 
Further desired changes should be submitted separately to avoid 
interfering with the momentum that has been generated.

The community is speaking and the AC is listening. What I am hearing is 
get busy and get 'er done. If the policy proposal can be supported as 
written, it should be. Any changes to the text as written will have to be 
listened to and responded to and cannot speed things up.

I am _NOT_ saying do not dissent, only that the conversation that ensues 
will take time.

Not to put words in Marty's mouth, but that is how I interpret what he is 
saying.

John Springer

On Wed, 30 Apr 2014, David Huberman wrote:

> 
> Derek,
> 
> ?
> 
> Marty can be a bit gruff - it's part of his charm :)? He's actually trying very hard to help you achieve your goals.? His observation you quoted is borne of wisdom of
> dealing with the policy process for many years.?? Some may agree, or may not agree.? I happened to agree strongly with him.
> 
> ?
> 
> Owen's proposal, without modifications (or at least, not the one proposed so far), has the best chance of succeeding, and doing so quickly.
> 
> ?
> 
> Just my opinion.
> 
> ?
> 
> /david
> 
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> 
> _______________________________________________________________________________________________________________________________________________________________________
> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of Derek Calanchini <derekc at cnets.net>
> Sent: Tuesday, April 29, 2014 6:13 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Reduce all Minimum Allocation/Assignment units to /24 ?
> Martin,
> 
> You seem very negative about this, disagreeing for the sake of disagreeing is counter productive.? Perhaps you could explain your concerns giving actual reasons,
> potential fallout, issues, etc in the hopes of making it better....
> 
> ?Best regards,
> 
> ?? Derek Calanchini
> ?? Owner
> ?? Creative Network Solutions
> ?? Phone: 916-852-2890
> ?? Fax: 916-852-2899
> 
> "Adopt the metric system!"
> 
> CNS LOGO
> On 4/29/2014 5:15 PM, Martin Hannigan wrote:
> 
> Owens change is simple and fast. Meddling beyond that is asking for trouble. ?It's a no op. Leave it alone.?
> Bring that to the PPC at NANOG and this is dead.?
> 
> 
> 
> 
> 
> On Tuesday, April 29, 2014, Jimmy Hess <mysidia at gmail.com> wrote:
>       On Tue, Apr 29, 2014 at 12:58 PM, Owen DeLong <owen at delong.com> wrote:
>
>       I support the proposed change as written.
>
>       In addition, ?since Multihomed ISPs no longer have a different minimum
>       allocation, I suggest ? ?removing the distinction between Multihomed
>       and non-Multihomed ISPs:
>
>       ? ?o 4.2.1.5 ? ? Delete the sentence that says "For multihomed ISPs...."
>       ? ?Remove multi-homed distinction and requirements for initial
>       allocations to ISPs.
>       ? ? ? o Delete section ?4.2.2.1 ?Standard or non-multihomed ?and subsections.
>
>       ? ? ? o Rename section 4.2.2.2 to ?remove references to Multihomed
>
>       Prepend ? ? "When requesting a ?/24, ?demonstrate the efficient
>       utilization of a minimum contiguous or non-contiguous ?/27 ?(two /28s)
>       from an upstream."
>
>       [Regardless if multihomed or not]
> 
> 
>
>       > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>       >
>       > 1. Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to
>       > /24
>       > 2. Proposal Originator
>       > a. name: Owen DeLong
>       > b. email: owen at delong.com
>       > c. telephone: 408-890-7992
>       > d. organization: Hurricane Electric
>       > 3. Date: 29 April, 2014
>       > 4. Problem Statement:
>       >
>       > As we approach runout, more and more end users and smaller ISPs will be
>       > unable to obtain space from their upstreams and will be seeking space from
>       > ARIN. In order to meet these needs to the extent possible and to make policy
>       > more fair to a broader range of the ARIN constituency, we should reduce the
>       > minimum assignment and allocation units to /24 across the board.
>       >
>       > 5. Policy statement:
>       >
>       > Change the minimum allocation and assignment unit for all IPv4 single and
>       > multi homed instances to /20. This would include:
>       >
>       >
>       > 4.2.1.5 Change all occurrences of /20 and /22 to /24
>       >
>       > 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24.
>       > Remove the example about 12 /24s.
>       >
>       > 4.3.2.1 Change both occurrences of /20 to /24
>       >
>       > 4.9 Change /22 to /24
>       >
>       > 4.9.1 Change all instances of /22 to /24. Remove the reference to 4 /24s.
>       >
>       >
>       > 6. Comments:
>       > a. Timetable for implementation: Immediate, possibly through board action.
>       > b. Anything else
>       >
>       > END OF TEMPLATE
>       >
>       >
>       >
>       > _______________________________________________
>       > 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.
> 
> 
>
>       --
>       -JH
>       _______________________________________________
>       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.
> 
> 
> 
> 
> _______________________________________________________________________________________________________________________________________________________________________
> [avast-mail-stamp.png]
> 
> This email is free from viruses and malware because avast! Antivirus protection is active.
> 
> 
> 
>

From billdarte at gmail.com  Wed Apr 30 14:28:56 2014
From: billdarte at gmail.com (Bill Darte)
Date: Wed, 30 Apr 2014 13:28:56 -0500
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <alpine.BSF.2.00.1404301108190.66806@mail.inlandnet.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<CAAAwwbU5ey6XzBvSxzt2RxANdkAPWTAG3ON+wk_6UuQKKn3Leg@mail.gmail.com>
	<CAMDXq5P23TN_1EPxwTN+rXO+bSqOTsLt9BbzJEyve5X_PJcrGw@mail.gmail.com>
	<53604E20.4020503@cnets.net>
	<aa681e3571a147b281b4a8842ebdc532@DM2PR03MB398.namprd03.prod.outlook.com>
	<alpine.BSF.2.00.1404301108190.66806@mail.inlandnet.com>
Message-ID: <CAMApp35dap=upBB-h_bU5oJ-Wh_+cKkJbBXJzszycTkybKSRyQ@mail.gmail.com>

Concur.

The multi-homing concern is worthy of discussion and I or another AC member
would be happy to help craft a subsequent policy proposal if members of the
community are so interested.

bd


On Wed, Apr 30, 2014 at 1:22 PM, John Springer <springer at inlandnet.com>wrote:

> The analysis by David is, in my opinion, correct. This policy proposal is
> receiving what in my experience is an unprecedented amount of community
> support, _AS_WRITTEN_. Changes to the text require support be reiterated,
> which might be unwanted and harmful to the text speed of the process.
> Further desired changes should be submitted separately to avoid interfering
> with the momentum that has been generated.
>
> The community is speaking and the AC is listening. What I am hearing is
> get busy and get 'er done. If the policy proposal can be supported as
> written, it should be. Any changes to the text as written will have to be
> listened to and responded to and cannot speed things up.
>
> I am _NOT_ saying do not dissent, only that the conversation that ensues
> will take time.
>
> Not to put words in Marty's mouth, but that is how I interpret what he is
> saying.
>
> John Springer
>
> On Wed, 30 Apr 2014, David Huberman wrote:
>
>
>> Derek,
>>
>>
>>
>> Marty can be a bit gruff - it's part of his charm :)  He's actually
>> trying very hard to help you achieve your goals.  His observation you
>> quoted is borne of wisdom of
>> dealing with the policy process for many years.   Some may agree, or may
>> not agree.  I happened to agree strongly with him.
>>
>>
>>
>> Owen's proposal, without modifications (or at least, not the one proposed
>> so far), has the best chance of succeeding, and doing so quickly.
>>
>>
>>
>> Just my opinion.
>>
>>
>>
>> /david
>>
>> David R Huberman
>> Microsoft Corporation
>> Senior IT/OPS Program Manager (GFS)
>>
>> ____________________________________________________________
>> ____________________________________________________________
>> _______________________________________________
>> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf
>> of Derek Calanchini <derekc at cnets.net>
>> Sent: Tuesday, April 29, 2014 6:13 PM
>> To: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Policy Proposal: Reduce all Minimum
>> Allocation/Assignment units to /24
>> Martin,
>>
>> You seem very negative about this, disagreeing for the sake of
>> disagreeing is counter productive.  Perhaps you could explain your concerns
>> giving actual reasons,
>> potential fallout, issues, etc in the hopes of making it better....
>>
>>  Best regards,
>>
>>    Derek Calanchini
>>    Owner
>>    Creative Network Solutions
>>    Phone: 916-852-2890
>>    Fax: 916-852-2899
>>
>> "Adopt the metric system!"
>>
>> CNS LOGO
>> On 4/29/2014 5:15 PM, Martin Hannigan wrote:
>>
>> Owens change is simple and fast. Meddling beyond that is asking for
>> trouble.  It's a no op. Leave it alone.
>> Bring that to the PPC at NANOG and this is dead.
>>
>>
>>
>>
>>
>> On Tuesday, April 29, 2014, Jimmy Hess <mysidia at gmail.com> wrote:
>>       On Tue, Apr 29, 2014 at 12:58 PM, Owen DeLong <owen at delong.com>
>> wrote:
>>
>>       I support the proposed change as written.
>>
>>       In addition,  since Multihomed ISPs no longer have a different
>> minimum
>>       allocation, I suggest    removing the distinction between Multihomed
>>       and non-Multihomed ISPs:
>>
>>          o 4.2.1.5     Delete the sentence that says "For multihomed
>> ISPs...."
>>          Remove multi-homed distinction and requirements for initial
>>       allocations to ISPs.
>>             o Delete section  4.2.2.1  Standard or non-multihomed  and
>> subsections.
>>
>>             o Rename section 4.2.2.2 to  remove references to Multihomed
>>
>>       Prepend     "When requesting a  /24,  demonstrate the efficient
>>       utilization of a minimum contiguous or non-contiguous  /27  (two
>> /28s)
>>       from an upstream."
>>
>>       [Regardless if multihomed or not]
>>
>>
>>
>>       > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>>       >
>>       > 1. Policy Proposal Name: Reduce all Minimum Allocation/Assignment
>> units to
>>       > /24
>>       > 2. Proposal Originator
>>       > a. name: Owen DeLong
>>       > b. email: owen at delong.com
>>       > c. telephone: 408-890-7992
>>       > d. organization: Hurricane Electric
>>       > 3. Date: 29 April, 2014
>>       > 4. Problem Statement:
>>       >
>>       > As we approach runout, more and more end users and smaller ISPs
>> will be
>>       > unable to obtain space from their upstreams and will be seeking
>> space from
>>       > ARIN. In order to meet these needs to the extent possible and to
>> make policy
>>       > more fair to a broader range of the ARIN constituency, we should
>> reduce the
>>       > minimum assignment and allocation units to /24 across the board.
>>       >
>>       > 5. Policy statement:
>>       >
>>       > Change the minimum allocation and assignment unit for all IPv4
>> single and
>>       > multi homed instances to /20. This would include:
>>       >
>>       >
>>       > 4.2.1.5 Change all occurrences of /20 and /22 to /24
>>       >
>>       > 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16
>> /24s to 1 /24.
>>       > Remove the example about 12 /24s.
>>       >
>>       > 4.3.2.1 Change both occurrences of /20 to /24
>>       >
>>       > 4.9 Change /22 to /24
>>       >
>>       > 4.9.1 Change all instances of /22 to /24. Remove the reference to
>> 4 /24s.
>>       >
>>       >
>>       > 6. Comments:
>>       > a. Timetable for implementation: Immediate, possibly through
>> board action.
>>       > b. Anything else
>>       >
>>       > END OF TEMPLATE
>>       >
>>       >
>>       >
>>       > _______________________________________________
>>       > 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.
>>
>>
>>
>>       --
>>       -JH
>>       _______________________________________________
>>       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.
>>
>>
>>
>>
>> ____________________________________________________________
>> ____________________________________________________________
>> _______________________________________________
>> [avast-mail-stamp.png]
>>
>> This email is free from viruses and malware because avast! Antivirus
>> protection is active.
>>
>>
>>
>>
> _______________________________________________
> 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/20140430/291a6440/attachment.htm>

From kevinb at thewire.ca  Wed Apr 30 15:10:32 2014
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Wed, 30 Apr 2014 19:10:32 +0000
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <alpine.BSF.2.00.1404301108190.66806@mail.inlandnet.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<CAAAwwbU5ey6XzBvSxzt2RxANdkAPWTAG3ON+wk_6UuQKKn3Leg@mail.gmail.com>
	<CAMDXq5P23TN_1EPxwTN+rXO+bSqOTsLt9BbzJEyve5X_PJcrGw@mail.gmail.com>,
	<53604E20.4020503@cnets.net>
	<aa681e3571a147b281b4a8842ebdc532@DM2PR03MB398.namprd03.prod.outlook.com>
	<alpine.BSF.2.00.1404301108190.66806@mail.inlandnet.com>
Message-ID: <7E7773B523E82C478734E793E58F69E78D6FB9DF@SBS2011.thewireinc.local>

Bill Darte and myself will be the Sheppard's for this proposal. At this time we are working on the policy changes and vetting
them against the text of the NRPM. 

I would appreciate feedback in regards to section 4.9 which is not mentioned in the current policy text but should probably be
removed as part of this policy.

4.9 Minimum Allocation in the Caribbean Region and North Atlantic Islands

The minimum IPv4 allocation size for ISPs from the Caribbean and North Atlantic Islands sector of the ARIN region is /22.

4.9.1. Allocation Criteria

The requesting organization must show the efficient utilization of an entire previously allocated /22 from their upstream ISP. This allocation (/22) may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space. The organization must meet the requirement of efficient use of 4 /24s.    Utilization Reporting and Justification. All other ARIN policies regarding the reporting of justification information for the allocation of IPv4 and IPv6 address space will remain in effect.

Thanks,

Kevin Blumberg





> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of John Springer
> Sent: Wednesday, April 30, 2014 2:22 PM
> To: David Huberman
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Reduce all Minimum
> Allocation/Assignment units to /24
> 
> The analysis by David is, in my opinion, correct. This policy proposal is
> receiving what in my experience is an unprecedented amount of community
> support, _AS_WRITTEN_. Changes to the text require support be reiterated,
> which might be unwanted and harmful to the text speed of the process.
> Further desired changes should be submitted separately to avoid
> interfering with the momentum that has been generated.
> 
> The community is speaking and the AC is listening. What I am hearing is
> get busy and get 'er done. If the policy proposal can be supported as
> written, it should be. Any changes to the text as written will have to be
> listened to and responded to and cannot speed things up.
> 
> I am _NOT_ saying do not dissent, only that the conversation that ensues
> will take time.
> 
> Not to put words in Marty's mouth, but that is how I interpret what he is
> saying.
> 
> John Springer
> 
> On Wed, 30 Apr 2014, David Huberman wrote:
> 
> >
> > Derek,
> >
> >
> >
> > Marty can be a bit gruff - it's part of his charm :)? He's actually trying very
> hard to help you achieve your goals.? His observation you quoted is borne of
> wisdom of
> > dealing with the policy process for many years.?? Some may agree, or may
> not agree.? I happened to agree strongly with him.
> >
> >
> >
> > Owen's proposal, without modifications (or at least, not the one proposed
> so far), has the best chance of succeeding, and doing so quickly.
> >
> >
> >
> > Just my opinion.
> >
> >
> >
> > /david
> >
> > David R Huberman
> > Microsoft Corporation
> > Senior IT/OPS Program Manager (GFS)
> >
> >
> __________________________________________________________
> __________________________________________________________
> ___________________________________________________
> > From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on
> behalf of Derek Calanchini <derekc at cnets.net>
> > Sent: Tuesday, April 29, 2014 6:13 PM
> > To: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Policy Proposal: Reduce all Minimum
> Allocation/Assignment units to /24
> > Martin,
> >
> > You seem very negative about this, disagreeing for the sake of disagreeing
> is counter productive.? Perhaps you could explain your concerns giving actual
> reasons,
> > potential fallout, issues, etc in the hopes of making it better....
> >
> > ?Best regards,
> >
> > ?? Derek Calanchini
> > ?? Owner
> > ?? Creative Network Solutions
> > ?? Phone: 916-852-2890
> > ?? Fax: 916-852-2899
> >
> > "Adopt the metric system!"
> >
> > CNS LOGO
> > On 4/29/2014 5:15 PM, Martin Hannigan wrote:
> >
> > Owens change is simple and fast. Meddling beyond that is asking for
> trouble. ?It's a no op. Leave it alone.
> > Bring that to the PPC at NANOG and this is dead.
> >
> >
> >
> >
> >
> > On Tuesday, April 29, 2014, Jimmy Hess <mysidia at gmail.com> wrote:
> >       On Tue, Apr 29, 2014 at 12:58 PM, Owen DeLong <owen at delong.com>
> wrote:
> >
> >       I support the proposed change as written.
> >
> >       In addition, ?since Multihomed ISPs no longer have a different minimum
> >       allocation, I suggest ? ?removing the distinction between Multihomed
> >       and non-Multihomed ISPs:
> >
> >       ? ?o 4.2.1.5 ? ? Delete the sentence that says "For multihomed ISPs...."
> >       ? ?Remove multi-homed distinction and requirements for initial
> >       allocations to ISPs.
> >       ? ? ? o Delete section ?4.2.2.1 ?Standard or non-multihomed ?and
> subsections.
> >
> >       ? ? ? o Rename section 4.2.2.2 to ?remove references to Multihomed
> >
> >       Prepend ? ? "When requesting a ?/24, ?demonstrate the efficient
> >       utilization of a minimum contiguous or non-contiguous ?/27 ?(two /28s)
> >       from an upstream."
> >
> >       [Regardless if multihomed or not]
> >
> >
> >
> >       > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
> >       >
> >       > 1. Policy Proposal Name: Reduce all Minimum Allocation/Assignment
> units to
> >       > /24
> >       > 2. Proposal Originator
> >       > a. name: Owen DeLong
> >       > b. email: owen at delong.com
> >       > c. telephone: 408-890-7992
> >       > d. organization: Hurricane Electric
> >       > 3. Date: 29 April, 2014
> >       > 4. Problem Statement:
> >       >
> >       > As we approach runout, more and more end users and smaller ISPs
> will be
> >       > unable to obtain space from their upstreams and will be seeking space
> from
> >       > ARIN. In order to meet these needs to the extent possible and to
> make policy
> >       > more fair to a broader range of the ARIN constituency, we should
> reduce the
> >       > minimum assignment and allocation units to /24 across the board.
> >       >
> >       > 5. Policy statement:
> >       >
> >       > Change the minimum allocation and assignment unit for all IPv4 single
> and
> >       > multi homed instances to /20. This would include:
> >       >
> >       >
> >       > 4.2.1.5 Change all occurrences of /20 and /22 to /24
> >       >
> >       > 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1
> /24.
> >       > Remove the example about 12 /24s.
> >       >
> >       > 4.3.2.1 Change both occurrences of /20 to /24
> >       >
> >       > 4.9 Change /22 to /24
> >       >
> >       > 4.9.1 Change all instances of /22 to /24. Remove the reference to 4
> /24s.
> >       >
> >       >
> >       > 6. Comments:
> >       > a. Timetable for implementation: Immediate, possibly through board
> action.
> >       > b. Anything else
> >       >
> >       > END OF TEMPLATE
> >       >
> >       >
> >       >
> >       > _______________________________________________
> >       > 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.
> >
> >
> >
> >       --
> >       -JH
> >       _______________________________________________
> >       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.
> >
> >
> >
> >
> >
> __________________________________________________________
> __________________________________________________________
> ___________________________________________________
> > [avast-mail-stamp.png]
> >
> > This email is free from viruses and malware because avast! Antivirus
> protection is active.
> >
> >
> >
> >


From cblecker at gmail.com  Wed Apr 30 15:37:19 2014
From: cblecker at gmail.com (Christoph Blecker)
Date: Wed, 30 Apr 2014 12:37:19 -0700
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
Message-ID: <CADx2oGE9sJhRUei0qpyMWSsqgduXGgJF8M5Z3vZ=GFcxO6W5EQ@mail.gmail.com>

Support.

Cheers,
Christoph


On Tue, Apr 29, 2014 at 10:58 AM, Owen DeLong <owen at delong.com> wrote:

> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>
> 	1.	Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24
> 	2.	Proposal Originator
> 		a.	name: Owen DeLong
> 		b.	email: owen at delong.com
> 		c.	telephone: 408-890-7992
> 		d.	organization: Hurricane Electric
> 	3.	Date: 29 April, 2014
> 	4.	Problem Statement:
>
> As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.
>
> 	5.	Policy statement:
>
> Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:
>
>
> 4.2.1.5 Change all occurrences of /20 and /22 to /24
>
> 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.
>
> 4.3.2.1	Change both occurrences of /20 to /24
>
> 4.9	Change /22 to /24
>
> 4.9.1	Change all instances of /22 to /24. Remove the reference to 4 /24s.
>
>
> 	6.	Comments:
> 		a.	Timetable for implementation: Immediate, possibly through board action.
> 		b.	Anything else
>
> END OF TEMPLATE
>
>
>
> _______________________________________________
> 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/20140430/bf5bc379/attachment.htm>

From george.herbert at gmail.com  Wed Apr 30 15:44:44 2014
From: george.herbert at gmail.com (George Herbert)
Date: Wed, 30 Apr 2014 12:44:44 -0700
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <7E7773B523E82C478734E793E58F69E78D6FB9DF@SBS2011.thewireinc.local>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<CAAAwwbU5ey6XzBvSxzt2RxANdkAPWTAG3ON+wk_6UuQKKn3Leg@mail.gmail.com>
	<CAMDXq5P23TN_1EPxwTN+rXO+bSqOTsLt9BbzJEyve5X_PJcrGw@mail.gmail.com>
	<53604E20.4020503@cnets.net>
	<aa681e3571a147b281b4a8842ebdc532@DM2PR03MB398.namprd03.prod.outlook.com>
	<alpine.BSF.2.00.1404301108190.66806@mail.inlandnet.com>
	<7E7773B523E82C478734E793E58F69E78D6FB9DF@SBS2011.thewireinc.local>
Message-ID: <CAK__KztnOx55H0mrE5axA+R7WMsaN9WeP1+7F0xZSnf=iziaUw@mail.gmail.com>

I would continue to support with 4.9 / 4.9.1 either deleted or ammended
with /22 replaced with /24.


On Wed, Apr 30, 2014 at 12:10 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> Bill Darte and myself will be the Sheppard's for this proposal. At this
> time we are working on the policy changes and vetting
> them against the text of the NRPM.
>
> I would appreciate feedback in regards to section 4.9 which is not
> mentioned in the current policy text but should probably be
> removed as part of this policy.
>
> 4.9 Minimum Allocation in the Caribbean Region and North Atlantic Islands
>
> The minimum IPv4 allocation size for ISPs from the Caribbean and North
> Atlantic Islands sector of the ARIN region is /22.
>
> 4.9.1. Allocation Criteria
>
> The requesting organization must show the efficient utilization of an
> entire previously allocated /22 from their upstream ISP. This allocation
> (/22) may have been provided by an ISP's upstream provider(s), and does not
> have to be contiguous address space. The organization must meet the
> requirement of efficient use of 4 /24s.    Utilization Reporting and
> Justification. All other ARIN policies regarding the reporting of
> justification information for the allocation of IPv4 and IPv6 address space
> will remain in effect.
>
> Thanks,
>
> Kevin Blumberg
>
>
>
>
>
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> > Behalf Of John Springer
> > Sent: Wednesday, April 30, 2014 2:22 PM
> > To: David Huberman
> > Cc: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Policy Proposal: Reduce all Minimum
> > Allocation/Assignment units to /24
> >
> > The analysis by David is, in my opinion, correct. This policy proposal is
> > receiving what in my experience is an unprecedented amount of community
> > support, _AS_WRITTEN_. Changes to the text require support be reiterated,
> > which might be unwanted and harmful to the text speed of the process.
> > Further desired changes should be submitted separately to avoid
> > interfering with the momentum that has been generated.
> >
> > The community is speaking and the AC is listening. What I am hearing is
> > get busy and get 'er done. If the policy proposal can be supported as
> > written, it should be. Any changes to the text as written will have to be
> > listened to and responded to and cannot speed things up.
> >
> > I am _NOT_ saying do not dissent, only that the conversation that ensues
> > will take time.
> >
> > Not to put words in Marty's mouth, but that is how I interpret what he is
> > saying.
> >
> > John Springer
> >
> > On Wed, 30 Apr 2014, David Huberman wrote:
> >
> > >
> > > Derek,
> > >
> > >
> > >
> > > Marty can be a bit gruff - it's part of his charm :)  He's actually
> trying very
> > hard to help you achieve your goals.  His observation you quoted is
> borne of
> > wisdom of
> > > dealing with the policy process for many years.   Some may agree, or
> may
> > not agree.  I happened to agree strongly with him.
> > >
> > >
> > >
> > > Owen's proposal, without modifications (or at least, not the one
> proposed
> > so far), has the best chance of succeeding, and doing so quickly.
> > >
> > >
> > >
> > > Just my opinion.
> > >
> > >
> > >
> > > /david
> > >
> > > David R Huberman
> > > Microsoft Corporation
> > > Senior IT/OPS Program Manager (GFS)
> > >
> > >
> > __________________________________________________________
> > __________________________________________________________
> > ___________________________________________________
> > > From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on
> > behalf of Derek Calanchini <derekc at cnets.net>
> > > Sent: Tuesday, April 29, 2014 6:13 PM
> > > To: arin-ppml at arin.net
> > > Subject: Re: [arin-ppml] Policy Proposal: Reduce all Minimum
> > Allocation/Assignment units to /24
> > > Martin,
> > >
> > > You seem very negative about this, disagreeing for the sake of
> disagreeing
> > is counter productive.  Perhaps you could explain your concerns giving
> actual
> > reasons,
> > > potential fallout, issues, etc in the hopes of making it better....
> > >
> > >  Best regards,
> > >
> > >    Derek Calanchini
> > >    Owner
> > >    Creative Network Solutions
> > >    Phone: 916-852-2890
> > >    Fax: 916-852-2899
> > >
> > > "Adopt the metric system!"
> > >
> > > CNS LOGO
> > > On 4/29/2014 5:15 PM, Martin Hannigan wrote:
> > >
> > > Owens change is simple and fast. Meddling beyond that is asking for
> > trouble.  It's a no op. Leave it alone.
> > > Bring that to the PPC at NANOG and this is dead.
> > >
> > >
> > >
> > >
> > >
> > > On Tuesday, April 29, 2014, Jimmy Hess <mysidia at gmail.com> wrote:
> > >       On Tue, Apr 29, 2014 at 12:58 PM, Owen DeLong <owen at delong.com>
> > wrote:
> > >
> > >       I support the proposed change as written.
> > >
> > >       In addition,  since Multihomed ISPs no longer have a different
> minimum
> > >       allocation, I suggest    removing the distinction between
> Multihomed
> > >       and non-Multihomed ISPs:
> > >
> > >          o 4.2.1.5     Delete the sentence that says "For multihomed
> ISPs...."
> > >          Remove multi-homed distinction and requirements for initial
> > >       allocations to ISPs.
> > >             o Delete section  4.2.2.1  Standard or non-multihomed  and
> > subsections.
> > >
> > >             o Rename section 4.2.2.2 to  remove references to
> Multihomed
> > >
> > >       Prepend     "When requesting a  /24,  demonstrate the efficient
> > >       utilization of a minimum contiguous or non-contiguous  /27  (two
> /28s)
> > >       from an upstream."
> > >
> > >       [Regardless if multihomed or not]
> > >
> > >
> > >
> > >       > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
> > >       >
> > >       > 1. Policy Proposal Name: Reduce all Minimum
> Allocation/Assignment
> > units to
> > >       > /24
> > >       > 2. Proposal Originator
> > >       > a. name: Owen DeLong
> > >       > b. email: owen at delong.com
> > >       > c. telephone: 408-890-7992
> > >       > d. organization: Hurricane Electric
> > >       > 3. Date: 29 April, 2014
> > >       > 4. Problem Statement:
> > >       >
> > >       > As we approach runout, more and more end users and smaller ISPs
> > will be
> > >       > unable to obtain space from their upstreams and will be
> seeking space
> > from
> > >       > ARIN. In order to meet these needs to the extent possible and
> to
> > make policy
> > >       > more fair to a broader range of the ARIN constituency, we
> should
> > reduce the
> > >       > minimum assignment and allocation units to /24 across the
> board.
> > >       >
> > >       > 5. Policy statement:
> > >       >
> > >       > Change the minimum allocation and assignment unit for all IPv4
> single
> > and
> > >       > multi homed instances to /20. This would include:
> > >       >
> > >       >
> > >       > 4.2.1.5 Change all occurrences of /20 and /22 to /24
> > >       >
> > >       > 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16
> /24s to 1
> > /24.
> > >       > Remove the example about 12 /24s.
> > >       >
> > >       > 4.3.2.1 Change both occurrences of /20 to /24
> > >       >
> > >       > 4.9 Change /22 to /24
> > >       >
> > >       > 4.9.1 Change all instances of /22 to /24. Remove the reference
> to 4
> > /24s.
> > >       >
> > >       >
> > >       > 6. Comments:
> > >       > a. Timetable for implementation: Immediate, possibly through
> board
> > action.
> > >       > b. Anything else
> > >       >
> > >       > END OF TEMPLATE
> > >       >
> > >       >
> > >       >
> > >       > _______________________________________________
> > >       > 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.
> > >
> > >
> > >
> > >       --
> > >       -JH
> > >       _______________________________________________
> > >       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.
> > >
> > >
> > >
> > >
> > >
> > __________________________________________________________
> > __________________________________________________________
> > ___________________________________________________
> > > [avast-mail-stamp.png]
> > >
> > > This email is free from viruses and malware because avast! Antivirus
> > protection is active.
> > >
> > >
> > >
> > >
> _______________________________________________
> 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.
>



-- 
-george william herbert
george.herbert at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/b81570a7/attachment.htm>

From rjletts at uw.edu  Wed Apr 30 16:38:56 2014
From: rjletts at uw.edu (Richard J. Letts)
Date: Wed, 30 Apr 2014 20:38:56 +0000
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
 Allocation/Assignment units to /24
In-Reply-To: <CADx2oGE9sJhRUei0qpyMWSsqgduXGgJF8M5Z3vZ=GFcxO6W5EQ@mail.gmail.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<CADx2oGE9sJhRUei0qpyMWSsqgduXGgJF8M5Z3vZ=GFcxO6W5EQ@mail.gmail.com>
Message-ID: <bbf32559def340fabe74583b1c90ead5@DM2PR08MB478.namprd08.prod.outlook.com>

Support.

4.9/4.9.1 could be deleted; ARIN would then need no special handling for that part of the region.

Richard Letts
Network Operations Center Manager
UW Information Technology
Mail: Box 354840
Street: 4545 15th Ave NE, Seattle, WA, 98105
206.685.1699 | mobile 206.790.5837
rjletts at uw.edu<mailto:rjletts at uw.edu>

On Tue, Apr 29, 2014 at 10:58 AM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:

Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0



     1.      Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24

     2.      Proposal Originator

             a.      name: Owen DeLong

             b.      email: owen at delong.com<mailto:owen at delong.com>

             c.      telephone: 408-890-7992<tel:408-890-7992>

             d.      organization: Hurricane Electric

     3.      Date: 29 April, 2014

     4.      Problem Statement:

As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.

     5.      Policy statement:

Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:



4.2.1.5 Change all occurrences of /20 and /22 to /24



4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.

4.3.2.1      Change both occurrences of /20 to /24

4.9  Change /22 to /24

4.9.1        Change all instances of /22 to /24. Remove the reference to 4 /24s.



     6.      Comments:

             a.      Timetable for implementation: Immediate, possibly through board action.

             b.      Anything else



END OF TEMPLATE


_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto: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/20140430/210f6fe5/attachment.htm>

From sandrabrown at ipv4marketgroup.com  Wed Apr 30 16:55:33 2014
From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com)
Date: Wed, 30 Apr 2014 13:55:33 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (Sandra Brown)
Message-ID: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>

Support.

I have been discussing the topic of reducing need with Andrew Dul and
Owen DeLong at and since ARIN33 in Chicago.  I too had reached the
conclusion that the right approach was for reduction of needs
justification for /16 and smaller, so I am very pleased to support this
proposal.  

Small businesses and ARIN staff should not be wasting their time on
needs justification of IPv4 addresses for /16 and smaller.  

ARIN should not be determining whether a small business needs a /16 or
smaller in order to conduct its business.  This is up to the business,
not a pseudo-governmental authority, such as ARIN.

The historical rationale for needs justification was to prevent
hoarding.

As David Huberman said, a small number of companies get MOST of the IP's
via the free pool.  In other words, the ARIN needs justification process
allows a small number of large companies to get a boatload of free IP's.
 But I talk to medium sized and small companies every day that cannot
get small blocks out of the free pool through the ARIN process.  The
needs justification process just does not work for them.

In THIS proposal we are talking about paid for transfers only.  The fact
there is a dollar amount attached to the transfer, is one impediment to
hoarding.

BUT:  With the limitation of the transfer size to a /16 or smaller, it
would take a lot of transfers to hoard.  It would take 256 transfers to
stockpile a /8.  This is the 2nd means to prevent hoarding.  Most
companies wanting that many IP's would simply do needs justification. 
With the ARIN affidavit by a company officer already needed for an 8.3
or 8.4 transfer, this is a 3rd deterrent to hoarding.  4thly the very
wide distribution of the IPv4 address pool is a deterrent to hoarding,
as it would take agreements and purchases from a vast number of
suppliers, each willing to transfer a vast number of /16's, for
significant hoarding to take place.  There is no danger of hoarding with
this proposal.

Most significantly, it will start to bring ARIN Region into the global
IPv4 internet age, where the RIPE community is leaving North America in
its dust.  RIPE NCC realized it would better support small business by
removing impediments such as needs justification.  This is ARIN region's
opportunity for North Americans to catch up and allow our small internet
and telco businesses to be competitive and thrive. 

Sandra Brown
IPv4 Market Group


From SRyerse at eclipse-networks.com  Wed Apr 30 17:00:32 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Wed, 30 Apr 2014 21:00:32 +0000
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
 IPv4Transfers (Sandra Brown)
In-Reply-To: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201529ADAE6@ENI-MAIL.eclipse-networks.com>

Amen!  ARIN's raison d'?tre is to allocate resources.  

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of sandrabrown at ipv4marketgroup.com
Sent: Wednesday, April 30, 2014 4:56 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4Transfers (Sandra Brown)

Support.

I have been discussing the topic of reducing need with Andrew Dul and Owen DeLong at and since ARIN33 in Chicago.  I too had reached the conclusion that the right approach was for reduction of needs justification for /16 and smaller, so I am very pleased to support this proposal.  

Small businesses and ARIN staff should not be wasting their time on needs justification of IPv4 addresses for /16 and smaller.  

ARIN should not be determining whether a small business needs a /16 or smaller in order to conduct its business.  This is up to the business, not a pseudo-governmental authority, such as ARIN.

The historical rationale for needs justification was to prevent hoarding.

As David Huberman said, a small number of companies get MOST of the IP's via the free pool.  In other words, the ARIN needs justification process allows a small number of large companies to get a boatload of free IP's.
 But I talk to medium sized and small companies every day that cannot get small blocks out of the free pool through the ARIN process.  The needs justification process just does not work for them.

In THIS proposal we are talking about paid for transfers only.  The fact there is a dollar amount attached to the transfer, is one impediment to hoarding.

BUT:  With the limitation of the transfer size to a /16 or smaller, it would take a lot of transfers to hoard.  It would take 256 transfers to stockpile a /8.  This is the 2nd means to prevent hoarding.  Most companies wanting that many IP's would simply do needs justification. 
With the ARIN affidavit by a company officer already needed for an 8.3 or 8.4 transfer, this is a 3rd deterrent to hoarding.  4thly the very wide distribution of the IPv4 address pool is a deterrent to hoarding, as it would take agreements and purchases from a vast number of suppliers, each willing to transfer a vast number of /16's, for significant hoarding to take place.  There is no danger of hoarding with this proposal.

Most significantly, it will start to bring ARIN Region into the global
IPv4 internet age, where the RIPE community is leaving North America in its dust.  RIPE NCC realized it would better support small business by removing impediments such as needs justification.  This is ARIN region's opportunity for North Americans to catch up and allow our small internet and telco businesses to be competitive and thrive. 

Sandra Brown
IPv4 Market Group
_______________________________________________
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.

From mike at nationwideinc.com  Wed Apr 30 17:26:36 2014
From: mike at nationwideinc.com (Mike Burns)
Date: Wed, 30 Apr 2014 17:26:36 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers (Sandra Brown)
In-Reply-To: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
Message-ID: <A88F8721EF0148788AE0C511437AE2DB@MPC>

As the author of the proposal, I would also like to indicate that I chose 
/16 for many of the reasons elucidated by Sarah below.
But I wanted that number to be a topic of discussion on the list and I am 
certainly amenable to a change of this number.
Thank you Owen, for proposing a different size and a limited duration as 
something you could perhaps support.

All the small buyers we see seem to be in a much more desperate need than 
the parties transacting in /16s and higher.
We are seeing that users can't get addresses from upstream providers.
I think this is because the upstream providers are unable to tighten the 
screws to get to 80%  utilization, otherwise they would get more from the 
free pool.
Whatever the reason, with this simple addition of a clause in two lines of 
the NRPM we solve many problems without risking any dangers of market 
manipulation.
Also of note regarding the illustration of the difficulties in hoarding with 
this limitation which Sandra provided, there is still the limit of one 
transfer per year.
So a series of transfers is precluded.

Regards,
Mike Burns
IPTrading.com





-----Original Message----- 
From: sandrabrown at ipv4marketgroup.com
Sent: Wednesday, April 30, 2014 4:55 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4 
Transfers (Sandra Brown)

Support.

I have been discussing the topic of reducing need with Andrew Dul and
Owen DeLong at and since ARIN33 in Chicago.  I too had reached the
conclusion that the right approach was for reduction of needs
justification for /16 and smaller, so I am very pleased to support this
proposal.

Small businesses and ARIN staff should not be wasting their time on
needs justification of IPv4 addresses for /16 and smaller.

ARIN should not be determining whether a small business needs a /16 or
smaller in order to conduct its business.  This is up to the business,
not a pseudo-governmental authority, such as ARIN.

The historical rationale for needs justification was to prevent
hoarding.

As David Huberman said, a small number of companies get MOST of the IP's
via the free pool.  In other words, the ARIN needs justification process
allows a small number of large companies to get a boatload of free IP's.
But I talk to medium sized and small companies every day that cannot
get small blocks out of the free pool through the ARIN process.  The
needs justification process just does not work for them.

In THIS proposal we are talking about paid for transfers only.  The fact
there is a dollar amount attached to the transfer, is one impediment to
hoarding.

BUT:  With the limitation of the transfer size to a /16 or smaller, it
would take a lot of transfers to hoard.  It would take 256 transfers to
stockpile a /8.  This is the 2nd means to prevent hoarding.  Most
companies wanting that many IP's would simply do needs justification.
With the ARIN affidavit by a company officer already needed for an 8.3
or 8.4 transfer, this is a 3rd deterrent to hoarding.  4thly the very
wide distribution of the IPv4 address pool is a deterrent to hoarding,
as it would take agreements and purchases from a vast number of
suppliers, each willing to transfer a vast number of /16's, for
significant hoarding to take place.  There is no danger of hoarding with
this proposal.

Most significantly, it will start to bring ARIN Region into the global
IPv4 internet age, where the RIPE community is leaving North America in
its dust.  RIPE NCC realized it would better support small business by
removing impediments such as needs justification.  This is ARIN region's
opportunity for North Americans to catch up and allow our small internet
and telco businesses to be competitive and thrive.

Sandra Brown
IPv4 Market Group
_______________________________________________
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. 



From bill at herrin.us  Wed Apr 30 17:39:03 2014
From: bill at herrin.us (William Herrin)
Date: Wed, 30 Apr 2014 17:39:03 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (fwd)
In-Reply-To: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>
References: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>
Message-ID: <CAP-guGVxkHBOdL6VKAGwB7Z=SRr0RzaQQ6K5gsnAaq-gVkjzvg@mail.gmail.com>

On Tue, Apr 29, 2014 at 1:35 AM, John Springer <springer at inlandnet.com> wrote:
> ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers
>
> Policy statement:
> Change the language in NRPM 8.3 after Conditions on the recipient of the
> transfer: from "The recipient must demonstrate the need for up to a 24-month
> supply of IP address resources under current ARIN policies and sign an RSA."
> to "For transfers larger than a /16 equivalent, the recipient must
> demonstrate the need for up to a 24-month supply of IP address resources
> under current ARIN policies and sign an RSA."

How would we go about assessing whether such changes prove harmful or
helpful? What metrics does ARIN collect under this policy which can be
analyzed and presented here so we can consider expanding it to larger
transfers? Does no justification mean no documentation?

What makes you think /16 is the right place to start testing this
idea? Traditionally /24 was the last no-justification request
accepted. Why is that not the right place to start testing a new
no-justification regime?

For now I OPPOSE the proposal as written but I'd like to hear more.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From JOHN at egh.com  Wed Apr 30 18:04:37 2014
From: JOHN at egh.com (John Santos)
Date: Wed, 30 Apr 2014 18:04:37 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers (fwd)
In-Reply-To: <CAP-guGVxkHBOdL6VKAGwB7Z=SRr0RzaQQ6K5gsnAaq-gVkjzvg@mail.gmail.com>
Message-ID: <1140430175749.19573A-100000@Ives.egh.com>


I agree with Bill.  It might be appropriate to drop needs testing for
small allocations simply because it is not worth the effort, but I don't
see a /16 as being small.  Something in the range of /24 to /20 would
be better.

Another idea to ponder would be instead of dropping the need requirement,
we adopt a presumption of good faith for small allocations.  ARIN would
simply take the word of the requester or recipient for small allocations
or transfers, but if it was later discovered the recipient was acting in
bad faith, the allocation could be revoked.

On Wed, 30 Apr 2014, William Herrin wrote:

> On Tue, Apr 29, 2014 at 1:35 AM, John Springer <springer at inlandnet.com> wrote:
> > ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers
> >
> > Policy statement:
> > Change the language in NRPM 8.3 after Conditions on the recipient of the
> > transfer: from "The recipient must demonstrate the need for up to a 24-month
> > supply of IP address resources under current ARIN policies and sign an RSA."
> > to "For transfers larger than a /16 equivalent, the recipient must
> > demonstrate the need for up to a 24-month supply of IP address resources
> > under current ARIN policies and sign an RSA."
> 
> How would we go about assessing whether such changes prove harmful or
> helpful? What metrics does ARIN collect under this policy which can be
> analyzed and presented here so we can consider expanding it to larger
> transfers? Does no justification mean no documentation?
> 
> What makes you think /16 is the right place to start testing this
> idea? Traditionally /24 was the last no-justification request
> accepted. Why is that not the right place to start testing a new
> no-justification regime?
> 
> For now I OPPOSE the proposal as written but I'd like to hear more.
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> 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.
> 
> 

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From michael at linuxmagic.com  Wed Apr 30 18:19:32 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Wed, 30 Apr 2014 15:19:32 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (fwd)
In-Reply-To: <1140430175749.19573A-100000@Ives.egh.com>
References: <1140430175749.19573A-100000@Ives.egh.com>
Message-ID: <536176F4.4050207@linuxmagic.com>

On 14-04-30 03:04 PM, John Santos wrote:
> Another idea to ponder would be instead of dropping the need requirement,
> we adopt a presumption of good faith for small allocations.  ARIN would
> simply take the word of the requester or recipient for small allocations
> or transfers, but if it was later discovered the recipient was acting in
> bad faith, the allocation could be revoked.

Except ARIN has no mandate for enforcement, that would have to be 
addressed first ;)


-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From hannigan at gmail.com  Wed Apr 30 18:19:24 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 30 Apr 2014 18:19:24 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (fwd)
In-Reply-To: <1140430175749.19573A-100000@Ives.egh.com>
References: <CAP-guGVxkHBOdL6VKAGwB7Z=SRr0RzaQQ6K5gsnAaq-gVkjzvg@mail.gmail.com>
	<1140430175749.19573A-100000@Ives.egh.com>
Message-ID: <CAMDXq5Mm8VXE0KVSS189X99sDtB+2azKevcpiNWZX5JAYSo93Q@mail.gmail.com>

It'll be a massive abuse vector.

Best,

Martin

On Wednesday, April 30, 2014, John Santos <JOHN at egh.com> wrote:

>
> I agree with Bill.  It might be appropriate to drop needs testing for
> small allocations simply because it is not worth the effort, but I don't
> see a /16 as being small.  Something in the range of /24 to /20 would
> be better.
>
> Another idea to ponder would be instead of dropping the need requirement,
> we adopt a presumption of good faith for small allocations.  ARIN would
> simply take the word of the requester or recipient for small allocations
> or transfers, but if it was later discovered the recipient was acting in
> bad faith, the allocation could be revoked.
>
> On Wed, 30 Apr 2014, William Herrin wrote:
>
> > On Tue, Apr 29, 2014 at 1:35 AM, John Springer <springer at inlandnet.com<javascript:;>>
> wrote:
> > > ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers
> > >
> > > Policy statement:
> > > Change the language in NRPM 8.3 after Conditions on the recipient of
> the
> > > transfer: from "The recipient must demonstrate the need for up to a
> 24-month
> > > supply of IP address resources under current ARIN policies and sign an
> RSA."
> > > to "For transfers larger than a /16 equivalent, the recipient must
> > > demonstrate the need for up to a 24-month supply of IP address
> resources
> > > under current ARIN policies and sign an RSA."
> >
> > How would we go about assessing whether such changes prove harmful or
> > helpful? What metrics does ARIN collect under this policy which can be
> > analyzed and presented here so we can consider expanding it to larger
> > transfers? Does no justification mean no documentation?
> >
> > What makes you think /16 is the right place to start testing this
> > idea? Traditionally /24 was the last no-justification request
> > accepted. Why is that not the right place to start testing a new
> > no-justification regime?
> >
> > For now I OPPOSE the proposal as written but I'd like to hear more.
> >
> > Regards,
> > Bill Herrin
> >
> >
> > --
> > William D. Herrin ................ herrin at dirtside.com <javascript:;>
> bill at herrin.us <javascript:;>
> > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> > Falls Church, VA 22042-3004
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net <javascript:;> if you experience any
> issues.
> >
> >
>
> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/5c15ae38/attachment.htm>

From jcurran at arin.net  Wed Apr 30 18:28:51 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 30 Apr 2014 22:28:51 +0000
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
	IPv4	Transfers (fwd)
In-Reply-To: <1140430175749.19573A-100000@Ives.egh.com>
References: <CAP-guGVxkHBOdL6VKAGwB7Z=SRr0RzaQQ6K5gsnAaq-gVkjzvg@mail.gmail.com>,
	<1140430175749.19573A-100000@Ives.egh.com>
Message-ID: <4EDD6436-1481-4736-9A7F-2C71E8990F72@arin.net>

John -

   If you apply for number resources today and make fraudulent statements
   to support your request, the resources obtained are subject to reclamation.

   Generally, this is when supporting material/representations were later found
   to be factually incorrect.  

   If ARIN were to simply accept the word of the requester, it is rather unlikely
   that any requests would subsequently be found to be "in bad faith", as we
   would never request supporting documentation to be contradicted later...
    
   (That is not a statement for or against your suggestion, just some notes for
    you to consider regarding implementation.)

Thanks!
/John

John curran 
President and CEO
ARIN




> On Apr 30, 2014, at 3:05 PM, "John Santos" <JOHN at egh.com> wrote:
> 
> ARIN would
> simply take the word of the requester or recipient for small allocations
> or transfers, but if it was later discovered the recipient was acting in
> bad faith, the allocation could be revoked.


From farmer at umn.edu  Wed Apr 30 18:35:57 2014
From: farmer at umn.edu (David Farmer)
Date: Wed, 30 Apr 2014 17:35:57 -0500
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (fwd)
In-Reply-To: <CAMDXq5Mm8VXE0KVSS189X99sDtB+2azKevcpiNWZX5JAYSo93Q@mail.gmail.com>
References: <CAP-guGVxkHBOdL6VKAGwB7Z=SRr0RzaQQ6K5gsnAaq-gVkjzvg@mail.gmail.com>	<1140430175749.19573A-100000@Ives.egh.com>
	<CAMDXq5Mm8VXE0KVSS189X99sDtB+2azKevcpiNWZX5JAYSo93Q@mail.gmail.com>
Message-ID: <53617ACD.4070407@umn.edu>

Marty,

Are you suggesting the whole idea of removing needs testing from small 
IPv4 transfers would be a massive abuse vector?  Or;

Do you mean only John's suggestion of a presumption of good faith for 
small allocations would be a massive abuse vector?

Thanks.

On 4/30/14, 17:19 , Martin Hannigan wrote:
> It'll be a massive abuse vector.
>
> Best,
>
> Martin
>
> On Wednesday, April 30, 2014, John Santos <JOHN at egh.com
> <mailto:JOHN at egh.com>> wrote:
>
>
>     I agree with Bill.  It might be appropriate to drop needs testing for
>     small allocations simply because it is not worth the effort, but I don't
>     see a /16 as being small.  Something in the range of /24 to /20 would
>     be better.
>
>     Another idea to ponder would be instead of dropping the need
>     requirement,
>     we adopt a presumption of good faith for small allocations.  ARIN would
>     simply take the word of the requester or recipient for small allocations
>     or transfers, but if it was later discovered the recipient was acting in
>     bad faith, the allocation could be revoked.
>
>     On Wed, 30 Apr 2014, William Herrin wrote:
>
>      > On Tue, Apr 29, 2014 at 1:35 AM, John Springer
>     <springer at inlandnet.com <javascript:;>> wrote:
>      > > ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers
>      > >
>      > > Policy statement:
>      > > Change the language in NRPM 8.3 after Conditions on the
>     recipient of the
>      > > transfer: from "The recipient must demonstrate the need for up
>     to a 24-month
>      > > supply of IP address resources under current ARIN policies and
>     sign an RSA."
>      > > to "For transfers larger than a /16 equivalent, the recipient must
>      > > demonstrate the need for up to a 24-month supply of IP address
>     resources
>      > > under current ARIN policies and sign an RSA."
>      >
>      > How would we go about assessing whether such changes prove harmful or
>      > helpful? What metrics does ARIN collect under this policy which
>     can be
>      > analyzed and presented here so we can consider expanding it to larger
>      > transfers? Does no justification mean no documentation?
>      >
>      > What makes you think /16 is the right place to start testing this
>      > idea? Traditionally /24 was the last no-justification request
>      > accepted. Why is that not the right place to start testing a new
>      > no-justification regime?
>      >
>      > For now I OPPOSE the proposal as written but I'd like to hear more.
>      >
>      > Regards,
>      > Bill Herrin
>      >
>      >
>      > --
>      > William D. Herrin ................ herrin at dirtside.com
>     <javascript:;> bill at herrin.us <javascript:;>
>      > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>      > Falls Church, VA 22042-3004
>      > _______________________________________________
>      > PPML
>      > You are receiving this message because you are subscribed to
>      > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>     <javascript:;>).
>      > Unsubscribe or manage your mailing list subscription at:
>      > http://lists.arin.net/mailman/listinfo/arin-ppml
>      > Please contact info at arin.net <javascript:;> if you experience any
>     issues.
>      >
>      >
>
>     --
>     John Santos
>     Evans Griffiths & Hart, Inc.
>     781-861-0670 ext 539
>
>     _______________________________________________
>     PPML
>     You are receiving this message because you are subscribed to
>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
>     Unsubscribe or manage your mailing list subscription at:
>     http://lists.arin.net/mailman/listinfo/arin-ppml
>     Please contact info at arin.net <javascript:;> 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.
>


-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================


From mike at iptrading.com  Wed Apr 30 18:41:04 2014
From: mike at iptrading.com (Mike Burns)
Date: Wed, 30 Apr 2014 18:41:04 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers (fwd)
References: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>
	<CAP-guGVxkHBOdL6VKAGwB7Z=SRr0RzaQQ6K5gsnAaq-gVkjzvg@mail.gmail.com>
Message-ID: <17D21BF24EC44EC695BAF3FF9768B17C@ncsscfoipoxes4>


> How would we go about assessing whether such changes prove harmful or
> helpful? What metrics does ARIN collect under this policy which can be
> analyzed and presented here so we can consider expanding it to larger
> transfers? Does no justification mean no documentation?
>
> What makes you think /16 is the right place to start testing this
> idea? Traditionally /24 was the last no-justification request
> accepted. Why is that not the right place to start testing a new
> no-justification regime?
>
> For now I OPPOSE the proposal as written but I'd like to hear more.
>
> Regards,
> Bill Herrin

Hi Bill,

I chose /16 as a starting point for negotiations because it is a common size 
I see in the brokerage business.

Removing the needs test serves many purposes. One that I have considered is 
the possibility for an Inter-RIR policy with RIPE.
I think this change at least lays the groundwork for that. I believe that a 
"compatible needs-based policy" would be a match for RIPE up to the point 
where ARIN needs tests would apply, since RIPEs needs test for transfers is 
less rigorous than ARIN's currently. But if ARIN drops the needs test up to 
a certain size, my hope is that the ARIN would recognize that the policies 
are now compatible for transfers lower than that certain size. I understand 
your reluctance to expose the remains of the free pool to possible predation 
through rinse-repeat allocations and sales, but the one per year allowance 
inhibits that, and we don't expect the free pool to be there much more than 
a year from now anyway.

Of course it also answers the needs of those who can't get addresses from 
their upstreams but don't qualify for the /20 minimum, without applying any 
additional draw on the free pool, but instead utilizing already allocated 
but unused space. We had a customer call today on just this issue. He has an 
acute need for a /24. His upstream has imposed a limit of 128 addresses. 
What can he do? He can acquire a shell corp with a /24 but those are few and 
far between. Absent that, what are his options? Answer is, he can lease the 
addresses or engage in an out-of-policy legacy transfer, both of which 
affect Whois accuracy negatively.

You ask how we can assess the effects of this policy, and I am not sure. 
Perhaps a count of small blocks transferred? If that increases, can we 
ascribe any rise to this policy? Probably not. Aborted 8.2 transfers don't 
apply. Maybe a count of aborted 8.3 transfers and 8.4 transfers?

Granted that it will be difficult to assess the impact of this policy beyond 
the anectodal hallelujahs from those who have been unable to secure 
addresses under current policy. But more important to me is the 
identification and assessment of potential downsides or risks. Are there any 
downsides or risks which you feel are important to address?

Would you support this policy if it were of limited duration and a smaller 
size, as Owen suggested?

Regards,
Mike





From mike at iptrading.com  Wed Apr 30 18:43:37 2014
From: mike at iptrading.com (Mike Burns)
Date: Wed, 30 Apr 2014 18:43:37 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
	IPv4Transfers (fwd)
References: <1140430175749.19573A-100000@Ives.egh.com>
Message-ID: <32A9641E5CE64832AA0FEB936C5B8196@ncsscfoipoxes4>

>
> Another idea to ponder would be instead of dropping the need requirement,
> we adopt a presumption of good faith for small allocations.  ARIN would
> simply take the word of the requester or recipient for small allocations
> or transfers, but if it was later discovered the recipient was acting in
> bad faith, the allocation could be revoked.

Hi John,

Just wanted to be sure we all recognize that this proposal would affect only 
transfers, not free pool allocations.
And transfers are subject to one per year limit.
But you are right that ARIN expends the same time scrutinizing transfers and 
allocations, and it may not be worth the time.

Regards,
Mike



From hannigan at gmail.com  Wed Apr 30 18:44:04 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 30 Apr 2014 18:44:04 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (fwd)
In-Reply-To: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>
References: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>
Message-ID: <CAMDXq5PqS-OQJ8Ypq+RXsEvTi-KNqv5W5XQCkGUW8Y+_9K_Nkg@mail.gmail.com>

Not in favor. Post exhaustion perhaps.



On Tuesday, April 29, 2014, John Springer <springer at inlandnet.com> wrote:

> Hi All,
>
> The following timely policy proposal is presented for your consideration,
> discussion and comment. Will you please comment?
>
> As always, expressions of support or opposition (and their reasons) are
> given slightly more weight than reasons why you might be in neither
> condition.
>
> John Springer
>
>
> ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers
>
> Date: 16 April 2014
> Problem Statement:
> ARIN staff, faced with a surge in near-exhaust allocations and subsequent
> transfer requests and a requirement for team review of these, is spending
> scarce staff time on needs testing of small transfers. This proposal seeks
> to decrease overall ARIN processing time through elimination of that needs
> test.
> Policy statement:
> Change the language in NRPM 8.3 after Conditions on the recipient of the
> transfer: from "The recipient must demonstrate the need for up to a
> 24-month supply of IP address resources under current ARIN policies and
> sign an RSA." to "For transfers larger than a /16 equivalent, the recipient
> must demonstrate the need for up to a 24-month supply of IP address
> resources under current ARIN policies and sign an RSA."
> Change the language in the third bullet point in NRPM 8.4 after Conditions
> on the recipient of the transfer: from "Recipients within the ARIN region
> must demonstrate the need for up to a 24-month supply of IPv4 address
> space." to "For transfers larger than a /16 equivalent, recipients in the
> ARIN region must demonstrate the need for up to a 24-month supply of IP
> address resources under current ARIN policies and sign an RSA."
> Comments:
> Needs testing has been maintained for transfers largely because the
> community wishes to ensure protection against hoarding and speculation in
> the IPv4 market. This proposal seeks a middle ground between the
> elimination of needs tests for transfers altogether, and the continuance of
> needs tests for every transfer. This should help ARIN staff to reduce
> transfer processing time, since most transfers have been smaller than /16.
> Timetable for implementation: Immediate
>
> _______________________________________________
> 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/20140430/ccdcf646/attachment.htm>

From mike at nationwideinc.com  Wed Apr 30 19:04:06 2014
From: mike at nationwideinc.com (Mike Burns)
Date: Wed, 30 Apr 2014 19:04:06 -0400
Subject: [arin-ppml] Fw: ARIN-prop-204 Removing Needs Test from Small
	IPv4Transfers (fwd)
Message-ID: <C869D23F219C499693C6FC9B0876A64A@ncsscfoipoxes4>

>> How would we go about assessing whether such changes prove harmful or
>> helpful? What metrics does ARIN collect under this policy which can be
>> analyzed and presented here so we can consider expanding it to larger
>> transfers? Does no justification mean no documentation?
>>
>> What makes you think /16 is the right place to start testing this
>> idea? Traditionally /24 was the last no-justification request
>> accepted. Why is that not the right place to start testing a new
>> no-justification regime?
>>
>> For now I OPPOSE the proposal as written but I'd like to hear more.
>>
>> Regards,
>> Bill Herrin
>
Hi Bill,

 I chose /16 as a starting point for negotiations because it is a common 
size
 I see in the brokerage business.

 Removing the needs test serves many purposes. One that I have considered is
 the possibility for an Inter-RIR policy with RIPE.
 I think this change at least lays the groundwork for that. I believe that a
 "compatible needs-based policy" would be a match for RIPE up to the point
 where ARIN needs tests would apply, since RIPEs needs test for transfers is
 less rigorous than ARIN's currently. But if ARIN drops the needs test up to
 a certain size, my hope is that the ARIN would recognize that the policies
 are now compatible for transfers lower than that certain size. I understand
 your reluctance to expose the remains of the free pool to possible 
predation
 through rinse-repeat allocations and sales, but the one per year allowance
 inhibits that, and we don't expect the free pool to be there much more than
 a year from now anyway.

 Of course it also answers the needs of those who can't get addresses from
 their upstreams but don't qualify for the /20 minimum, without applying any
 additional draw on the free pool, but instead utilizing already allocated
 but unused space. We had a customer call today on just this issue. He has 
an
 acute need for a /24. His upstream has imposed a limit of 128 addresses.
 What can he do? He can acquire a shell corp with a /24 but those are few 
and
 far between. Absent that, what are his options? Answer is, he can lease the
 addresses or engage in an out-of-policy legacy transfer, both of which
 affect Whois accuracy negatively.

You ask how we can assess the effects of this policy, and I am not sure.
 Perhaps a count of small blocks transferred? If that increases, can we
 ascribe any rise to this policy? Probably not. Aborted 8.2 transfers don't
 apply. Maybe a count of aborted 8.3 transfers and 8.4 transfers?

 Granted that it will be difficult to assess the impact of this policy 
beyond
 the anectodal hallelujahs from those who have been unable to secure
 addresses under current policy. But more important to me is the
 identification and assessment of potential downsides or risks. Are there 
any
 downsides or risks which you feel are important to address?

 Would you support this policy if it were of limited duration and a smaller
 size, as Owen suggested?

 Regards,
 Mike
>
>
>
> _______________________________________________
> 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.
> 



From mike at nationwideinc.com  Wed Apr 30 19:04:34 2014
From: mike at nationwideinc.com (Mike Burns)
Date: Wed, 30 Apr 2014 19:04:34 -0400
Subject: [arin-ppml] Fw: ARIN-prop-204 Removing Needs Test from
	SmallIPv4Transfers (fwd)
Message-ID: <C84D93B4B4804405AAF6C70BC17A9096@ncsscfoipoxes4>



> >
>> Another idea to ponder would be instead of dropping the need requirement,
>> we adopt a presumption of good faith for small allocations.  ARIN would
>> simply take the word of the requester or recipient for small allocations
>> or transfers, but if it was later discovered the recipient was acting in
>> bad faith, the allocation could be revoked.
>
 Hi John,

 Just wanted to be sure we all recognize that this proposal would affect 
only
 transfers, not free pool allocations.
 And transfers are subject to one per year limit.
 But you are right that ARIN expends the same time scrutinizing transfers 
and
 allocations, and it may not be worth the time.

 Regards,
 Mike



From sandrabrown at ipv4marketgroup.com  Wed Apr 30 19:20:16 2014
From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com)
Date: Wed, 30 Apr 2014 16:20:16 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
Message-ID: <20140430162016.ec289651d84890fcbef5f195936e1217.4c9c834b4e.wbe@email17.secureserver.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/63a1ac48/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sigimg0
Type: image/png
Size: 33354 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/63a1ac48/attachment.png>

From hannigan at gmail.com  Wed Apr 30 19:35:33 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 30 Apr 2014 19:35:33 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
In-Reply-To: <20140430162016.ec289651d84890fcbef5f195936e1217.4c9c834b4e.wbe@email17.secureserver.net>
References: <20140430162016.ec289651d84890fcbef5f195936e1217.4c9c834b4e.wbe@email17.secureserver.net>
Message-ID: <2BE124C5-2D49-4831-9BDA-CD0EE3D31F64@gmail.com>


Of course you would say that. (Smiley). 

You think it accelerates exhaustion. Trust me, it needs no help. Sit back and let real stakeholders define our own destiny please. 

Best, 

-M< 



> On Apr 30, 2014, at 19:20, <sandrabrown at ipv4marketgroup.com> wrote:
> 
> 
> 
> <sigimg0>
> 
> 
> 
> Message: 4
> Date: Wed, 30 Apr 2014 18:44:04 -0400
> From: Martin Hannigan <hannigan at gmail.com>
> To: John Springer <springer at inlandnet.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
> IPv4 Transfers (fwd)
> Message-ID:
> <CAMDXq5PqS-OQJ8Ypq+RXsEvTi-KNqv5W5XQCkGUW8Y+_9K_Nkg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Not in favor. Post exhaustion perhaps.
> 
> 
> To negate Mr. Hannigan's point, 
> 
> 1) it will not be an abuse vector, as it is only for transfers, not for requests from the ARIN free pool.
> 
> 2) There is no need to wait for exhaustion, as transfers are the same pre as post exhaustion.
> 
> If anything removal of needs justification prior to exhaustion will cause the ARIN free pool to last longer.
> 
> Sandra Brown
> IPv4 Market Group
> _______________________________________________
> 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/20140430/e8b5212c/attachment.htm>

From sandrabrown at ipv4marketgroup.com  Wed Apr 30 19:44:51 2014
From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com)
Date: Wed, 30 Apr 2014 16:44:51 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers
Message-ID: <20140430164451.ec289651d84890fcbef5f195936e1217.59548c3c7f.wbe@email17.secureserver.net>

I would like to address Mr. Herrin's questions below.

------

Message: 2
Date: Wed, 30 Apr 2014 17:39:03 -0400
From: William Herrin <bill at herrin.us>
To: John Springer <springer at inlandnet.com>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
 IPv4 Transfers (fwd)
Message-ID:
 <CAP-guGVxkHBOdL6VKAGwB7Z=SRr0RzaQQ6K5gsnAaq-gVkjzvg at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Tue, Apr 29, 2014 at 1:35 AM, John Springer <springer at inlandnet.com>
wrote:
> ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers
>
> Policy statement:
> Change the language in NRPM 8.3 after Conditions on the recipient of the
> transfer: from "The recipient must demonstrate the need for up to a 24-month
> supply of IP address resources under current ARIN policies and sign an RSA."
> to "For transfers larger than a /16 equivalent, the recipient must
> demonstrate the need for up to a 24-month supply of IP address resources
> under current ARIN policies and sign an RSA."

How would we go about assessing whether such changes prove harmful or
helpful? 
----------
1.  There was the interesting statistic that 11 companies get x% (need
David to restate) from the free pool.
meaning that the free pool is not going to the vast number of small
businesses in North America, even though
all statistics show them to be the largest employers.
2.  There is the interesting discussion on this very PPML of the case of
 Derek Calanchini who can't get IPv4 addresses with current ARIN rules. 
I hear these stories every week.  I'm sure ARIN staff could tell you
these stories and give you metrics, if they tracked them.
3.  It will not touch the free pool, and if anything, will cause more
transfers of previously allocated IP's, not free ARIN IP's, and
therefore, could cause the ARIN free pool to last longer.
4.  Transfer stats are currently very low.  ARIN staff publish these. 
Simply watch how they trend over time to assess change.
----

What metrics does ARIN collect under this policy which can be
analyzed and presented here so we can consider expanding it to larger
transfers? 
------
1.  Publishes all transfers (and there are not very many of them today).
-----

Does no justification mean no documentation?
----
1.  8.3 and 8.4 still require affidavits and "proof of ownership".
2.  Still require a transfer fee.
------

What makes you think /16 is the right place to start testing this
idea? 
-----
1.  Will cover, in my estimation, and I'm sure ARIN staff can tell you
more accurately, 95-99% of transfers.
------
Traditionally /24 was the last no-justification request
accepted. Why is that not the right place to start testing a new
no-justification regime?
_________________________________________________________________________________________________________________
1.  We proposed no needs 2 years ago and got push back that the time was
not right.  A lot has changed since then.  RIPE has implemented no need.
 North America is being left behind by Europe.  It is a serious problem
when pseudo-government tells you whether you can buy IP's in North
America, but your competitors are free to buy IP's in Europe.  North
America is supposed to be the leading free market in the world, but
apparently not in the internet space.  

2.  A /24 is only 256 IP's.  This is, and ARIN staff can confirm this,
probably 30-40 % of all ARIN requests.  In my transfer world, it is more
like 10% of requests, and frankly, we don't do /24 requests because they
are too small.  To be worthwhile, it has to be a meaningful size range. 
A /16 is about 25% of our transfer requests.

I have not heard a valid reason to oppose a /16  no needs policy:
- not hoarding
- not lack of control

I have heard FUD - fear, uncertainty and doubt.  I have heard lack of
understanding, thinking it applied to the free pool, but it does not.  

I have not heard a valid REASON to deny this policy:  This policy will
help small and medium sized business in the US, Canada and the
Caribbean.  

Sandra Brown
IPv4 Market Group
-------------------------------------------------------------------------------------------

For now I OPPOSE the proposal as written but I'd like to hear more.

Regards,
Bill Herrin



From andrew.dul at quark.net  Wed Apr 30 19:45:02 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Wed, 30 Apr 2014 16:45:02 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (Sandra Brown)
In-Reply-To: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
Message-ID: <53618AFE.8090903@quark.net>

On 4/30/2014 1:55 PM, sandrabrown at ipv4marketgroup.com wrote:
> BUT:  With the limitation of the transfer size to a /16 or smaller, it
> would take a lot of transfers to hoard.  It would take 256 transfers to
> stockpile a /8.  This is the 2nd means to prevent hoarding.  Most
> companies wanting that many IP's would simply do needs justification. 
It seems trivial to me to divide a /8 into /16s or any other smaller
block so I could transfer it without doing the needs justification.  I
could write a script for the transfer templates and just send them off. 
Once the legwork for the first transfer is complete, the rest should
just flow right through.  Nothing I see in the current text or policy
prevents someone from taking a larger block and slicing it up to get
under the /16 limit.  Since most of the brokers are out speculating that
these blocks have significant value it seems clear that if the large
players need them they will just be paying a staff person a few extra
hours to manage this overhead.

Does the current policy need to change?  Yes.  Do I think this policy
proposal is the right answer, No.

Andrew





From scottleibrand at gmail.com  Wed Apr 30 19:50:10 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 30 Apr 2014 16:50:10 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers (Sandra Brown)
In-Reply-To: <53618AFE.8090903@quark.net>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<53618AFE.8090903@quark.net>
Message-ID: <F28793E3-EFFE-47D9-9EC3-BB13684D3A01@gmail.com>


> On Apr 30, 2014, at 4:45 PM, Andrew Dul <andrew.dul at quark.net> wrote:
> 
>> On 4/30/2014 1:55 PM, sandrabrown at ipv4marketgroup.com wrote:
>> BUT:  With the limitation of the transfer size to a /16 or smaller, it
>> would take a lot of transfers to hoard.  It would take 256 transfers to
>> stockpile a /8.  This is the 2nd means to prevent hoarding.  Most
>> companies wanting that many IP's would simply do needs justification.
> It seems trivial to me to divide a /8 into /16s or any other smaller
> block so I could transfer it without doing the needs justification.  I
> could write a script for the transfer templates and just send them off. 
> Once the legwork for the first transfer is complete, the rest should
> just flow right through.  Nothing I see in the current text or policy
> prevents someone from taking a larger block and slicing it up to get
> under the /16 limit.  Since most of the brokers are out speculating that
> these blocks have significant value it seems clear that if the large
> players need them they will just be paying a staff person a few extra
> hours to manage this overhead.

Current transfer policy operates on the *recipient* of the transfer. It requires that they meet their need with a single block, and prevents repeated transfers to circumvent that. 

Scott

> 
> Does the current policy need to change?  Yes.  Do I think this policy
> proposal is the right answer, No.
> 
> Andrew
> 
> 
> 
> _______________________________________________
> 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.


From mike at nationwideinc.com  Wed Apr 30 19:56:31 2014
From: mike at nationwideinc.com (Mike Burns)
Date: Wed, 30 Apr 2014 19:56:31 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers (Sandra Brown)
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<53618AFE.8090903@quark.net>
Message-ID: <BC07E05EDDE34CEC847985F4DF5F5CFF@ncsscfoipoxes4>

Hi Andrew,

I don't understand what the problem is.
Are you saying that a recipient who wanted more than a /16 but was unwilling 
to demonstrate need would create separate entities?
Remember only one transfer per year.

Regards
Mike

----- Original Message ----- 
From: "Andrew Dul" <andrew.dul at quark.net>
To: <arin-ppml at arin.net>
Sent: Wednesday, April 30, 2014 7:45 PM
Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4 
Transfers (Sandra Brown)


> On 4/30/2014 1:55 PM, sandrabrown at ipv4marketgroup.com wrote:
>> BUT:  With the limitation of the transfer size to a /16 or smaller, it
>> would take a lot of transfers to hoard.  It would take 256 transfers to
>> stockpile a /8.  This is the 2nd means to prevent hoarding.  Most
>> companies wanting that many IP's would simply do needs justification.
> It seems trivial to me to divide a /8 into /16s or any other smaller
> block so I could transfer it without doing the needs justification.  I
> could write a script for the transfer templates and just send them off.
> Once the legwork for the first transfer is complete, the rest should
> just flow right through.  Nothing I see in the current text or policy
> prevents someone from taking a larger block and slicing it up to get
> under the /16 limit.  Since most of the brokers are out speculating that
> these blocks have significant value it seems clear that if the large
> players need them they will just be paying a staff person a few extra
> hours to manage this overhead.
>
> Does the current policy need to change?  Yes.  Do I think this policy
> proposal is the right answer, No.
>
> Andrew
>
>
>
> _______________________________________________
> 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.
> 



From sandrabrown at ipv4marketgroup.com  Wed Apr 30 19:56:51 2014
From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com)
Date: Wed, 30 Apr 2014 16:56:51 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
Message-ID: <20140430165651.ec289651d84890fcbef5f195936e1217.79c6ddfbd0.wbe@email17.secureserver.net>

Martin:

I think making transfers of already allocated IP's easier,  makes the
free pool last longer.  This decelerates, not accelerates, exhaustion.  
The impact will probably be slight because the buyers, the transferors,
are the medium to little guys, not David's 11 who are getting the vast
majority of the IP's.

Of course, making the free pool last longer could allow companies who
know how to work the current ARIN policy system, get even more  blocks
over the next few months.  You don't know of any large companies that
got a /10 from the free pool lately, do you? 

(Smiley)

Best,
Sandra


-------- Original Message --------
Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
IPv4
From: Martin Hannigan <hannigan at gmail.com>
Date: Wed, April 30, 2014 7:35 pm
To: "<sandrabrown at ipv4marketgroup.com>"
<sandrabrown at ipv4marketgroup.com>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>



Of course you would say that. (Smiley). 


You think it accelerates exhaustion. Trust me, it needs no help. Sit
back and let real stakeholders define our own destiny please. 


Best, 


-M< 





On Apr 30, 2014, at 19:20, <sandrabrown at ipv4marketgroup.com> wrote:






<sigimg0>



 
 Message: 4
 Date: Wed, 30 Apr 2014 18:44:04 -0400
 From: Martin Hannigan <hannigan at gmail.com>
 To: John Springer <springer at inlandnet.com>
 Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
 Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
 IPv4 Transfers (fwd)
 Message-ID:
 <CAMDXq5PqS-OQJ8Ypq+RXsEvTi-KNqv5W5XQCkGUW8Y+_9K_Nkg at mail.gmail.com>
 Content-Type: text/plain; charset="iso-8859-1"
 
 Not in favor. Post exhaustion perhaps.



To negate Mr. Hannigan's point, 


1) it will not be an abuse vector, as it is only for transfers, not for
requests from the ARIN free pool.


2) There is no need to wait for exhaustion, as transfers are the same
pre as post exhaustion.


If anything removal of needs justification prior to exhaustion will
cause the ARIN free pool to last longer.


Sandra Brown
IPv4 Market Group

_______________________________________________
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.


From andrew.dul at quark.net  Wed Apr 30 20:04:06 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Wed, 30 Apr 2014 17:04:06 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (Sandra Brown)
In-Reply-To: <F28793E3-EFFE-47D9-9EC3-BB13684D3A01@gmail.com>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<53618AFE.8090903@quark.net>
	<F28793E3-EFFE-47D9-9EC3-BB13684D3A01@gmail.com>
Message-ID: <53618F76.9040905@quark.net>

On 4/30/2014 4:50 PM, Scott Leibrand wrote:
>> On Apr 30, 2014, at 4:45 PM, Andrew Dul <andrew.dul at quark.net> wrote:
>>
>>> On 4/30/2014 1:55 PM, sandrabrown at ipv4marketgroup.com wrote:
>>> BUT:  With the limitation of the transfer size to a /16 or smaller, it
>>> would take a lot of transfers to hoard.  It would take 256 transfers to
>>> stockpile a /8.  This is the 2nd means to prevent hoarding.  Most
>>> companies wanting that many IP's would simply do needs justification.
>> It seems trivial to me to divide a /8 into /16s or any other smaller
>> block so I could transfer it without doing the needs justification.  I
>> could write a script for the transfer templates and just send them off. 
>> Once the legwork for the first transfer is complete, the rest should
>> just flow right through.  Nothing I see in the current text or policy
>> prevents someone from taking a larger block and slicing it up to get
>> under the /16 limit.  Since most of the brokers are out speculating that
>> these blocks have significant value it seems clear that if the large
>> players need them they will just be paying a staff person a few extra
>> hours to manage this overhead.
> Current transfer policy operates on the *recipient* of the transfer. It requires that they meet their need with a single block, and prevents repeated transfers to circumvent that. 
>
>
Conditions on recipient of the transfer:

  * The recipient must demonstrate the need for up to a 24-month supply
    of IP address resources under current ARIN policies and sign an RSA.
  * The resources transferred will be subject to current ARIN policies.



Scott, I don't see any restrictions on the recipient that would prevent
them from receiving multiple blocks...where do you see that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/f20961d0/attachment.htm>

From andrew.dul at quark.net  Wed Apr 30 20:10:58 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Wed, 30 Apr 2014 17:10:58 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (Sandra Brown)
In-Reply-To: <BC07E05EDDE34CEC847985F4DF5F5CFF@ncsscfoipoxes4>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<53618AFE.8090903@quark.net>
	<BC07E05EDDE34CEC847985F4DF5F5CFF@ncsscfoipoxes4>
Message-ID: <53619112.9000807@quark.net>

On 4/30/2014 4:56 PM, Mike Burns wrote:
> Hi Andrew,
>
> I don't understand what the problem is.
> Are you saying that a recipient who wanted more than a /16 but was
> unwilling to demonstrate need would create separate entities?

Separate entities I don't believe are needed, just slice up the block in
to smaller blocks, and then transfer the smaller blocks. (If you wanted
you could get tricky with the bit-math so the sliced up blocks can't be
aggregated into a larger block)

> Remember only one transfer per year.
>
My read is that the one year restriction is only on the source entity
and it only prevents them from receiving addresses within that period,
not from doing additional transfers out.

Andrew

>
> ----- Original Message ----- From: "Andrew Dul" <andrew.dul at quark.net>
> To: <arin-ppml at arin.net>
> Sent: Wednesday, April 30, 2014 7:45 PM
> Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
> IPv4 Transfers (Sandra Brown)
>
>
>> On 4/30/2014 1:55 PM, sandrabrown at ipv4marketgroup.com wrote:
>>> BUT:  With the limitation of the transfer size to a /16 or smaller, it
>>> would take a lot of transfers to hoard.  It would take 256 transfers to
>>> stockpile a /8.  This is the 2nd means to prevent hoarding.  Most
>>> companies wanting that many IP's would simply do needs justification.
>> It seems trivial to me to divide a /8 into /16s or any other smaller
>> block so I could transfer it without doing the needs justification.  I
>> could write a script for the transfer templates and just send them off.
>> Once the legwork for the first transfer is complete, the rest should
>> just flow right through.  Nothing I see in the current text or policy
>> prevents someone from taking a larger block and slicing it up to get
>> under the /16 limit.  Since most of the brokers are out speculating that
>> these blocks have significant value it seems clear that if the large
>> players need them they will just be paying a staff person a few extra
>> hours to manage this overhead.
>>
>> Does the current policy need to change?  Yes.  Do I think this policy
>> proposal is the right answer, No.
>>
>> Andrew
>>
>>
>>
>> _______________________________________________
>> 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.
>>
>



From drc at virtualized.org  Wed Apr 30 20:11:59 2014
From: drc at virtualized.org (David Conrad)
Date: Wed, 30 Apr 2014 17:11:59 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
	IPv4Transfers (Sandra Brown)
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201529ADAE6@ENI-MAIL.eclipse-networks.com>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<5B9E90747FA2974D91A54FCFA1B8AD1201529ADAE6@ENI-MAIL.eclipse-networks.com>
Message-ID: <0FDFAD20-C870-4F19-A09D-CFA33C61BE57@virtualized.org>

Hi,

On Apr 30, 2014, at 2:00 PM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:
> Amen!  ARIN's raison d'?tre is to allocate resources.  

That is part of ARIN's reason to exist, one that becomes significantly less relevant as the free pool exhausts.

ARIN also exists to maintain an accurate registry. This reason becomes significantly more important both as the free pool exhausts and afterwards.

Inasmuch as this proposal helps ensure that transfers are accurately recorded, I support.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/e9d16e70/attachment.sig>

From drc at virtualized.org  Wed Apr 30 20:15:07 2014
From: drc at virtualized.org (David Conrad)
Date: Wed, 30 Apr 2014 17:15:07 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
	IPv4Transfers (Sandra Brown)
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201529ADAE6@ENI-MAIL.eclipse-networks.com>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<5B9E90747FA2974D91A54FCFA1B8AD1201529ADAE6@ENI-MAIL.eclipse-networks.com>
Message-ID: <0FC7DE8B-CD3A-4315-B0AE-998A389D5D4F@virtualized.org>

[apologies if duplicate -- mail client issues :(]

Hi,

On Apr 30, 2014, at 2:00 PM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:
> Amen!  ARIN's raison d'?tre is to allocate resources.  

That is part of ARIN's reason to exist, one that becomes significantly less relevant as the free pool exhausts.

ARIN also exists to maintain an accurate registry. This reason becomes significantly more important both as the free pool exhausts and afterwards.

Inasmuch as this proposal helps ensure that transfers are accurately recorded, I support.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/e3fb1d20/attachment.sig>

From springer at inlandnet.com  Wed Apr 30 20:17:40 2014
From: springer at inlandnet.com (John Springer)
Date: Wed, 30 Apr 2014 17:17:40 -0700 (PDT)
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (fwd)
In-Reply-To: <1140430175749.19573A-100000@Ives.egh.com>
References: <1140430175749.19573A-100000@Ives.egh.com>
Message-ID: <alpine.BSF.2.00.1404301508580.90136@mail.inlandnet.com>

Hi Bill and John,

Thank you for the thoughtful responses. As a purely process note, please 
allow me to point out that what we have here, ARIN-prop-204, is merely a 
policy proposal. I will do my best to answer comments and questions posed 
inline, but they appear to relate to later steps in the process. At this 
point, when I propose that this proposal be advanced to Draft Policy, the 
only two tests are: Is there a clear problem statement and is that problem 
statement in scope for the AC (for which I am in no way speaking on behalf 
of right now). From my perspective, I am tending toward asserting that 
these criteria have been met, but I am very much interested in opinions to 
the contrary.

On to your comments.

On Wed, 30 Apr 2014, John Santos wrote:

>
> I agree with Bill.

I am going to interpret this as agreeing with his oppostion, as the rest 
of his post was questions.

> It might be appropriate to drop needs testing for
> small allocations simply because it is not worth the effort, but I don't
> see a /16 as being small.  Something in the range of /24 to /20 would
> be better.

The author has expressed that he has thrown out the metric of /16 as a 
basis for discussion. This proposal is couched in terms of reducing ARIN 
staff processing load. If I am understanding the author correctly, setting 
the bar at /16 will have a much greater effect on staffing load than a 
lower bar. It may be that enough of the load is present at say /20 that a 
substantial effect may be realized. It's OK that we talk about the setting 
of this bar now, but it is not directly germane to the next step in the 
PDP.

> Another idea to ponder would be instead of dropping the need requirement,
> we adopt a presumption of good faith for small allocations.  ARIN would
> simply take the word of the requester or recipient for small allocations
> or transfers, but if it was later discovered the recipient was acting in
> bad faith, the allocation could be revoked.

This just seems to me to be Not A Good Idea. I'd have to think on it 
some to elaborate.

> On Wed, 30 Apr 2014, William Herrin wrote:
>
>> On Tue, Apr 29, 2014 at 1:35 AM, John Springer <springer at inlandnet.com> wrote:
>>> ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers
>>>
>>> Policy statement:
>>> Change the language in NRPM 8.3 after Conditions on the recipient of the
>>> transfer: from "The recipient must demonstrate the need for up to a 24-month
>>> supply of IP address resources under current ARIN policies and sign an RSA."
>>> to "For transfers larger than a /16 equivalent, the recipient must
>>> demonstrate the need for up to a 24-month supply of IP address resources
>>> under current ARIN policies and sign an RSA."
>>
>> How would we go about assessing whether such changes prove harmful or
>> helpful?
>>
>> What metrics does ARIN collect under this policy which can be
>> analyzed and presented here so we can consider expanding it to larger
>> transfers?

TBD? Speculative? The usual ways? I'm not sure I would advise inserting 
that level of stuff in policy. It might not be germane at this point in 
the PDP, but I will think on it as the process continues. I feel sure that 
you know of: https://www.arin.net/knowledge/statistics/index.html

ARIN staff has shown willing to provide stats not present there.

>> Does no justification mean no documentation?

This seems more philosophical. I hate to try to guess what your opinion 
is from the proposition. I don't have much of one at this point.

>> What makes you think /16 is the right place to start testing this
>> idea? Traditionally /24 was the last no-justification request
>> accepted. Why is that not the right place to start testing a new
>> no-justification regime?

That the author chose this level to couch his proposal in does not seem to 
make his problem statement unclear or out of scope. I take it from the 
gist that you are more aligned with John Santos' opinion that "Something 
in the range of /24 to /20 would be better."?

John Springer

>> For now I OPPOSE the proposal as written but I'd like to hear more.
>>
>> Regards,
>> Bill Herrin
>>
>>
>> --
>> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
>> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>> Falls Church, VA 22042-3004
>> _______________________________________________
>> 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.
>>
>>
>
> -- 
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
>
>
>


From mike at nationwideinc.com  Wed Apr 30 20:20:35 2014
From: mike at nationwideinc.com (Mike Burns)
Date: Wed, 30 Apr 2014 20:20:35 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers (Sandra Brown)
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<53618AFE.8090903@quark.net>
	<BC07E05EDDE34CEC847985F4DF5F5CFF@ncsscfoipoxes4>
	<53619112.9000807@quark.net>
Message-ID: <29F8FD39FDC94A4F8A97C6321DDC5B43@ncsscfoipoxes4>

Hi Andrew,

Yeah, you're right, my bad.
I thought there was a limit on the recipient, too.

If there is enough interest in pursuing this policy change, I suppose 
language can be added that restricts needs-free transfers to once per year.
It was my intention that such a limit be in place.
Can we consider, for future discussion, that such language is included in 
the proposal?
I will submit a changed proposal tomorrow with a limit of one needs-free 
transfer per year, like this:

"For block sizes of /16 and smaller and for recipients who have not engaged 
in a transfer during the previous year, etc."

Regards,
Mike


----- Original Message ----- 
From: "Andrew Dul" <andrew.dul at quark.net>
To: "Mike Burns" <mike at nationwideinc.com>; <arin-ppml at arin.net>
Sent: Wednesday, April 30, 2014 8:10 PM
Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4 
Transfers (Sandra Brown)


> On 4/30/2014 4:56 PM, Mike Burns wrote:
>> Hi Andrew,
>>
>> I don't understand what the problem is.
>> Are you saying that a recipient who wanted more than a /16 but was
>> unwilling to demonstrate need would create separate entities?
>
> Separate entities I don't believe are needed, just slice up the block in
> to smaller blocks, and then transfer the smaller blocks. (If you wanted
> you could get tricky with the bit-math so the sliced up blocks can't be
> aggregated into a larger block)
>
>> Remember only one transfer per year.
>>
> My read is that the one year restriction is only on the source entity
> and it only prevents them from receiving addresses within that period,
> not from doing additional transfers out.
>
> Andrew
>
>>
>> ----- Original Message ----- From: "Andrew Dul" <andrew.dul at quark.net>
>> To: <arin-ppml at arin.net>
>> Sent: Wednesday, April 30, 2014 7:45 PM
>> Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
>> IPv4 Transfers (Sandra Brown)
>>
>>
>>> On 4/30/2014 1:55 PM, sandrabrown at ipv4marketgroup.com wrote:
>>>> BUT:  With the limitation of the transfer size to a /16 or smaller, it
>>>> would take a lot of transfers to hoard.  It would take 256 transfers to
>>>> stockpile a /8.  This is the 2nd means to prevent hoarding.  Most
>>>> companies wanting that many IP's would simply do needs justification.
>>> It seems trivial to me to divide a /8 into /16s or any other smaller
>>> block so I could transfer it without doing the needs justification.  I
>>> could write a script for the transfer templates and just send them off.
>>> Once the legwork for the first transfer is complete, the rest should
>>> just flow right through.  Nothing I see in the current text or policy
>>> prevents someone from taking a larger block and slicing it up to get
>>> under the /16 limit.  Since most of the brokers are out speculating that
>>> these blocks have significant value it seems clear that if the large
>>> players need them they will just be paying a staff person a few extra
>>> hours to manage this overhead.
>>>
>>> Does the current policy need to change?  Yes.  Do I think this policy
>>> proposal is the right answer, No.
>>>
>>> Andrew
>>>
>>>
>>>
>>> _______________________________________________
>>> 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.
>>>
>>
> 



From hannigan at gmail.com  Wed Apr 30 20:28:20 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 30 Apr 2014 20:28:20 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
In-Reply-To: <20140430165651.ec289651d84890fcbef5f195936e1217.79c6ddfbd0.wbe@email17.secureserver.net>
References: <20140430165651.ec289651d84890fcbef5f195936e1217.79c6ddfbd0.wbe@email17.secureserver.net>
Message-ID: <CAMDXq5PVyE2WxcKMzK5QdXjWEaVx3y2pPxB6BobqcfLOTGLKsQ@mail.gmail.com>

Sandra,

The goal isn't to extend the free pool. There is no goal. We'll exhaust
based on current policy.  This is bad policy that benefits few.

PLease elaborate on your questions about recent assignments. Happy to
educate you.

Best,

-M<

On Wednesday, April 30, 2014, <sandrabrown at ipv4marketgroup.com> wrote:

> Martin:
>
> I think making transfers of already allocated IP's easier,  makes the
> free pool last longer.  This decelerates, not accelerates, exhaustion.
> The impact will probably be slight because the buyers, the transferors,
> are the medium to little guys, not David's 11 who are getting the vast
> majority of the IP's.
>
> Of course, making the free pool last longer could allow companies who
> know how to work the current ARIN policy system, get even more  blocks
> over the next few months.  You don't know of any large companies that
> got a /10 from the free pool lately, do you?
>
> (Smiley)
>
> Best,
> Sandra
>
>
> -------- Original Message --------
> Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
> IPv4
> From: Martin Hannigan <hannigan at gmail.com <javascript:;>>
> Date: Wed, April 30, 2014 7:35 pm
> To: "<sandrabrown at ipv4marketgroup.com <javascript:;>>"
> <sandrabrown at ipv4marketgroup.com <javascript:;>>
> Cc: "arin-ppml at arin.net <javascript:;>" <arin-ppml at arin.net <javascript:;>
> >
>
>
>
> Of course you would say that. (Smiley).
>
>
> You think it accelerates exhaustion. Trust me, it needs no help. Sit
> back and let real stakeholders define our own destiny please.
>
>
> Best,
>
>
> -M<
>
>
>
>
>
> On Apr 30, 2014, at 19:20, <sandrabrown at ipv4marketgroup.com <javascript:;>>
> wrote:
>
>
>
>
>
>
> <sigimg0>
>
>
>
>
>  Message: 4
>  Date: Wed, 30 Apr 2014 18:44:04 -0400
>  From: Martin Hannigan <hannigan at gmail.com <javascript:;>>
>  To: John Springer <springer at inlandnet.com <javascript:;>>
>  Cc: "arin-ppml at arin.net <javascript:;>" <arin-ppml at arin.net<javascript:;>
> >
>  Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
>  IPv4 Transfers (fwd)
>  Message-ID:
>  <CAMDXq5PqS-OQJ8Ypq+RXsEvTi-KNqv5W5XQCkGUW8Y+_9K_Nkg at mail.gmail.com<javascript:;>
> >
>  Content-Type: text/plain; charset="iso-8859-1"
>
>  Not in favor. Post exhaustion perhaps.
>
>
>
> To negate Mr. Hannigan's point,
>
>
> 1) it will not be an abuse vector, as it is only for transfers, not for
> requests from the ARIN free pool.
>
>
> 2) There is no need to wait for exhaustion, as transfers are the same
> pre as post exhaustion.
>
>
> If anything removal of needs justification prior to exhaustion will
> cause the ARIN free pool to last longer.
>
>
> Sandra Brown
> IPv4 Market Group
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/be072180/attachment.htm>

From michael at linuxmagic.com  Wed Apr 30 20:38:54 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Wed, 30 Apr 2014 17:38:54 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
 IPv4Transfers (Sandra Brown)
In-Reply-To: <0FDFAD20-C870-4F19-A09D-CFA33C61BE57@virtualized.org>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>	<5B9E90747FA2974D91A54FCFA1B8AD1201529ADAE6@ENI-MAIL.eclipse-networks.com>
	<0FDFAD20-C870-4F19-A09D-CFA33C61BE57@virtualized.org>
Message-ID: <5361979E.2020808@linuxmagic.com>

On 14-04-30 05:11 PM, David Conrad wrote:
> ARIN also exists to maintain an accurate registry. This reason becomes significantly more important both as the free pool exhausts and afterwards.

It is this area I would like to see some new changes, it is impossible 
to accomplish this, if there is no mandate on enforcing the requirements 
after allocation..

As pointed out recently, if an organization 'chooses' not to perform 
rwhois on their IP(s) or if they simply let the rwhois service die and 
wither, ARIN has no enforcement ability to make the organization keep 
their rwhois servers functioning and up to date.

A report to ARIN about the issue, doesn't even mean it will be escalated 
to the organization, unless the organization applies for more space.

And some of the large allocations in the last six months have gone to 
organizations without currently working rwhois servers on their existing 
space.

This is especially prevalent amongst the hosting companies of course, as 
they do most of the sale/delegation/rental of sub-space to companies.

Until ARIN, (or some other party) can be empowered with the 'if you 
don't do this.. we hit you with a stick..', abuse will continue to 
occur.. and the idea of 'maintaining an accurate registry' will only be 
accurate at the top level.

Now, we have some very great net citizens, who diligently keep good 
records, but as long as nothing happens to those who do not, you can 
expect that even those good records will crumble, as not worth the effort.

I know the whois topic is a hot button, but ideas on how to mandate 
enforcement to ARIN is something I would like to hear about.  What would 
enforcement look like? Loose 10% of your IP Space each year if you don't 
keep good rwhois records? I don't know, need to think of something 
imaginative in order for ARIN to serve the mandate..

(Now that Derek's email started the ball rolling on that well over due 
change, let's keep it going?)

With the diminishing pool, we need more real information about existing 
operators needs, before allowing new allocations.. (especially to a few 
very large operators, with the worst history of performing rwhois, who 
still get new allocations given them) which can only come from accurate 
and functioning rwhois server records.


I recognize, any empowerment of ARIN for enforcement is a divisive 
topic, and has been for some time, but it doesn't mean we shouldn't look 
for a solution.




-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From hkl at softlinx.com  Wed Apr 30 21:10:03 2014
From: hkl at softlinx.com (Hikyu Lee)
Date: Wed, 30 Apr 2014 21:10:03 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers
Message-ID: <CAH1sMd_o+GwK7yfjttOm8NU+1+N-hYS9Bqa5tfDiLvp3Hx2W5A@mail.gmail.com>

Support  - I agree with Sandra Brown.
_____________
Hikyu Lee
President
Softlinx, Inc.
Work: +1.978.881.0561
Mobile: +1.978.502.4283
Email: hkl at softlinx.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/20b4093a/attachment.htm>

From scottleibrand at gmail.com  Wed Apr 30 21:40:45 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 30 Apr 2014 18:40:45 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers (Sandra Brown)
In-Reply-To: <53618F76.9040905@quark.net>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<53618AFE.8090903@quark.net>
	<F28793E3-EFFE-47D9-9EC3-BB13684D3A01@gmail.com>
	<53618F76.9040905@quark.net>
Message-ID: <E227D6B9-ACC3-44F3-BCCA-28CD444F5694@gmail.com>


> On Apr 30, 2014, at 5:04 PM, Andrew Dul <andrew.dul at quark.net> wrote:
> 
>> On 4/30/2014 4:50 PM, Scott Leibrand wrote:
>>>> On Apr 30, 2014, at 4:45 PM, Andrew Dul <andrew.dul at quark.net> wrote:
>>>> 
>>>> On 4/30/2014 1:55 PM, sandrabrown at ipv4marketgroup.com wrote:
>>>> BUT:  With the limitation of the transfer size to a /16 or smaller, it
>>>> would take a lot of transfers to hoard.  It would take 256 transfers to
>>>> stockpile a /8.  This is the 2nd means to prevent hoarding.  Most
>>>> companies wanting that many IP's would simply do needs justification.
>>> It seems trivial to me to divide a /8 into /16s or any other smaller
>>> block so I could transfer it without doing the needs justification.  I
>>> could write a script for the transfer templates and just send them off. 
>>> Once the legwork for the first transfer is complete, the rest should
>>> just flow right through.  Nothing I see in the current text or policy
>>> prevents someone from taking a larger block and slicing it up to get
>>> under the /16 limit.  Since most of the brokers are out speculating that
>>> these blocks have significant value it seems clear that if the large
>>> players need them they will just be paying a staff person a few extra
>>> hours to manage this overhead.
>> Current transfer policy operates on the *recipient* of the transfer. It requires that they meet their need with a single block, and prevents repeated transfers to circumvent that. 
>> 
>> 
> Conditions on recipient of the transfer:
> The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA.
> The resources transferred will be subject to current ARIN policies.
> 
> 
> Scott, I don't see any restrictions on the recipient that would prevent them from receiving multiple blocks...where do you see that?

It's hiding in 4.1.8: 

Repeated requests, in a manner that would circumvent 4.1.6, are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. 

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140430/3bd9289e/attachment.htm>

From andrew.dul at quark.net  Wed Apr 30 22:05:31 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Wed, 30 Apr 2014 19:05:31 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (Sandra Brown)
In-Reply-To: <E227D6B9-ACC3-44F3-BCCA-28CD444F5694@gmail.com>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<53618AFE.8090903@quark.net>
	<F28793E3-EFFE-47D9-9EC3-BB13684D3A01@gmail.com>
	<53618F76.9040905@quark.net>
	<E227D6B9-ACC3-44F3-BCCA-28CD444F5694@gmail.com>
Message-ID: <5361ABEB.7060606@quark.net>

On 4/30/2014 6:40 PM, Scott Leibrand wrote:
>
> On Apr 30, 2014, at 5:04 PM, Andrew Dul <andrew.dul at quark.net
> <mailto:andrew.dul at quark.net>> wrote:
>
>> On 4/30/2014 4:50 PM, Scott Leibrand wrote:
>>>> On Apr 30, 2014, at 4:45 PM, Andrew Dul <andrew.dul at quark.net> wrote:
>>>>
>>>>> On 4/30/2014 1:55 PM, sandrabrown at ipv4marketgroup.com wrote:
>>>>> BUT:  With the limitation of the transfer size to a /16 or smaller, it
>>>>> would take a lot of transfers to hoard.  It would take 256 transfers to
>>>>> stockpile a /8.  This is the 2nd means to prevent hoarding.  Most
>>>>> companies wanting that many IP's would simply do needs justification.
>>>> It seems trivial to me to divide a /8 into /16s or any other smaller
>>>> block so I could transfer it without doing the needs justification.  I
>>>> could write a script for the transfer templates and just send them off. 
>>>> Once the legwork for the first transfer is complete, the rest should
>>>> just flow right through.  Nothing I see in the current text or policy
>>>> prevents someone from taking a larger block and slicing it up to get
>>>> under the /16 limit.  Since most of the brokers are out speculating that
>>>> these blocks have significant value it seems clear that if the large
>>>> players need them they will just be paying a staff person a few extra
>>>> hours to manage this overhead.
>>> Current transfer policy operates on the *recipient* of the transfer. It requires that they meet their need with a single block, and prevents repeated transfers to circumvent that. 
>>>
>>>
>> Conditions on recipient of the transfer:
>>
>>   * The recipient must demonstrate the need for up to a 24-month
>>     supply of IP address resources under current ARIN policies and
>>     sign an RSA.
>>   * The resources transferred will be subject to current ARIN policies.
>>
>>
>>
>> Scott, I don't see any restrictions on the recipient that would
>> prevent them from receiving multiple blocks...where do you see that?
>
> It's hiding in 4.1.8: 
>
> Repeated requests, in a manner that would circumvent 4.1.6, are not
> allowed: an organization may only receive one allocation, assignment,
> or transfer every 3 months, but ARIN, at its sole discretion, may
> waive this requirement if the requester can document a change in
> circumstances since their last request that could not have been
> reasonably foreseen at the time of the original request, and which now
> justifies additional space. 
>
Fair enough, but one could also argue that 4.1.8 doesn't apply to
transfers because the whole section is about ARIN issued space, not
transfer obtained space.  They key is how ARIN would implement the
proposed policy, which will happen latter in the staff assessment after
the proposal is a draft policy.

Andrew

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

From mike at nationwideinc.com  Wed Apr 30 22:58:09 2014
From: mike at nationwideinc.com (Mike Burns)
Date: Wed, 30 Apr 2014 22:58:09 -0400
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers (Sandra Brown)
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net><53618AFE.8090903@quark.net><F28793E3-EFFE-47D9-9EC3-BB13684D3A01@gmail.com><53618F76.9040905@quark.net><E227D6B9-ACC3-44F3-BCCA-28CD444F5694@gmail.com>
	<5361ABEB.7060606@quark.net>
Message-ID: <9A137F754E1043A699773B89B3D400DB@ncsscfoipoxes4>

Hi Andrew,

I had a similar question. 8.3 says the minimum transfer is /24. ARIN's initial ISP minimum allocation is a /20. If a new ISP wants to buy just a /24, which minimum would apply?
We called ARIN today and found out that section 4 prevails and the new ISP could not purchase a /24 even with justified need. He would have to multi-home or justify at least a /20.

If that is the standard then Scott is correct and there is a limit on the number of transfers received in a year and this would cover needs-free transfers, negating the possibility of a series of sub-/16 transfers. I guess staff could confirm this interpretation?

You are correct in noting this would be a deal-breaker for my proposal, so if necessary I will add language to limit needs-free transfers to one per year.

Regards,
Mike




  Fair enough, but one could also argue that 4.1.8 doesn't apply to transfers because the whole section is about ARIN issued space, not transfer obtained space.  They key is how ARIN would implement the proposed policy, which will happen latter in the staff assessment after the proposal is a draft policy. 

  Andrew


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