From job at ntt.net  Wed Feb  1 03:48:49 2017
From: job at ntt.net (Job Snijders)
Date: Wed, 1 Feb 2017 09:48:49 +0100
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
 <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>
Message-ID: <20170201084849.GN1111@hanna.meerval.net>

Hi Owen,

On Tue, Jan 31, 2017 at 06:41:39PM -0800, Owen DeLong wrote:
> RPKI doesn?t secure BGP.
> 
> All it does is provide a cryptographically signed mechanism by which
> you can suggest what ASN should be forged as the origin of a route that
> you want to hijack.

That feels like a misconstrued statement.

You highlight a subset of RPKI: a feature that are commonly available
today. There is potentially far more that can be done with the RPKI,
such as the distribution and validation of router certificates,
manifests and other statements related to network management.

The RPKI stands for "Resource Public Key Infrastructure", it is a public
key infrastructure framework of which you currently only see one
application.

It is important in this discussion to recognise the value and potential
of the RPKI.

Kind regards,

Job


From job at ntt.net  Wed Feb  1 04:01:38 2017
From: job at ntt.net (Job Snijders)
Date: Wed, 1 Feb 2017 10:01:38 +0100
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
Message-ID: <20170201090138.GO1111@hanna.meerval.net>

On Tue, Jan 31, 2017 at 09:42:50PM +0000, John Curran wrote:
> On 30 Jan 2017, at 3:14 PM, Job Snijders <job at ntt.net> wrote:
> > 
> >> Is it the presence of legal constraints that it is the concern, or the
> >> fact that ARIN requires explicit downloading (and thus awareness of
> >> this fact) that is the issue?
> > 
> > Both are a concern. Please note that I am not advocating that all legal
> > constraints should be lifted, for me its the results that matter: at
> > this point in time it appears that ARIN's TAL is not bundled with common
> > RPKI tools, and that to me is a problem.
> 
> Job - 
> 
> ARIN?s TAL is readily available (for any who wish it) via a simple
> download that requires a trivial amount of technical effort when
> compared to the related task of introducing RPKI data into a networks
> routing decisions. The act of obtaining ARIN?s TAL, while technically
> quite simple, is one that must be done explicitly.
>
> The reason that obtaining ARIN?s TAL must be done explicitly that the use 
> of ARIN?s RPKI data is not an activity to be undertaken lightly, and includes 
> responsibilities that we wish parties to carefully consider.   As others have 
> noted elsewhere in this thread, under US law it is indeterminate whether use 
> of an open RPKI repository would entail agreement to the corresponding terms 
> of usage (despite this practice being used by other RIRs), whereas obtaining
> ARIN?s TAL via explicit act is much more certain in this regard. 
> 
> > We seek to reduce friction down to the point of:
> >    `sudo apt-get install -y arin-rpki-magic`,
> > or that the RIPE NCC RPKI Validator can add the TAL directly to its
> > source code repository.
> 
> I am certain that an appropriate (and equally short) wget command
> could suffice technically for installing ARIN?s TAL, but including
> such in a script (or including the TAL directly in the source code
> repository) would deprive parties of the ability to fully consider and
> accept the responsibilities involved.  

Correct. Thank you for this summary. Your summary narrows it down to
exactly the point of friction.

Questions that come to mind: are the responsibilities as outlined by the
RPA proportional to the goals the RPA is intended to achieve? Should any
responsibilities be associated with the distribution of cryptographic
public keys? To me DNSSEC seems an apt comparison.

> While ARIN?s Board of Trustees has been quite consistent in its
> position that RPKI services are to be offered under clear terms and
> conditions, I will also bring this email thread to their attention for
> further consideration.

Thank you.

Kind regards,

Job


From jcurran at arin.net  Wed Feb  1 09:53:51 2017
From: jcurran at arin.net (John Curran)
Date: Wed, 1 Feb 2017 14:53:51 +0000
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <20170201090138.GO1111@hanna.meerval.net>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <20170201090138.GO1111@hanna.meerval.net>
Message-ID: <334C44F8-2C10-4A4C-B347-24565FE10377@arin.net>

On 1 Feb 2017, at 4:01 AM, Job Snijders <job at ntt.net<mailto:job at ntt.net>> wrote:
I am certain that an appropriate (and equally short) wget command
could suffice technically for installing ARIN?s TAL, but including
such in a script (or including the TAL directly in the source code
repository) would deprive parties of the ability to fully consider and
accept the responsibilities involved.

Correct. Thank you for this summary. Your summary narrows it down to
exactly the point of friction.

Questions that come to mind: are the responsibilities as outlined by the
RPA proportional to the goals the RPA is intended to achieve? Should any
responsibilities be associated with the distribution of cryptographic
public keys? To me DNSSEC seems an apt comparison.

Job -

The typical relying parties ?usage? of certificates in DNSSEC is heavily proscribed by
both protocol and implementation, and occurs with only nominal configuration choices on
behalf of the relying party.  Both the maturity of DNSSEC and deployment model greatly
minimize the potential for misconfiguration on behalf of a relying party, with the result being
that misconfiguration by zone administrators is a much more common occurrence and one
whose impact is limited to but their own domain (reference RFC 7646 for more detail on
same and thus the desire for locally administered negative trust anchors to address
such circumstances...)  Even when a DNSSEC validation error occurs, there remains the
potential for self-help on behalf of end users (via the option to switch to a non-validating
resolver.)

Contrast this to RPKI, wherein the introduction of origin validation into an ISP?s routing
architecture has many operational considerations, and inherently includes the potential to
readily impact the ISP's primary business under anything less than carefully planned and
executed BGP origin validation deployment efforts.   While I?m am certain that everyone
deploying RKPI has BCP 185 memorized, the scope of any such impacts (and lack of viable
workarounds by the impacted customers) inherently means the potential for business impact
is greater than exists with deployment of DNSEC validation by ISPs ? i.e. while I do believe
that your comparison to DNSSEC is directionally correct, it fails overall due to the very real
and significant difference in the magnitude of potential business impact to the relying party.

/John

John Curran
President and CEO
ARIN





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

From jschiller at google.com  Wed Feb  1 16:57:11 2017
From: jschiller at google.com (Jason Schiller)
Date: Wed, 1 Feb 2017 16:57:11 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
Message-ID: <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>

Owen,

My experience suggests renumbering that much IP space that is actually in
use is non-trivial.

However, if renumbering as a justification sounds insufficient to many how
about demonstrated growth equal or greater than 50% of the transferred IP
space.

Certainly an organization had to list the IP holdings and utilization at
the time they requested transfer approval. Certainly they would have to do
the same with their next request to demonstrate efficient utilization.
Generating a delta of the count of things vs a delta of half of new
addresses seems simple.

Would that be sufficient?

The nice thing about avoiding the traditional request path is avoiding
future looking projections, speculation about business plans, and
unpredictable outcomes.

___Jason

On Jan 31, 2017 9:38 PM, "Owen DeLong" <owen at delong.com> wrote:

> I argue that it is insufficient and that a 6-month moratorium on a second
> simplified transfer is easier for everyone to understand and implement.
>
> The reason I feel it is insufficient is that renumbering a DHCP server
> handing out a /17 (or cobbling up a DHCP server handing out a /17) isn?t a
> particularly difficult barrier.
>
> Given that the preponderance of addresses handed out by larger service
> providers these days are dynamic in nature, renumbering large swaths of
> address space to circumvent the intent of the /16 limit on this policy is
> relatively trivial.
>
> Any organization that truly needs a larger transfer is free to get the
> approval through the conventional process and this simplified process is
> probably not a good fit as a result.
>
> I believe that is congruent with your original intent and that the
> six-month recycle limit is a quite reasonable safeguard.
>
> Owen
>
> On Jan 31, 2017, at 08:04 , Jason Schiller <jschiller at google.com> wrote:
>
> As one of the originators of this policy change I welcome the rewrite,
> with the exception the mechanism to avoid abuse.
>
> Can someone explain the "abuse" concerns if I have not correctly captured
> it?
>
>
> Abuse concern:
> ---------------------
> As far as I can tell, the combination of 2016-5 and this proposal (2016-3)
> is where the issue comes from.
> One of the goals of 2016-5 was to separate section 4 from transfers.
>
> As a result, NRPM 4.2.4.1 & 4.3.6.1 which specifies that organizations
> must show efficient utilization of 80% in aggregate, and 50% for each
> allocation/assignment is no longer a restriction to transfers.
>
> Without applying 4.2.4.1 & 4.3.6.1 an organization that is holding a /8
> that is 90% utilized, could then use 8.5.7 to justify a specified transfer
> of a /16.
>
> Once completed, the total holding of a /16 and a /8 would be 89.65%
> utilized and could immediately use 8.5.7 to justify another specified
> transfer of a /16.
>
> This process could be used 33 times and could result in drawing down a /11
> and a /16 without putting a single new address into service.
>
>
> Basic idea of 2016-3 and 2016-4:
> ---------------------------------------------
>
> 1. Make an easy to use process with an easily predictable outcome for
>     "simplified" transfers
> 2. Modify slow start and make it applicable to transfers for end-sites and
> ISPs
> 3. Give blanket approval for a "first", "small" starter block
> 4. Show that you have used what you got and then double what you have
> 5. Can always get more than double following the non-simplified process
>
>
> Intended Cap implementation:
> ----------------------------------------
>
> Doubling more than a /16 could provide way too much IP space
> (consider an efficiently used org than is not growing)
> Instead the doubling policy is limited at a /16.
> However if an organization is growing and has legitimate need for more
> than a /16, then it can get a /16 put it into service and then come back
> and get another dip.
>
>
> Suggested Anti-abuse text:
> -------------------------------------
>
> To this, 2016-3 now adds a new paragraph:
>
> 8.5.7 Alternative Additional IPv4 Address Block Criteria
> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
> address blocks by demonstrating both
> - 80% utilization of their currently allocated space
> - at least 50% utilization of each allocation and assignment
> If they do so, they qualify to receive one or more transfers up to the
> total size of their current ARIN IPv4 address holdings, with a maximum size
> of /16.
>
> Taking the abuse example above of an organization with a /8 that is is 90%
> utilized,
> the organization would need to transfer in a /16.
> Then the organization would need to put 32,768 of the new IPs into
> service,
> or renumber the use of 32,768 of IPs from the older IP space to the new
> space.
>
> I argue that need to show growth or the renumbering of usage into the new
> IP space
> is of sufficient pain to avoid abuse by organizations that don't actually
> need the IP space.
>
> __Jason
>
>
>
>
> On Tue, Jan 31, 2017 at 8:18 AM, David R Huberman <daveid at panix.com>
> wrote:
>
>> Hello,
>>
>> TL;DR:  We updated 2016-3 to fit into the upcoming NRPM, and closed an
>> abuse vector.  We kept the original text and just incorporated it in the
>> new section 8.5 so it works, and time limited it to once every 6 months.
>>
>> Background:
>>
>> At the ARIN meeting in Dallas, there was a discussion about 2016-3, a
>> policy which seeks to remove Needs Testing for smaller 8.3 and 8.4
>> transfers (with a cap of /16).  Some more work needed to be done on it, and
>> a vote at the Dallas meeting had 27 people ask the AC to continue working
>> on it, with 1 person against.
>>
>> We've done some work, and the new text is ready for your review and
>> comment.
>>
>>
>> New NRPM Coming Out Affects 2016-3:
>>
>> Policy 2016-5 was ratified by the board, and will be entering the NRPM
>> shortly.  2016-5 adds a new section to section 8 -- it adds 8.5, which are
>> the qualifying criteria for transfers.  It looks like this:
>>
>> 8.5. Specified Transfer Recipient Requirements
>>
>> 8.5.1. Registration Services Agreement
>> The receiving entity must sign an RSA covering all resources to be
>> transferred unless that entity has a current (within the last two versions)
>> RSA on file.
>>
>> 8.5.2. Operational Use
>> ARIN allocates or assigns number resources to organizations via transfer
>> solely for the purpose of use on an operational network.
>>
>> 8.5.3. Minimum transfer size
>> ARINs minimum IPv4 transfer size is a /24.
>>
>> 8.5.4. Initial block
>> Organizations without direct assignments or allocations from ARIN qualify
>> for transfer of an initial IPv4 block of ARINs minimum transfer size.
>>
>> 8.5.5. Block size
>> Organizations may qualify for the transfer of a larger initial block, or
>> an additional block, by providing documentation to ARIN which details the
>> use of at least 50% of the requested IPv4 block size within 24 months. An
>> officer of the organization shall attest to the documentation provided to
>> ARIN.
>>
>> 8.5.6. Efficient utilization of previous blocks
>> Organizations with direct assignments or allocations from ARIN must have
>> efficiently utilized at least 50% of their cumulative IPv4 address blocks
>> in order to receive additional space. This includes all space reassigned to
>> their customers.
>>
>>
>> To this, 2016-3 now adds a new paragraph:
>>
>> 8.5.7 Alternative Additional IPv4 Address Block Criteria
>> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
>> address blocks by demonstrating 80% utilization of their currently
>> allocated space. If they do so, they qualify to receive one or more
>> transfers up to the total size of their current ARIN IPv4 address holdings,
>> with a maximum size of /16.
>>
>> An organization may only qualify under 8.5.7 once every 6 months.
>>
>>
>> Conclusion:
>>
>> This text is pretty much the same text that was originally proposed in
>> 2016-3, simply incorporated into the new NRPM language that's coming out.
>>
>> It also puts in a mechanism to avoid abuse -- people trying to get around
>> the /16 cap -- by limiting it to once every 6 months.
>>
>> The AC welcomes your feedback.
>>
>> Thank you,
>> David
>> _______________________________________________
>> 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.
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170201/79c96441/attachment.htm>

From jschiller at google.com  Wed Feb  1 18:05:08 2017
From: jschiller at google.com (Jason Schiller)
Date: Wed, 1 Feb 2017 18:05:08 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
Message-ID: <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>

Owen,

Also with the passage of 2016-5 severing transfer justification from
section 4, I do not believe "the conventional method" is still available.

In the case where an ISP is more than doubling, it gets a slow start block,
and if that is less than a one year supply the next time it gets twice as
much.  It keeps doubling until it can not consume the space in one year.
It then keeps getting that size until it can not use the space in two
years.  Then the size falls back depending on how long it takes to use the
space.

___Jason

On Feb 1, 2017 4:57 PM, "Jason Schiller" <jschiller at google.com> wrote:

> Owen,
>
> My experience suggests renumbering that much IP space that is actually in
> use is non-trivial.
>
> However, if renumbering as a justification sounds insufficient to many how
> about demonstrated growth equal or greater than 50% of the transferred IP
> space.
>
> Certainly an organization had to list the IP holdings and utilization at
> the time they requested transfer approval. Certainly they would have to do
> the same with their next request to demonstrate efficient utilization.
> Generating a delta of the count of things vs a delta of half of new
> addresses seems simple.
>
> Would that be sufficient?
>
> The nice thing about avoiding the traditional request path is avoiding
> future looking projections, speculation about business plans, and
> unpredictable outcomes.
>
> ___Jason
>
> On Jan 31, 2017 9:38 PM, "Owen DeLong" <owen at delong.com> wrote:
>
>> I argue that it is insufficient and that a 6-month moratorium on a second
>> simplified transfer is easier for everyone to understand and implement.
>>
>> The reason I feel it is insufficient is that renumbering a DHCP server
>> handing out a /17 (or cobbling up a DHCP server handing out a /17) isn?t a
>> particularly difficult barrier.
>>
>> Given that the preponderance of addresses handed out by larger service
>> providers these days are dynamic in nature, renumbering large swaths of
>> address space to circumvent the intent of the /16 limit on this policy is
>> relatively trivial.
>>
>> Any organization that truly needs a larger transfer is free to get the
>> approval through the conventional process and this simplified process is
>> probably not a good fit as a result.
>>
>> I believe that is congruent with your original intent and that the
>> six-month recycle limit is a quite reasonable safeguard.
>>
>> Owen
>>
>> On Jan 31, 2017, at 08:04 , Jason Schiller <jschiller at google.com> wrote:
>>
>> As one of the originators of this policy change I welcome the rewrite,
>> with the exception the mechanism to avoid abuse.
>>
>> Can someone explain the "abuse" concerns if I have not correctly captured
>> it?
>>
>>
>> Abuse concern:
>> ---------------------
>> As far as I can tell, the combination of 2016-5 and this proposal
>> (2016-3) is where the issue comes from.
>> One of the goals of 2016-5 was to separate section 4 from transfers.
>>
>> As a result, NRPM 4.2.4.1 & 4.3.6.1 which specifies that organizations
>> must show efficient utilization of 80% in aggregate, and 50% for each
>> allocation/assignment is no longer a restriction to transfers.
>>
>> Without applying 4.2.4.1 & 4.3.6.1 an organization that is holding a /8
>> that is 90% utilized, could then use 8.5.7 to justify a specified transfer
>> of a /16.
>>
>> Once completed, the total holding of a /16 and a /8 would be 89.65%
>> utilized and could immediately use 8.5.7 to justify another specified
>> transfer of a /16.
>>
>> This process could be used 33 times and could result in drawing down a
>> /11 and a /16 without putting a single new address into service.
>>
>>
>> Basic idea of 2016-3 and 2016-4:
>> ---------------------------------------------
>>
>> 1. Make an easy to use process with an easily predictable outcome for
>>     "simplified" transfers
>> 2. Modify slow start and make it applicable to transfers for end-sites
>> and ISPs
>> 3. Give blanket approval for a "first", "small" starter block
>> 4. Show that you have used what you got and then double what you have
>> 5. Can always get more than double following the non-simplified process
>>
>>
>> Intended Cap implementation:
>> ----------------------------------------
>>
>> Doubling more than a /16 could provide way too much IP space
>> (consider an efficiently used org than is not growing)
>> Instead the doubling policy is limited at a /16.
>> However if an organization is growing and has legitimate need for more
>> than a /16, then it can get a /16 put it into service and then come back
>> and get another dip.
>>
>>
>> Suggested Anti-abuse text:
>> -------------------------------------
>>
>> To this, 2016-3 now adds a new paragraph:
>>
>> 8.5.7 Alternative Additional IPv4 Address Block Criteria
>> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
>> address blocks by demonstrating both
>> - 80% utilization of their currently allocated space
>> - at least 50% utilization of each allocation and assignment
>> If they do so, they qualify to receive one or more transfers up to the
>> total size of their current ARIN IPv4 address holdings, with a maximum size
>> of /16.
>>
>> Taking the abuse example above of an organization with a /8 that is is
>> 90% utilized,
>> the organization would need to transfer in a /16.
>> Then the organization would need to put 32,768 of the new IPs into
>> service,
>> or renumber the use of 32,768 of IPs from the older IP space to the new
>> space.
>>
>> I argue that need to show growth or the renumbering of usage into the new
>> IP space
>> is of sufficient pain to avoid abuse by organizations that don't actually
>> need the IP space.
>>
>> __Jason
>>
>>
>>
>>
>> On Tue, Jan 31, 2017 at 8:18 AM, David R Huberman <daveid at panix.com>
>> wrote:
>>
>>> Hello,
>>>
>>> TL;DR:  We updated 2016-3 to fit into the upcoming NRPM, and closed an
>>> abuse vector.  We kept the original text and just incorporated it in the
>>> new section 8.5 so it works, and time limited it to once every 6 months.
>>>
>>> Background:
>>>
>>> At the ARIN meeting in Dallas, there was a discussion about 2016-3, a
>>> policy which seeks to remove Needs Testing for smaller 8.3 and 8.4
>>> transfers (with a cap of /16).  Some more work needed to be done on it, and
>>> a vote at the Dallas meeting had 27 people ask the AC to continue working
>>> on it, with 1 person against.
>>>
>>> We've done some work, and the new text is ready for your review and
>>> comment.
>>>
>>>
>>> New NRPM Coming Out Affects 2016-3:
>>>
>>> Policy 2016-5 was ratified by the board, and will be entering the NRPM
>>> shortly.  2016-5 adds a new section to section 8 -- it adds 8.5, which are
>>> the qualifying criteria for transfers.  It looks like this:
>>>
>>> 8.5. Specified Transfer Recipient Requirements
>>>
>>> 8.5.1. Registration Services Agreement
>>> The receiving entity must sign an RSA covering all resources to be
>>> transferred unless that entity has a current (within the last two versions)
>>> RSA on file.
>>>
>>> 8.5.2. Operational Use
>>> ARIN allocates or assigns number resources to organizations via transfer
>>> solely for the purpose of use on an operational network.
>>>
>>> 8.5.3. Minimum transfer size
>>> ARINs minimum IPv4 transfer size is a /24.
>>>
>>> 8.5.4. Initial block
>>> Organizations without direct assignments or allocations from ARIN
>>> qualify for transfer of an initial IPv4 block of ARINs minimum transfer
>>> size.
>>>
>>> 8.5.5. Block size
>>> Organizations may qualify for the transfer of a larger initial block, or
>>> an additional block, by providing documentation to ARIN which details the
>>> use of at least 50% of the requested IPv4 block size within 24 months. An
>>> officer of the organization shall attest to the documentation provided to
>>> ARIN.
>>>
>>> 8.5.6. Efficient utilization of previous blocks
>>> Organizations with direct assignments or allocations from ARIN must have
>>> efficiently utilized at least 50% of their cumulative IPv4 address blocks
>>> in order to receive additional space. This includes all space reassigned to
>>> their customers.
>>>
>>>
>>> To this, 2016-3 now adds a new paragraph:
>>>
>>> 8.5.7 Alternative Additional IPv4 Address Block Criteria
>>> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional
>>> IPv4 address blocks by demonstrating 80% utilization of their currently
>>> allocated space. If they do so, they qualify to receive one or more
>>> transfers up to the total size of their current ARIN IPv4 address holdings,
>>> with a maximum size of /16.
>>>
>>> An organization may only qualify under 8.5.7 once every 6 months.
>>>
>>>
>>> Conclusion:
>>>
>>> This text is pretty much the same text that was originally proposed in
>>> 2016-3, simply incorporated into the new NRPM language that's coming out.
>>>
>>> It also puts in a mechanism to avoid abuse -- people trying to get
>>> around the /16 cap -- by limiting it to once every 6 months.
>>>
>>> The AC welcomes your feedback.
>>>
>>> Thank you,
>>> David
>>> _______________________________________________
>>> 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.
>>>
>>
>>
>>
>> --
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>> <(571)%20266-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.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170201/08873d3b/attachment.htm>

From info at arin.net  Thu Feb  2 12:59:17 2017
From: info at arin.net (ARIN)
Date: Thu, 2 Feb 2017 12:59:17 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - January 2017
Message-ID: <58937375.4020900@arin.net>

In accordance with the Policy Development Process (PDP), the Advisory 
Council (AC) met on 27 January 2017.

The AC has abandoned the following Draft Policy:

Draft Policy ARIN-2016-7: Integration of Community Networks into 
existing ISP policy

The AC provided the following statement:

"The Advisory Council decided to abandon ARIN-2016-7: Integration of 
Community Networks into existing ISP policy, due to a lack of support. 
There was no feedback from any community network operators, and this 
proposal raises the question whether the community network policy is 
still necessary."

Anyone dissatisfied with this decision may initiate a petition. The 
deadline to begin a petition will be five business days after the AC's 
draft meeting minutes are published.

The AC is continuing to work on:

Draft Policy ARIN-2016-3: Alternative simplified criteria for justifying 
small IPv4 transfers
Draft Policy ARIN-2016-8: Removal of Indirect POC Validation Requirement
Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers

The PDP 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,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)


From owen at delong.com  Thu Feb  2 20:41:19 2017
From: owen at delong.com (Owen DeLong)
Date: Thu, 2 Feb 2017 17:41:19 -0800
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <20170201084849.GN1111@hanna.meerval.net>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
 <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>
 <20170201084849.GN1111@hanna.meerval.net>
Message-ID: <F3459EE0-CEA7-41B5-A3EF-29FDEF0C9412@delong.com>


> On Feb 1, 2017, at 00:48 , Job Snijders <job at ntt.net> wrote:
> 
> Hi Owen,
> 
> On Tue, Jan 31, 2017 at 06:41:39PM -0800, Owen DeLong wrote:
>> RPKI doesn?t secure BGP.
>> 
>> All it does is provide a cryptographically signed mechanism by which
>> you can suggest what ASN should be forged as the origin of a route that
>> you want to hijack.
> 
> That feels like a misconstrued statement.
> 
> You highlight a subset of RPKI: a feature that are commonly available
> today. There is potentially far more that can be done with the RPKI,
> such as the distribution and validation of router certificates,
> manifests and other statements related to network management.
> 
> The RPKI stands for "Resource Public Key Infrastructure", it is a public
> key infrastructure framework of which you currently only see one
> application.
> 
> It is important in this discussion to recognise the value and potential
> of the RPKI.
> 
> Kind regards,
> 
> Job

Does any RIR or any other place have even a specification for those other
purposes, let alone actual implementation?

If not, then I stand by my statement as regards the current state of the RPKI.

Owen



From owen at delong.com  Thu Feb  2 20:49:22 2017
From: owen at delong.com (Owen DeLong)
Date: Thu, 2 Feb 2017 17:49:22 -0800
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
Message-ID: <4D7A126F-CBBD-47F0-8B03-D1B905D67BAF@delong.com>


> On Feb 1, 2017, at 13:57 , Jason Schiller <jschiller at google.com> wrote:
> 
> Owen,
> 
> My experience suggests renumbering that much IP space that is actually in use is non-trivial.
> 
I think that depends tremendously on the type of network. Since MSOs seem to renumber some batch of customers on /20s and sometimes larger on an almost nightly basis, I don?t think it can be that difficult for them.
> However, if renumbering as a justification sounds insufficient to many how about demonstrated growth equal or greater than 50% of the transferred IP space. 
> 
Wouldn?t that be equivalent to the current process which remains available to them outside of this simplified process?
> Certainly an organization had to list the IP holdings and utilization at the time they requested transfer approval. Certainly they would have to do the same with their next request to demonstrate efficient utilization. Generating a delta of the count of things vs a delta of half of new addresses seems simple.
> 
That raises the bar only slightly, but it might be sufficient. I won?t strongly oppose this, but I don?t see a major advantage of doing repeated transfers of /16s via this mechanism vs. transferring a larger block under more traditional policies in that case. So I still think that the 6 month hold-down on this procedure makes more sense.
> Would that be sufficient?
> 
> The nice thing about avoiding the traditional request path is avoiding future looking projections, speculation about business plans, and unpredictable outcomes.
> 
Sure, but I think allowing this path to be rapidly repeated in order to overcome the /16 safety valve offers little benefit, so I think that a timed hold-down is a more direct application of the intent ? Limiting this path to a /16 or smaller need and requiring more stringent evaluation of larger transfers. Additionally, allowing such a path creates an incentive for additional unnecessary fragmentation.

Owen

> ___Jason
> 
> 
> On Jan 31, 2017 9:38 PM, "Owen DeLong" <owen at delong.com <mailto:owen at delong.com>> wrote:
> I argue that it is insufficient and that a 6-month moratorium on a second simplified transfer is easier for everyone to understand and implement.
> 
> The reason I feel it is insufficient is that renumbering a DHCP server handing out a /17 (or cobbling up a DHCP server handing out a /17) isn?t a particularly difficult barrier.
> 
> Given that the preponderance of addresses handed out by larger service providers these days are dynamic in nature, renumbering large swaths of address space to circumvent the intent of the /16 limit on this policy is relatively trivial.
> 
> Any organization that truly needs a larger transfer is free to get the approval through the conventional process and this simplified process is probably not a good fit as a result.
> 
> I believe that is congruent with your original intent and that the six-month recycle limit is a quite reasonable safeguard.
> 
> Owen
> 
>> On Jan 31, 2017, at 08:04 , Jason Schiller <jschiller at google.com <mailto:jschiller at google.com>> wrote:
>> 
>> As one of the originators of this policy change I welcome the rewrite, 
>> with the exception the mechanism to avoid abuse.
>> 
>> Can someone explain the "abuse" concerns if I have not correctly captured it?
>> 
>> 
>> Abuse concern:
>> ---------------------
>> As far as I can tell, the combination of 2016-5 and this proposal (2016-3) is where the issue comes from. 
>> One of the goals of 2016-5 was to separate section 4 from transfers.
>> 
>> As a result, NRPM 4.2.4.1 & 4.3.6.1 which specifies that organizations must show efficient utilization of 80% in aggregate, and 50% for each allocation/assignment is no longer a restriction to transfers.
>> 
>> Without applying 4.2.4.1 & 4.3.6.1 an organization that is holding a /8 that is 90% utilized, could then use 8.5.7 to justify a specified transfer of a /16.  
>> 
>> Once completed, the total holding of a /16 and a /8 would be 89.65% utilized and could immediately use 8.5.7 to justify another specified transfer of a /16.  
>> 
>> This process could be used 33 times and could result in drawing down a /11 and a /16 without putting a single new address into service.
>> 
>> 
>> Basic idea of 2016-3 and 2016-4:
>> ---------------------------------------------
>> 
>> 1. Make an easy to use process with an easily predictable outcome for 
>>     "simplified" transfers
>> 2. Modify slow start and make it applicable to transfers for end-sites and ISPs
>> 3. Give blanket approval for a "first", "small" starter block
>> 4. Show that you have used what you got and then double what you have
>> 5. Can always get more than double following the non-simplified process
>> 
>> 
>> Intended Cap implementation:
>> ----------------------------------------
>> 
>> Doubling more than a /16 could provide way too much IP space
>> (consider an efficiently used org than is not growing)
>> Instead the doubling policy is limited at a /16.
>> However if an organization is growing and has legitimate need for more 
>> than a /16, then it can get a /16 put it into service and then come back 
>> and get another dip.
>> 
>> 
>> Suggested Anti-abuse text:
>> -------------------------------------
>> 
>> To this, 2016-3 now adds a new paragraph:
>> 
>> 8.5.7 Alternative Additional IPv4 Address Block Criteria
>> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 address blocks by demonstrating both 
>> - 80% utilization of their currently allocated space 
>> - at least 50% utilization of each allocation and assignment
>> If they do so, they qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16.
>> 
>> Taking the abuse example above of an organization with a /8 that is is 90% utilized, 
>> the organization would need to transfer in a /16.  
>> Then the organization would need to put 32,768 of the new IPs into service, 
>> or renumber the use of 32,768 of IPs from the older IP space to the new space.
>> 
>> I argue that need to show growth or the renumbering of usage into the new IP space 
>> is of sufficient pain to avoid abuse by organizations that don't actually need the IP space.
>> 
>> __Jason
>> 
>>  
>> 
>> 
>> On Tue, Jan 31, 2017 at 8:18 AM, David R Huberman <daveid at panix.com <mailto:daveid at panix.com>> wrote:
>> Hello,
>> 
>> TL;DR:  We updated 2016-3 to fit into the upcoming NRPM, and closed an abuse vector.  We kept the original text and just incorporated it in the new section 8.5 so it works, and time limited it to once every 6 months.
>> 
>> Background:
>> 
>> At the ARIN meeting in Dallas, there was a discussion about 2016-3, a policy which seeks to remove Needs Testing for smaller 8.3 and 8.4 transfers (with a cap of /16).  Some more work needed to be done on it, and a vote at the Dallas meeting had 27 people ask the AC to continue working on it, with 1 person against.
>> 
>> We've done some work, and the new text is ready for your review and comment.
>> 
>> 
>> New NRPM Coming Out Affects 2016-3:
>> 
>> Policy 2016-5 was ratified by the board, and will be entering the NRPM shortly.  2016-5 adds a new section to section 8 -- it adds 8.5, which are the qualifying criteria for transfers.  It looks like this:
>> 
>> 8.5. Specified Transfer Recipient Requirements
>> 
>> 8.5.1. Registration Services Agreement
>> The receiving entity must sign an RSA covering all resources to be transferred unless that entity has a current (within the last two versions) RSA on file.
>> 
>> 8.5.2. Operational Use
>> ARIN allocates or assigns number resources to organizations via transfer solely for the purpose of use on an operational network.
>> 
>> 8.5.3. Minimum transfer size
>> ARINs minimum IPv4 transfer size is a /24.
>> 
>> 8.5.4. Initial block
>> Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial IPv4 block of ARINs minimum transfer size.
>> 
>> 8.5.5. Block size
>> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.
>> 
>> 8.5.6. Efficient utilization of previous blocks
>> Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of their cumulative IPv4 address blocks in order to receive additional space. This includes all space reassigned to their customers.
>> 
>> 
>> To this, 2016-3 now adds a new paragraph:
>> 
>> 8.5.7 Alternative Additional IPv4 Address Block Criteria
>> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 address blocks by demonstrating 80% utilization of their currently allocated space. If they do so, they qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16.
>> 
>> An organization may only qualify under 8.5.7 once every 6 months.
>> 
>> 
>> Conclusion:
>> 
>> This text is pretty much the same text that was originally proposed in 2016-3, simply incorporated into the new NRPM language that's coming out.
>> 
>> It also puts in a mechanism to avoid abuse -- people trying to get around the /16 cap -- by limiting it to once every 6 months.
>> 
>> The AC welcomes your feedback.
>> 
>> Thank you,
>> David
>> _______________________________________________
>> 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 <http://lists.arin.net/mailman/listinfo/arin-ppml>
>> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
>> 
>> 
>> 
>> -- 
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com <mailto:jschiller at google.com>|571-266-0006 <tel:(571)%20266-0006>
>> 
>> _______________________________________________
>> 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 <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/20170202/b95760fa/attachment.htm>

From owen at delong.com  Thu Feb  2 20:51:06 2017
From: owen at delong.com (Owen DeLong)
Date: Thu, 2 Feb 2017 17:51:06 -0800
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
Message-ID: <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>


> On Feb 1, 2017, at 15:05 , Jason Schiller <jschiller at google.com> wrote:
> 
> Owen,
> 
> Also with the passage of 2016-5 severing transfer justification from section 4, I do not believe "the conventional method" is still available. 
> 
> In the case where an ISP is more than doubling, it gets a slow start block, and if that is less than a one year supply the next time it gets twice as much.  It keeps doubling until it can not consume the space in one year.  It then keeps getting that size until it can not use the space in two years.  Then the size falls back depending on how long it takes to use the space.
> 

I believe it keeps doubling to 2 years, but I could be wrong.

In any case, I don?t think that the severing resets their slow-start, so I think that effectively preserves the conventional method for all practical purposes.

Owen

> ___Jason
> 
> 
> On Feb 1, 2017 4:57 PM, "Jason Schiller" <jschiller at google.com <mailto:jschiller at google.com>> wrote:
> Owen,
> 
> My experience suggests renumbering that much IP space that is actually in use is non-trivial.
> 
> However, if renumbering as a justification sounds insufficient to many how about demonstrated growth equal or greater than 50% of the transferred IP space. 
> 
> Certainly an organization had to list the IP holdings and utilization at the time they requested transfer approval. Certainly they would have to do the same with their next request to demonstrate efficient utilization. Generating a delta of the count of things vs a delta of half of new addresses seems simple.
> 
> Would that be sufficient?
> 
> The nice thing about avoiding the traditional request path is avoiding future looking projections, speculation about business plans, and unpredictable outcomes.
> 
> ___Jason
> 
> 
> On Jan 31, 2017 9:38 PM, "Owen DeLong" <owen at delong.com <mailto:owen at delong.com>> wrote:
> I argue that it is insufficient and that a 6-month moratorium on a second simplified transfer is easier for everyone to understand and implement.
> 
> The reason I feel it is insufficient is that renumbering a DHCP server handing out a /17 (or cobbling up a DHCP server handing out a /17) isn?t a particularly difficult barrier.
> 
> Given that the preponderance of addresses handed out by larger service providers these days are dynamic in nature, renumbering large swaths of address space to circumvent the intent of the /16 limit on this policy is relatively trivial.
> 
> Any organization that truly needs a larger transfer is free to get the approval through the conventional process and this simplified process is probably not a good fit as a result.
> 
> I believe that is congruent with your original intent and that the six-month recycle limit is a quite reasonable safeguard.
> 
> Owen
> 
>> On Jan 31, 2017, at 08:04 , Jason Schiller <jschiller at google.com <mailto:jschiller at google.com>> wrote:
>> 
>> As one of the originators of this policy change I welcome the rewrite, 
>> with the exception the mechanism to avoid abuse.
>> 
>> Can someone explain the "abuse" concerns if I have not correctly captured it?
>> 
>> 
>> Abuse concern:
>> ---------------------
>> As far as I can tell, the combination of 2016-5 and this proposal (2016-3) is where the issue comes from. 
>> One of the goals of 2016-5 was to separate section 4 from transfers.
>> 
>> As a result, NRPM 4.2.4.1 & 4.3.6.1 which specifies that organizations must show efficient utilization of 80% in aggregate, and 50% for each allocation/assignment is no longer a restriction to transfers.
>> 
>> Without applying 4.2.4.1 & 4.3.6.1 an organization that is holding a /8 that is 90% utilized, could then use 8.5.7 to justify a specified transfer of a /16.  
>> 
>> Once completed, the total holding of a /16 and a /8 would be 89.65% utilized and could immediately use 8.5.7 to justify another specified transfer of a /16.  
>> 
>> This process could be used 33 times and could result in drawing down a /11 and a /16 without putting a single new address into service.
>> 
>> 
>> Basic idea of 2016-3 and 2016-4:
>> ---------------------------------------------
>> 
>> 1. Make an easy to use process with an easily predictable outcome for 
>>     "simplified" transfers
>> 2. Modify slow start and make it applicable to transfers for end-sites and ISPs
>> 3. Give blanket approval for a "first", "small" starter block
>> 4. Show that you have used what you got and then double what you have
>> 5. Can always get more than double following the non-simplified process
>> 
>> 
>> Intended Cap implementation:
>> ----------------------------------------
>> 
>> Doubling more than a /16 could provide way too much IP space
>> (consider an efficiently used org than is not growing)
>> Instead the doubling policy is limited at a /16.
>> However if an organization is growing and has legitimate need for more 
>> than a /16, then it can get a /16 put it into service and then come back 
>> and get another dip.
>> 
>> 
>> Suggested Anti-abuse text:
>> -------------------------------------
>> 
>> To this, 2016-3 now adds a new paragraph:
>> 
>> 8.5.7 Alternative Additional IPv4 Address Block Criteria
>> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 address blocks by demonstrating both 
>> - 80% utilization of their currently allocated space 
>> - at least 50% utilization of each allocation and assignment
>> If they do so, they qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16.
>> 
>> Taking the abuse example above of an organization with a /8 that is is 90% utilized, 
>> the organization would need to transfer in a /16.  
>> Then the organization would need to put 32,768 of the new IPs into service, 
>> or renumber the use of 32,768 of IPs from the older IP space to the new space.
>> 
>> I argue that need to show growth or the renumbering of usage into the new IP space 
>> is of sufficient pain to avoid abuse by organizations that don't actually need the IP space.
>> 
>> __Jason
>> 
>>  
>> 
>> 
>> On Tue, Jan 31, 2017 at 8:18 AM, David R Huberman <daveid at panix.com <mailto:daveid at panix.com>> wrote:
>> Hello,
>> 
>> TL;DR:  We updated 2016-3 to fit into the upcoming NRPM, and closed an abuse vector.  We kept the original text and just incorporated it in the new section 8.5 so it works, and time limited it to once every 6 months.
>> 
>> Background:
>> 
>> At the ARIN meeting in Dallas, there was a discussion about 2016-3, a policy which seeks to remove Needs Testing for smaller 8.3 and 8.4 transfers (with a cap of /16).  Some more work needed to be done on it, and a vote at the Dallas meeting had 27 people ask the AC to continue working on it, with 1 person against.
>> 
>> We've done some work, and the new text is ready for your review and comment.
>> 
>> 
>> New NRPM Coming Out Affects 2016-3:
>> 
>> Policy 2016-5 was ratified by the board, and will be entering the NRPM shortly.  2016-5 adds a new section to section 8 -- it adds 8.5, which are the qualifying criteria for transfers.  It looks like this:
>> 
>> 8.5. Specified Transfer Recipient Requirements
>> 
>> 8.5.1. Registration Services Agreement
>> The receiving entity must sign an RSA covering all resources to be transferred unless that entity has a current (within the last two versions) RSA on file.
>> 
>> 8.5.2. Operational Use
>> ARIN allocates or assigns number resources to organizations via transfer solely for the purpose of use on an operational network.
>> 
>> 8.5.3. Minimum transfer size
>> ARINs minimum IPv4 transfer size is a /24.
>> 
>> 8.5.4. Initial block
>> Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial IPv4 block of ARINs minimum transfer size.
>> 
>> 8.5.5. Block size
>> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.
>> 
>> 8.5.6. Efficient utilization of previous blocks
>> Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of their cumulative IPv4 address blocks in order to receive additional space. This includes all space reassigned to their customers.
>> 
>> 
>> To this, 2016-3 now adds a new paragraph:
>> 
>> 8.5.7 Alternative Additional IPv4 Address Block Criteria
>> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 address blocks by demonstrating 80% utilization of their currently allocated space. If they do so, they qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16.
>> 
>> An organization may only qualify under 8.5.7 once every 6 months.
>> 
>> 
>> Conclusion:
>> 
>> This text is pretty much the same text that was originally proposed in 2016-3, simply incorporated into the new NRPM language that's coming out.
>> 
>> It also puts in a mechanism to avoid abuse -- people trying to get around the /16 cap -- by limiting it to once every 6 months.
>> 
>> The AC welcomes your feedback.
>> 
>> Thank you,
>> David
>> _______________________________________________
>> 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 <http://lists.arin.net/mailman/listinfo/arin-ppml>
>> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
>> 
>> 
>> 
>> -- 
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com <mailto:jschiller at google.com>|571-266-0006 <tel:(571)%20266-0006>
>> 
>> _______________________________________________
>> 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 <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/20170202/bf7c631d/attachment.htm>

From jschiller at google.com  Thu Feb  2 22:31:55 2017
From: jschiller at google.com (Jason Schiller)
Date: Thu, 2 Feb 2017 22:31:55 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
Message-ID: <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>

Can staff comment on this specific question.

Post implementation of 2016-5, will all the requirements for the approval
of a specified transfer be contained in 8.5?

In other words if I had what would have previously been an accepted
justification under section 4 for a specified transfer, and that
justification is not contained in 8.5 is my justification still accepted
for a specified transfer.

The case I was thinking of is slow start in 4.2.1.4.  Can I get a specified
transfer, make it and the rest of my IP space efficiently utilized in less
than a year, and use that as a justification to get a twice as big
specified transfer post 2016-5.

(WRT doubling time, I remember ARIN started rounding down instead of up for
approvals after ISP's time horizon was shortened to no more than a 90 day
supply. It wasn't clear to me if they were/are rounding down on the two
year transfer window as well.)

___Jason

On Feb 2, 2017 8:52 PM, "Owen DeLong" <owen at delong.com> wrote:


On Feb 1, 2017, at 15:05 , Jason Schiller <jschiller at google.com> wrote:

Owen,

Also with the passage of 2016-5 severing transfer justification from
section 4, I do not believe "the conventional method" is still available.

In the case where an ISP is more than doubling, it gets a slow start block,
and if that is less than a one year supply the next time it gets twice as
much.  It keeps doubling until it can not consume the space in one year.
It then keeps getting that size until it can not use the space in two
years.  Then the size falls back depending on how long it takes to use the
space.


I believe it keeps doubling to 2 years, but I could be wrong.

In any case, I don?t think that the severing resets their slow-start, so I
think that effectively preserves the conventional method for all practical
purposes.

Owen

___Jason

On Feb 1, 2017 4:57 PM, "Jason Schiller" <jschiller at google.com> wrote:

> Owen,
>
> My experience suggests renumbering that much IP space that is actually in
> use is non-trivial.
>
> However, if renumbering as a justification sounds insufficient to many how
> about demonstrated growth equal or greater than 50% of the transferred IP
> space.
>
> Certainly an organization had to list the IP holdings and utilization at
> the time they requested transfer approval. Certainly they would have to do
> the same with their next request to demonstrate efficient utilization.
> Generating a delta of the count of things vs a delta of half of new
> addresses seems simple.
>
> Would that be sufficient?
>
> The nice thing about avoiding the traditional request path is avoiding
> future looking projections, speculation about business plans, and
> unpredictable outcomes.
>
> ___Jason
>
> On Jan 31, 2017 9:38 PM, "Owen DeLong" <owen at delong.com> wrote:
>
>> I argue that it is insufficient and that a 6-month moratorium on a second
>> simplified transfer is easier for everyone to understand and implement.
>>
>> The reason I feel it is insufficient is that renumbering a DHCP server
>> handing out a /17 (or cobbling up a DHCP server handing out a /17) isn?t a
>> particularly difficult barrier.
>>
>> Given that the preponderance of addresses handed out by larger service
>> providers these days are dynamic in nature, renumbering large swaths of
>> address space to circumvent the intent of the /16 limit on this policy is
>> relatively trivial.
>>
>> Any organization that truly needs a larger transfer is free to get the
>> approval through the conventional process and this simplified process is
>> probably not a good fit as a result.
>>
>> I believe that is congruent with your original intent and that the
>> six-month recycle limit is a quite reasonable safeguard.
>>
>> Owen
>>
>> On Jan 31, 2017, at 08:04 , Jason Schiller <jschiller at google.com> wrote:
>>
>> As one of the originators of this policy change I welcome the rewrite,
>> with the exception the mechanism to avoid abuse.
>>
>> Can someone explain the "abuse" concerns if I have not correctly captured
>> it?
>>
>>
>> Abuse concern:
>> ---------------------
>> As far as I can tell, the combination of 2016-5 and this proposal
>> (2016-3) is where the issue comes from.
>> One of the goals of 2016-5 was to separate section 4 from transfers.
>>
>> As a result, NRPM 4.2.4.1 & 4.3.6.1 which specifies that organizations
>> must show efficient utilization of 80% in aggregate, and 50% for each
>> allocation/assignment is no longer a restriction to transfers.
>>
>> Without applying 4.2.4.1 & 4.3.6.1 an organization that is holding a /8
>> that is 90% utilized, could then use 8.5.7 to justify a specified transfer
>> of a /16.
>>
>> Once completed, the total holding of a /16 and a /8 would be 89.65%
>> utilized and could immediately use 8.5.7 to justify another specified
>> transfer of a /16.
>>
>> This process could be used 33 times and could result in drawing down a
>> /11 and a /16 without putting a single new address into service.
>>
>>
>> Basic idea of 2016-3 and 2016-4:
>> ---------------------------------------------
>>
>> 1. Make an easy to use process with an easily predictable outcome for
>>     "simplified" transfers
>> 2. Modify slow start and make it applicable to transfers for end-sites
>> and ISPs
>> 3. Give blanket approval for a "first", "small" starter block
>> 4. Show that you have used what you got and then double what you have
>> 5. Can always get more than double following the non-simplified process
>>
>>
>> Intended Cap implementation:
>> ----------------------------------------
>>
>> Doubling more than a /16 could provide way too much IP space
>> (consider an efficiently used org than is not growing)
>> Instead the doubling policy is limited at a /16.
>> However if an organization is growing and has legitimate need for more
>> than a /16, then it can get a /16 put it into service and then come back
>> and get another dip.
>>
>>
>> Suggested Anti-abuse text:
>> -------------------------------------
>>
>> To this, 2016-3 now adds a new paragraph:
>>
>> 8.5.7 Alternative Additional IPv4 Address Block Criteria
>> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
>> address blocks by demonstrating both
>> - 80% utilization of their currently allocated space
>> - at least 50% utilization of each allocation and assignment
>> If they do so, they qualify to receive one or more transfers up to the
>> total size of their current ARIN IPv4 address holdings, with a maximum size
>> of /16.
>>
>> Taking the abuse example above of an organization with a /8 that is is
>> 90% utilized,
>> the organization would need to transfer in a /16.
>> Then the organization would need to put 32,768 of the new IPs into
>> service,
>> or renumber the use of 32,768 of IPs from the older IP space to the new
>> space.
>>
>> I argue that need to show growth or the renumbering of usage into the new
>> IP space
>> is of sufficient pain to avoid abuse by organizations that don't actually
>> need the IP space.
>>
>> __Jason
>>
>>
>>
>>
>> On Tue, Jan 31, 2017 at 8:18 AM, David R Huberman <daveid at panix.com>
>> wrote:
>>
>>> Hello,
>>>
>>> TL;DR:  We updated 2016-3 to fit into the upcoming NRPM, and closed an
>>> abuse vector.  We kept the original text and just incorporated it in the
>>> new section 8.5 so it works, and time limited it to once every 6 months.
>>>
>>> Background:
>>>
>>> At the ARIN meeting in Dallas, there was a discussion about 2016-3, a
>>> policy which seeks to remove Needs Testing for smaller 8.3 and 8.4
>>> transfers (with a cap of /16).  Some more work needed to be done on it, and
>>> a vote at the Dallas meeting had 27 people ask the AC to continue working
>>> on it, with 1 person against.
>>>
>>> We've done some work, and the new text is ready for your review and
>>> comment.
>>>
>>>
>>> New NRPM Coming Out Affects 2016-3:
>>>
>>> Policy 2016-5 was ratified by the board, and will be entering the NRPM
>>> shortly.  2016-5 adds a new section to section 8 -- it adds 8.5, which are
>>> the qualifying criteria for transfers.  It looks like this:
>>>
>>> 8.5. Specified Transfer Recipient Requirements
>>>
>>> 8.5.1. Registration Services Agreement
>>> The receiving entity must sign an RSA covering all resources to be
>>> transferred unless that entity has a current (within the last two versions)
>>> RSA on file.
>>>
>>> 8.5.2. Operational Use
>>> ARIN allocates or assigns number resources to organizations via transfer
>>> solely for the purpose of use on an operational network.
>>>
>>> 8.5.3. Minimum transfer size
>>> ARINs minimum IPv4 transfer size is a /24.
>>>
>>> 8.5.4. Initial block
>>> Organizations without direct assignments or allocations from ARIN
>>> qualify for transfer of an initial IPv4 block of ARINs minimum transfer
>>> size.
>>>
>>> 8.5.5. Block size
>>> Organizations may qualify for the transfer of a larger initial block, or
>>> an additional block, by providing documentation to ARIN which details the
>>> use of at least 50% of the requested IPv4 block size within 24 months. An
>>> officer of the organization shall attest to the documentation provided to
>>> ARIN.
>>>
>>> 8.5.6. Efficient utilization of previous blocks
>>> Organizations with direct assignments or allocations from ARIN must have
>>> efficiently utilized at least 50% of their cumulative IPv4 address blocks
>>> in order to receive additional space. This includes all space reassigned to
>>> their customers.
>>>
>>>
>>> To this, 2016-3 now adds a new paragraph:
>>>
>>> 8.5.7 Alternative Additional IPv4 Address Block Criteria
>>> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional
>>> IPv4 address blocks by demonstrating 80% utilization of their currently
>>> allocated space. If they do so, they qualify to receive one or more
>>> transfers up to the total size of their current ARIN IPv4 address holdings,
>>> with a maximum size of /16.
>>>
>>> An organization may only qualify under 8.5.7 once every 6 months.
>>>
>>>
>>> Conclusion:
>>>
>>> This text is pretty much the same text that was originally proposed in
>>> 2016-3, simply incorporated into the new NRPM language that's coming out.
>>>
>>> It also puts in a mechanism to avoid abuse -- people trying to get
>>> around the /16 cap -- by limiting it to once every 6 months.
>>>
>>> The AC welcomes your feedback.
>>>
>>> Thank you,
>>> David
>>> _______________________________________________
>>> 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.
>>>
>>
>>
>>
>> --
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>> <(571)%20266-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.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170202/b6be2074/attachment.htm>

From job at ntt.net  Fri Feb  3 03:49:14 2017
From: job at ntt.net (Job Snijders)
Date: Fri, 3 Feb 2017 09:49:14 +0100
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <F3459EE0-CEA7-41B5-A3EF-29FDEF0C9412@delong.com>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
 <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>
 <20170201084849.GN1111@hanna.meerval.net>
 <F3459EE0-CEA7-41B5-A3EF-29FDEF0C9412@delong.com>
Message-ID: <20170203084914.GA72088@Vurt.local>

On Thu, Feb 02, 2017 at 05:41:19PM -0800, Owen DeLong wrote:
> > On Feb 1, 2017, at 00:48 , Job Snijders <job at ntt.net> wrote:
> > On Tue, Jan 31, 2017 at 06:41:39PM -0800, Owen DeLong wrote:
> >> RPKI doesn?t secure BGP.
> >> 
> >> All it does is provide a cryptographically signed mechanism by which
> >> you can suggest what ASN should be forged as the origin of a route that
> >> you want to hijack.
> > 
> > That feels like a misconstrued statement.
> > 
> > You highlight a subset of RPKI: a feature that are commonly
> > available today. There is potentially far more that can be done with
> > the RPKI, such as the distribution and validation of router
> > certificates, manifests and other statements related to network
> > management.
> > 
> > The RPKI stands for "Resource Public Key Infrastructure", it is a
> > public key infrastructure framework of which you currently only see
> > one application.
> > 
> > It is important in this discussion to recognise the value and potential
> > of the RPKI.
> 
> Does any RIR or any other place have even a specification for those
> other purposes, let alone actual implementation?

As recent as January 18th, 2017 the IESG approved the "BGPsec Protocol
Specification" to be published as Standards Track RFC. The announcement
can be read here:
https://www.ietf.org/mail-archive/web/ietf-announce/current/msg16252.html

And for those of us who possess technical prowess, perhaps the actual
specification might be of interest:
https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-22

BGPsec relies on the Resource Public Key Infrastructure (RPKI)
certificates that attest to the allocation of AS number and IP address
resources. Any BGPsec speaker who wishes to send, to external (eBGP)
peers, BGP update messages containing the BGPsec_Path needs to possess a
private key associated with an RPKI router certificate that corresponds
to the BGPsec speaker's AS number. Note, however, that a BGPsec speaker
does not need such a certificate in order to validate received update
messages containing the BGPsec_Path attribute. However, the organisation
wishing to validate these updates will need access to the ARIN TAL.

> If not, then I stand by my statement as regards the current state of
> the RPKI.

Please keep in mind that this thread was about removing barriers, to
enable RPKI innovation. 

Kind regards,

Job


From eric.loos at bics.com  Fri Feb  3 08:15:52 2017
From: eric.loos at bics.com (LOOS Eric (BCS/CBU))
Date: Fri, 3 Feb 2017 13:15:52 +0000
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <334C44F8-2C10-4A4C-B347-24565FE10377@arin.net>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <20170201090138.GO1111@hanna.meerval.net>
 <334C44F8-2C10-4A4C-B347-24565FE10377@arin.net>
Message-ID: <F2BCA30AF0923046891980C0C406DE78B6193C5E@A04083.BGC.NET>

IANAL, but I have worked enough with our legal department to see some red flags in the RPA:

-          Possibility for on-sided modifications of the T&C with automatic acceptance thereof

-          Complete indemnification of ARIN et al.

So I definitely sympathize with the point that the RPA as worded there is probably unacceptable for many carriers (us included)
I also agree that it is a moot point whether this is a click through before a download is possible or fine print of the website which is presumable accepted once the service is accessed; it is in fact indeed commendable that ARIN does not try to let companies agree to such far reaching legal language without at least raising the flag. Therefore the points made by Wes during his nanog talk regarding the modification of the RPA are pertinent here.

I wonder why the trustees have chosen to take such a defensive approach on information contained in the RKPI, after all we have had RBL lists in the past for blocking mail, we pretty much all uses RIR routing registries for building our filters, many people rely on PeeringDB for keeping their peering records up to date and I have not encountered such defensive position before.

Especially RPKI requires a wide acceptance to be able to do anything useful.
What would be the process for the trustees to review this matter and share their insights on this matter?

Eric Loos
Senior Product Manager - Capacity & IP
Tel. +32 2 547 51 21 ? Mob. +32 475 40 94 44
eric.loos at bics.com<mailto:eric.loos at bics.com>

BICS SA/NV
Rue Lebeau 4, 1000 Brussels, Belgium
www.bics.com<http://www.bics.com/>



From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran
Sent: Wednesday 1 February 2017 15:54
To: Job Snijders <job at ntt.net>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?

On 1 Feb 2017, at 4:01 AM, Job Snijders <job at ntt.net<mailto:job at ntt.net>> wrote:
I am certain that an appropriate (and equally short) wget command
could suffice technically for installing ARIN?s TAL, but including
such in a script (or including the TAL directly in the source code
repository) would deprive parties of the ability to fully consider and
accept the responsibilities involved.

Correct. Thank you for this summary. Your summary narrows it down to
exactly the point of friction.

Questions that come to mind: are the responsibilities as outlined by the
RPA proportional to the goals the RPA is intended to achieve? Should any
responsibilities be associated with the distribution of cryptographic
public keys? To me DNSSEC seems an apt comparison.

Job -

The typical relying parties ?usage? of certificates in DNSSEC is heavily proscribed by
both protocol and implementation, and occurs with only nominal configuration choices on
behalf of the relying party.  Both the maturity of DNSSEC and deployment model greatly
minimize the potential for misconfiguration on behalf of a relying party, with the result being
that misconfiguration by zone administrators is a much more common occurrence and one
whose impact is limited to but their own domain (reference RFC 7646 for more detail on
same and thus the desire for locally administered negative trust anchors to address
such circumstances...)  Even when a DNSSEC validation error occurs, there remains the
potential for self-help on behalf of end users (via the option to switch to a non-validating
resolver.)

Contrast this to RPKI, wherein the introduction of origin validation into an ISP?s routing
architecture has many operational considerations, and inherently includes the potential to
readily impact the ISP's primary business under anything less than carefully planned and
executed BGP origin validation deployment efforts.   While I?m am certain that everyone
deploying RKPI has BCP 185 memorized, the scope of any such impacts (and lack of viable
workarounds by the impacted customers) inherently means the potential for business impact
is greater than exists with deployment of DNSEC validation by ISPs ? i.e. while I do believe
that your comparison to DNSSEC is directionally correct, it fails overall due to the very real
and significant difference in the magnitude of potential business impact to the relying party.

/John

John Curran
President and CEO
ARIN






________________________________

**** DISCLAIMER****
http://www.bics.com/maildisclaimer/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170203/366b37af/attachment.htm>

From daveid at panix.com  Fri Feb  3 08:39:53 2017
From: daveid at panix.com (David R Huberman)
Date: Fri, 3 Feb 2017 08:39:53 -0500 (EST)
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
Message-ID: <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>

What I dislike about the proposed addition of:

"- at least 50% utilization of each allocation and assignment"

... is it gives ARIN staff no room to take into account individual 
topology.

I may run a network at 95% utilization across all IP addresses.  But I may 
also have a pool of addresses in datacenter X that is under 50% utilized. 
Why am I being penalized for something unrelated to the intent of the 
anti-abuse text?

I think I like the 2016-3 anti-abuse mechanism as-is. It is effective at 
stopping an abuse vector, and easy to implement across myriad topologies.


From jschiller at google.com  Fri Feb  3 10:10:16 2017
From: jschiller at google.com (Jason Schiller)
Date: Fri, 3 Feb 2017 10:10:16 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
Message-ID: <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>

David,

This policy was  proposed to make transfers easy, with predictable
outcomes, for organizations that have used what they got and likely need
more.

This policy was not proposed to ration to those organizations with the most
need, which is exactly what the up to a /16 every 6 months does.

I appreciate the need to prevent abuse, but want this policy to be able to
be used by all organizations that are using what they have got, and will
continue to do such.  For this reason I oppose the once every 6 months
clause.


In a later thread I suggested demonstrate growth of IPv4 utilization of at
least half of the amount of specified transfers since the previous transfer
pre-authorization or approval.  Would that approach work for your
scenario?  As long as your newly deployed specified transfer space was
above 50% or you had some other growth somewhere else to off set under
utilization (which may be associated with a renumbering event) then you
should be fine.

If that approach still doesn't work can you suggest some other mechanism to
prevent abuse that does not prevent an organization who needs IP space from
using this policy?

While I hate creating added complexity, I could get on board for an either
or...

-------
8.5.7 Alternative Additional IPv4 Address Block Criteria
In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
address blocks by demonstrating 80% utilization of their currently
allocated space. If they do so, they qualify to receive one or more
transfers up to the total size of their current ARIN IPv4 address holdings,
with a maximum size of /16.

An organization may only qualify under 8.5.7 once every 6 months, unless
they can also demonstrate growth of IPv4 utilization of at least half of
the amount of specified transfers since the previous transfer
pre-authorization or approval.

OR if the community prefers

An organization may only qualify under 8.5.7 once every 6 months, unless
they can also demonstrate at least 50% utilization of each allocation and
assignment.
------

I think Owen prefers the former version, and maybe the former version does
not penalized a requester for something unrelated to the intent of the
anti-abuse text.  This approach would still meet your needs, not rate limit
the organizations with the most need who want to use this policy, still
provide benefits over the non-simplified approach of having a predictable
outcome and not dependent on some assessment of the hand waviness of future
looking predictions, and does not impact organizations that use this policy
infrequently.)

___Jason


On Fri, Feb 3, 2017 at 8:39 AM, David R Huberman <daveid at panix.com> wrote:

> What I dislike about the proposed addition of:
>
> "- at least 50% utilization of each allocation and assignment"
>
> ... is it gives ARIN staff no room to take into account individual
> topology.
>
> I may run a network at 95% utilization across all IP addresses.  But I may
> also have a pool of addresses in datacenter X that is under 50% utilized.
> Why am I being penalized for something unrelated to the intent of the
> anti-abuse text?
>
> I think I like the 2016-3 anti-abuse mechanism as-is. It is effective at
> stopping an abuse vector, and easy to implement across myriad topologies.
>
> _______________________________________________
> 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.
>



-- 
_______________________________________________________
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/20170203/862efb8b/attachment.htm>

From daveid at panix.com  Fri Feb  3 10:19:22 2017
From: daveid at panix.com (David R Huberman)
Date: Fri, 3 Feb 2017 10:19:22 -0500 (EST)
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
Message-ID: <Pine.NEB.4.64.1702031016000.29477@panix1.panix.com>


I thought of a possible problem with the anti-abuse language -- all 
versions of it.  Let me talk it out.

An organization has a /19.
It has growing products, and wants another /19 for its 1 or 2 year need.
It wants to avail itself of the new language.
It is able to buy a /20 from Buyer A, and a /20 from Buyer B.

It closes the deal with Buyer A first, and transfers at ARIN using the 
proposed language.

How does it use any version we've discussed (Jason's various proposals, 
the current text, etc) to transfer the space it buys from Buyer B?


(In all discussion, yes, you can always use the other sections of 8.5, but 
let's stick to the spirit of this policy language, which is meant to help 
smaller and mid-size networks double their holdings without needs 
testing.)


From mike at iptrading.com  Fri Feb  3 10:34:03 2017
From: mike at iptrading.com (Mike Burns)
Date: Fri, 3 Feb 2017 10:34:03 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
Message-ID: <012901d27e32$f2c2e850$d848b8f0$@iptrading.com>

 

If that approach still doesn't work can you suggest some other mechanism to prevent abuse that does not prevent an organization who needs IP space from using this policy?  

 

 

Hi Jason,

 

Why are we ignoring the mechanism that prevents organizations from buying un-needed anything? To wit, they have to pay money for these addresses. You guys are spinning up unlikely scenarios and ignoring the 800lb. elephant in the room? the cost of these addresses is the mechanism you seek.  

 

Regards,

Mike

 

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

From daveid at panix.com  Fri Feb  3 10:43:00 2017
From: daveid at panix.com (David Huberman)
Date: Fri, 3 Feb 2017 10:43:00 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <012901d27e32$f2c2e850$d848b8f0$@iptrading.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <012901d27e32$f2c2e850$d848b8f0$@iptrading.com>
Message-ID: <AA54F140-A9E3-4811-9761-21BFB42C67DF@panix.com>

Mike,

I buy a /13. I abuse the spirit of 2016-3, meant for smaller transfers as our first attempt at no needs testing, by reiterating /16 transfers one after the other.

Market pricing doesn't stop this, and the ARIN community who participates in public policy matters has made it clear that an incremental approach towards needs testing is a good thing.

David

Sent from my iPhone

> On Feb 3, 2017, at 10:34 AM, Mike Burns <mike at iptrading.com> wrote:
> 
>  
> If that approach still doesn't work can you suggest some other mechanism to prevent abuse that does not prevent an organization who needs IP space from using this policy?  
>  
>  
> Hi Jason,
>  
> Why are we ignoring the mechanism that prevents organizations from buying un-needed anything? To wit, they have to pay money for these addresses. You guys are spinning up unlikely scenarios and ignoring the 800lb. elephant in the room? the cost of these addresses is the mechanism you seek. 
>  
> Regards,
> Mike
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170203/5c01b459/attachment.htm>

From bill at herrin.us  Fri Feb  3 10:47:10 2017
From: bill at herrin.us (William Herrin)
Date: Fri, 3 Feb 2017 10:47:10 -0500
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <20170203084914.GA72088@Vurt.local>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
 <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>
 <20170201084849.GN1111@hanna.meerval.net>
 <F3459EE0-CEA7-41B5-A3EF-29FDEF0C9412@delong.com>
 <20170203084914.GA72088@Vurt.local>
Message-ID: <CAP-guGXTZ900V9M08AVOjmRDeEefBquKmuVuw=dZaXZVbE6nww@mail.gmail.com>

On Fri, Feb 3, 2017 at 3:49 AM, Job Snijders <job at ntt.net> wrote:
> Please keep in mind that this thread was about removing barriers, to
> enable RPKI innovation.

Hi folks,

Is ARIN the right place for an RPKI registry? They seem... reluctant.
It's not just the data for relying parties; they won't publish RPKI
information for the legacy registrants without those registrants first
entering contractual relationships unrelated to RPKI.

Classically ARIN has had a minimalist role in routing policy
decisions. This has been considered a good thing. Fundamentally, RPKI
is routing policy. Maybe another organization should be created to
manage RPKI in North America, one which doesn't suffer ARIN's mindset.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>


From mike at iptrading.com  Fri Feb  3 10:53:57 2017
From: mike at iptrading.com (Mike Burns)
Date: Fri, 3 Feb 2017 10:53:57 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <AA54F140-A9E3-4811-9761-21BFB42C67DF@panix.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <012901d27e32$f2c2e850$d848b8f0$@iptrading.com>
 <AA54F140-A9E3-4811-9761-21BFB42C67DF@panix.com>
Message-ID: <015801d27e35$bac84820$3058d860$@iptrading.com>

Hi David,

 

I appreciate you trying to make me understand.

So are you assuming in your example that you seek to purchase space that you do not need for your business purposes.

My argument is that organizations do not purchase space for which they don?t feel there is a valid business purpose.  Now it?s true that an organization?s perception of need will vary from the one which is being rigorously defined here, but there is an obvious brake on the purchase of items for which there is not a business purpose.

 

And for those whom we are imagining who are determined to somehow go around policy to acquire un-necessary space, there are already plenty of workarounds, the simplest of which is to acquire RIPE space.

 

Am I missing something obvious that requires this additional complexity to what was a nice smooth section of the NRPM?  

 

Regards,

Mike

 

 

From: David Huberman [mailto:daveid at panix.com] 
Sent: Friday, February 03, 2017 10:43 AM
To: Mike Burns <mike at iptrading.com>
Cc: Jason Schiller <jschiller at google.com>; arin-ppml at arin.net
Subject: Re: [arin-ppml] 2016-3 Revisited

 

Mike,

 

I buy a /13. I abuse the spirit of 2016-3, meant for smaller transfers as our first attempt at no needs testing, by reiterating /16 transfers one after the other.

 

Market pricing doesn't stop this, and the ARIN community who participates in public policy matters has made it clear that an incremental approach towards needs testing is a good thing.

 

David

Sent from my iPhone


On Feb 3, 2017, at 10:34 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:

 

If that approach still doesn't work can you suggest some other mechanism to prevent abuse that does not prevent an organization who needs IP space from using this policy?  

 

 

Hi Jason,

 

Why are we ignoring the mechanism that prevents organizations from buying un-needed anything? To wit, they have to pay money for these addresses. You guys are spinning up unlikely scenarios and ignoring the 800lb. elephant in the room? the cost of these addresses is the mechanism you seek.  

 

Regards,

Mike

 

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

From kevinb at thewire.ca  Fri Feb  3 10:56:11 2017
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Fri, 3 Feb 2017 15:56:11 +0000
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <Pine.NEB.4.64.1702031016000.29477@panix1.panix.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <Pine.NEB.4.64.1702031016000.29477@panix1.panix.com>
Message-ID: <7E7773B523E82C478734E793E58F69E78E4F4CD1@SBS2011.thewireinc.local>

David,

I support this policy as revised.

I believe also that statistics previously showed that a large majority of requests were /16 and smaller.

Can you please confirm the following?

1) The policy would remove the requirement for documentation of future use.
2) The policy would not assist organizations that are consistently doubling more than every 6 months.
3) The policy would not assist organizations that require more than a /16.
4) The policy would allow an organization with larger holdings (ie /12) to get a /16 every 6 months.
5) The policy would not limit other transfers in section 8.5.

Thanks,

Kevin Blumberg

-----Original Message-----
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David R Huberman
Sent: Friday, February 3, 2017 10:19 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] 2016-3 Revisited


I thought of a possible problem with the anti-abuse language -- all versions of it.  Let me talk it out.

An organization has a /19.
It has growing products, and wants another /19 for its 1 or 2 year need.
It wants to avail itself of the new language.
It is able to buy a /20 from Buyer A, and a /20 from Buyer B.

It closes the deal with Buyer A first, and transfers at ARIN using the proposed language.

How does it use any version we've discussed (Jason's various proposals, the current text, etc) to transfer the space it buys from Buyer B?


(In all discussion, yes, you can always use the other sections of 8.5, but 
let's stick to the spirit of this policy language, which is meant to help 
smaller and mid-size networks double their holdings without needs 
testing.)
_______________________________________________
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  Fri Feb  3 11:02:25 2017
From: jcurran at arin.net (John Curran)
Date: Fri, 3 Feb 2017 16:02:25 +0000
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <F2BCA30AF0923046891980C0C406DE78B6193C5E@A04083.BGC.NET>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <20170201090138.GO1111@hanna.meerval.net>
 <334C44F8-2C10-4A4C-B347-24565FE10377@arin.net>
 <F2BCA30AF0923046891980C0C406DE78B6193C5E@A04083.BGC.NET>
Message-ID: <5D0CCCD5-07B7-4B2F-B18B-50A76EAD6867@arin.net>

On 3 Feb 2017, at 8:15 AM, LOOS Eric (BCS/CBU) <eric.loos at bics.com<mailto:eric.loos at bics.com>> wrote:

IANAL, but I have worked enough with our legal department to see some red flags in the RPA:
-          Possibility for on-sided modifications of the T&C with automatic acceptance thereof
-          Complete indemnification of ARIN et al.

So I definitely sympathize with the point that the RPA as worded there is probably unacceptable for many carriers (us included)
I also agree that it is a moot point whether this is a click through before a download is possible or fine print of the website which is presumable accepted once the service is accessed; it is in fact indeed commendable that ARIN does not try to let companies agree to such far reaching legal language without at least raising the flag.

Eric -

ARIN does indeed call out the entry into a RPKI legal agreement, and this is an
agreement that includes indemnification (whereas other RIRs rely upon implicit
binding via use to similar provisions in their overall registry agreements.)

Therefore the points made by Wes during his nanog talk regarding the modification of the RPA are pertinent here.

After Wes? presentation, access to ARIN?s TAL was changed to no longer require
explicit acceptance (via entry of email address and access via emailed link) and
instead allow direct download, but it remains unclear whether implicit agreement
via having the TAL bundled with other software would suffice for the same purposes
(at least in the US.)

I wonder why the trustees have chosen to take such a defensive approach on information contained in the RKPI, after all we have had RBL lists in the past for blocking mail, we pretty much all uses RIR routing registries for building our filters, many people rely on PeeringDB for keeping their peering records up to date and I have not encountered such defensive position before.

It is true that the ARIN RPA contains an indemnification clause, but as I pointed out to
Wes, it is remarkably similar to the indemnification clauses that are contained in many
carriers' Internet service contracts.  Providing and purchasing Internet services under
such indemnification provisions does tend to belie claims that those same provisions for
RPKI are burdensome, and further those provisions serve an important role in making
sure that ARIN?s overall registry services (used by many thousands of organizations)
cannot be impacted by any adverse outcome resulting from less-than-diligent RPKI usage.

Especially RPKI requires a wide acceptance to be able to do anything useful.
What would be the process for the trustees to review this matter and share their insights on this matter?

The ARIN Board of Trustees has spent a very significant amount of time in recent
years on RPKI services, including their availability, terms of service and related risks ?
this has resulted in continuous improvement to both the agreements and methods of
access to the TAL as noted above.

The Trustees are all on this mailing list, and I will (as previously noted) bring this
topic to them at their next meeting for further review.  I also note that the ARIN
Board of Trustees holds a public session at each ARIN meeting and is available
to address questions such as these if a more interactive format is preferred.

Thanks!
/John

John Curran
President and CEO
ARIN



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

From daveid at panix.com  Fri Feb  3 11:03:44 2017
From: daveid at panix.com (David R Huberman)
Date: Fri, 3 Feb 2017 11:03:44 -0500 (EST)
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <015801d27e35$bac84820$3058d860$@iptrading.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <012901d27e32$f2c2e850$d848b8f0$@iptrading.com>
 <AA54F140-A9E3-4811-9761-21BFB42C67DF@panix.com>
 <015801d27e35$bac84820$3058d860$@iptrading.com>
Message-ID: <Pine.NEB.4.64.1702031103140.29477@panix1.panix.com>


Mike,

For clarity, your last question - the final paragraph - what smooth 
section is that?  Existing NRPM 8.5, or 2016-3 without the anti-abuse 
clause?

David


On Fri, 3 Feb 2017, Mike Burns wrote:

> Hi David,
>
>
>
> I appreciate you trying to make me understand.
>
> So are you assuming in your example that you seek to purchase space that you do not need for your business purposes.
>
> My argument is that organizations do not purchase space for which they don???t feel there is a valid business purpose.  Now it???s true that an organization???s perception of need will vary from the one which is being rigorously defined here, but there is an obvious brake on the purchase of items for which there is not a business purpose.
>
>
>
> And for those whom we are imagining who are determined to somehow go around policy to acquire un-necessary space, there are already plenty of workarounds, the simplest of which is to acquire RIPE space.
>
>
>
> Am I missing something obvious that requires this additional complexity to what was a nice smooth section of the NRPM?
>
>
>
> Regards,
>
> Mike
>
>
>
>
>
> From: David Huberman [mailto:daveid at panix.com]
> Sent: Friday, February 03, 2017 10:43 AM
> To: Mike Burns <mike at iptrading.com>
> Cc: Jason Schiller <jschiller at google.com>; arin-ppml at arin.net
> Subject: Re: [arin-ppml] 2016-3 Revisited
>
>
>
> Mike,
>
>
>
> I buy a /13. I abuse the spirit of 2016-3, meant for smaller transfers as our first attempt at no needs testing, by reiterating /16 transfers one after the other.
>
>
>
> Market pricing doesn't stop this, and the ARIN community who participates in public policy matters has made it clear that an incremental approach towards needs testing is a good thing.
>
>
>
> David
>
> Sent from my iPhone
>
>
> On Feb 3, 2017, at 10:34 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:
>
>
>
> If that approach still doesn't work can you suggest some other mechanism to prevent abuse that does not prevent an organization who needs IP space from using this policy?
>
>
>
>
>
> Hi Jason,
>
>
>
> Why are we ignoring the mechanism that prevents organizations from buying un-needed anything? To wit, they have to pay money for these addresses. You guys are spinning up unlikely scenarios and ignoring the 800lb. elephant in the room??? the cost of these addresses is the mechanism you seek.
>
>
>
> Regards,
>
> Mike
>
>
>
>

From daveid at panix.com  Fri Feb  3 11:06:58 2017
From: daveid at panix.com (David R Huberman)
Date: Fri, 3 Feb 2017 11:06:58 -0500 (EST)
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <7E7773B523E82C478734E793E58F69E78E4F4CD1@SBS2011.thewireinc.local>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <Pine.NEB.4.64.1702031016000.29477@panix1.panix.com>
 <7E7773B523E82C478734E793E58F69E78E4F4CD1@SBS2011.thewireinc.local>
Message-ID: <Pine.NEB.4.64.1702031106210.29477@panix1.panix.com>


All confirmed, with the reminder of 5), that in all cases, you can always 
use other clauses in 8.5 to qualify for any transfer.


> I support this policy as revised.
>
> I believe also that statistics previously showed that a large majority of requests were /16 and smaller.
>
> Can you please confirm the following?
>
> 1) The policy would remove the requirement for documentation of future use.
> 2) The policy would not assist organizations that are consistently doubling more than every 6 months.
> 3) The policy would not assist organizations that require more than a /16.
> 4) The policy would allow an organization with larger holdings (ie /12) to get a /16 every 6 months.
> 5) The policy would not limit other transfers in section 8.5.
>
> Thanks,
>
> Kevin Blumberg
>
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David R Huberman
> Sent: Friday, February 3, 2017 10:19 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] 2016-3 Revisited
>
>
> I thought of a possible problem with the anti-abuse language -- all versions of it.  Let me talk it out.
>
> An organization has a /19.
> It has growing products, and wants another /19 for its 1 or 2 year need.
> It wants to avail itself of the new language.
> It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
>
> It closes the deal with Buyer A first, and transfers at ARIN using the proposed language.
>
> How does it use any version we've discussed (Jason's various proposals, the current text, etc) to transfer the space it buys from Buyer B?
>
>
> (In all discussion, yes, you can always use the other sections of 8.5, but
> let's stick to the spirit of this policy language, which is meant to help
> smaller and mid-size networks double their holdings without needs
> testing.)
> _______________________________________________
> 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  Fri Feb  3 11:13:15 2017
From: jcurran at arin.net (John Curran)
Date: Fri, 3 Feb 2017 16:13:15 +0000
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <CAP-guGXTZ900V9M08AVOjmRDeEefBquKmuVuw=dZaXZVbE6nww@mail.gmail.com>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
 <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>
 <20170201084849.GN1111@hanna.meerval.net>
 <F3459EE0-CEA7-41B5-A3EF-29FDEF0C9412@delong.com>
 <20170203084914.GA72088@Vurt.local>
 <CAP-guGXTZ900V9M08AVOjmRDeEefBquKmuVuw=dZaXZVbE6nww@mail.gmail.com>
Message-ID: <45740696-4AAB-489F-8476-4F6A823D3BCA@arin.net>

On 3 Feb 2017, at 10:47 AM, William Herrin <bill at herrin.us> wrote:
> 
> Is ARIN the right place for an RPKI registry? They seem... reluctant.

ARIN is actually quite active in development, promotion, and support 
of RPKI services ? please do not confuse having appropriate legal 
agreements with level of enthusiasm...

> It's not just the data for relying parties; they won't publish RPKI
> information for the legacy registrants without those registrants first
> entering contractual relationships unrelated to RPKI. 


As you are aware, we provide legacy resource holders the same registry
services (including ability to update Whois contact info, reverse DNS, etc.)
that they received at ARIN?s formation, and that is done no charge and with 
no  requirement for any agreement.  Resource holders who want newer 
services paid for by the community are expected join and pay the same 
fees as others in that community. 

Thanks,
/John

John Curran
President and CEO
ARIN




From mike at iptrading.com  Fri Feb  3 11:18:45 2017
From: mike at iptrading.com (Mike Burns)
Date: Fri, 3 Feb 2017 11:18:45 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <Pine.NEB.4.64.1702031103140.29477@panix1.panix.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <012901d27e32$f2c2e850$d848b8f0$@iptrading.com>
 <AA54F140-A9E3-4811-9761-21BFB42C67DF@panix.com>
 <015801d27e35$bac84820$3058d860$@iptrading.com>
 <Pine.NEB.4.64.1702031103140.29477@panix1.panix.com>
Message-ID: <017301d27e39$319e76b0$94db6410$@iptrading.com>

Hi David,

I am comparing Section 4 to Section 8 in toto, and bemoaning the growth of Section 8.

As I am sure is obvious, I think that adding verbiage into Section 8 to address problems which have never been shown to exist is just a waste.

These things conspire to protect against the fears of market manipulation which always seem to me to be at the root of these  proposals:

1. IPv4 value will be zero after the IPv6 transition
2. IP address transfers are publicly recorded so there can be no invisible move to control the market
3. IP address rights are subject to change by stakeholders
4. RIPE has had a no-needs policy for quite a while with no evidence of manipulation
5. The IPv4 supply market has been fragmented by 30 years of distribution

I know that you are aware that there is no one-stop-shopping for large IPv4 address blocks, and there are not now nor have ever been enough addresses on the market to come close to levels required for manipulation.

The whole thing is farcical in my mind, and as a broker of more than 350 transfers I think I have as good a window on this market as anybody.   So I just have to point out when we engage in this discussion that we are tilting at windmills and my posts are exaggerated eye-rolling attempts.

Regards,
Mike



-----Original Message-----
From: David R Huberman [mailto:daveid at panix.com] 
Sent: Friday, February 03, 2017 11:04 AM
To: Mike Burns <mike at iptrading.com>
Cc: 'Jason Schiller' <jschiller at google.com>; arin-ppml at arin.net
Subject: RE: [arin-ppml] 2016-3 Revisited


Mike,

For clarity, your last question - the final paragraph - what smooth section is that?  Existing NRPM 8.5, or 2016-3 without the anti-abuse clause?

David


On Fri, 3 Feb 2017, Mike Burns wrote:

> Hi David,
>
>
>
> I appreciate you trying to make me understand.
>
> So are you assuming in your example that you seek to purchase space that you do not need for your business purposes.
>
> My argument is that organizations do not purchase space for which they don???t feel there is a valid business purpose.  Now it???s true that an organization???s perception of need will vary from the one which is being rigorously defined here, but there is an obvious brake on the purchase of items for which there is not a business purpose.
>
>
>
> And for those whom we are imagining who are determined to somehow go around policy to acquire un-necessary space, there are already plenty of workarounds, the simplest of which is to acquire RIPE space.
>
>
>
> Am I missing something obvious that requires this additional complexity to what was a nice smooth section of the NRPM?
>
>
>
> Regards,
>
> Mike
>
>
>
>
>
> From: David Huberman [mailto:daveid at panix.com]
> Sent: Friday, February 03, 2017 10:43 AM
> To: Mike Burns <mike at iptrading.com>
> Cc: Jason Schiller <jschiller at google.com>; arin-ppml at arin.net
> Subject: Re: [arin-ppml] 2016-3 Revisited
>
>
>
> Mike,
>
>
>
> I buy a /13. I abuse the spirit of 2016-3, meant for smaller transfers as our first attempt at no needs testing, by reiterating /16 transfers one after the other.
>
>
>
> Market pricing doesn't stop this, and the ARIN community who participates in public policy matters has made it clear that an incremental approach towards needs testing is a good thing.
>
>
>
> David
>
> Sent from my iPhone
>
>
> On Feb 3, 2017, at 10:34 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:
>
>
>
> If that approach still doesn't work can you suggest some other mechanism to prevent abuse that does not prevent an organization who needs IP space from using this policy?
>
>
>
>
>
> Hi Jason,
>
>
>
> Why are we ignoring the mechanism that prevents organizations from buying un-needed anything? To wit, they have to pay money for these addresses. You guys are spinning up unlikely scenarios and ignoring the 800lb. elephant in the room??? the cost of these addresses is the mechanism you seek.
>
>
>
> Regards,
>
> Mike
>
>
>
>



From jschiller at google.com  Fri Feb  3 11:46:02 2017
From: jschiller at google.com (Jason Schiller)
Date: Fri, 3 Feb 2017 11:46:02 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <Pine.NEB.4.64.1702031016000.29477@panix1.panix.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <Pine.NEB.4.64.1702031016000.29477@panix1.panix.com>
Message-ID: <CAC4yj2XYi+_XwLeQihT3jZLdLQLOXQ=vr70N-NN=wVi9Dus5ew@mail.gmail.com>

David,

TL;DR
The policy says "one or more transfers up to the total size of their
current ARIN IPv4 address holdings"

My read suggests you can do one or many transfers within a two year window
up to the amount approved.  There is no need to re-demonstrate utilization
within the two year window so long as total specified transfer is less than
a /16 or double your current holdings.

Can you address the question of if "demonstrated growth of IPv4 utilization
of at least half of the amount of specified transfers" is acceptable to you
as the sole anti-abuse provision, or if it is acceptable to you in addition
to the 6 month restriction.

--

An organization has a /19.
It has growing products, and wants another /19 for its 1 or 2 year need.
It wants to avail itself of the new language.
It show 80%+ utilization of its existing /19.
It then gets blanket pre-approval for one or more transfers which total to
a /19 over then next 2 years.

Then it transfers one /20, then the other..

OR

It closes the deal with Buyer A first, and transfers at ARIN using the
proposed language.
That process yields
1. pre-authorization for a /19 equalivent of specified transfers
2. approval for the /20 which is deducted from the /19 pre-athorization


Policy Text
---------------

8.5.7 Alternative Additional IPv4 Address Block Criteria
In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
address blocks by demonstrating 80% utilization of their currently
allocated space. If they do so, they qualify to receive one or more
transfers up to the total size of their current ARIN IPv4 address holdings,
with a maximum size of /16.

An organization may only qualify under 8.5.7 once every 6 months, unless
they can also demonstrate growth of IPv4 utilization of at least half of
the amount of specified transfers since the previous transfer
pre-authorization or approval.


Some extra words in policy text for more clarity
--------------------------------------------------------------

In lieu of 8.5.5 and 8.5.6, organizations may  qualify to get a new two
year specified transfer pre-authorization under 8.5.7 once every 6 months,
unless they can also demonstrate growth of IPv4 utilization of at least
half of the amount of specified transfers since the previous transfer
pre-authorization or approval.

An organization may only qualify to get a new two year specified transfer
pre-authorization  under 8.5.7 once every 6 months, unless they can also
demonstrate growth of IPv4 utilization of at least half of the amount of
specified transfers since the previous transfer pre-authorization or
approval.



__Jason


On Fri, Feb 3, 2017 at 10:19 AM, David R Huberman <daveid at panix.com> wrote:

>
> I thought of a possible problem with the anti-abuse language -- all
> versions of it.  Let me talk it out.
>
> An organization has a /19.
> It has growing products, and wants another /19 for its 1 or 2 year need.
> It wants to avail itself of the new language.
> It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
>
> It closes the deal with Buyer A first, and transfers at ARIN using the
> proposed language.
>
> How does it use any version we've discussed (Jason's various proposals,
> the current text, etc) to transfer the space it buys from Buyer B?
>
>
> (In all discussion, yes, you can always use the other sections of 8.5, but
> let's stick to the spirit of this policy language, which is meant to help
> smaller and mid-size networks double their holdings without needs testing.)
>
> _______________________________________________
> 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.
>



-- 
_______________________________________________________
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/20170203/1f1b2d79/attachment.htm>

From bill at herrin.us  Fri Feb  3 12:29:29 2017
From: bill at herrin.us (William Herrin)
Date: Fri, 3 Feb 2017 12:29:29 -0500
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <45740696-4AAB-489F-8476-4F6A823D3BCA@arin.net>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
 <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>
 <20170201084849.GN1111@hanna.meerval.net>
 <F3459EE0-CEA7-41B5-A3EF-29FDEF0C9412@delong.com>
 <20170203084914.GA72088@Vurt.local>
 <CAP-guGXTZ900V9M08AVOjmRDeEefBquKmuVuw=dZaXZVbE6nww@mail.gmail.com>
 <45740696-4AAB-489F-8476-4F6A823D3BCA@arin.net>
Message-ID: <CAP-guGUOXrf3mRNOiWf4dmpqTaipzA_jPOUVftuGtt+LzhYcng@mail.gmail.com>

On Fri, Feb 3, 2017 at 11:13 AM, John Curran <jcurran at arin.net> wrote:
> On 3 Feb 2017, at 10:47 AM, William Herrin <bill at herrin.us> wrote:
>> Is ARIN the right place for an RPKI registry? They seem... reluctant.
> ARIN is actually quite active in development, promotion, and support
> of RPKI services ? please do not confuse having appropriate legal
> agreements with level of enthusiasm...

John,

There's nothing more dangerous to an effort than a bureaucrat's
enthusiasm. Out in the real world, "Best efforts. AS IS," is more
often than not the appropriate legal agreement. It's a contract that
allows work to get done.


>> It's not just the data for relying parties; they won't publish RPKI
>> information for the legacy registrants without those registrants first
>> entering contractual relationships unrelated to RPKI.
>
> As you are aware, we provide legacy resource holders the same registry
> services (including ability to update Whois contact info, reverse DNS, etc.)
> that they received at ARIN?s formation, and that is done no charge and with
> no  requirement for any agreement.

Exactly. You refuse to provide new services related to legacy resource
holdings, including RPKI. While not unreasonable in the context of
ARIN operations, this is harmful to the RPKI efforts. This is
something no organization prioritizing RPKI would do. Since offering
new services like RPKI to legacy registrants* appears inimical to
ARIN's core mission I respectfully question whether ARIN can be a
satisfactory steward for RPKI.

I've been watching this for a couple years now John. What you're doing
with RPKI isn't working.

Regards,
Bill Herrin


* without explicitly signing a registration services agreement
contract with far broader implications for the resource than what is
tied to the new service.


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>


From scottleibrand at gmail.com  Fri Feb  3 12:44:07 2017
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 3 Feb 2017 09:44:07 -0800
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <CAC4yj2XYi+_XwLeQihT3jZLdLQLOXQ=vr70N-NN=wVi9Dus5ew@mail.gmail.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <Pine.NEB.4.64.1702031016000.29477@panix1.panix.com>
 <CAC4yj2XYi+_XwLeQihT3jZLdLQLOXQ=vr70N-NN=wVi9Dus5ew@mail.gmail.com>
Message-ID: <CAGkMwz6Mnfo3xnQwLXwUFMUfm=sMoudHYEa_Jj+KteMjft5L3Q@mail.gmail.com>

On Fri, Feb 3, 2017 at 8:46 AM, Jason Schiller <jschiller at google.com> wrote:

> David,
>
> TL;DR
> The policy says "one or more transfers up to the total size of their
> current ARIN IPv4 address holdings"
>
> My read suggests you can do one or many transfers within a two year window
> up to the amount approved.  There is no need to re-demonstrate utilization
> within the two year window so long as total specified transfer is less than
> a /16 or double your current holdings.
>
> Can you address the question of if "demonstrated growth of IPv4
> utilization of at least half of the amount of specified transfers" is
> acceptable to you as the sole anti-abuse provision, or if it is acceptable
> to you in addition to the 6 month restriction.
>
> --
>
> An organization has a /19.
> It has growing products, and wants another /19 for its 1 or 2 year need.
> It wants to avail itself of the new language.
> It show 80%+ utilization of its existing /19.
> It then gets blanket pre-approval for one or more transfers which total to
> a /19 over then next 2 years.
>
> Then it transfers one /20, then the other..
>
> OR
>
> It closes the deal with Buyer A first, and transfers at ARIN using the
> proposed language.
> That process yields
> 1. pre-authorization for a /19 equalivent of specified transfers
> 2. approval for the /20 which is deducted from the /19 pre-athorization
>
>
> Policy Text
> ---------------
>
> 8.5.7 Alternative Additional IPv4 Address Block Criteria
> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
> address blocks by demonstrating 80% utilization of their currently
> allocated space. If they do so, they qualify to receive one or more
> transfers up to the total size of their current ARIN IPv4 address holdings,
> with a maximum size of /16.
>
> An organization may only qualify under 8.5.7 once every 6 months, unless
> they can also demonstrate growth of IPv4 utilization of at least half of
> the amount of specified transfers since the previous transfer
> pre-authorization or approval.
>

This works for me.  It removes my problems with the "every 6 months"
language: particularly, a small fast-growing company using 8.5.7 to double
their holdings from a /24 to a /23 might fully utilize the /23 and need
another /23 before 6 months is out.

>
>
> Some extra words in policy text for more clarity
>
--------------------------------------------------------------
>

I think the duplicate words added to the first sentence actually make it
less clear, so I would go with the simpler text above.

-Scott

>

>
> In lieu of 8.5.5 and 8.5.6, organizations may  qualify to get a new two
> year specified transfer pre-authorization under 8.5.7 once every 6 months,
> unless they can also demonstrate growth of IPv4 utilization of at least
> half of the amount of specified transfers since the previous transfer
> pre-authorization or approval.
>
> An organization may only qualify to get a new two year specified transfer
> pre-authorization  under 8.5.7 once every 6 months, unless they can also
> demonstrate growth of IPv4 utilization of at least half of the amount of
> specified transfers since the previous transfer pre-authorization or
> approval.
>
>
>
> __Jason
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170203/e2ddbd21/attachment.htm>

From jcurran at arin.net  Fri Feb  3 14:20:59 2017
From: jcurran at arin.net (John Curran)
Date: Fri, 3 Feb 2017 19:20:59 +0000
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <CAP-guGUOXrf3mRNOiWf4dmpqTaipzA_jPOUVftuGtt+LzhYcng@mail.gmail.com>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
 <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>
 <20170201084849.GN1111@hanna.meerval.net>
 <F3459EE0-CEA7-41B5-A3EF-29FDEF0C9412@delong.com>
 <20170203084914.GA72088@Vurt.local>
 <CAP-guGXTZ900V9M08AVOjmRDeEefBquKmuVuw=dZaXZVbE6nww@mail.gmail.com>
 <45740696-4AAB-489F-8476-4F6A823D3BCA@arin.net>
 <CAP-guGUOXrf3mRNOiWf4dmpqTaipzA_jPOUVftuGtt+LzhYcng@mail.gmail.com>
Message-ID: <FB696922-5F68-4874-BF32-1EF10F8561D9@arin.net>

On 3 Feb 2017, at 12:29 PM, William Herrin <bill at herrin.us> wrote:
>> As you are aware, we provide legacy resource holders the same registry
>> services (including ability to update Whois contact info, reverse DNS, etc.)
>> that they received at ARIN?s formation, and that is done no charge and with
>> no  requirement for any agreement.
> 
> Exactly. You refuse to provide new services related to legacy resource
> holdings, including RPKI. While not unreasonable in the context of
> ARIN operations, this is harmful to the RPKI efforts. 

Bill -

To be clear, we offer all registry services to all resources holders under the
same terms, but I do agree that having a segment of resource holders that 
do not wish to participate in the ARIN community nor support it financially 
does detract somewhat from community initiatives such as RPKI.   This
is unfortunate, but seems to slowly diminishing over time via both IPv4 
transfers and IPv6 deployment.

Thanks!
/John

John Curran
President and CEO
ARIN


From bill at herrin.us  Fri Feb  3 14:25:45 2017
From: bill at herrin.us (William Herrin)
Date: Fri, 3 Feb 2017 14:25:45 -0500
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <FB696922-5F68-4874-BF32-1EF10F8561D9@arin.net>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
 <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>
 <20170201084849.GN1111@hanna.meerval.net>
 <F3459EE0-CEA7-41B5-A3EF-29FDEF0C9412@delong.com>
 <20170203084914.GA72088@Vurt.local>
 <CAP-guGXTZ900V9M08AVOjmRDeEefBquKmuVuw=dZaXZVbE6nww@mail.gmail.com>
 <45740696-4AAB-489F-8476-4F6A823D3BCA@arin.net>
 <CAP-guGUOXrf3mRNOiWf4dmpqTaipzA_jPOUVftuGtt+LzhYcng@mail.gmail.com>
 <FB696922-5F68-4874-BF32-1EF10F8561D9@arin.net>
Message-ID: <CAP-guGVCBeTCZNSYw5rVOsJpmiC_dwOgK_cZHa_31-A-MnFzSg@mail.gmail.com>

On Fri, Feb 3, 2017 at 2:20 PM, John Curran <jcurran at arin.net> wrote:
> On 3 Feb 2017, at 12:29 PM, William Herrin <bill at herrin.us> wrote:
>>> As you are aware, we provide legacy resource holders the same registry
>>> services (including ability to update Whois contact info, reverse DNS, etc.)
>>> that they received at ARIN?s formation, and that is done no charge and with
>>> no  requirement for any agreement.
>>
>> Exactly. You refuse to provide new services related to legacy resource
>> holdings, including RPKI. While not unreasonable in the context of
>> ARIN operations, this is harmful to the RPKI efforts.
>
> To be clear, we offer all registry services to all resources holders under the
> same terms, but I do agree that having a segment of resource holders that
> do not wish to participate in the ARIN community nor support it financially
> does detract somewhat from community initiatives such as RPKI.   This
> is unfortunate, but seems to slowly diminishing over time via both IPv4
> transfers and IPv6 deployment.

John,

Respectfully, the all-or-nothing requirement isn't something
mysteriously and unfortunately happening to you. ARIN is the cause.

Regards,
Bill Herrin




-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>


From rjletts at uw.edu  Fri Feb  3 14:46:42 2017
From: rjletts at uw.edu (Richard J. Letts)
Date: Fri, 3 Feb 2017 19:46:42 +0000
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <CAP-guGUOXrf3mRNOiWf4dmpqTaipzA_jPOUVftuGtt+LzhYcng@mail.gmail.com>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
 <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>
 <20170201084849.GN1111@hanna.meerval.net>
 <F3459EE0-CEA7-41B5-A3EF-29FDEF0C9412@delong.com>
 <20170203084914.GA72088@Vurt.local>
 <CAP-guGXTZ900V9M08AVOjmRDeEefBquKmuVuw=dZaXZVbE6nww@mail.gmail.com>
 <45740696-4AAB-489F-8476-4F6A823D3BCA@arin.net>
 <CAP-guGUOXrf3mRNOiWf4dmpqTaipzA_jPOUVftuGtt+LzhYcng@mail.gmail.com>
Message-ID: <DM5PR08MB2633A25005C78FC46D2FC42DC04F0@DM5PR08MB2633.namprd08.prod.outlook.com>

From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
> Sent: Friday, February 3, 2017 9:29 AM
...
> Exactly. You refuse to provide new services related to legacy resource
> holdings, including RPKI. While not unreasonable in the context of ARIN
> operations, this is harmful to the RPKI efforts. This is something no
> organization prioritizing RPKI would do. Since offering new services like RPKI
> to legacy registrants* appears inimical to ARIN's core mission I respectfully
> question whether ARIN can be a satisfactory steward for RPKI.

RIPE's Policy is:
The resource certificate is linked to RIPE NCC registration. This is because only for as long as you are a RIPE NCC member and *have a contractual relationship with the RIPE NCC* can it be authoritatively stated who the holder of a certain Internet number resource is. 

 [Emphasis mine]

It doesn't seem to that different from what I understand ARIN's policy is.


From jcurran at arin.net  Fri Feb  3 15:06:08 2017
From: jcurran at arin.net (John Curran)
Date: Fri, 3 Feb 2017 20:06:08 +0000
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <DM5PR08MB2633A25005C78FC46D2FC42DC04F0@DM5PR08MB2633.namprd08.prod.outlook.com>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
 <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>
 <20170201084849.GN1111@hanna.meerval.net>
 <F3459EE0-CEA7-41B5-A3EF-29FDEF0C9412@delong.com>
 <20170203084914.GA72088@Vurt.local>
 <CAP-guGXTZ900V9M08AVOjmRDeEefBquKmuVuw=dZaXZVbE6nww@mail.gmail.com>
 <45740696-4AAB-489F-8476-4F6A823D3BCA@arin.net>
 <CAP-guGUOXrf3mRNOiWf4dmpqTaipzA_jPOUVftuGtt+LzhYcng@mail.gmail.com>
 <DM5PR08MB2633A25005C78FC46D2FC42DC04F0@DM5PR08MB2633.namprd08.prod.outlook.com>
Message-ID: <3910F61F-E71A-4A2C-BFDF-93973930B004@arin.net>

On 3 Feb 2017, at 2:46 PM, Richard J. Letts <rjletts at uw.edu> wrote:
> 
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
>> Sent: Friday, February 3, 2017 9:29 AM
> ...
>> Exactly. You refuse to provide new services related to legacy resource
>> holdings, including RPKI. While not unreasonable in the context of ARIN
>> operations, this is harmful to the RPKI efforts. This is something no
>> organization prioritizing RPKI would do. Since offering new services like RPKI
>> to legacy registrants* appears inimical to ARIN's core mission I respectfully
>> question whether ARIN can be a satisfactory steward for RPKI.
> 
> RIPE's Policy is:
> The resource certificate is linked to RIPE NCC registration. This is because only for as long as you are a RIPE NCC member and *have a contractual relationship with the RIPE NCC* can it be authoritatively stated who the holder of a certain Internet number resource is. 
> 
> [Emphasis mine]
> 
> It doesn't seem to that different from what I understand ARIN's policy is.


Richard - 
 
   RIPE?s handling of legacy resource holders is different from ARIN?s,
   in that ARIN requires that legacy resource holders wishing to receive
   additional services sign the RSA and pay legacy maintenance fees. 
 
   Because the RSA delineates specific rights of the resource holder 
   (and includes a disclaimer of other rights that some might wish to
   assert), ARIN?s requirement to enter into such an agreement to 
   provide RPKI services likely precludes some parties from RPKI 
   deployment: specifically those parties that value indeterminate 
   perceived rights as more important than participating in RPKI. 

I hope this helps clarify the issue somewhat (and Bill - if I?ve 
mischaracterized the situation, please feel free to elaborate)

Thanks,
/John

John Curran
President and CEO
ARIN


From bill at herrin.us  Fri Feb  3 15:33:06 2017
From: bill at herrin.us (William Herrin)
Date: Fri, 3 Feb 2017 15:33:06 -0500
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <3910F61F-E71A-4A2C-BFDF-93973930B004@arin.net>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
 <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>
 <20170201084849.GN1111@hanna.meerval.net>
 <F3459EE0-CEA7-41B5-A3EF-29FDEF0C9412@delong.com>
 <20170203084914.GA72088@Vurt.local>
 <CAP-guGXTZ900V9M08AVOjmRDeEefBquKmuVuw=dZaXZVbE6nww@mail.gmail.com>
 <45740696-4AAB-489F-8476-4F6A823D3BCA@arin.net>
 <CAP-guGUOXrf3mRNOiWf4dmpqTaipzA_jPOUVftuGtt+LzhYcng@mail.gmail.com>
 <DM5PR08MB2633A25005C78FC46D2FC42DC04F0@DM5PR08MB2633.namprd08.prod.outlook.com>
 <3910F61F-E71A-4A2C-BFDF-93973930B004@arin.net>
Message-ID: <CAP-guGXf9=+wBvp0immqDf8_M_WBi9THYy1n1KBuaisXdpmFHw@mail.gmail.com>

On Fri, Feb 3, 2017 at 3:06 PM, John Curran <jcurran at arin.net> wrote:
>    RIPE?s handling of legacy resource holders is different from ARIN?s,
>    in that ARIN requires that legacy resource holders wishing to receive
>    additional services sign the RSA and pay legacy maintenance fees.
>
>    Because the RSA delineates specific rights of the resource holder
>    (and includes a disclaimer of other rights that some might wish to
>    assert), ARIN?s requirement to enter into such an agreement to
>    provide RPKI services likely precludes some parties from RPKI
>    deployment: specifically those parties that value indeterminate
>    perceived rights as more important than participating in RPKI.
>
> I hope this helps clarify the issue somewhat (and Bill - if I?ve
> mischaracterized the situation, please feel free to elaborate)

Hi John,

Close enough for the sake of this discussion. The point is: as a
steward of RPKI, ARIN has to make choices which advance the use and
utility of RPKI. ARIN also makes choices which enhance ARIN's legal
standing as the North American monopoly address registry. These
choices are not 100% compatible and where there has been a conflict of
interest ARIN seems to me to have consistently prioritized its
non-RPKI address registry legal standing over advancing the utility of
RPKI. This is damaging to RPKI and to my way of thinking calls in to
question ARIN's suitability to be the steward.

Richard - I'm not conversant enough about RIPE practices and policies
to offer argument about what you said. I don't even know if RIPE
maintains registrations which are "legacy" in the ARIN sense of the
word -- such registrations predated the creation of current RIRs
including ARIN and RIPE.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>


From owen at delong.com  Fri Feb  3 17:22:15 2017
From: owen at delong.com (Owen DeLong)
Date: Fri, 3 Feb 2017 14:22:15 -0800
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <Pine.NEB.4.64.1702031016000.29477@panix1.panix.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <Pine.NEB.4.64.1702031016000.29477@panix1.panix.com>
Message-ID: <BE2B2B79-D4BA-4000-9C2E-718119AD5501@delong.com>

Simple to resolve for the 6-month horizon ?

? Such that no more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period. ?

Owen

> On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com> wrote:
> 
> 
> I thought of a possible problem with the anti-abuse language -- all versions of it.  Let me talk it out.
> 
> An organization has a /19.
> It has growing products, and wants another /19 for its 1 or 2 year need.
> It wants to avail itself of the new language.
> It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
> 
> It closes the deal with Buyer A first, and transfers at ARIN using the proposed language.
> 
> How does it use any version we've discussed (Jason's various proposals, the current text, etc) to transfer the space it buys from Buyer B?
> 
> 
> (In all discussion, yes, you can always use the other sections of 8.5, but let's stick to the spirit of this policy language, which is meant to help smaller and mid-size networks double their holdings without needs testing.)
> _______________________________________________
> 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 Feb  3 17:23:53 2017
From: owen at delong.com (Owen DeLong)
Date: Fri, 3 Feb 2017 14:23:53 -0800
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <CAP-guGXTZ900V9M08AVOjmRDeEefBquKmuVuw=dZaXZVbE6nww@mail.gmail.com>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
 <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>
 <20170201084849.GN1111@hanna.meerval.net>
 <F3459EE0-CEA7-41B5-A3EF-29FDEF0C9412@delong.com>
 <20170203084914.GA72088@Vurt.local>
 <CAP-guGXTZ900V9M08AVOjmRDeEefBquKmuVuw=dZaXZVbE6nww@mail.gmail.com>
Message-ID: <AA6E4B88-46FC-47A4-8780-BDBCF88D1EF8@delong.com>


> On Feb 3, 2017, at 07:47 , William Herrin <bill at herrin.us> wrote:
> 
> On Fri, Feb 3, 2017 at 3:49 AM, Job Snijders <job at ntt.net> wrote:
>> Please keep in mind that this thread was about removing barriers, to
>> enable RPKI innovation.
> 
> Hi folks,
> 
> Is ARIN the right place for an RPKI registry? They seem... reluctant.
> It's not just the data for relying parties; they won't publish RPKI
> information for the legacy registrants without those registrants first
> entering contractual relationships unrelated to RPKI.
> 
> Classically ARIN has had a minimalist role in routing policy
> decisions. This has been considered a good thing. Fundamentally, RPKI
> is routing policy. Maybe another organization should be created to
> manage RPKI in North America, one which doesn't suffer ARIN's mindset.
> 

Since ARIN is the registry, there?s really no other authoritative source
for the information.

As such, nobody else is in a proper position to certify the resource holdings.

Owen



From owen at delong.com  Fri Feb  3 17:25:51 2017
From: owen at delong.com (Owen DeLong)
Date: Fri, 3 Feb 2017 14:25:51 -0800
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <015801d27e35$bac84820$3058d860$@iptrading.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <012901d27e32$f2c2e850$d848b8f0$@iptrading.com>
 <AA54F140-A9E3-4811-9761-21BFB42C67DF@panix.com>
 <015801d27e35$bac84820$3058d860$@iptrading.com>
Message-ID: <826CB552-121B-4F2F-8715-057C97511805@delong.com>

No, Mike, You are missing that ?an organization?s business purpose? may be something other than ?running an operational network?.

We are attempting to ensure that the addresses go to those who intend to use them in an operational network, rather than treating them as a commodity futures investment, speculative transaction, or other financial manipulation at the expense of the internet.

Even RIPE requires you to use at least half of the addresses on an operational network.

Owen

> On Feb 3, 2017, at 07:53 , Mike Burns <mike at iptrading.com> wrote:
> 
> Hi David,
>  
> I appreciate you trying to make me understand.
> So are you assuming in your example that you seek to purchase space that you do not need for your business purposes.
> My argument is that organizations do not purchase space for which they don?t feel there is a valid business purpose.  Now it?s true that an organization?s perception of need will vary from the one which is being rigorously defined here, but there is an obvious brake on the purchase of items for which there is not a business purpose.
>  
> And for those whom we are imagining who are determined to somehow go around policy to acquire un-necessary space, there are already plenty of workarounds, the simplest of which is to acquire RIPE space.
>  
> Am I missing something obvious that requires this additional complexity to what was a nice smooth section of the NRPM?  
>  
> Regards,
> Mike
>  
>  
> From: David Huberman [mailto:daveid at panix.com <mailto:daveid at panix.com>] 
> Sent: Friday, February 03, 2017 10:43 AM
> To: Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com>>
> Cc: Jason Schiller <jschiller at google.com <mailto:jschiller at google.com>>; arin-ppml at arin.net <mailto:arin-ppml at arin.net>
> Subject: Re: [arin-ppml] 2016-3 Revisited
>  
> Mike,
>  
> I buy a /13. I abuse the spirit of 2016-3, meant for smaller transfers as our first attempt at no needs testing, by reiterating /16 transfers one after the other.
>  
> Market pricing doesn't stop this, and the ARIN community who participates in public policy matters has made it clear that an incremental approach towards needs testing is a good thing.
>  
> David
> 
> Sent from my iPhone
> 
> On Feb 3, 2017, at 10:34 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com>> wrote:
> 
>>  
>> If that approach still doesn't work can you suggest some other mechanism to prevent abuse that does not prevent an organization who needs IP space from using this policy?  
>>  
>>  
>> Hi Jason,
>>  
>> Why are we ignoring the mechanism that prevents organizations from buying un-needed anything? To wit, they have to pay money for these addresses. You guys are spinning up unlikely scenarios and ignoring the 800lb. elephant in the room? the cost of these addresses is the mechanism you seek.  
>>  
>> Regards,
>> Mike
>>  
> _______________________________________________
> 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 <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/20170203/623404bf/attachment.htm>

From owen at delong.com  Fri Feb  3 17:26:27 2017
From: owen at delong.com (Owen DeLong)
Date: Fri, 3 Feb 2017 14:26:27 -0800
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <7E7773B523E82C478734E793E58F69E78E4F4CD1@SBS2011.thewireinc.local>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <Pine.NEB.4.64.1702031016000.29477@panix1.panix.com>
 <7E7773B523E82C478734E793E58F69E78E4F4CD1@SBS2011.thewireinc.local>
Message-ID: <9542B1E5-1791-4ED6-946B-A7DA65C27DF6@delong.com>

All of those are correct, Kevin.

Owen

> On Feb 3, 2017, at 07:56 , Kevin Blumberg <kevinb at thewire.ca> wrote:
> 
> David,
> 
> I support this policy as revised.
> 
> I believe also that statistics previously showed that a large majority of requests were /16 and smaller.
> 
> Can you please confirm the following?
> 
> 1) The policy would remove the requirement for documentation of future use.
> 2) The policy would not assist organizations that are consistently doubling more than every 6 months.
> 3) The policy would not assist organizations that require more than a /16.
> 4) The policy would allow an organization with larger holdings (ie /12) to get a /16 every 6 months.
> 5) The policy would not limit other transfers in section 8.5.
> 
> Thanks,
> 
> Kevin Blumberg
> 
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David R Huberman
> Sent: Friday, February 3, 2017 10:19 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] 2016-3 Revisited
> 
> 
> I thought of a possible problem with the anti-abuse language -- all versions of it.  Let me talk it out.
> 
> An organization has a /19.
> It has growing products, and wants another /19 for its 1 or 2 year need.
> It wants to avail itself of the new language.
> It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
> 
> It closes the deal with Buyer A first, and transfers at ARIN using the proposed language.
> 
> How does it use any version we've discussed (Jason's various proposals, the current text, etc) to transfer the space it buys from Buyer B?
> 
> 
> (In all discussion, yes, you can always use the other sections of 8.5, but 
> let's stick to the spirit of this policy language, which is meant to help 
> smaller and mid-size networks double their holdings without needs 
> testing.)
> _______________________________________________
> 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 Feb  3 17:32:47 2017
From: owen at delong.com (Owen DeLong)
Date: Fri, 3 Feb 2017 14:32:47 -0800
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <017301d27e39$319e76b0$94db6410$@iptrading.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <012901d27e32$f2c2e850$d848b8f0$@iptrading.com>
 <AA54F140-A9E3-4811-9761-21BFB42C67DF@panix.com>
 <015801d27e35$bac84820$3058d860$@iptrading.com>
 <Pine.NEB.4.64.1702031103140.29477@panix1.panix.com>
 <017301d27e39$319e76b0$94db6410$@iptrading.com>
Message-ID: <C6D6981E-A12E-4C0C-8D5A-60C47168B571@delong.com>


> On Feb 3, 2017, at 08:18 , Mike Burns <mike at iptrading.com> wrote:
> 
> Hi David,
> 
> I am comparing Section 4 to Section 8 in toto, and bemoaning the growth of Section 8.
> 
> As I am sure is obvious, I think that adding verbiage into Section 8 to address problems which have never been shown to exist is just a waste.
> 
> These things conspire to protect against the fears of market manipulation which always seem to me to be at the root of these  proposals:
> 
> 1. IPv4 value will be zero after the IPv6 transition
	Which does nothing to prevent speculative transactions placing bets against this
	transition through IPv4 market manipulation.

> 2. IP address transfers are publicly recorded so there can be no invisible move to control the market
	Except that the public information is rather limited and there?s nothing that guarantees a single
	actor is visible as a single Organization.

> 3. IP address rights are subject to change by stakeholders
	Within the limitations of the RSA which is rather rigid, actually.

> 4. RIPE has had a no-needs policy for quite a while with no evidence of manipulation
	Simply not true. RIPE has a questionable needs policy IMHO, but it is still a needs-based policy.

> 5. The IPv4 supply market has been fragmented by 30 years of distribution
	Not sure how this contributes to preventing speculative transactions. Many stocks are speculatively traded every day
	which have been on the market for far more than 30 years. Companies more than 30 years old have been subject of hostile
	takeovers.

> I know that you are aware that there is no one-stop-shopping for large IPv4 address blocks, and there are not now nor have ever been enough addresses on the market to come close to levels required for manipulation.

Manipulation of a market only requires gaining control of a substantial portion of the market, not necessarily the total of all IPv4 addresses. Indeed your statement here would support the idea that the small market is easier to manipulate rather than more difficult.

> The whole thing is farcical in my mind, and as a broker of more than 350 transfers I think I have as good a window on this market as anybody.   So I just have to point out when we engage in this discussion that we are tilting at windmills and my posts are exaggerated eye-rolling attempts.

While I appreciate your colorful characterization of those of us with opposing views as much as anyone else, I find your belief that the market is free of manipulation or that there is no need to make efforts to prevent same to be equally worthy of a donkey and substantial eye-rolling.

Owen

> 
> Regards,
> Mike
> 
> 
> 
> -----Original Message-----
> From: David R Huberman [mailto:daveid at panix.com] 
> Sent: Friday, February 03, 2017 11:04 AM
> To: Mike Burns <mike at iptrading.com>
> Cc: 'Jason Schiller' <jschiller at google.com>; arin-ppml at arin.net
> Subject: RE: [arin-ppml] 2016-3 Revisited
> 
> 
> Mike,
> 
> For clarity, your last question - the final paragraph - what smooth section is that?  Existing NRPM 8.5, or 2016-3 without the anti-abuse clause?
> 
> David
> 
> 
> On Fri, 3 Feb 2017, Mike Burns wrote:
> 
>> Hi David,
>> 
>> 
>> 
>> I appreciate you trying to make me understand.
>> 
>> So are you assuming in your example that you seek to purchase space that you do not need for your business purposes.
>> 
>> My argument is that organizations do not purchase space for which they don???t feel there is a valid business purpose.  Now it???s true that an organization???s perception of need will vary from the one which is being rigorously defined here, but there is an obvious brake on the purchase of items for which there is not a business purpose.
>> 
>> 
>> 
>> And for those whom we are imagining who are determined to somehow go around policy to acquire un-necessary space, there are already plenty of workarounds, the simplest of which is to acquire RIPE space.
>> 
>> 
>> 
>> Am I missing something obvious that requires this additional complexity to what was a nice smooth section of the NRPM?
>> 
>> 
>> 
>> Regards,
>> 
>> Mike
>> 
>> 
>> 
>> 
>> 
>> From: David Huberman [mailto:daveid at panix.com]
>> Sent: Friday, February 03, 2017 10:43 AM
>> To: Mike Burns <mike at iptrading.com>
>> Cc: Jason Schiller <jschiller at google.com>; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] 2016-3 Revisited
>> 
>> 
>> 
>> Mike,
>> 
>> 
>> 
>> I buy a /13. I abuse the spirit of 2016-3, meant for smaller transfers as our first attempt at no needs testing, by reiterating /16 transfers one after the other.
>> 
>> 
>> 
>> Market pricing doesn't stop this, and the ARIN community who participates in public policy matters has made it clear that an incremental approach towards needs testing is a good thing.
>> 
>> 
>> 
>> David
>> 
>> Sent from my iPhone
>> 
>> 
>> On Feb 3, 2017, at 10:34 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:
>> 
>> 
>> 
>> If that approach still doesn't work can you suggest some other mechanism to prevent abuse that does not prevent an organization who needs IP space from using this policy?
>> 
>> 
>> 
>> 
>> 
>> Hi Jason,
>> 
>> 
>> 
>> Why are we ignoring the mechanism that prevents organizations from buying un-needed anything? To wit, they have to pay money for these addresses. You guys are spinning up unlikely scenarios and ignoring the 800lb. elephant in the room??? the cost of these addresses is the mechanism you seek.
>> 
>> 
>> 
>> 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 iptrading.com  Fri Feb  3 17:45:29 2017
From: mike at iptrading.com (Mike Burns)
Date: Fri, 3 Feb 2017 17:45:29 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <826CB552-121B-4F2F-8715-057C97511805@delong.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <012901d27e32$f2c2e850$d848b8f0$@iptrading.com>
 <AA54F140-A9E3-4811-9761-21BFB42C67DF@panix.com>
 <015801d27e35$bac84820$3058d860$@iptrading.com>
 <826CB552-121B-4F2F-8715-057C97511805@delong.com>
Message-ID: <000f01d27e6f$3834a6d0$a89df470$@iptrading.com>

Hi Owen,

 

As far as I know, Ripe does not require that, only addresses sourced in ARIN or APNIC require a needs test at RIPE.

And thank you for demonstrating  yet again that you are basing these policy decisions on a fear of market manipulation.

You ignored the various reasons why we do not have to fear this, and the absence of evidence of such attempts.

Can you present any evidence of IPv4 transfer market manipulation or speculation that does not involve free-pool plundering?

 

I think that if we are bound to clutter the NRPM over these fears, some evidence should be forthcoming.

After all, we are the stakeholders who have some control over the situation and certainly would have time to erect one of these policy barriers in the case that such evidence arose. 

 

Regards,
Mike

 

 

 

From: Owen DeLong [mailto:owen at delong.com] 
Sent: Friday, February 03, 2017 5:26 PM
To: Mike Burns <mike at iptrading.com>
Cc: David Huberman <daveid at panix.com>; arin-ppml at arin.net
Subject: Re: [arin-ppml] 2016-3 Revisited

 

No, Mike, You are missing that ?an organization?s business purpose? may be something other than ?running an operational network?.

 

We are attempting to ensure that the addresses go to those who intend to use them in an operational network, rather than treating them as a commodity futures investment, speculative transaction, or other financial manipulation at the expense of the internet.

 

Even RIPE requires you to use at least half of the addresses on an operational network.

 

Owen

 

On Feb 3, 2017, at 07:53 , Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:

 

Hi David,

 

I appreciate you trying to make me understand.

So are you assuming in your example that you seek to purchase space that you do not need for your business purposes.

My argument is that organizations do not purchase space for which they don?t feel there is a valid business purpose.  Now it?s true that an organization?s perception of need will vary from the one which is being rigorously defined here, but there is an obvious brake on the purchase of items for which there is not a business purpose.

 

And for those whom we are imagining who are determined to somehow go around policy to acquire un-necessary space, there are already plenty of workarounds, the simplest of which is to acquire RIPE space.

 

Am I missing something obvious that requires this additional complexity to what was a nice smooth section of the NRPM?  

 

Regards,

Mike

 

 

From: David Huberman [ <mailto:daveid at panix.com> mailto:daveid at panix.com] 
Sent: Friday, February 03, 2017 10:43 AM
To: Mike Burns < <mailto:mike at iptrading.com> mike at iptrading.com>
Cc: Jason Schiller < <mailto:jschiller at google.com> jschiller at google.com>;  <mailto:arin-ppml at arin.net> arin-ppml at arin.net
Subject: Re: [arin-ppml] 2016-3 Revisited

 

Mike,

 

I buy a /13. I abuse the spirit of 2016-3, meant for smaller transfers as our first attempt at no needs testing, by reiterating /16 transfers one after the other.

 

Market pricing doesn't stop this, and the ARIN community who participates in public policy matters has made it clear that an incremental approach towards needs testing is a good thing.

 

David

Sent from my iPhone


On Feb 3, 2017, at 10:34 AM, Mike Burns < <mailto:mike at iptrading.com> mike at iptrading.com> wrote:

 

If that approach still doesn't work can you suggest some other mechanism to prevent abuse that does not prevent an organization who needs IP space from using this policy?  

 

 

Hi Jason,

 

Why are we ignoring the mechanism that prevents organizations from buying un-needed anything? To wit, they have to pay money for these addresses. You guys are spinning up unlikely scenarios and ignoring the 800lb. elephant in the room? the cost of these addresses is the mechanism you seek.  

 

Regards,

Mike

 

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ( <mailto:ARIN-PPML at arin.net> ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
 <http://lists.arin.net/mailman/listinfo/arin-ppml> http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact  <mailto:info at arin.net> 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/20170203/e3f8c332/attachment.htm>

From mike at iptrading.com  Fri Feb  3 18:03:46 2017
From: mike at iptrading.com (Mike Burns)
Date: Fri, 3 Feb 2017 18:03:46 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <C6D6981E-A12E-4C0C-8D5A-60C47168B571@delong.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <012901d27e32$f2c2e850$d848b8f0$@iptrading.com>
 <AA54F140-A9E3-4811-9761-21BFB42C67DF@panix.com>
 <015801d27e35$bac84820$3058d860$@iptrading.com>
 <Pine.NEB.4.64.1702031103140.29477@panix1.panix.com>
 <017301d27e39$319e76b0$94db6410$@iptrading.com>
 <C6D6981E-A12E-4C0C-8D5A-60C47168B571@delong.com>
Message-ID: <002201d27e71$c61d9f40$5258ddc0$@iptrading.com>

Hi Owen, replies inline in quotes.
> 
> 1. IPv4 value will be zero after the IPv6 transition
	Which does nothing to prevent speculative transactions placing bets against this
	transition through IPv4 market manipulation.

"Wrong. It puts the fear of an un-timeable transition foremost in the mind of any potential speculator."

> 2. IP address transfers are publicly recorded so there can be no 
> invisible move to control the market
	Except that the public information is rather limited and there?s nothing that guarantees a single
	actor is visible as a single Organization.

"Here is why I roll my eyes. Think about what you are suggesting. Some multi-billion dollar enterprise is going to engage in shady dealings, attempting to hide their true identity behind bogus ORG-IDS or the like.  Signing C-Level notarized attestations. All to corner a market, the cornering of which will surely speed the transition to IPv6 and an IPv4 value trending towards zero. "

> 3. IP address rights are subject to change by stakeholders
	Within the limitations of the RSA which is rather rigid, actually.

"The RSA is mutable, obviously, and there are several other policy-based mechanisms up to and including restoring utilization requirements."

> 4. RIPE has had a no-needs policy for quite a while with no evidence 
> of manipulation
	Simply not true. RIPE has a questionable needs policy IMHO, but it is still a needs-based policy.

"Owen I believe you to be simply wrong on this. RIPE needs-tests inbound inter-regionals only. RIPE does have a 2 year resale hold."


> 5. The IPv4 supply market has been fragmented by 30 years of 
> distribution
	Not sure how this contributes to preventing speculative transactions. Many stocks are speculatively traded every day
	which have been on the market for far more than 30 years. Companies more than 30 years old have been subject of hostile
	takeovers.

"To make this clear, there are no suppliers taken individually or together, who are able to sell enough addresses to manipulate the market. This situation is a result of RIR and Pre-RIR distributions to thousands and thousands of discrete organizations. What's more, should any attempt to rig the market take root, rising prices will tend to shake loose more supply, requiring continued (clandestine!) purchases. The total aggregate space transferred to date would not be enough to move the market even if it all went to one buyer, IMO."


> I know that you are aware that there is no one-stop-shopping for large IPv4 address blocks, and there are not now nor have ever been enough addresses on the market to come close to levels required for manipulation.

Manipulation of a market only requires gaining control of a substantial portion of the market, not necessarily the total of all IPv4 addresses. Indeed your statement here would support the idea that the small market is easier to manipulate rather than more difficult.

"This market is impossible to manipulate in my opinion, given current circumstances and the Sword of Damocles hanging over it in the form of IPv6 transition."

> The whole thing is farcical in my mind, and as a broker of more than 350 transfers I think I have as good a window on this market as anybody.   So I just have to point out when we engage in this discussion that we are tilting at windmills and my posts are exaggerated eye-rolling attempts.

While I appreciate your colorful characterization of those of us with opposing views as much as anyone else, I find your belief that the market is free of manipulation or that there is no need to make efforts to prevent same to be equally worthy of a donkey and substantial eye-rolling.


"At least I am not the one making rules based on frankly unsubstantiated fears. Where is your evidence?"

Regards,
Mike


Owen

> 
> Regards,
> Mike
> 
> 
> 
> -----Original Message-----
> From: David R Huberman [mailto:daveid at panix.com]
> Sent: Friday, February 03, 2017 11:04 AM
> To: Mike Burns <mike at iptrading.com>
> Cc: 'Jason Schiller' <jschiller at google.com>; arin-ppml at arin.net
> Subject: RE: [arin-ppml] 2016-3 Revisited
> 
> 
> Mike,
> 
> For clarity, your last question - the final paragraph - what smooth section is that?  Existing NRPM 8.5, or 2016-3 without the anti-abuse clause?
> 
> David
> 
> 
> On Fri, 3 Feb 2017, Mike Burns wrote:
> 
>> Hi David,
>> 
>> 
>> 
>> I appreciate you trying to make me understand.
>> 
>> So are you assuming in your example that you seek to purchase space that you do not need for your business purposes.
>> 
>> My argument is that organizations do not purchase space for which they don???t feel there is a valid business purpose.  Now it???s true that an organization???s perception of need will vary from the one which is being rigorously defined here, but there is an obvious brake on the purchase of items for which there is not a business purpose.
>> 
>> 
>> 
>> And for those whom we are imagining who are determined to somehow go around policy to acquire un-necessary space, there are already plenty of workarounds, the simplest of which is to acquire RIPE space.
>> 
>> 
>> 
>> Am I missing something obvious that requires this additional complexity to what was a nice smooth section of the NRPM?
>> 
>> 
>> 
>> Regards,
>> 
>> Mike
>> 
>> 
>> 
>> 
>> 
>> From: David Huberman [mailto:daveid at panix.com]
>> Sent: Friday, February 03, 2017 10:43 AM
>> To: Mike Burns <mike at iptrading.com>
>> Cc: Jason Schiller <jschiller at google.com>; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] 2016-3 Revisited
>> 
>> 
>> 
>> Mike,
>> 
>> 
>> 
>> I buy a /13. I abuse the spirit of 2016-3, meant for smaller transfers as our first attempt at no needs testing, by reiterating /16 transfers one after the other.
>> 
>> 
>> 
>> Market pricing doesn't stop this, and the ARIN community who participates in public policy matters has made it clear that an incremental approach towards needs testing is a good thing.
>> 
>> 
>> 
>> David
>> 
>> Sent from my iPhone
>> 
>> 
>> On Feb 3, 2017, at 10:34 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:
>> 
>> 
>> 
>> If that approach still doesn't work can you suggest some other mechanism to prevent abuse that does not prevent an organization who needs IP space from using this policy?
>> 
>> 
>> 
>> 
>> 
>> Hi Jason,
>> 
>> 
>> 
>> Why are we ignoring the mechanism that prevents organizations from buying un-needed anything? To wit, they have to pay money for these addresses. You guys are spinning up unlikely scenarios and ignoring the 800lb. elephant in the room??? the cost of these addresses is the mechanism you seek.
>> 
>> 
>> 
>> 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 bill at herrin.us  Fri Feb  3 18:50:57 2017
From: bill at herrin.us (William Herrin)
Date: Fri, 3 Feb 2017 18:50:57 -0500
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <AA6E4B88-46FC-47A4-8780-BDBCF88D1EF8@delong.com>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
 <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>
 <20170201084849.GN1111@hanna.meerval.net>
 <F3459EE0-CEA7-41B5-A3EF-29FDEF0C9412@delong.com>
 <20170203084914.GA72088@Vurt.local>
 <CAP-guGXTZ900V9M08AVOjmRDeEefBquKmuVuw=dZaXZVbE6nww@mail.gmail.com>
 <AA6E4B88-46FC-47A4-8780-BDBCF88D1EF8@delong.com>
Message-ID: <CAP-guGXsm1dkYtas2=mm0qjuAjYOjbE4KdebTmXKBXFM7EfmGA@mail.gmail.com>

On Fri, Feb 3, 2017 at 5:23 PM, Owen DeLong <owen at delong.com> wrote:
> Since ARIN is the registry, there?s really no other authoritative source
> for the information.
>
> As such, nobody else is in a proper position to certify the resource holdings.

Hi Owen,

ARIN openly publishes sufficient information to verify that you're
talking to the resource holder. Depending on how much confidence you
want, you can automate by email, require the POC to answer a phone
call or respond to a code provided via certified mail.

Because ARIN publishes the identities of address holders, anybody and
everybody is in a position to certify the resource holdings.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>


From scottleibrand at gmail.com  Fri Feb  3 19:01:49 2017
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 3 Feb 2017 16:01:49 -0800
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <BE2B2B79-D4BA-4000-9C2E-718119AD5501@delong.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <Pine.NEB.4.64.1702031016000.29477@panix1.panix.com>
 <BE2B2B79-D4BA-4000-9C2E-718119AD5501@delong.com>
Message-ID: <CAGkMwz7+SMRqxBA_9-eEsaQeh9OwtE2Bm_HudOG9-rWYacYEUA@mail.gmail.com>

That would be a significant improvement on the current ("An organization
may only qualify under 8.5.7 once every 6 months.") text.  I would be
equally fine with this text ("No more than a total of a /16 equivalent may
be transferred under these provisions within any 6 month period." or
similar) or with Jason's ("An organization may only qualify under 8.5.7
once every 6 months, unless they can also demonstrate growth of IPv4
utilization of at least half of the amount of specified transfers since the
previous transfer pre-authorization or approval.")

Thanks,
Scott

On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <owen at delong.com> wrote:

> Simple to resolve for the 6-month horizon ?
>
> ? Such that no more than a total of a /16 equivalent may be transferred
> under these provisions within any 6 month period. ?
>
> Owen
>
> > On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com> wrote:
> >
> >
> > I thought of a possible problem with the anti-abuse language -- all
> versions of it.  Let me talk it out.
> >
> > An organization has a /19.
> > It has growing products, and wants another /19 for its 1 or 2 year need.
> > It wants to avail itself of the new language.
> > It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
> >
> > It closes the deal with Buyer A first, and transfers at ARIN using the
> proposed language.
> >
> > How does it use any version we've discussed (Jason's various proposals,
> the current text, etc) to transfer the space it buys from Buyer B?
> >
> >
> > (In all discussion, yes, you can always use the other sections of 8.5,
> but let's stick to the spirit of this policy language, which is meant to
> help smaller and mid-size networks double their holdings without needs
> testing.)
> > _______________________________________________
> > 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/20170203/27a7b72a/attachment.htm>

From owen at delong.com  Mon Feb  6 13:51:16 2017
From: owen at delong.com (Owen DeLong)
Date: Mon, 6 Feb 2017 10:51:16 -0800
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <000f01d27e6f$3834a6d0$a89df470$@iptrading.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <012901d27e32$f2c2e850$d848b8f0$@iptrading.com>
 <AA54F140-A9E3-4811-9761-21BFB42C67DF@panix.com>
 <015801d27e35$bac84820$3058d860$@iptrading.com>
 <826CB552-121B-4F2F-8715-057C97511805@delong.com>
 <000f01d27e6f$3834a6d0$a89df470$@iptrading.com>
Message-ID: <74859CC1-5AD5-4D4B-A26A-6856F60EE65C@delong.com>


> On Feb 3, 2017, at 14:45 , Mike Burns <mike at iptrading.com> wrote:
> 
> Hi Owen,
>  
> As far as I know, Ripe does not require that, only addresses sourced in ARIN or APNIC require a needs test at RIPE.

My understanding is that 50% within 5 years is required on all RIPE NCC allocations.

RIPE NCC does not do assignments, they farm those out through ?sponsoring LIRs?.

> And thank you for demonstrating  yet again that you are basing these policy decisions on a fear of market manipulation.

No, I am stating that market manipulation is one valid consideration in these policy decisions.

> You ignored the various reasons why we do not have to fear this, and the absence of evidence of such attempts.

No, I didn?t ignore it, I rebutted your claim that it was nonexistent.

> Can you present any evidence of IPv4 transfer market manipulation or speculation that does not involve free-pool plundering?

No, but I can?t tell you what was on the missing seconds of tape from Watergate, either. Absence of evidence is not the same as evidence or absence.

> I think that if we are bound to clutter the NRPM over these fears, some evidence should be forthcoming.

I don?t feel that the NRPM is cluttered, nor do I feel that these concerns are the only reason these are reasonable protections to preserve.

> After all, we are the stakeholders who have some control over the situation and certainly would have time to erect one of these policy barriers in the case that such evidence arose. 

That?s laughable? It generally takes at least a year for anything with any controversy at all to go from proposal to submission to the board for ratification. Then it?s usually a month or two for ratification and another 6 months or more for implementation. In addition to that, given the likely mechanisms at work in such a scheme, it would be unlikely that we would see evidence, per se, before it was too late to really do anything effective.

Owen

>  
> Regards,
> Mike
>  
>  
>  
> From: Owen DeLong [mailto:owen at delong.com <mailto:owen at delong.com>] 
> Sent: Friday, February 03, 2017 5:26 PM
> To: Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com>>
> Cc: David Huberman <daveid at panix.com <mailto:daveid at panix.com>>; arin-ppml at arin.net <mailto:arin-ppml at arin.net>
> Subject: Re: [arin-ppml] 2016-3 Revisited
>  
> No, Mike, You are missing that ?an organization?s business purpose? may be something other than ?running an operational network?.
>  
> We are attempting to ensure that the addresses go to those who intend to use them in an operational network, rather than treating them as a commodity futures investment, speculative transaction, or other financial manipulation at the expense of the internet.
>  
> Even RIPE requires you to use at least half of the addresses on an operational network.
>  
> Owen
>  
>> On Feb 3, 2017, at 07:53 , Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com>> wrote:
>>  
>> Hi David,
>>  
>> I appreciate you trying to make me understand.
>> So are you assuming in your example that you seek to purchase space that you do not need for your business purposes.
>> My argument is that organizations do not purchase space for which they don?t feel there is a valid business purpose.  Now it?s true that an organization?s perception of need will vary from the one which is being rigorously defined here, but there is an obvious brake on the purchase of items for which there is not a business purpose.
>>  
>> And for those whom we are imagining who are determined to somehow go around policy to acquire un-necessary space, there are already plenty of workarounds, the simplest of which is to acquire RIPE space.
>>  
>> Am I missing something obvious that requires this additional complexity to what was a nice smooth section of the NRPM?  
>>  
>> Regards,
>> Mike
>>  
>>  
>> From: David Huberman [mailto:daveid at panix.com <mailto:daveid at panix.com>] 
>> Sent: Friday, February 03, 2017 10:43 AM
>> To: Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com>>
>> Cc: Jason Schiller <jschiller at google.com <mailto:jschiller at google.com>>; arin-ppml at arin.net <mailto:arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] 2016-3 Revisited
>>  
>> Mike,
>>  
>> I buy a /13. I abuse the spirit of 2016-3, meant for smaller transfers as our first attempt at no needs testing, by reiterating /16 transfers one after the other.
>>  
>> Market pricing doesn't stop this, and the ARIN community who participates in public policy matters has made it clear that an incremental approach towards needs testing is a good thing.
>>  
>> David
>> 
>> Sent from my iPhone
>> 
>> On Feb 3, 2017, at 10:34 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com>> wrote:
>> 
>>>  
>>> If that approach still doesn't work can you suggest some other mechanism to prevent abuse that does not prevent an organization who needs IP space from using this policy?  
>>>  
>>>  
>>> Hi Jason,
>>>  
>>> Why are we ignoring the mechanism that prevents organizations from buying un-needed anything? To wit, they have to pay money for these addresses. You guys are spinning up unlikely scenarios and ignoring the 800lb. elephant in the room? the cost of these addresses is the mechanism you seek.  
>>>  
>>> Regards,
>>> Mike
>>>  
>> _______________________________________________
>> 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 <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/20170206/34ec8c56/attachment.htm>

From owen at delong.com  Mon Feb  6 14:08:44 2017
From: owen at delong.com (Owen DeLong)
Date: Mon, 6 Feb 2017 11:08:44 -0800
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <002201d27e71$c61d9f40$5258ddc0$@iptrading.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>
 <CAC4yj2WBVL-OX89Nztx52qFLyT1Q4RPho=-BusYn914sFUo_tw@mail.gmail.com>
 <CAC4yj2VRapXkwD8-j8ot1vdXj0Txi7TY7PwrYAKKdtKP1tx50Q@mail.gmail.com>
 <2A0E6652-311B-4225-9913-41D33532E9ED@delong.com>
 <CAC4yj2VUkhCq8VTN=29UQM+PtPWohLsQ1Cg9HWKi4Csv27Stvg@mail.gmail.com>
 <Pine.NEB.4.64.1702030833220.26818@panix1.panix.com>
 <CAC4yj2W_es4UjSGYtUH38Ah41ihg83HYt2ZVFs6jQ4P=Ar7Umg@mail.gmail.com>
 <012901d27e32$f2c2e850$d848b8f0$@iptrading.com>
 <AA54F140-A9E3-4811-9761-21BFB42C67DF@panix.com>
 <015801d27e35$bac84820$3058d860$@iptrading.com>
 <Pine.NEB.4.64.1702031103140.29477@panix1.panix.com>
 <017301d27e39$319e76b0$94db6410$@iptrading.com>
 <C6D6981E-A12E-4C0C-8D5A-60C47168B571@delong.com>
 <002201d27e71$c61d9f40$5258ddc0$@iptrading.com>
Message-ID: <C703DF86-3C9F-4764-8C11-6208790DBA9C@delong.com>


> On Feb 3, 2017, at 15:03 , Mike Burns <mike at iptrading.com> wrote:
> 
> Hi Owen, replies inline in quotes.
>> 
>> 1. IPv4 value will be zero after the IPv6 transition
> 	Which does nothing to prevent speculative transactions placing bets against this
> 	transition through IPv4 market manipulation.
> 
> "Wrong. It puts the fear of an un-timeable transition foremost in the mind of any potential speculator.?

That depends on how well resourced and how confident the speculator is in their ability to achieve their desired goal, which may not necessarily be directly profiting from the resale of the IPv4 addresses in question.

>> 2. IP address transfers are publicly recorded so there can be no 
>> invisible move to control the market
> 	Except that the public information is rather limited and there?s nothing that guarantees a single
> 	actor is visible as a single Organization.
> 
> "Here is why I roll my eyes. Think about what you are suggesting. Some multi-billion dollar enterprise is going to engage in shady dealings, attempting to hide their true identity behind bogus ORG-IDS or the like.  Signing C-Level notarized attestations. All to corner a market, the cornering of which will surely speed the transition to IPv6 and an IPv4 value trending towards zero. ?

I realize that this sounds almost as ridiculous as a major automobile manufacturer falsifying emissions reports, but hey, what do I know.

>> 3. IP address rights are subject to change by stakeholders
> 	Within the limitations of the RSA which is rather rigid, actually.
> 
> "The RSA is mutable, obviously, and there are several other policy-based mechanisms up to and including restoring utilization requirements.?

No, the RSA can be modified for future signatories, but we don?t have the power to strip away existing protections from those that have already signed the agreement.

>> 4. RIPE has had a no-needs policy for quite a while with no evidence 
>> of manipulation
> 	Simply not true. RIPE has a questionable needs policy IMHO, but it is still a needs-based policy.
> 
> "Owen I believe you to be simply wrong on this. RIPE needs-tests inbound inter-regionals only. RIPE does have a 2 year resale hold.?

I stand corrected? The RIPE policy is, in fact, more questionable than I was previously led to believe.

Nonetheless, absence of evidence (which I?m not convinced is entirely true, I simply don?t have any that I can provide without violating NDAs).

>> 5. The IPv4 supply market has been fragmented by 30 years of 
>> distribution
> 	Not sure how this contributes to preventing speculative transactions. Many stocks are speculatively traded every day
> 	which have been on the market for far more than 30 years. Companies more than 30 years old have been subject of hostile
> 	takeovers.
> 
> "To make this clear, there are no suppliers taken individually or together, who are able to sell enough addresses to manipulate the market. This situation is a result of RIR and Pre-RIR distributions to thousands and thousands of discrete organizations. What's more, should any attempt to rig the market take root, rising prices will tend to shake loose more supply, requiring continued (clandestine!) purchases. The total aggregate space transferred to date would not be enough to move the market even if it all went to one buyer, IMO.?

Moving the market is not the only possible objective of such manipulation.

>> I know that you are aware that there is no one-stop-shopping for large IPv4 address blocks, and there are not now nor have ever been enough addresses on the market to come close to levels required for manipulation.
> 
> Manipulation of a market only requires gaining control of a substantial portion of the market, not necessarily the total of all IPv4 addresses. Indeed your statement here would support the idea that the small market is easier to manipulate rather than more difficult.
> 
> "This market is impossible to manipulate in my opinion, given current circumstances and the Sword of Damocles hanging over it in the form of IPv6 transition.?

You are only considering one possible target of manipulation (namely an attempt to maximize the resale price of the addresses hoarded). There are other possible goals.

>> The whole thing is farcical in my mind, and as a broker of more than 350 transfers I think I have as good a window on this market as anybody.   So I just have to point out when we engage in this discussion that we are tilting at windmills and my posts are exaggerated eye-rolling attempts.
> 
> While I appreciate your colorful characterization of those of us with opposing views as much as anyone else, I find your belief that the market is free of manipulation or that there is no need to make efforts to prevent same to be equally worthy of a donkey and substantial eye-rolling.
> 
> 
> "At least I am not the one making rules based on frankly unsubstantiated fears. Where is your evidence??

Where is your evidence that there is no manipulation, no speculative transactions, and nothing going on underground?

You?ve presented no contrary evidence. You?ve only made unsubstantiated claims that because I cannot produce proof of a black market or other clandestine transactions that you don?t believe they are occurring.

All either of us can work with is our opinion. Again, absence of evidence isn?t evidence of absence, no matter how much you would like to claim that is the case.

I can?t personally prove that front-running orders happens in the stock market, but I?m pretty sure it does.

Owen

> 
> Regards,
> Mike
> 
> 
> Owen
> 
>> 
>> Regards,
>> Mike
>> 
>> 
>> 
>> -----Original Message-----
>> From: David R Huberman [mailto:daveid at panix.com]
>> Sent: Friday, February 03, 2017 11:04 AM
>> To: Mike Burns <mike at iptrading.com>
>> Cc: 'Jason Schiller' <jschiller at google.com>; arin-ppml at arin.net
>> Subject: RE: [arin-ppml] 2016-3 Revisited
>> 
>> 
>> Mike,
>> 
>> For clarity, your last question - the final paragraph - what smooth section is that?  Existing NRPM 8.5, or 2016-3 without the anti-abuse clause?
>> 
>> David
>> 
>> 
>> On Fri, 3 Feb 2017, Mike Burns wrote:
>> 
>>> Hi David,
>>> 
>>> 
>>> 
>>> I appreciate you trying to make me understand.
>>> 
>>> So are you assuming in your example that you seek to purchase space that you do not need for your business purposes.
>>> 
>>> My argument is that organizations do not purchase space for which they don???t feel there is a valid business purpose.  Now it???s true that an organization???s perception of need will vary from the one which is being rigorously defined here, but there is an obvious brake on the purchase of items for which there is not a business purpose.
>>> 
>>> 
>>> 
>>> And for those whom we are imagining who are determined to somehow go around policy to acquire un-necessary space, there are already plenty of workarounds, the simplest of which is to acquire RIPE space.
>>> 
>>> 
>>> 
>>> Am I missing something obvious that requires this additional complexity to what was a nice smooth section of the NRPM?
>>> 
>>> 
>>> 
>>> Regards,
>>> 
>>> Mike
>>> 
>>> 
>>> 
>>> 
>>> 
>>> From: David Huberman [mailto:daveid at panix.com]
>>> Sent: Friday, February 03, 2017 10:43 AM
>>> To: Mike Burns <mike at iptrading.com>
>>> Cc: Jason Schiller <jschiller at google.com>; arin-ppml at arin.net
>>> Subject: Re: [arin-ppml] 2016-3 Revisited
>>> 
>>> 
>>> 
>>> Mike,
>>> 
>>> 
>>> 
>>> I buy a /13. I abuse the spirit of 2016-3, meant for smaller transfers as our first attempt at no needs testing, by reiterating /16 transfers one after the other.
>>> 
>>> 
>>> 
>>> Market pricing doesn't stop this, and the ARIN community who participates in public policy matters has made it clear that an incremental approach towards needs testing is a good thing.
>>> 
>>> 
>>> 
>>> David
>>> 
>>> Sent from my iPhone
>>> 
>>> 
>>> On Feb 3, 2017, at 10:34 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:
>>> 
>>> 
>>> 
>>> If that approach still doesn't work can you suggest some other mechanism to prevent abuse that does not prevent an organization who needs IP space from using this policy?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Hi Jason,
>>> 
>>> 
>>> 
>>> Why are we ignoring the mechanism that prevents organizations from buying un-needed anything? To wit, they have to pay money for these addresses. You guys are spinning up unlikely scenarios and ignoring the 800lb. elephant in the room??? the cost of these addresses is the mechanism you seek.
>>> 
>>> 
>>> 
>>> 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 jschiller at google.com  Tue Feb  7 14:53:46 2017
From: jschiller at google.com (Jason Schiller)
Date: Tue, 7 Feb 2017 14:53:46 -0500
Subject: [arin-ppml] 2016-3 Revisited - anti-abuse clause
Message-ID: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>

We have a few options on the table and only a few voices in the
discussion...

I'd like to quickly outline the options, and see if we can get more people
to weigh in and either note they object to one or more options, are
ambivalent to one or more options, or support one or more options (with
some preference).


1. demonstrate 80% utilization on average for all your IP space
2. get pre-authorization for 1 or more transfers up to double your current
holdings over then two years
2.1. this is limited to a /16

A. you can use this policy once every 6 months

B. If you need to use this policy more than once every 6 months you need to
also demonstrate growth equalling half what you have transferred since you
last used this policy.

C. you can use this policy to transfer a total of up to a /16

Where do you stand on A, B or C?

__Jason


On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <scottleibrand at gmail.com>
wrote:

> That would be a significant improvement on the current ("An organization
> may only qualify under 8.5.7 once every 6 months.") text.  I would be
> equally fine with this text ("No more than a total of a /16 equivalent
> may be transferred under these provisions within any 6 month period." or
> similar) or with Jason's ("An organization may only qualify under 8.5.7
> once every 6 months, unless they can also demonstrate growth of IPv4
> utilization of at least half of the amount of specified transfers since the
> previous transfer pre-authorization or approval.")
>
> Thanks,
> Scott
>
> On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <owen at delong.com> wrote:
>
>> Simple to resolve for the 6-month horizon ?
>>
>> ? Such that no more than a total of a /16 equivalent may be transferred
>> under these provisions within any 6 month period. ?
>>
>> Owen
>>
>> > On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com> wrote:
>> >
>> >
>> > I thought of a possible problem with the anti-abuse language -- all
>> versions of it.  Let me talk it out.
>> >
>> > An organization has a /19.
>> > It has growing products, and wants another /19 for its 1 or 2 year need.
>> > It wants to avail itself of the new language.
>> > It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
>> >
>> > It closes the deal with Buyer A first, and transfers at ARIN using the
>> proposed language.
>> >
>> > How does it use any version we've discussed (Jason's various proposals,
>> the current text, etc) to transfer the space it buys from Buyer B?
>> >
>> >
>> > (In all discussion, yes, you can always use the other sections of 8.5,
>> but let's stick to the spirit of this policy language, which is meant to
>> help smaller and mid-size networks double their holdings without needs
>> testing.)
>> > _______________________________________________
>> > 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.
>



-- 
_______________________________________________________
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/20170207/765bd97b/attachment.htm>

From jschiller at google.com  Tue Feb  7 15:04:49 2017
From: jschiller at google.com (Jason Schiller)
Date: Tue, 7 Feb 2017 15:04:49 -0500
Subject: [arin-ppml] 2016-3 Revisited - anti-abuse clause
In-Reply-To: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>
References: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>
Message-ID: <CAC4yj2WBCOK_Zwk09XBzCfeZm+W-PpAKjuVUCzE5Tx7o2gSn3Q@mail.gmail.com>

I support B.

It puts added work on those who need more than a /16, or have a growth rate
more than doubling every half yeah, but does not prevent organizations who
need IP addresses from getting them.

I oppose A and C as they are unfair,

A.
  - unfairly penalizes large organizations that need more than a /16
  - unfairly penalizes organizations growing faster than double their
current holding
    (especially new organizations that started with a /24 and have a growth
rate greater than 512 customer per year)

C.
   - unfairly penalizes large organizations that need more than a /16
   - unfairly penalizes organizations growing faster than double their
current holding
   - unfairly does not penalizes organizations growing faster than double
their current holding so long as they need less than a /16


A > B or B > A?

I can't decide if A is less unfair because there is no carve out for
organizations that need less than a /16.  On one hand those needing less
than a /16 are not treated unfairly as a special class, but as a result the
number of organizations who need IP addresses that are rate limited is
greater.

 Or if C is less unfair because it is unfair to have a carve out for the
organization that need less than a /16 for exactly the opposite reasons.

__Jason

On Tue, Feb 7, 2017 at 2:53 PM, Jason Schiller <jschiller at google.com> wrote:

> We have a few options on the table and only a few voices in the
> discussion...
>
> I'd like to quickly outline the options, and see if we can get more people
> to weigh in and either note they object to one or more options, are
> ambivalent to one or more options, or support one or more options (with
> some preference).
>
>
> 1. demonstrate 80% utilization on average for all your IP space
> 2. get pre-authorization for 1 or more transfers up to double your current
> holdings over then two years
> 2.1. this is limited to a /16
>
> A. you can use this policy once every 6 months
>
> B. If you need to use this policy more than once every 6 months you need
> to also demonstrate growth equalling half what you have transferred since
> you last used this policy.
>
> C. you can use this policy to transfer a total of up to a /16
>
> Where do you stand on A, B or C?
>
> __Jason
>
>
> On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
>
>> That would be a significant improvement on the current ("An organization
>> may only qualify under 8.5.7 once every 6 months.") text.  I would be
>> equally fine with this text ("No more than a total of a /16 equivalent
>> may be transferred under these provisions within any 6 month period." or
>> similar) or with Jason's ("An organization may only qualify under 8.5.7
>> once every 6 months, unless they can also demonstrate growth of IPv4
>> utilization of at least half of the amount of specified transfers since the
>> previous transfer pre-authorization or approval.")
>>
>> Thanks,
>> Scott
>>
>> On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <owen at delong.com> wrote:
>>
>>> Simple to resolve for the 6-month horizon ?
>>>
>>> ? Such that no more than a total of a /16 equivalent may be transferred
>>> under these provisions within any 6 month period. ?
>>>
>>> Owen
>>>
>>> > On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com> wrote:
>>> >
>>> >
>>> > I thought of a possible problem with the anti-abuse language -- all
>>> versions of it.  Let me talk it out.
>>> >
>>> > An organization has a /19.
>>> > It has growing products, and wants another /19 for its 1 or 2 year
>>> need.
>>> > It wants to avail itself of the new language.
>>> > It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
>>> >
>>> > It closes the deal with Buyer A first, and transfers at ARIN using the
>>> proposed language.
>>> >
>>> > How does it use any version we've discussed (Jason's various
>>> proposals, the current text, etc) to transfer the space it buys from Buyer
>>> B?
>>> >
>>> >
>>> > (In all discussion, yes, you can always use the other sections of 8.5,
>>> but let's stick to the spirit of this policy language, which is meant to
>>> help smaller and mid-size networks double their holdings without needs
>>> testing.)
>>> > _______________________________________________
>>> > 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.
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006>
>
>


-- 
_______________________________________________________
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/20170207/e93e3e0a/attachment.htm>

From owen at delong.com  Wed Feb  8 15:35:29 2017
From: owen at delong.com (Owen DeLong)
Date: Wed, 8 Feb 2017 12:35:29 -0800
Subject: [arin-ppml] 2016-3 Revisited - anti-abuse clause
In-Reply-To: <CAC4yj2WBCOK_Zwk09XBzCfeZm+W-PpAKjuVUCzE5Tx7o2gSn3Q@mail.gmail.com>
References: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>
 <CAC4yj2WBCOK_Zwk09XBzCfeZm+W-PpAKjuVUCzE5Tx7o2gSn3Q@mail.gmail.com>
Message-ID: <A63CFFB1-0D0A-4EC3-B0E7-30A9C45F3201@delong.com>

Respectfully I reject your premise on the fairness.

Neither A, nor C prevent large organizations from getting more, they merely require that they use other less simplified provisions of the existing policy.

I think what I support is sort of a hybrid between A and C in that I believe you should be able to use the policy to transfer as often as you want, so long as your transfers within any 6 month period under this policy don?t exceed a /16. You?d still be able to transfer a /16 under this policy and then use other existing policies if you needed more.

Owen

> On Feb 7, 2017, at 12:04 , Jason Schiller <jschiller at google.com> wrote:
> 
> I support B.  
> 
> It puts added work on those who need more than a /16, or have a growth rate more than doubling every half yeah, but does not prevent organizations who need IP addresses from getting them.
> 
> I oppose A and C as they are unfair, 
> 
> A. 
>   - unfairly penalizes large organizations that need more than a /16
>   - unfairly penalizes organizations growing faster than double their current holding
>     (especially new organizations that started with a /24 and have a growth rate greater than 512 customer per year)
> 
> C.
>    - unfairly penalizes large organizations that need more than a /16
>    - unfairly penalizes organizations growing faster than double their current holding
>    - unfairly does not penalizes organizations growing faster than double their current holding so long as they need less than a /16
> 
> 
> A > B or B > A?
> 
> I can't decide if A is less unfair because there is no carve out for organizations that need less than a /16.  On one hand those needing less than a /16 are not treated unfairly as a special class, but as a result the number of organizations who need IP addresses that are rate limited is greater.
> 
>  Or if C is less unfair because it is unfair to have a carve out for the organization that need less than a /16 for exactly the opposite reasons.
> 
> __Jason
> 
> On Tue, Feb 7, 2017 at 2:53 PM, Jason Schiller <jschiller at google.com <mailto:jschiller at google.com>> wrote:
> We have a few options on the table and only a few voices in the discussion...
> 
> I'd like to quickly outline the options, and see if we can get more people to weigh in and either note they object to one or more options, are ambivalent to one or more options, or support one or more options (with some preference).
> 
> 
> 1. demonstrate 80% utilization on average for all your IP space
> 2. get pre-authorization for 1 or more transfers up to double your current holdings over then two years
> 2.1. this is limited to a /16
> 
> A. you can use this policy once every 6 months
> 
> B. If you need to use this policy more than once every 6 months you need to also demonstrate growth equalling half what you have transferred since you last used this policy.
> 
> C. you can use this policy to transfer a total of up to a /16
> 
> Where do you stand on A, B or C?
> 
> __Jason
> 
> 
> On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>> wrote:
> That would be a significant improvement on the current ("An organization may only qualify under 8.5.7 once every 6 months.") text.  I would be equally fine with this text ("No more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period." or similar) or with Jason's ("An organization may only qualify under 8.5.7 once every 6 months, unless they can also demonstrate growth of IPv4 utilization of at least half of the amount of specified transfers since the previous transfer pre-authorization or approval.")
> 
> Thanks,
> Scott
> 
> On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
> Simple to resolve for the 6-month horizon ?
> 
> ? Such that no more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period. ?
> 
> Owen
> 
> > On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com <mailto:daveid at panix.com>> wrote:
> >
> >
> > I thought of a possible problem with the anti-abuse language -- all versions of it.  Let me talk it out.
> >
> > An organization has a /19.
> > It has growing products, and wants another /19 for its 1 or 2 year need.
> > It wants to avail itself of the new language.
> > It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
> >
> > It closes the deal with Buyer A first, and transfers at ARIN using the proposed language.
> >
> > How does it use any version we've discussed (Jason's various proposals, the current text, etc) to transfer the space it buys from Buyer B?
> >
> >
> > (In all discussion, yes, you can always use the other sections of 8.5, but let's stick to the spirit of this policy language, which is meant to help smaller and mid-size networks double their holdings without needs testing.)
> > _______________________________________________
> > 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 <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 <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 <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
> 
> 
> 
> -- 
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com <mailto:jschiller at google.com>|571-266-0006 <tel:(571)%20266-0006>
> 
> 
> 
> 
> -- 
> _______________________________________________________
> 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/20170208/8df718d7/attachment.htm>

From jschiller at google.com  Thu Feb  9 11:39:22 2017
From: jschiller at google.com (Jason Schiller)
Date: Thu, 9 Feb 2017 11:39:22 -0500
Subject: [arin-ppml] 2016-3 Revisited - anti-abuse clause
In-Reply-To: <A63CFFB1-0D0A-4EC3-B0E7-30A9C45F3201@delong.com>
References: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>
 <CAC4yj2WBCOK_Zwk09XBzCfeZm+W-PpAKjuVUCzE5Tx7o2gSn3Q@mail.gmail.com>
 <A63CFFB1-0D0A-4EC3-B0E7-30A9C45F3201@delong.com>
Message-ID: <CAC4yj2WK+9B20yQ3pO3UKyEfAiK1JV490JYb9QKX3T-JNzfq7g@mail.gmail.com>

Owen,

After reading your mail, I noticed I artificially shortened the text for
C.  It should have been what you described as your preferred choice.

Re-asking the question for clarity (and hopes of getting new voices).

We have a few options on the table and only a few voices in the
discussion...

I'd like to quickly outline the options, and see if we can get more people
to weigh in and either note they object to one or more options, are
ambivalent to one or more options, or support one or more options (with
some preference).


1. demonstrate 80% utilization on average for all your IP space
2. get pre-authorization for 1 or more transfers up to double your current
holdings over then two years
2.1. this is limited to a /16

A. you can use this policy once every 6 months

B. If you need to use this policy more than once every 6 months you need to
also demonstrate growth equaling half what you have transferred since you
last used this policy.

C. You can use this policy to transfer a total of up to a /16 every 6 months

Where do you stand on A, B or C?



On Wed, Feb 8, 2017 at 3:35 PM, Owen DeLong <owen at delong.com> wrote:

> Respectfully I reject your premise on the fairness.
>
> Neither A, nor C prevent large organizations from getting more, they
> merely require that they use other less simplified provisions of the
> existing policy.
>
> I think what I support is sort of a hybrid between A and C in that I
> believe you should be able to use the policy to transfer as often as you
> want, so long as your transfers within any 6 month period under this policy
> don?t exceed a /16. You?d still be able to transfer a /16 under this policy
> and then use other existing policies if you needed more.
>
> Owen
>
> On Feb 7, 2017, at 12:04 , Jason Schiller <jschiller at google.com> wrote:
>
> I support B.
>
> It puts added work on those who need more than a /16, or have a growth
> rate more than doubling every half yeah, but does not prevent organizations
> who need IP addresses from getting them.
>
> I oppose A and C as they are unfair,
>
> A.
>   - unfairly penalizes large organizations that need more than a /16
>   - unfairly penalizes organizations growing faster than double their
> current holding
>     (especially new organizations that started with a /24 and have a
> growth rate greater than 512 customer per year)
>
> C.
>    - unfairly penalizes large organizations that need more than a /16
>    - unfairly penalizes organizations growing faster than double their
> current holding
>    - unfairly does not penalizes organizations growing faster than double
> their current holding so long as they need less than a /16
>
>
> A > B or B > A?
>
> I can't decide if A is less unfair because there is no carve out for
> organizations that need less than a /16.  On one hand those needing less
> than a /16 are not treated unfairly as a special class, but as a result the
> number of organizations who need IP addresses that are rate limited is
> greater.
>
>  Or if C is less unfair because it is unfair to have a carve out for the
> organization that need less than a /16 for exactly the opposite reasons.
>
> __Jason
>
> On Tue, Feb 7, 2017 at 2:53 PM, Jason Schiller <jschiller at google.com>
> wrote:
>
>> We have a few options on the table and only a few voices in the
>> discussion...
>>
>> I'd like to quickly outline the options, and see if we can get more
>> people to weigh in and either note they object to one or more options, are
>> ambivalent to one or more options, or support one or more options (with
>> some preference).
>>
>>
>> 1. demonstrate 80% utilization on average for all your IP space
>> 2. get pre-authorization for 1 or more transfers up to double your
>> current holdings over then two years
>> 2.1. this is limited to a /16
>>
>> A. you can use this policy once every 6 months
>>
>> B. If you need to use this policy more than once every 6 months you need
>> to also demonstrate growth equalling half what you have transferred since
>> you last used this policy.
>>
>> C. you can use this policy to transfer a total of up to a /16
>>
>> Where do you stand on A, B or C?
>>
>> __Jason
>>
>>
>> On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <scottleibrand at gmail.com>
>> wrote:
>>
>>> That would be a significant improvement on the current ("An organization
>>> may only qualify under 8.5.7 once every 6 months.") text.  I would be
>>> equally fine with this text ("No more than a total of a /16 equivalent
>>> may be transferred under these provisions within any 6 month period." or
>>> similar) or with Jason's ("An organization may only qualify under 8.5.7
>>> once every 6 months, unless they can also demonstrate growth of IPv4
>>> utilization of at least half of the amount of specified transfers since the
>>> previous transfer pre-authorization or approval.")
>>>
>>> Thanks,
>>> Scott
>>>
>>> On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <owen at delong.com> wrote:
>>>
>>>> Simple to resolve for the 6-month horizon ?
>>>>
>>>> ? Such that no more than a total of a /16 equivalent may be transferred
>>>> under these provisions within any 6 month period. ?
>>>>
>>>> Owen
>>>>
>>>> > On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com> wrote:
>>>> >
>>>> >
>>>> > I thought of a possible problem with the anti-abuse language -- all
>>>> versions of it.  Let me talk it out.
>>>> >
>>>> > An organization has a /19.
>>>> > It has growing products, and wants another /19 for its 1 or 2 year
>>>> need.
>>>> > It wants to avail itself of the new language.
>>>> > It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
>>>> >
>>>> > It closes the deal with Buyer A first, and transfers at ARIN using
>>>> the proposed language.
>>>> >
>>>> > How does it use any version we've discussed (Jason's various
>>>> proposals, the current text, etc) to transfer the space it buys from Buyer
>>>> B?
>>>> >
>>>> >
>>>> > (In all discussion, yes, you can always use the other sections of
>>>> 8.5, but let's stick to the spirit of this policy language, which is meant
>>>> to help smaller and mid-size networks double their holdings without needs
>>>> testing.)
>>>> > _______________________________________________
>>>> > 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.
>>>
>>
>>
>>
>> --
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>> <(571)%20266-0006>
>>
>>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006>
>
>
>


-- 
_______________________________________________________
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/20170209/fd671889/attachment.htm>

From scottleibrand at gmail.com  Thu Feb  9 12:44:16 2017
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 9 Feb 2017 10:44:16 -0700
Subject: [arin-ppml] 2016-3 Revisited - anti-abuse clause
In-Reply-To: <CAC4yj2WK+9B20yQ3pO3UKyEfAiK1JV490JYb9QKX3T-JNzfq7g@mail.gmail.com>
References: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>
 <CAC4yj2WBCOK_Zwk09XBzCfeZm+W-PpAKjuVUCzE5Tx7o2gSn3Q@mail.gmail.com>
 <A63CFFB1-0D0A-4EC3-B0E7-30A9C45F3201@delong.com>
 <CAC4yj2WK+9B20yQ3pO3UKyEfAiK1JV490JYb9QKX3T-JNzfq7g@mail.gmail.com>
Message-ID: <0B4BDEC5-C7DA-4A36-8F63-18DB742E605D@gmail.com>

Not a new voice, but C for me please. It avoids a bunch of corner cases that A introduces, but is far simpler and easier for everyone to understand than B. It also is more consistent with the original idea of a /16 limit, which gets us the simplification benefit for the vast majority of transfers while avoiding some concerns about making really large transfers too easy. We can always change /16 to something larger once we have experience with using it. 

Scott

> On Feb 9, 2017, at 9:39 AM, Jason Schiller <jschiller at google.com> wrote:
> 
> Owen,
> 
> After reading your mail, I noticed I artificially shortened the text for C.  It should have been what you described as your preferred choice.
> 
> Re-asking the question for clarity (and hopes of getting new voices).
> 
> We have a few options on the table and only a few voices in the discussion...
> 
> I'd like to quickly outline the options, and see if we can get more people to weigh in and either note they object to one or more options, are ambivalent to one or more options, or support one or more options (with some preference).
> 
> 
> 1. demonstrate 80% utilization on average for all your IP space
> 2. get pre-authorization for 1 or more transfers up to double your current holdings over then two years
> 2.1. this is limited to a /16
> 
> A. you can use this policy once every 6 months
> 
> B. If you need to use this policy more than once every 6 months you need to also demonstrate growth equaling half what you have transferred since you last used this policy.
> 
> C. You can use this policy to transfer a total of up to a /16 every 6 months
> 
> Where do you stand on A, B or C?
> 
> 
> 
>> On Wed, Feb 8, 2017 at 3:35 PM, Owen DeLong <owen at delong.com> wrote:
>> Respectfully I reject your premise on the fairness.
>> 
>> Neither A, nor C prevent large organizations from getting more, they merely require that they use other less simplified provisions of the existing policy.
>> 
>> I think what I support is sort of a hybrid between A and C in that I believe you should be able to use the policy to transfer as often as you want, so long as your transfers within any 6 month period under this policy don?t exceed a /16. You?d still be able to transfer a /16 under this policy and then use other existing policies if you needed more.
>> 
>> Owen
>> 
>>> On Feb 7, 2017, at 12:04 , Jason Schiller <jschiller at google.com> wrote:
>>> 
>>> I support B.  
>>> 
>>> It puts added work on those who need more than a /16, or have a growth rate more than doubling every half yeah, but does not prevent organizations who need IP addresses from getting them.
>>> 
>>> I oppose A and C as they are unfair, 
>>> 
>>> A. 
>>>   - unfairly penalizes large organizations that need more than a /16
>>>   - unfairly penalizes organizations growing faster than double their current holding
>>>     (especially new organizations that started with a /24 and have a growth rate greater than 512 customer per year)
>>> 
>>> C.
>>>    - unfairly penalizes large organizations that need more than a /16
>>>    - unfairly penalizes organizations growing faster than double their current holding
>>>    - unfairly does not penalizes organizations growing faster than double their current holding so long as they need less than a /16
>>> 
>>> 
>>> A > B or B > A?
>>> 
>>> I can't decide if A is less unfair because there is no carve out for organizations that need less than a /16.  On one hand those needing less than a /16 are not treated unfairly as a special class, but as a result the number of organizations who need IP addresses that are rate limited is greater.
>>> 
>>>  Or if C is less unfair because it is unfair to have a carve out for the organization that need less than a /16 for exactly the opposite reasons.
>>> 
>>> __Jason
>>> 
>>>> On Tue, Feb 7, 2017 at 2:53 PM, Jason Schiller <jschiller at google.com> wrote:
>>>> We have a few options on the table and only a few voices in the discussion...
>>>> 
>>>> I'd like to quickly outline the options, and see if we can get more people to weigh in and either note they object to one or more options, are ambivalent to one or more options, or support one or more options (with some preference).
>>>> 
>>>> 
>>>> 1. demonstrate 80% utilization on average for all your IP space
>>>> 2. get pre-authorization for 1 or more transfers up to double your current holdings over then two years
>>>> 2.1. this is limited to a /16
>>>> 
>>>> A. you can use this policy once every 6 months
>>>> 
>>>> B. If you need to use this policy more than once every 6 months you need to also demonstrate growth equalling half what you have transferred since you last used this policy.
>>>> 
>>>> C. you can use this policy to transfer a total of up to a /16
>>>> 
>>>> Where do you stand on A, B or C?
>>>> 
>>>> __Jason
>>>> 
>>>> 
>>>>> On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>>>>> That would be a significant improvement on the current ("An organization may only qualify under 8.5.7 once every 6 months.") text.  I would be equally fine with this text ("No more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period." or similar) or with Jason's ("An organization may only qualify under 8.5.7 once every 6 months, unless they can also demonstrate growth of IPv4 utilization of at least half of the amount of specified transfers since the previous transfer pre-authorization or approval.")
>>>>> 
>>>>> Thanks,
>>>>> Scott
>>>>> 
>>>>>> On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <owen at delong.com> wrote:
>>>>>> Simple to resolve for the 6-month horizon ?
>>>>>> 
>>>>>> ? Such that no more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period. ?
>>>>>> 
>>>>>> Owen
>>>>>> 
>>>>>> > On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com> wrote:
>>>>>> >
>>>>>> >
>>>>>> > I thought of a possible problem with the anti-abuse language -- all versions of it.  Let me talk it out.
>>>>>> >
>>>>>> > An organization has a /19.
>>>>>> > It has growing products, and wants another /19 for its 1 or 2 year need.
>>>>>> > It wants to avail itself of the new language.
>>>>>> > It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
>>>>>> >
>>>>>> > It closes the deal with Buyer A first, and transfers at ARIN using the proposed language.
>>>>>> >
>>>>>> > How does it use any version we've discussed (Jason's various proposals, the current text, etc) to transfer the space it buys from Buyer B?
>>>>>> >
>>>>>> >
>>>>>> > (In all discussion, yes, you can always use the other sections of 8.5, but let's stick to the spirit of this policy language, which is meant to help smaller and mid-size networks double their holdings without needs testing.)
>>>>>> > _______________________________________________
>>>>>> > 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.
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> _______________________________________________________
>>>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> _______________________________________________________
>>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>>> 
>> 
> 
> 
> 
> -- 
> _______________________________________________________
> 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/20170209/f4c2a0c5/attachment.htm>

From jschiller at google.com  Thu Feb  9 12:45:14 2017
From: jschiller at google.com (Jason Schiller)
Date: Thu, 9 Feb 2017 12:45:14 -0500
Subject: [arin-ppml] 2016-3 Revisited - anti-abuse clause
In-Reply-To: <A63CFFB1-0D0A-4EC3-B0E7-30A9C45F3201@delong.com>
References: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>
 <CAC4yj2WBCOK_Zwk09XBzCfeZm+W-PpAKjuVUCzE5Tx7o2gSn3Q@mail.gmail.com>
 <A63CFFB1-0D0A-4EC3-B0E7-30A9C45F3201@delong.com>
Message-ID: <CAC4yj2XcmFTLnwtPj0yooox1dCTP4kpwZ7_oWskKmwHXsucORA@mail.gmail.com>

Maybe fairness was not the word I was looking for...

I don't mind large organizations using a more difficult process or
requiring greater proof, as was the case with the "less simplified
provisions of the existing policy" wrt the ISP slow start policy of the
ARIN pool.  But slow start as it is currently written does not work well in
the transfer market.  So instead the specified transfer is granted based on
some hand wavy, future looking prediction with unpredictable results.


Everyone should be able to use a process that is predictable, and not
dependent on hand wavy future looking projections.


For ARIN Pool space, as an ISP, I could "slow start" if I have no history
of utilization, or if my history of utilization is less than my current
growth rate.

In the case of the former I start with a small block (initially /22, later
between a /24 and /22).

In the case of the later, I start with a block size based on my previous
year's run rate (initially a 2 year supply, then 3 month supply, and now
again a 2 year supply).

I use up what I got.  If I can use it in less time than the time window of
space I am allowed to get I can double, if it takes the time window, I get
that size again, and if it takes longer than the time window it goes down.
(plus rounding up initially or down later.)

This approach is:
1. predictable
2. is based on A. actual demonstrable utilization, and B.the belief that
growth will continue
3. does not require product folks to make some sort of hand wavy future
projection
4. does not require ARIN to engage in back and forth in an attempt to
assess the veracity of the projection
5. does not depend on a future looking belief which in the end cannot be
tested, proven or disproven.
6. does not depend on a claim that if not met can simply be excused with
"well, we missed" with no harm no foul.
7. does not reward more overly optimistic organizations with a greater over
supply.

My desire is to permit everyone (end users and ISPs) to use a predictable,
slow start mechanism in the transfer market.

My suggested transfer text differs essentially in three ways:

1. Demonstration of past utilization is slightly easier.
    For ARIN IP space you have to show 80% utilization on average, and 50%
on each block.
    For the suggested text its 80% on average and growth equal to 50% of
the space transferred.

   - the 50% clause is to prevent someone with high utilization from
getting IP space, not using it
     and their now lower utilization still being high enough to get more IP
space.
   - the problem with this approach is someone may actually be growing,
needing, and using the new
     space but have a small historically under utilized block, say a
deployment that got delayed.
   - the growth equal to 50% of transferred space clause it to meet the
intent of the policy while giving
     flexibility to renumber

2. Historical growth may not be a good measure because growth may be rate
limited waiting on a transfer.

   - Basically the first block is "easy".

   - We have a policy to let those with no space to get a /24

   - For those with efficient utilization they can easily double (but not
bigger than a /16).
     If the org never grows it could have up to a 50% surplus after using
this policy.

   - Any org growing at less than the doubling rate will have trouble with
the 80% on average re-certification,
     and will not be able to get another block.
    They could have up to a 50% surplus if growth stops shortly after using
this policy

   - Any org growing at more than the doubling rate needs and is using the
space, and should be able to get more.

  - An org's who is doubling in size, will have trouble with the 80% on
average re-certification, when the growth
    rate drops below doubling.
   They may have up to a 50% surplus if growth stops right after they use
this policy for the last time.

 - An org's who growth rate is greater than a /16 over the time window
(currently suggested as 6 months)
   may have up to a /16 surplus if they if growth stops right after they
use this policy for the last time.

3. An organization will also have to a pay fee for the IP space
   - this is likely a significant deterrent for small organizations




On Wed, Feb 8, 2017 at 3:35 PM, Owen DeLong <owen at delong.com> wrote:

> Respectfully I reject your premise on the fairness.
>
> Neither A, nor C prevent large organizations from getting more, they
> merely require that they use other less simplified provisions of the
> existing policy.
>
> I think what I support is sort of a hybrid between A and C in that I
> believe you should be able to use the policy to transfer as often as you
> want, so long as your transfers within any 6 month period under this policy
> don?t exceed a /16. You?d still be able to transfer a /16 under this policy
> and then use other existing policies if you needed more.
>
> Owen
>
> On Feb 7, 2017, at 12:04 , Jason Schiller <jschiller at google.com> wrote:
>
> I support B.
>
> It puts added work on those who need more than a /16, or have a growth
> rate more than doubling every half yeah, but does not prevent organizations
> who need IP addresses from getting them.
>
> I oppose A and C as they are unfair,
>
> A.
>   - unfairly penalizes large organizations that need more than a /16
>   - unfairly penalizes organizations growing faster than double their
> current holding
>     (especially new organizations that started with a /24 and have a
> growth rate greater than 512 customer per year)
>
> C.
>    - unfairly penalizes large organizations that need more than a /16
>    - unfairly penalizes organizations growing faster than double their
> current holding
>    - unfairly does not penalizes organizations growing faster than double
> their current holding so long as they need less than a /16
>
>
> A > B or B > A?
>
> I can't decide if A is less unfair because there is no carve out for
> organizations that need less than a /16.  On one hand those needing less
> than a /16 are not treated unfairly as a special class, but as a result the
> number of organizations who need IP addresses that are rate limited is
> greater.
>
>  Or if C is less unfair because it is unfair to have a carve out for the
> organization that need less than a /16 for exactly the opposite reasons.
>
> __Jason
>
> On Tue, Feb 7, 2017 at 2:53 PM, Jason Schiller <jschiller at google.com>
> wrote:
>
>> We have a few options on the table and only a few voices in the
>> discussion...
>>
>> I'd like to quickly outline the options, and see if we can get more
>> people to weigh in and either note they object to one or more options, are
>> ambivalent to one or more options, or support one or more options (with
>> some preference).
>>
>>
>> 1. demonstrate 80% utilization on average for all your IP space
>> 2. get pre-authorization for 1 or more transfers up to double your
>> current holdings over then two years
>> 2.1. this is limited to a /16
>>
>> A. you can use this policy once every 6 months
>>
>> B. If you need to use this policy more than once every 6 months you need
>> to also demonstrate growth equalling half what you have transferred since
>> you last used this policy.
>>
>> C. you can use this policy to transfer a total of up to a /16
>>
>> Where do you stand on A, B or C?
>>
>> __Jason
>>
>>
>> On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <scottleibrand at gmail.com>
>> wrote:
>>
>>> That would be a significant improvement on the current ("An organization
>>> may only qualify under 8.5.7 once every 6 months.") text.  I would be
>>> equally fine with this text ("No more than a total of a /16 equivalent
>>> may be transferred under these provisions within any 6 month period." or
>>> similar) or with Jason's ("An organization may only qualify under 8.5.7
>>> once every 6 months, unless they can also demonstrate growth of IPv4
>>> utilization of at least half of the amount of specified transfers since the
>>> previous transfer pre-authorization or approval.")
>>>
>>> Thanks,
>>> Scott
>>>
>>> On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <owen at delong.com> wrote:
>>>
>>>> Simple to resolve for the 6-month horizon ?
>>>>
>>>> ? Such that no more than a total of a /16 equivalent may be transferred
>>>> under these provisions within any 6 month period. ?
>>>>
>>>> Owen
>>>>
>>>> > On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com> wrote:
>>>> >
>>>> >
>>>> > I thought of a possible problem with the anti-abuse language -- all
>>>> versions of it.  Let me talk it out.
>>>> >
>>>> > An organization has a /19.
>>>> > It has growing products, and wants another /19 for its 1 or 2 year
>>>> need.
>>>> > It wants to avail itself of the new language.
>>>> > It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
>>>> >
>>>> > It closes the deal with Buyer A first, and transfers at ARIN using
>>>> the proposed language.
>>>> >
>>>> > How does it use any version we've discussed (Jason's various
>>>> proposals, the current text, etc) to transfer the space it buys from Buyer
>>>> B?
>>>> >
>>>> >
>>>> > (In all discussion, yes, you can always use the other sections of
>>>> 8.5, but let's stick to the spirit of this policy language, which is meant
>>>> to help smaller and mid-size networks double their holdings without needs
>>>> testing.)
>>>> > _______________________________________________
>>>> > 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.
>>>
>>
>>
>>
>> --
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>> <(571)%20266-0006>
>>
>>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006>
>
>
>


-- 
_______________________________________________________
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/20170209/0ec0fbf8/attachment.htm>

From narten at us.ibm.com  Fri Feb 10 00:53:28 2017
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 10 Feb 2017 00:53:28 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201702100553.v1A5rSBl018441@rotala.raleigh.ibm.com>

Total of 24 messages in the last 7 days.
 
script run at: Fri Feb 10 00:53:23 EST 2017
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 16.67% |    4 | 26.53% |   100701 | jschiller at google.com
 20.83% |    5 | 11.43% |    43402 | daveid at panix.com
 12.50% |    3 | 10.91% |    41417 | jcurran at arin.net
 12.50% |    3 | 10.20% |    38727 | mike at iptrading.com
  8.33% |    2 | 12.51% |    47498 | scottleibrand at gmail.com
 12.50% |    3 |  6.39% |    24273 | bill at herrin.us
  4.17% |    1 |  9.61% |    36466 | eric.loos at bics.com
  4.17% |    1 |  6.97% |    26449 | owen at delong.com
  4.17% |    1 |  3.27% |    12412 | rjletts at uw.edu
  4.17% |    1 |  2.18% |     8277 | kevinb at thewire.ca
--------+------+--------+----------+------------------------
100.00% |   24 |100.00% |   379622 | Total



From kevinb at thewire.ca  Fri Feb 10 12:31:22 2017
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Fri, 10 Feb 2017 17:31:22 +0000
Subject: [arin-ppml] 2016-3 Revisited - anti-abuse clause
In-Reply-To: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>
References: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>
Message-ID: <7E7773B523E82C478734E793E58F69E78E505305@SBS2011.thewireinc.local>

Jason,

In regards to A that would be the presumed assumption of the existing text correct?

I?m not comfortable with B.

In regards to C the intent would be to allow someone who has a /19 to get a /18 and then as an example three months later come back for a /17 once they have shown 80 percent of the /18?

There is another option.

D) you can use this policy once every 3 months

Thanks,

Kevin Blumberg




From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason Schiller
Sent: Tuesday, February 7, 2017 2:54 PM
To: Scott Leibrand <scottleibrand at gmail.com>
Cc: ARIN-PPML List <arin-ppml at arin.net>
Subject: Re: [arin-ppml] 2016-3 Revisited - anti-abuse clause

We have a few options on the table and only a few voices in the discussion...

I'd like to quickly outline the options, and see if we can get more people to weigh in and either note they object to one or more options, are ambivalent to one or more options, or support one or more options (with some preference).


1. demonstrate 80% utilization on average for all your IP space
2. get pre-authorization for 1 or more transfers up to double your current holdings over then two years
2.1. this is limited to a /16

A. you can use this policy once every 6 months

B. If you need to use this policy more than once every 6 months you need to also demonstrate growth equalling half what you have transferred since you last used this policy.

C. you can use this policy to transfer a total of up to a /16

Where do you stand on A, B or C?

__Jason


On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <scottleibrand at gmail.com<mailto:scottleibrand at gmail.com>> wrote:
That would be a significant improvement on the current ("An organization may only qualify under 8.5.7 once every 6 months.") text.  I would be equally fine with this text ("No more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period." or similar) or with Jason's ("An organization may only qualify under 8.5.7 once every 6 months, unless they can also demonstrate growth of IPv4 utilization of at least half of the amount of specified transfers since the previous transfer pre-authorization or approval.")

Thanks,
Scott

On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:
Simple to resolve for the 6-month horizon ?

? Such that no more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period. ?

Owen

> On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com<mailto:daveid at panix.com>> wrote:
>
>
> I thought of a possible problem with the anti-abuse language -- all versions of it.  Let me talk it out.
>
> An organization has a /19.
> It has growing products, and wants another /19 for its 1 or 2 year need.
> It wants to avail itself of the new language.
> It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
>
> It closes the deal with Buyer A first, and transfers at ARIN using the proposed language.
>
> How does it use any version we've discussed (Jason's various proposals, the current text, etc) to transfer the space it buys from Buyer B?
>
>
> (In all discussion, yes, you can always use the other sections of 8.5, but let's stick to the spirit of this policy language, which is meant to help smaller and mid-size networks double their holdings without needs testing.)
> _______________________________________________
> 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.



--
_______________________________________________________
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/20170210/cec07ce0/attachment.htm>

From scottleibrand at gmail.com  Fri Feb 10 12:56:04 2017
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 10 Feb 2017 10:56:04 -0700
Subject: [arin-ppml] 2016-3 Revisited - anti-abuse clause
In-Reply-To: <7E7773B523E82C478734E793E58F69E78E505305@SBS2011.thewireinc.local>
References: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E505305@SBS2011.thewireinc.local>
Message-ID: <CAGkMwz61HVSmeq40bEcsQy9nyOzuRsDkz1G-YkPfSg6z8Zoq=Q@mail.gmail.com>

Kevin,

I think that is correct, although I'm not sure they'd have to show 80% of
the new /18, just meet the overall usage threshold. Depends on the exact
language we use, of course.

What's your preference between A, C, and D?

-Scott

On Fri, Feb 10, 2017 at 10:31 AM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> Jason,
>
>
>
> In regards to A that would be the presumed assumption of the existing text
> correct?
>
>
>
> I?m not comfortable with B.
>
>
>
> In regards to C the intent would be to allow someone who has a /19 to get
> a /18 and then as an example three months later come back for a /17 once
> they have shown 80 percent of the /18?
>
>
>
> There is another option.
>
>
>
> D) you can use this policy once every 3 months
>
>
>
> Thanks,
>
> Kevin Blumberg
>
>
>
>
>
>
>
>
>
> *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *Jason
> Schiller
> *Sent:* Tuesday, February 7, 2017 2:54 PM
> *To:* Scott Leibrand <scottleibrand at gmail.com>
> *Cc:* ARIN-PPML List <arin-ppml at arin.net>
> *Subject:* Re: [arin-ppml] 2016-3 Revisited - anti-abuse clause
>
>
>
> We have a few options on the table and only a few voices in the
> discussion...
>
>
>
> I'd like to quickly outline the options, and see if we can get more people
> to weigh in and either note they object to one or more options, are
> ambivalent to one or more options, or support one or more options (with
> some preference).
>
>
>
>
>
> 1. demonstrate 80% utilization on average for all your IP space
>
> 2. get pre-authorization for 1 or more transfers up to double your current
> holdings over then two years
>
> 2.1. this is limited to a /16
>
>
>
> A. you can use this policy once every 6 months
>
>
>
> B. If you need to use this policy more than once every 6 months you need
> to also demonstrate growth equalling half what you have transferred since
> you last used this policy.
>
>
>
> C. you can use this policy to transfer a total of up to a /16
>
>
>
> Where do you stand on A, B or C?
>
>
>
> __Jason
>
>
>
>
>
> On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
>
> That would be a significant improvement on the current ("An organization
> may only qualify under 8.5.7 once every 6 months.") text.  I would be
> equally fine with this text ("No more than a total of a /16 equivalent
> may be transferred under these provisions within any 6 month period." or
> similar) or with Jason's ("An organization may only qualify under 8.5.7
> once every 6 months, unless they can also demonstrate growth of IPv4
> utilization of at least half of the amount of specified transfers since the
> previous transfer pre-authorization or approval.")
>
>
>
> Thanks,
>
> Scott
>
>
>
> On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <owen at delong.com> wrote:
>
> Simple to resolve for the 6-month horizon ?
>
> ? Such that no more than a total of a /16 equivalent may be transferred
> under these provisions within any 6 month period. ?
>
> Owen
>
>
> > On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com> wrote:
> >
> >
> > I thought of a possible problem with the anti-abuse language -- all
> versions of it.  Let me talk it out.
> >
> > An organization has a /19.
> > It has growing products, and wants another /19 for its 1 or 2 year need.
> > It wants to avail itself of the new language.
> > It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
> >
> > It closes the deal with Buyer A first, and transfers at ARIN using the
> proposed language.
> >
> > How does it use any version we've discussed (Jason's various proposals,
> the current text, etc) to transfer the space it buys from Buyer B?
> >
> >
> > (In all discussion, yes, you can always use the other sections of 8.5,
> but let's stick to the spirit of this policy language, which is meant to
> help smaller and mid-size networks double their holdings without needs
> testing.)
> > _______________________________________________
> > 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.
>
>
>
>
>
> --
>
> _______________________________________________________
>
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170210/99803490/attachment.htm>

From jschiller at google.com  Fri Feb 10 13:07:12 2017
From: jschiller at google.com (Jason Schiller)
Date: Fri, 10 Feb 2017 13:07:12 -0500
Subject: [arin-ppml] 2016-3 Revisited - anti-abuse clause
In-Reply-To: <7E7773B523E82C478734E793E58F69E78E505305@SBS2011.thewireinc.local>
References: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E505305@SBS2011.thewireinc.local>
Message-ID: <CAC4yj2WP1BfeRfd3t3a=YuiVdn43+af9jyVGZ3ZjHJU5B8TQcg@mail.gmail.com>

Kevin,

Yes, A is the current proposed text.

B, which you are not comfortable with, allows you to come back and
re-certify under what is currently used for approving ARIN space for ISP
slow start, as was the original intent.

C, yes, but I will restate for clarity.
- an org has a /19 that is 80%+ utilized
- they get transfer pre-authorization for up to a /19 within two years of
today 02/10/2017
- they complete one or more transfers and transfer in a /19 equivalent by
04/10/2017
- on 05/10/2017 they demonstrate 80%+ total utilization (the /19 they held,
plus the /19 equivalent transferred in)
- They get transfer pre-authorization for up to a /18 within two years of
05/10/2017

I would actually like to take option D off the table, and instead have a
separate discussion of the proper size for the time window.  3 months, 6
months, 1 year, 18 months, 2 years...

I think the timing is impacted by who can come back more frequently and how
much documentation is needed.

I am personally more comfortable making the window longer, and having a
more detailed utilization justification required for coming back inside the
window.

__Jason


On Fri, Feb 10, 2017 at 12:31 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> Jason,
>
>
>
> In regards to A that would be the presumed assumption of the existing text
> correct?
>
>
>
> I?m not comfortable with B.
>
>
>
> In regards to C the intent would be to allow someone who has a /19 to get
> a /18 and then as an example three months later come back for a /17 once
> they have shown 80 percent of the /18?
>
>
>
> There is another option.
>
>
>
> D) you can use this policy once every 3 months
>
>
>
> Thanks,
>
> Kevin Blumberg
>
>
>
>
>
>
>
>
>
> *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *Jason
> Schiller
> *Sent:* Tuesday, February 7, 2017 2:54 PM
> *To:* Scott Leibrand <scottleibrand at gmail.com>
> *Cc:* ARIN-PPML List <arin-ppml at arin.net>
> *Subject:* Re: [arin-ppml] 2016-3 Revisited - anti-abuse clause
>
>
>
> We have a few options on the table and only a few voices in the
> discussion...
>
>
>
> I'd like to quickly outline the options, and see if we can get more people
> to weigh in and either note they object to one or more options, are
> ambivalent to one or more options, or support one or more options (with
> some preference).
>
>
>
>
>
> 1. demonstrate 80% utilization on average for all your IP space
>
> 2. get pre-authorization for 1 or more transfers up to double your current
> holdings over then two years
>
> 2.1. this is limited to a /16
>
>
>
> A. you can use this policy once every 6 months
>
>
>
> B. If you need to use this policy more than once every 6 months you need
> to also demonstrate growth equalling half what you have transferred since
> you last used this policy.
>
>
>
> C. you can use this policy to transfer a total of up to a /16
>
>
>
> Where do you stand on A, B or C?
>
>
>
> __Jason
>
>
>
>
>
> On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
>
> That would be a significant improvement on the current ("An organization
> may only qualify under 8.5.7 once every 6 months.") text.  I would be
> equally fine with this text ("No more than a total of a /16 equivalent
> may be transferred under these provisions within any 6 month period." or
> similar) or with Jason's ("An organization may only qualify under 8.5.7
> once every 6 months, unless they can also demonstrate growth of IPv4
> utilization of at least half of the amount of specified transfers since the
> previous transfer pre-authorization or approval.")
>
>
>
> Thanks,
>
> Scott
>
>
>
> On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <owen at delong.com> wrote:
>
> Simple to resolve for the 6-month horizon ?
>
> ? Such that no more than a total of a /16 equivalent may be transferred
> under these provisions within any 6 month period. ?
>
> Owen
>
>
> > On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com> wrote:
> >
> >
> > I thought of a possible problem with the anti-abuse language -- all
> versions of it.  Let me talk it out.
> >
> > An organization has a /19.
> > It has growing products, and wants another /19 for its 1 or 2 year need.
> > It wants to avail itself of the new language.
> > It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
> >
> > It closes the deal with Buyer A first, and transfers at ARIN using the
> proposed language.
> >
> > How does it use any version we've discussed (Jason's various proposals,
> the current text, etc) to transfer the space it buys from Buyer B?
> >
> >
> > (In all discussion, yes, you can always use the other sections of 8.5,
> but let's stick to the spirit of this policy language, which is meant to
> help smaller and mid-size networks double their holdings without needs
> testing.)
> > _______________________________________________
> > 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.
>
>
>
>
>
> --
>
> _______________________________________________________
>
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006>
>
>
>



-- 
_______________________________________________________
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/20170210/43605d8d/attachment.htm>

From kevinb at thewire.ca  Fri Feb 10 13:46:10 2017
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Fri, 10 Feb 2017 18:46:10 +0000
Subject: [arin-ppml] 2016-3 Revisited - anti-abuse clause
In-Reply-To: <CAC4yj2WP1BfeRfd3t3a=YuiVdn43+af9jyVGZ3ZjHJU5B8TQcg@mail.gmail.com>
References: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E505305@SBS2011.thewireinc.local>
 <CAC4yj2WP1BfeRfd3t3a=YuiVdn43+af9jyVGZ3ZjHJU5B8TQcg@mail.gmail.com>
Message-ID: <7E7773B523E82C478734E793E58F69E78E50541D@SBS2011.thewireinc.local>

Jason,

I will rate on preference and look forward to more feedback from the community.

1) A ? Leave the proposal AS IS.
2) C ? Allow multiple requests inside of the 6-month window.

I?m curious on the transfers that have been done, how many organizations were approved for space more than once every 6 months?

I would prefer that edge cases be handled by the standard process and the number of variables be kept to a minimum here.

Thanks,

Kevin Blumberg

From: Jason Schiller [mailto:jschiller at google.com]
Sent: Friday, February 10, 2017 1:07 PM
To: Kevin Blumberg <kevinb at thewire.ca>
Cc: Scott Leibrand <scottleibrand at gmail.com>; ARIN-PPML List <arin-ppml at arin.net>
Subject: Re: [arin-ppml] 2016-3 Revisited - anti-abuse clause

Kevin,

Yes, A is the current proposed text.

B, which you are not comfortable with, allows you to come back and re-certify under what is currently used for approving ARIN space for ISP slow start, as was the original intent.

C, yes, but I will restate for clarity.
- an org has a /19 that is 80%+ utilized
- they get transfer pre-authorization for up to a /19 within two years of today 02/10/2017
- they complete one or more transfers and transfer in a /19 equivalent by 04/10/2017
- on 05/10/2017 they demonstrate 80%+ total utilization (the /19 they held, plus the /19 equivalent transferred in)
- They get transfer pre-authorization for up to a /18 within two years of 05/10/2017

I would actually like to take option D off the table, and instead have a separate discussion of the proper size for the time window.  3 months, 6 months, 1 year, 18 months, 2 years...

I think the timing is impacted by who can come back more frequently and how much documentation is needed.

I am personally more comfortable making the window longer, and having a more detailed utilization justification required for coming back inside the window.

__Jason


On Fri, Feb 10, 2017 at 12:31 PM, Kevin Blumberg <kevinb at thewire.ca<mailto:kevinb at thewire.ca>> wrote:
Jason,

In regards to A that would be the presumed assumption of the existing text correct?

I?m not comfortable with B.

In regards to C the intent would be to allow someone who has a /19 to get a /18 and then as an example three months later come back for a /17 once they have shown 80 percent of the /18?

There is another option.

D) you can use this policy once every 3 months

Thanks,

Kevin Blumberg




From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>] On Behalf Of Jason Schiller
Sent: Tuesday, February 7, 2017 2:54 PM
To: Scott Leibrand <scottleibrand at gmail.com<mailto:scottleibrand at gmail.com>>
Cc: ARIN-PPML List <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] 2016-3 Revisited - anti-abuse clause

We have a few options on the table and only a few voices in the discussion...

I'd like to quickly outline the options, and see if we can get more people to weigh in and either note they object to one or more options, are ambivalent to one or more options, or support one or more options (with some preference).


1. demonstrate 80% utilization on average for all your IP space
2. get pre-authorization for 1 or more transfers up to double your current holdings over then two years
2.1. this is limited to a /16

A. you can use this policy once every 6 months

B. If you need to use this policy more than once every 6 months you need to also demonstrate growth equalling half what you have transferred since you last used this policy.

C. you can use this policy to transfer a total of up to a /16

Where do you stand on A, B or C?

__Jason


On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <scottleibrand at gmail.com<mailto:scottleibrand at gmail.com>> wrote:
That would be a significant improvement on the current ("An organization may only qualify under 8.5.7 once every 6 months.") text.  I would be equally fine with this text ("No more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period." or similar) or with Jason's ("An organization may only qualify under 8.5.7 once every 6 months, unless they can also demonstrate growth of IPv4 utilization of at least half of the amount of specified transfers since the previous transfer pre-authorization or approval.")

Thanks,
Scott

On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:
Simple to resolve for the 6-month horizon ?

? Such that no more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period. ?

Owen

> On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com<mailto:daveid at panix.com>> wrote:
>
>
> I thought of a possible problem with the anti-abuse language -- all versions of it.  Let me talk it out.
>
> An organization has a /19.
> It has growing products, and wants another /19 for its 1 or 2 year need.
> It wants to avail itself of the new language.
> It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
>
> It closes the deal with Buyer A first, and transfers at ARIN using the proposed language.
>
> How does it use any version we've discussed (Jason's various proposals, the current text, etc) to transfer the space it buys from Buyer B?
>
>
> (In all discussion, yes, you can always use the other sections of 8.5, but let's stick to the spirit of this policy language, which is meant to help smaller and mid-size networks double their holdings without needs testing.)
> _______________________________________________
> 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.



--
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com<mailto:jschiller at google.com>|571-266-0006<tel:(571)%20266-0006>




--
_______________________________________________________
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/20170210/1d97eb2f/attachment.htm>

From rbf+arin-ppml at panix.com  Sat Feb 11 14:17:58 2017
From: rbf+arin-ppml at panix.com (Brett Frankenberger)
Date: Sat, 11 Feb 2017 13:17:58 -0600
Subject: [arin-ppml] 2016-3 Revisited - anti-abuse clause
In-Reply-To: <A63CFFB1-0D0A-4EC3-B0E7-30A9C45F3201@delong.com>
References: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>
 <CAC4yj2WBCOK_Zwk09XBzCfeZm+W-PpAKjuVUCzE5Tx7o2gSn3Q@mail.gmail.com>
 <A63CFFB1-0D0A-4EC3-B0E7-30A9C45F3201@delong.com>
Message-ID: <20170211191758.GA456@panix.com>

On Wed, Feb 08, 2017 at 12:35:29PM -0800, Owen DeLong wrote:
>
> Respectfully I reject your premise on the fairness.

Agreed.  It imposes more process (on ARIN and on the requester) for
organizations whose demand for space is higher.  This is neither unfair
nor new, and seems reasonable.  Larger transfers warrant greater
scrutiny.  Existing policy requires a showing of (among other things)
80% utilization; that's relatively easy if you have a /20, and
considerably more work if you have a /13.  (The point stands even
though the /13 holder may have completely automated the process.  That
just means they did the work upfront.)

> Neither A, nor C prevent large organizations from getting more, they
> merely require that they use other less simplified provisions of the
> existing policy.
> 
> I think what I support is sort of a hybrid between A and C in that I
> believe you should be able to use the policy to transfer as often as
> you want, so long as your transfers within any 6 month period under
> this policy don?t exceed a /16.  You?d still be able to transfer a
> /16 under this policy and then use other existing policies if you
> needed more.

I favor that as well.

Any line we draw is bound to be somewhat arbitrary.  But drawing it at
"when you're consuming more than /16 every 6 months, you're big enough
to use the existing process" is, I think, better than the proposed
alternatives.

Option A denies small but fast growing organizations the full benefits
of this policy.  Option B adds additional process to what is supposed
to be a simplified option.  Option C effectively defines "large"
without regard to growth rate, whereas the proposal above defines
"large" based on growth rate.  It's harder to say why I favor the
latter, but I think the policy should be available to the provider who
needs a /16 or less every 6 months, even if he's already got a /15 half
of which came under this policy.

More generally, I think the structure of "no more than a /X in Y
months" is the right structure.  Exactly what X and Y should be could
be discussed independently.  I wouldn't be opposed to the limit being
/16 in 12 months, for example.

     -- Brett


From owen at delong.com  Sat Feb 11 21:59:50 2017
From: owen at delong.com (Owen DeLong)
Date: Sat, 11 Feb 2017 18:59:50 -0800
Subject: [arin-ppml] 2016-3 Revisited - anti-abuse clause
In-Reply-To: <CAC4yj2WK+9B20yQ3pO3UKyEfAiK1JV490JYb9QKX3T-JNzfq7g@mail.gmail.com>
References: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>
 <CAC4yj2WBCOK_Zwk09XBzCfeZm+W-PpAKjuVUCzE5Tx7o2gSn3Q@mail.gmail.com>
 <A63CFFB1-0D0A-4EC3-B0E7-30A9C45F3201@delong.com>
 <CAC4yj2WK+9B20yQ3pO3UKyEfAiK1JV490JYb9QKX3T-JNzfq7g@mail.gmail.com>
Message-ID: <8CF75D78-5DA3-46DC-B230-064A30A3E10D@delong.com>

To be clear, I?m proposing a 6 month sliding window.

Owen

> On Feb 9, 2017, at 08:39 , Jason Schiller <jschiller at google.com> wrote:
> 
> Owen,
> 
> After reading your mail, I noticed I artificially shortened the text for C.  It should have been what you described as your preferred choice.
> 
> Re-asking the question for clarity (and hopes of getting new voices).
> 
> We have a few options on the table and only a few voices in the discussion...
> 
> I'd like to quickly outline the options, and see if we can get more people to weigh in and either note they object to one or more options, are ambivalent to one or more options, or support one or more options (with some preference).
> 
> 
> 1. demonstrate 80% utilization on average for all your IP space
> 2. get pre-authorization for 1 or more transfers up to double your current holdings over then two years
> 2.1. this is limited to a /16
> 
> A. you can use this policy once every 6 months
> 
> B. If you need to use this policy more than once every 6 months you need to also demonstrate growth equaling half what you have transferred since you last used this policy.
> 
> C. You can use this policy to transfer a total of up to a /16 every 6 months
> 
> Where do you stand on A, B or C?
> 
> 
> 
> On Wed, Feb 8, 2017 at 3:35 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
> Respectfully I reject your premise on the fairness.
> 
> Neither A, nor C prevent large organizations from getting more, they merely require that they use other less simplified provisions of the existing policy.
> 
> I think what I support is sort of a hybrid between A and C in that I believe you should be able to use the policy to transfer as often as you want, so long as your transfers within any 6 month period under this policy don?t exceed a /16. You?d still be able to transfer a /16 under this policy and then use other existing policies if you needed more.
> 
> Owen
> 
>> On Feb 7, 2017, at 12:04 , Jason Schiller <jschiller at google.com <mailto:jschiller at google.com>> wrote:
>> 
>> I support B.  
>> 
>> It puts added work on those who need more than a /16, or have a growth rate more than doubling every half yeah, but does not prevent organizations who need IP addresses from getting them.
>> 
>> I oppose A and C as they are unfair, 
>> 
>> A. 
>>   - unfairly penalizes large organizations that need more than a /16
>>   - unfairly penalizes organizations growing faster than double their current holding
>>     (especially new organizations that started with a /24 and have a growth rate greater than 512 customer per year)
>> 
>> C.
>>    - unfairly penalizes large organizations that need more than a /16
>>    - unfairly penalizes organizations growing faster than double their current holding
>>    - unfairly does not penalizes organizations growing faster than double their current holding so long as they need less than a /16
>> 
>> 
>> A > B or B > A?
>> 
>> I can't decide if A is less unfair because there is no carve out for organizations that need less than a /16.  On one hand those needing less than a /16 are not treated unfairly as a special class, but as a result the number of organizations who need IP addresses that are rate limited is greater.
>> 
>>  Or if C is less unfair because it is unfair to have a carve out for the organization that need less than a /16 for exactly the opposite reasons.
>> 
>> __Jason
>> 
>> On Tue, Feb 7, 2017 at 2:53 PM, Jason Schiller <jschiller at google.com <mailto:jschiller at google.com>> wrote:
>> We have a few options on the table and only a few voices in the discussion...
>> 
>> I'd like to quickly outline the options, and see if we can get more people to weigh in and either note they object to one or more options, are ambivalent to one or more options, or support one or more options (with some preference).
>> 
>> 
>> 1. demonstrate 80% utilization on average for all your IP space
>> 2. get pre-authorization for 1 or more transfers up to double your current holdings over then two years
>> 2.1. this is limited to a /16
>> 
>> A. you can use this policy once every 6 months
>> 
>> B. If you need to use this policy more than once every 6 months you need to also demonstrate growth equalling half what you have transferred since you last used this policy.
>> 
>> C. you can use this policy to transfer a total of up to a /16
>> 
>> Where do you stand on A, B or C?
>> 
>> __Jason
>> 
>> 
>> On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>> wrote:
>> That would be a significant improvement on the current ("An organization may only qualify under 8.5.7 once every 6 months.") text.  I would be equally fine with this text ("No more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period." or similar) or with Jason's ("An organization may only qualify under 8.5.7 once every 6 months, unless they can also demonstrate growth of IPv4 utilization of at least half of the amount of specified transfers since the previous transfer pre-authorization or approval.")
>> 
>> Thanks,
>> Scott
>> 
>> On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
>> Simple to resolve for the 6-month horizon ?
>> 
>> ? Such that no more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period. ?
>> 
>> Owen
>> 
>> > On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com <mailto:daveid at panix.com>> wrote:
>> >
>> >
>> > I thought of a possible problem with the anti-abuse language -- all versions of it.  Let me talk it out.
>> >
>> > An organization has a /19.
>> > It has growing products, and wants another /19 for its 1 or 2 year need.
>> > It wants to avail itself of the new language.
>> > It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
>> >
>> > It closes the deal with Buyer A first, and transfers at ARIN using the proposed language.
>> >
>> > How does it use any version we've discussed (Jason's various proposals, the current text, etc) to transfer the space it buys from Buyer B?
>> >
>> >
>> > (In all discussion, yes, you can always use the other sections of 8.5, but let's stick to the spirit of this policy language, which is meant to help smaller and mid-size networks double their holdings without needs testing.)
>> > _______________________________________________
>> > 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 <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 <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 <http://lists.arin.net/mailman/listinfo/arin-ppml>
>> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
>> 
>> 
>> 
>> -- 
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com <mailto:jschiller at google.com>|571-266-0006 <tel:(571)%20266-0006>
>> 
>> 
>> 
>> 
>> -- 
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com <mailto:jschiller at google.com>|571-266-0006 <tel:(571)%20266-0006>
>> 
> 
> 
> 
> 
> -- 
> _______________________________________________________
> 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/20170211/bc8482d7/attachment.htm>

From owen at delong.com  Sat Feb 11 22:11:59 2017
From: owen at delong.com (Owen DeLong)
Date: Sat, 11 Feb 2017 19:11:59 -0800
Subject: [arin-ppml] 2016-3 Revisited - anti-abuse clause
In-Reply-To: <CAGkMwz61HVSmeq40bEcsQy9nyOzuRsDkz1G-YkPfSg6z8Zoq=Q@mail.gmail.com>
References: <CAC4yj2UyLzZeoj-Jwbdkxa2s6QKViaNDZ6_6SBLJDL5ARs8_ig@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E505305@SBS2011.thewireinc.local>
 <CAGkMwz61HVSmeq40bEcsQy9nyOzuRsDkz1G-YkPfSg6z8Zoq=Q@mail.gmail.com>
Message-ID: <D1B5743D-4400-479E-97C5-01D53040A05C@delong.com>

Kevin,

For C, no, they wouldn?t need to show 80% utilization of the /18, they need to again show 80% overall when they came back.

Basically it introduces a 6 month sliding window allowing a total of up to a /16 transferred under this policy during any preceding 6 months.

However, there are other flaws with your scenario.

As I understand the proposal, you?re able to transfer up to your current size (max /16), so if they hold a /19, they can only transfer another /19 bringing their total holdings to /18 equivalent. Let?s call that T+0 months.

At T+2 months, they?ve again achieved 80% utilization overall and come back for a /18. They now hold a /17 equivalent total.

At T+4 months, they apply again and are able to transfer another /17 bringing their total holdings to /16.

Growth accelerates and now they come back at T+5 months. They can?t transfer another /16 because within the preceding 6 months, they?ve already transferred a /17+/18/+19.

All they would be able to transfer at T+5 months would be a /19 because that would complete a /16 worth of transfers in the preceding 6 months.

A month later, they could (potentially) transfer another /19 and 2 months later, they could potentially transfer another /18.

Owen

> On Feb 10, 2017, at 09:56 , Scott Leibrand <scottleibrand at gmail.com> wrote:
> 
> Kevin,
> 
> I think that is correct, although I'm not sure they'd have to show 80% of the new /18, just meet the overall usage threshold. Depends on the exact language we use, of course.
> 
> What's your preference between A, C, and D?
> 
> -Scott
> 
> On Fri, Feb 10, 2017 at 10:31 AM, Kevin Blumberg <kevinb at thewire.ca <mailto:kevinb at thewire.ca>> wrote:
> Jason, <>
>  
> 
> In regards to A that would be the presumed assumption of the existing text correct?
> 
>  
> 
> I?m not comfortable with B.
> 
>  
> 
> In regards to C the intent would be to allow someone who has a /19 to get a /18 and then as an example three months later come back for a /17 once they have shown 80 percent of the /18?
> 
>  
> 
> There is another option.
> 
>  
> 
> D) you can use this policy once every 3 months
> 
>  
> 
> Thanks,
> 
> Kevin Blumberg
> 
>  
> 
>  
> 
>  
> 
>  
> 
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net <mailto:arin-ppml-bounces at arin.net>] On Behalf Of Jason Schiller
> Sent: Tuesday, February 7, 2017 2:54 PM
> To: Scott Leibrand <scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>>
> Cc: ARIN-PPML List <arin-ppml at arin.net <mailto:arin-ppml at arin.net>>
> Subject: Re: [arin-ppml] 2016-3 Revisited - anti-abuse clause
> 
>  
> 
> We have a few options on the table and only a few voices in the discussion...
> 
>  
> 
> I'd like to quickly outline the options, and see if we can get more people to weigh in and either note they object to one or more options, are ambivalent to one or more options, or support one or more options (with some preference).
> 
>  
> 
>  
> 
> 1. demonstrate 80% utilization on average for all your IP space
> 
> 2. get pre-authorization for 1 or more transfers up to double your current holdings over then two years
> 
> 2.1. this is limited to a /16
> 
>  
> 
> A. you can use this policy once every 6 months
> 
>  
> 
> B. If you need to use this policy more than once every 6 months you need to also demonstrate growth equalling half what you have transferred since you last used this policy.
> 
>  
> 
> C. you can use this policy to transfer a total of up to a /16
> 
>  
> 
> Where do you stand on A, B or C?
> 
>  
> 
> __Jason
> 
>  
> 
>  
> 
> On Fri, Feb 3, 2017 at 7:01 PM, Scott Leibrand <scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>> wrote:
> 
> That would be a significant improvement on the current ("An organization may only qualify under 8.5.7 once every 6 months.") text.  I would be equally fine with this text ("No more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period." or similar) or with Jason's ("An organization may only qualify under 8.5.7 once every 6 months, unless they can also demonstrate growth of IPv4 utilization of at least half of the amount of specified transfers since the previous transfer pre-authorization or approval.")
> 
>  
> 
> Thanks,
> 
> Scott
> 
>  
> 
> On Fri, Feb 3, 2017 at 2:22 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
> 
> Simple to resolve for the 6-month horizon ?
> 
> ? Such that no more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period. ?
> 
> Owen
> 
> 
> > On Feb 3, 2017, at 07:19 , David R Huberman <daveid at panix.com <mailto:daveid at panix.com>> wrote:
> >
> >
> > I thought of a possible problem with the anti-abuse language -- all versions of it.  Let me talk it out.
> >
> > An organization has a /19.
> > It has growing products, and wants another /19 for its 1 or 2 year need.
> > It wants to avail itself of the new language.
> > It is able to buy a /20 from Buyer A, and a /20 from Buyer B.
> >
> > It closes the deal with Buyer A first, and transfers at ARIN using the proposed language.
> >
> > How does it use any version we've discussed (Jason's various proposals, the current text, etc) to transfer the space it buys from Buyer B?
> >
> >
> > (In all discussion, yes, you can always use the other sections of 8.5, but let's stick to the spirit of this policy language, which is meant to help smaller and mid-size networks double their holdings without needs testing.)
> > _______________________________________________
> > 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 <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 <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 <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
> 
> 
> 
> 
>  
> 
> --
> 
> _______________________________________________________
> 
> Jason Schiller|NetOps|jschiller at google.com <mailto:jschiller at google.com>|571-266-0006 <tel:(571)%20266-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.

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

From andrew.dul at quark.net  Tue Feb 14 21:40:27 2017
From: andrew.dul at quark.net (Andrew Dul)
Date: Tue, 14 Feb 2017 18:40:27 -0800
Subject: [arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect POC
 Validation Requirement
In-Reply-To: <585973ED.9090606@arin.net>
References: <585973ED.9090606@arin.net>
Message-ID: <842b9da9-8d5d-93b7-5364-dd95fe719c9e@quark.net>

There has been some good discussion about this draft. 

At this time, it seems like perhaps there is disagreement within the
community on the purpose and use of reassignment records.  As we have
gone past IPv4 run-out, perhaps now is the time to consider if
reassignment records provide the same level of value to the Internet
community that they used to provide.  Doing reassignments was one of the
primary ways that a service provider showed utilization to ARIN.  This
could also be done by having an organization share these records
directly with ARIN during a resource request.

I'd like to throw out a few open ended questions that perhaps will guide
the AC as it considers this draft:

1. Do you think reassignment records provide value to the Internet
community from an operational perspective?  Do they provide the same
value if they are not accurate?  At what point does the "record set" as
a whole become invaluable because the data in the records isn't
representative of current reassignments?

2. Who do you think should be responsible for ensuring that resource
records are accurate?  The organization doing the reassignment?  ARIN? 
Someone else?

3. Given we are past IPv4 run-out, do reassignment records provide the
same value to ARIN for the purposes of determining utilization?  Should
other methods be used to determine utilization going forward?

4. Would you support the concept of removing reassignment records for
which a POC has not been validated after a certain period of time?  1
year?  2 years?  x years?

5. Would you support the idea that a new reassignment could not be added
to the database without the approval of the POC who is receiving the
resource by reassignment?

Thanks for your input

Andrew



On 12/20/2016 10:09 AM, ARIN wrote:
>
>
> ##########
>
> ARIN-2016-8: Removal of Indirect POC Validation Requirement
>
> Problem Statement:
>
> There are over 600,000 POCs registered in Whois that are only
> associated with indirect assignments (reassignments) and indirect
> allocations (reallocations). NRPM 3.6 requires ARIN to contact all
> 600,000+ of these every year to validate the POC information. This is
> problematic for a few reasons:
>
> 1) ARIN does not have a business relationships with these POCs. By
> conducting POC validation via email, ARIN is sending Unsolicited
> Commercial Emails. Further, because of NRPM 3.6.1, ARIN cannot offer
> an opt-out mechanism. Finally, ARIN's resultant listing on anti-spam
> lists causes unacceptable damage to ARIN's ability to conduct ordinary
> business over email
>
> 2) ARIN has previously reported that POC validation to reassignments
> causes tremendous work for the staff. It receives many angry phone
> calls and emails about the POC validation process. I believe the ARIN
> staff should be focused on POC validation efforts for directly issued
> resources, as that has more value to internet operations and law
> enforcement than end-user POC information.
>
> Policy statement:
>
> Replace the first sentence of 3.6.1:
>
> "During ARIN's annual Whois POC validation, an email will be sent to
> every POC in the Whois database."
>
> with
>
> "During ARIN's annual Whois POC validation, an email will be sent to
> every POC that is a contact for a direct assignment, direct
> allocation, reallocation, and AS number, and their associated OrgIDs."
>
> 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 rjletts at uw.edu  Wed Feb 15 20:33:38 2017
From: rjletts at uw.edu (Richard J. Letts)
Date: Thu, 16 Feb 2017 01:33:38 +0000
Subject: [arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect POC
 Validation Requirement
In-Reply-To: <842b9da9-8d5d-93b7-5364-dd95fe719c9e@quark.net>
References: <585973ED.9090606@arin.net>
 <842b9da9-8d5d-93b7-5364-dd95fe719c9e@quark.net>
Message-ID: <DM5PR08MB26338FDF7B063C2E21D1F0B4C05A0@DM5PR08MB2633.namprd08.prod.outlook.com>

> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Dul
> Sent: Tuesday, February 14, 2017 6:40 PM
> 
> I'd like to throw out a few open ended questions that perhaps will guide the
> AC as it considers this draft:
> 
> 1. Do you think reassignment records provide value to the Internet
> community from an operational perspective?  Do they provide the same
> value if they are not accurate?  At what point does the "record set" as a
> whole become invaluable because the data in the records isn't
> representative of current reassignments?

a) Yes; in particular the 'abuse' and 'noc' contacts which are often used for receiving DCMA complaints

b) If they are not accurate then the ISP receives the complaints and are motivated to get the re-assignment records out there.
However they do not necessarily need to be fully accurate. For example I'm not sure ARIN has ever validated the name of some of the POC.
(e.g. if an organization has renamed itself from Networks and Distributed Systems, to Computing and Communications, and then to Information Technology that's not validated and doesn't need to be accurate for communication to occur)

c) No idea what you're getting at with the last part of this question

> 2. Who do you think should be responsible for ensuring that resource records
> are accurate?  The organization doing the reassignment?  ARIN?
> Someone else?

the organization doing the re-assignment

> 3. Given we are past IPv4 run-out, do reassignment records provide the
> same value to ARIN for the purposes of determining utilization?  Should
> other methods be used to determine utilization going forward?

The area where we publish the most reassignment records is for the state education network -- I think the need and opportunity to acquire additional IPv4 address space for that network has probably passed. (The network's fully IPv6 enabled, most school districts have NAT and firewalls). So there's little/no value in publishing these records JUST for ARIN to determine utilization as [today] I'm unlikely to need them for that purpose.

> 4. Would you support the concept of removing reassignment records for
> which a POC has not been validated after a certain period of time?  1 year?  2
> years?  x years?
No -- not by ARIN anyway given my belief that the organization performing the re-assignment ought to be responsible for maintaining the records of their customers properly.


> 5. Would you support the idea that a new reassignment could not be added
> to the database without the approval of the POC who is receiving the
> resource by reassignment?
No -- but then we have a well-defined customer base that hardly changes so it's not as if we're adding random people at an organization.

My 2cents

Richard Letts


From kevinb at thewire.ca  Wed Feb 15 21:42:29 2017
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Thu, 16 Feb 2017 02:42:29 +0000
Subject: [arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect POC
 Validation Requirement
In-Reply-To: <842b9da9-8d5d-93b7-5364-dd95fe719c9e@quark.net>
References: <585973ED.9090606@arin.net>
 <842b9da9-8d5d-93b7-5364-dd95fe719c9e@quark.net>
Message-ID: <7E7773B523E82C478734E793E58F69E78E5148EA@SBS2011.thewireinc.local>

Andrew,

There are 2 kinds of reassignments that I use simple and detailed. All the issues that are described in this draft only exist in the detailed re-assignment. An ORG could use the simple option and not have POC validation issues. Is there a reason that simple re-assignments were left out of the problem statement?

1) Yes and Yes. Even bad data has value.
2) Everyone has some responsibility, it shouldn't be lumped on any one group. 
3) Leading question that can only be answered by Staff. 
4) No. I would be in favor of marking the record as stale or switching the record to Simple and removing the POC.
5) Yes.

Thanks,

Kevin Blumberg

-----Original Message-----
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Dul
Sent: Tuesday, February 14, 2017 9:40 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect POC Validation Requirement

There has been some good discussion about this draft. 

At this time, it seems like perhaps there is disagreement within the community on the purpose and use of reassignment records.  As we have gone past IPv4 run-out, perhaps now is the time to consider if reassignment records provide the same level of value to the Internet community that they used to provide.  Doing reassignments was one of the primary ways that a service provider showed utilization to ARIN.  This could also be done by having an organization share these records directly with ARIN during a resource request.

I'd like to throw out a few open ended questions that perhaps will guide the AC as it considers this draft:

1. Do you think reassignment records provide value to the Internet community from an operational perspective?  Do they provide the same value if they are not accurate?  At what point does the "record set" as a whole become invaluable because the data in the records isn't representative of current reassignments?

2. Who do you think should be responsible for ensuring that resource records are accurate?  The organization doing the reassignment?  ARIN? 
Someone else?

3. Given we are past IPv4 run-out, do reassignment records provide the same value to ARIN for the purposes of determining utilization?  Should other methods be used to determine utilization going forward?

4. Would you support the concept of removing reassignment records for which a POC has not been validated after a certain period of time?  1 year?  2 years?  x years?

5. Would you support the idea that a new reassignment could not be added to the database without the approval of the POC who is receiving the resource by reassignment?

Thanks for your input

Andrew



On 12/20/2016 10:09 AM, ARIN wrote:
>
>
> ##########
>
> ARIN-2016-8: Removal of Indirect POC Validation Requirement
>
> Problem Statement:
>
> There are over 600,000 POCs registered in Whois that are only 
> associated with indirect assignments (reassignments) and indirect 
> allocations (reallocations). NRPM 3.6 requires ARIN to contact all 
> 600,000+ of these every year to validate the POC information. This is 
> problematic for a few reasons:
>
> 1) ARIN does not have a business relationships with these POCs. By 
> conducting POC validation via email, ARIN is sending Unsolicited 
> Commercial Emails. Further, because of NRPM 3.6.1, ARIN cannot offer 
> an opt-out mechanism. Finally, ARIN's resultant listing on anti-spam 
> lists causes unacceptable damage to ARIN's ability to conduct ordinary 
> business over email
>
> 2) ARIN has previously reported that POC validation to reassignments 
> causes tremendous work for the staff. It receives many angry phone 
> calls and emails about the POC validation process. I believe the ARIN 
> staff should be focused on POC validation efforts for directly issued 
> resources, as that has more value to internet operations and law 
> enforcement than end-user POC information.
>
> Policy statement:
>
> Replace the first sentence of 3.6.1:
>
> "During ARIN's annual Whois POC validation, an email will be sent to 
> every POC in the Whois database."
>
> with
>
> "During ARIN's annual Whois POC validation, an email will be sent to 
> every POC that is a contact for a direct assignment, direct 
> allocation, reallocation, and AS number, and their associated OrgIDs."
>
> 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.


From jschiller at google.com  Thu Feb 16 12:11:28 2017
From: jschiller at google.com (Jason Schiller)
Date: Thu, 16 Feb 2017 12:11:28 -0500
Subject: [arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect POC
 Validation Requirement
In-Reply-To: <7E7773B523E82C478734E793E58F69E78E5148EA@SBS2011.thewireinc.local>
References: <585973ED.9090606@arin.net>
 <842b9da9-8d5d-93b7-5364-dd95fe719c9e@quark.net>
 <7E7773B523E82C478734E793E58F69E78E5148EA@SBS2011.thewireinc.local>
Message-ID: <CAC4yj2W95GXmps0xCMob5GyxnLXj6txuR8yn1N6baLHhuQN6Tg@mail.gmail.com>

I have two operational perspectives wrt re-allocation/re-assignments.

first:
-----
+1 Owen, Joe Provo, james machado -- Randomly re-allocating / re-assigning
addresses to
some random person / email / mailing location at my company is a problem.

When we Peer the point-to-point is sometimes out of the Peers IP space.

The Peer will sometimes reassign detail the IP space to a random OrgID with
our company in the name
(in this case the contact is good, but the space is often held by the wrong
OrgID),

OR the Peer will reassign simple it to some random mailing address with our
compnay in the name
creating a customer C###### orgID,
(In this case there is no email address to validate,
but still held by the wrong OrgID, and possibly wrong mailing address.)

OR the Peer will reassign detail it to some random google mail and e-mail
address.

In this last case the orgID is not under our control.
We only find out about this during the annual POC review.
I get an email from someone in our Peering dept saying why is ARIN poking
me?
It is only then when I find the OrgID, and take it over, and fix the
contact.
To move the resources to the correct OrgID is more difficult, as the SWIP
is owned by the Peer
who is sometime unresponsive.

I believe the source of all of these issues is the same problem.
If we can solve that, it would be good.
If we can checking with the down stream to make sure the information is
correct
then we can avoid bad data getting in there.


Second:
-----------
With the experience of working at an ISP with business customers, I find
customers fall into three buckets:
1. Already have a relationship with ARIN (know and can provide their
correct OrgID/POC)
2. Have an IP person who would know about all their IP space, and can make
sure they are looped in
3. What is an IP admin? ARIN who?  You have my contact info from my circuit
order. Can I get my /26 now?

Depending on who places the order for service, you may sort them into the
wrong bucket

For customer of type 1, ARIN should verify them, and it should be fine.

For customers of type 2, there needs to be a process to get them as the
contact removed
and updated to the right person

For customers of type 3, the ISP should do the verification, or there
should be no validation.
Yes, they are still a customer, yes their circuit/bill goes to that
location,
yes we have that email as a contact.


I think verification at time of issuing makes sense.
I think reaffirming what bucket they are in at the time of issuing makes
sense.
In cases where the customer doesn't want to deal with ARIN, it should be
clear
What ISP record (e.g. outage contact, billing contact) and that the ISP will
continue to verify this information based on records held by the ISP (If at
all).

___Jason





On Wed, Feb 15, 2017 at 9:42 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> Andrew,
>
> There are 2 kinds of reassignments that I use simple and detailed. All the
> issues that are described in this draft only exist in the detailed
> re-assignment. An ORG could use the simple option and not have POC
> validation issues. Is there a reason that simple re-assignments were left
> out of the problem statement?
>
> 1) Yes and Yes. Even bad data has value.
> 2) Everyone has some responsibility, it shouldn't be lumped on any one
> group.
> 3) Leading question that can only be answered by Staff.
> 4) No. I would be in favor of marking the record as stale or switching the
> record to Simple and removing the POC.
> 5) Yes.
>
> Thanks,
>
> Kevin Blumberg
>
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew
> Dul
> Sent: Tuesday, February 14, 2017 9:40 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect POC
> Validation Requirement
>
> There has been some good discussion about this draft.
>
> At this time, it seems like perhaps there is disagreement within the
> community on the purpose and use of reassignment records.  As we have gone
> past IPv4 run-out, perhaps now is the time to consider if reassignment
> records provide the same level of value to the Internet community that they
> used to provide.  Doing reassignments was one of the primary ways that a
> service provider showed utilization to ARIN.  This could also be done by
> having an organization share these records directly with ARIN during a
> resource request.
>
> I'd like to throw out a few open ended questions that perhaps will guide
> the AC as it considers this draft:
>
> 1. Do you think reassignment records provide value to the Internet
> community from an operational perspective?  Do they provide the same value
> if they are not accurate?  At what point does the "record set" as a whole
> become invaluable because the data in the records isn't representative of
> current reassignments?
>
> 2. Who do you think should be responsible for ensuring that resource
> records are accurate?  The organization doing the reassignment?  ARIN?
> Someone else?
>
> 3. Given we are past IPv4 run-out, do reassignment records provide the
> same value to ARIN for the purposes of determining utilization?  Should
> other methods be used to determine utilization going forward?
>
> 4. Would you support the concept of removing reassignment records for
> which a POC has not been validated after a certain period of time?  1
> year?  2 years?  x years?
>
> 5. Would you support the idea that a new reassignment could not be added
> to the database without the approval of the POC who is receiving the
> resource by reassignment?
>
> Thanks for your input
>
> Andrew
>
>
>
> On 12/20/2016 10:09 AM, ARIN wrote:
> >
> >
> > ##########
> >
> > ARIN-2016-8: Removal of Indirect POC Validation Requirement
> >
> > Problem Statement:
> >
> > There are over 600,000 POCs registered in Whois that are only
> > associated with indirect assignments (reassignments) and indirect
> > allocations (reallocations). NRPM 3.6 requires ARIN to contact all
> > 600,000+ of these every year to validate the POC information. This is
> > problematic for a few reasons:
> >
> > 1) ARIN does not have a business relationships with these POCs. By
> > conducting POC validation via email, ARIN is sending Unsolicited
> > Commercial Emails. Further, because of NRPM 3.6.1, ARIN cannot offer
> > an opt-out mechanism. Finally, ARIN's resultant listing on anti-spam
> > lists causes unacceptable damage to ARIN's ability to conduct ordinary
> > business over email
> >
> > 2) ARIN has previously reported that POC validation to reassignments
> > causes tremendous work for the staff. It receives many angry phone
> > calls and emails about the POC validation process. I believe the ARIN
> > staff should be focused on POC validation efforts for directly issued
> > resources, as that has more value to internet operations and law
> > enforcement than end-user POC information.
> >
> > Policy statement:
> >
> > Replace the first sentence of 3.6.1:
> >
> > "During ARIN's annual Whois POC validation, an email will be sent to
> > every POC in the Whois database."
> >
> > with
> >
> > "During ARIN's annual Whois POC validation, an email will be sent to
> > every POC that is a contact for a direct assignment, direct
> > allocation, reallocation, and AS number, and their associated OrgIDs."
> >
> > 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.
> _______________________________________________
> 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.
>



-- 
_______________________________________________________
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/20170216/ae86ecb7/attachment.htm>

From narten at us.ibm.com  Fri Feb 17 00:53:19 2017
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 17 Feb 2017 00:53:19 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201702170553.v1H5rJoX001449@rotala.raleigh.ibm.com>

Total of 12 messages in the last 7 days.
 
script run at: Fri Feb 17 00:53:18 EST 2017
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 25.00% |    3 | 32.54% |    91558 | kevinb at thewire.ca
 16.67% |    2 | 23.41% |    65865 | owen at delong.com
 16.67% |    2 | 20.10% |    56575 | jschiller at google.com
  8.33% |    1 |  9.18% |    25824 | scottleibrand at gmail.com
  8.33% |    1 |  4.76% |    13406 | rjletts at uw.edu
  8.33% |    1 |  3.99% |    11228 | andrew.dul at quark.net
  8.33% |    1 |  3.17% |     8912 | narten at us.ibm.com
  8.33% |    1 |  2.85% |     8030 | rbf+arin-ppml at panix.com
--------+------+--------+----------+------------------------
100.00% |   12 |100.00% |   281398 | Total



From info at arin.net  Tue Feb 21 10:57:48 2017
From: info at arin.net (ARIN)
Date: Tue, 21 Feb 2017 10:57:48 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - January 2017
Message-ID: <58AC637C.9060005@arin.net>

 > The AC has abandoned the following Draft Policy:
 >
 > Draft Policy ARIN-2016-7: Integration of Community Networks into 
existing ISP policy
 >
 > The AC provided the following statement:
 >
 > "The Advisory Council decided to abandon ARIN-2016-7: Integration of 
Community Networks into existing ISP policy, due to a lack of support. 
There was no feedback from any community network operators, and this 
proposal raises the question whether the community network policy is 
still necessary."
 >
 > Anyone dissatisfied with this decision may initiate a petition. The 
deadline to begin a petition will be five business days after the AC's 
draft meeting minutes are published.

The minutes from the ARIN Advisory Council's 27 January 2017 meeting 
have been published:
https://www.arin.net/about_us/ac/ac2017_0127.html

The petition deadline is 27 February 2017.

For more information on starting and participating in petitions, see PDP 
Petitions at: https://www.arin.net/policy/pdp_petitions.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)


From info at arin.net  Tue Feb 21 14:52:05 2017
From: info at arin.net (ARIN)
Date: Tue, 21 Feb 2017 14:52:05 -0500
Subject: [arin-ppml] NRPM 2017.1 - New Policies Implemented
In-Reply-To: <586EB97D.8030207@arin.net>
References: <586EB97D.8030207@arin.net>
Message-ID: <58AC9A65.1070102@arin.net>

On 19 December 2016, the Board of Trustees adopted the following 
Recommended Draft Policies:

ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
ARIN-2016-1: Reserved Pool Transfer Policy
ARIN-2016-2: Change timeframes for IPv4 requests to 24 months
ARIN-2016-4: Transfers for new entrants
ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
ARIN-2016-6: Eliminate HD-Ratio from NRPM

All aforementioned policies are now in effect, with the exception of 
ARIN-2016-2. This policy will be implemented no later than 19 June 2017 
in accordance with its Staff and Legal Review, which rated the policy's 
resource impact as moderate.

A new version of the ARIN Number Resource Policy Manual (NRPM) has been 
published to the ARIN website.

NRPM version 2017.1 is effective 21 February 2017 and supersedes the 
previous version.

The NRPM is available at:
https://www.arin.net/policy/nrpm.html

Board minutes are available at:
https://www.arin.net/about_us/bot/index.html

Draft policies and proposals are available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process (PDP) is available at:
https://www.arin.net/policy/pdp.html

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)


From info at arin.net  Tue Feb 21 14:55:24 2017
From: info at arin.net (ARIN)
Date: Tue, 21 Feb 2017 14:55:24 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - February 2017
Message-ID: <58AC9B2C.2050209@arin.net>

In accordance with the Policy Development Process (PDP), the Advisory 
Council (AC) met on 16 February 2017 and advanced the following to 
Recommended Draft Policy status (will be posted separately as such):

ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 
transfers

The AC advances Draft Policies to Recommended Draft Policy status once 
they have been fully developed and meet ARIN's Principles of Internet 
Number Resource Policy. Specifically, these principles are:

Enabling Fair and Impartial Number Resource Administration
Technically Sound
Supported by the Community

The AC is continuing to work on:

Draft Policy ARIN-2016-8: Removal of Indirect POC Validation Requirement
Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers

The PDP 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,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)


From info at arin.net  Tue Feb 21 14:57:56 2017
From: info at arin.net (ARIN)
Date: Tue, 21 Feb 2017 14:57:56 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-3: Alternative
 simplified criteria for justifying small IPv4 transfers
Message-ID: <58AC9BC4.3040804@arin.net>

On 16 February 2017 the ARIN Advisory Council (AC) advanced the 
following Draft Policy to Recommended Draft Policy status:

ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 
transfers

The text of the Recommended Draft Policy is below, and may also be found at:
https://www.arin.net/policy/proposals/2016_3.html

You are encouraged to discuss all Recommended Draft Policies on PPML
prior to their presentation at the next ARIN Public Policy Meeting (PPM) 
or Public Policy Consultation (PPC). PPML and PPC discussions are 
invaluable to the AC when determining community consensus.

The PDP 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,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)


Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria 
for justifying small IPv4 transfers

Version Date: 16 February 2017

AC's Statement of Conformance with ARIN's Principles of Internet Number 
Resource Policy

This proposal is technically sound and enables fair and impartial number 
policy by allowing transfers to specified recipients of blocks of a 
certain size to occur without a needs assessment performed by ARIN 
staff. The Staff and Legal Assessment raised no material issues, and 
there has been consistent support on both the mailing list and at the 
Dallas ARIN meeting for incorporating this mechanism into NRPM.

Problem Statement:

ARIN transfer policy currently inherits all its demonstrated need 
requirements for IPv4 transfers from NRPM sections 4. Because that 
section was written primarily to deal with free pool allocations, it is 
much more complicated than is really necessary for transfers.

This proposal allows organizations using 80% of their current space to 
double their current holdings via 8.3 or 8.4 specified transfers, up to 
a /16 equivalent.

Policy Statement:

Add a new section:

8.5.7 Alternative Additional IPv4 Address Block Criteria

In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional 
IPv4 address blocks by demonstrating 80% utilization of their currently 
allocated space. If they do so, they qualify to receive one or more 
transfers up to the total size of their current ARIN IPv4 address 
holdings, with a maximum size of /16.

An organization may qualify via 8.5.7 for a total of a /16 equivalent in 
any 6 month period.


From owen at delong.com  Tue Feb 21 19:02:42 2017
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Feb 2017 16:02:42 -0800
Subject: [arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect POC
 Validation Requirement
In-Reply-To: <842b9da9-8d5d-93b7-5364-dd95fe719c9e@quark.net>
References: <585973ED.9090606@arin.net>
 <842b9da9-8d5d-93b7-5364-dd95fe719c9e@quark.net>
Message-ID: <F6917761-E892-4E04-9EAD-D73ECCC523EE@delong.com>


> On Feb 14, 2017, at 18:40 , Andrew Dul <andrew.dul at quark.net> wrote:
> 
> There has been some good discussion about this draft. 
> 
> At this time, it seems like perhaps there is disagreement within the
> community on the purpose and use of reassignment records.  As we have
> gone past IPv4 run-out, perhaps now is the time to consider if
> reassignment records provide the same level of value to the Internet
> community that they used to provide.  Doing reassignments was one of the
> primary ways that a service provider showed utilization to ARIN.  This
> could also be done by having an organization share these records
> directly with ARIN during a resource request.
> 
> I'd like to throw out a few open ended questions that perhaps will guide
> the AC as it considers this draft:
> 
> 1. Do you think reassignment records provide value to the Internet
> community from an operational perspective?  Do they provide the same
> value if they are not accurate?  At what point does the "record set" as
> a whole become invaluable because the data in the records isn't
> representative of current reassignments?

1a) Yes.
1b) Somewhat less than if they are accurate, but there?s a lot of questions
	of degree here and the level of inaccuracy that can be tolerated while
	still providing value varies greatly with the perspective of the
	particular consumer of the data.
> 
> 2. Who do you think should be responsible for ensuring that resource
> records are accurate?  The organization doing the reassignment?  ARIN? 
> Someone else?

I think this is a shared responsibility. I think that the organization
receiving the resources from ARIN has primary responsibility. I think
ARIN has a role as auditor. I think that the organization using the
resources should also have some responsibility/accountability here in
the case of delegated resources (reassignment/reallocation/etc.)

> 
> 3. Given we are past IPv4 run-out, do reassignment records provide the
> same value to ARIN for the purposes of determining utilization?  Should
> other methods be used to determine utilization going forward?

3a: Yes.
3b: Such as? It is hard to evaluate alternatives relative to the current
system when no alternatives have yet been proposed.


> 
> 4. Would you support the concept of removing reassignment records for
> which a POC has not been validated after a certain period of time?  1
> year?  2 years?  x years?

No. The records should remain, but should be labeled as ?POC INVALID?.

I would support terminating RDNS services after a notice period for all
records. In the case of reassignment/reallocation records, I would require
that the notification of pending termination be sent not only to the resource
holder of record, but also to the parent LIR in question and the direct
ARIN recipient in the chain.

> 
> 5. Would you support the idea that a new reassignment could not be added
> to the database without the approval of the POC who is receiving the
> resource by reassignment?

YES YES YES. Further, I think that it should be somehow possible to register
an ORG->{DOMAIN,?} map using some mechanism by which ARIN can validate that
the DOMAIN in question legitimately belongs to ORG. At that point, it should
be possible for the ORG to register a POC MANAGEMENT contact who has the
authority to approve or deny ALL POC requests involving user@{DOMAIN} emails
where the DOMAIN is one of the ORG?s registered DOMAINs.

Owen

> 
> Thanks for your input
> 
> Andrew
> 
> 
> 
> On 12/20/2016 10:09 AM, ARIN wrote:
>> 
>> 
>> ##########
>> 
>> ARIN-2016-8: Removal of Indirect POC Validation Requirement
>> 
>> Problem Statement:
>> 
>> There are over 600,000 POCs registered in Whois that are only
>> associated with indirect assignments (reassignments) and indirect
>> allocations (reallocations). NRPM 3.6 requires ARIN to contact all
>> 600,000+ of these every year to validate the POC information. This is
>> problematic for a few reasons:
>> 
>> 1) ARIN does not have a business relationships with these POCs. By
>> conducting POC validation via email, ARIN is sending Unsolicited
>> Commercial Emails. Further, because of NRPM 3.6.1, ARIN cannot offer
>> an opt-out mechanism. Finally, ARIN's resultant listing on anti-spam
>> lists causes unacceptable damage to ARIN's ability to conduct ordinary
>> business over email
>> 
>> 2) ARIN has previously reported that POC validation to reassignments
>> causes tremendous work for the staff. It receives many angry phone
>> calls and emails about the POC validation process. I believe the ARIN
>> staff should be focused on POC validation efforts for directly issued
>> resources, as that has more value to internet operations and law
>> enforcement than end-user POC information.
>> 
>> Policy statement:
>> 
>> Replace the first sentence of 3.6.1:
>> 
>> "During ARIN's annual Whois POC validation, an email will be sent to
>> every POC in the Whois database."
>> 
>> with
>> 
>> "During ARIN's annual Whois POC validation, an email will be sent to
>> every POC that is a contact for a direct assignment, direct
>> allocation, reallocation, and AS number, and their associated OrgIDs."
>> 
>> 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.



From jschiller at google.com  Wed Feb 22 13:48:09 2017
From: jschiller at google.com (Jason Schiller)
Date: Wed, 22 Feb 2017 13:48:09 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-3: Alternative
 simplified criteria for justifying small IPv4 transfers
In-Reply-To: <58AC9BC4.3040804@arin.net>
References: <58AC9BC4.3040804@arin.net>
Message-ID: <CAC4yj2VQRoes5qq_GY5V+Oa_09rZ=9j_ZmGfSWOJB6fGAtO2rg@mail.gmail.com>

I got the impression from Scott that alternate text was more clear and
preferred.
(note I'm not advocating for it, I believe it has no impact on
implementation).

8.5.7 Alternative Additional IPv4 Address Block Criteria

In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
address blocks by demonstrating 80% utilization of their currently
allocated space. If they do so, they are pre-authorized for a two year
window to receive one or more transfers up to the total size of their
current ARIN IPv4 address holdings, with a maximum size of /16.

An organization may qualify via 8.5.7 for a total of a /16 equivalent in
any 6 month period.

___Jason

On Tue, Feb 21, 2017 at 2:57 PM, ARIN <info at arin.net> wrote:

> On 16 February 2017 the ARIN Advisory Council (AC) advanced the following
> Draft Policy to Recommended Draft Policy status:
>
> ARIN-2016-3: Alternative simplified criteria for justifying small IPv4
> transfers
>
> The text of the Recommended Draft Policy is below, and may also be found
> at:
> https://www.arin.net/policy/proposals/2016_3.html
>
> You are encouraged to discuss all Recommended Draft Policies on PPML
> prior to their presentation at the next ARIN Public Policy Meeting (PPM)
> or Public Policy Consultation (PPC). PPML and PPC discussions are
> invaluable to the AC when determining community consensus.
>
> The PDP 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,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
> Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria for
> justifying small IPv4 transfers
>
> Version Date: 16 February 2017
>
> AC's Statement of Conformance with ARIN's Principles of Internet Number
> Resource Policy
>
> This proposal is technically sound and enables fair and impartial number
> policy by allowing transfers to specified recipients of blocks of a certain
> size to occur without a needs assessment performed by ARIN staff. The Staff
> and Legal Assessment raised no material issues, and there has been
> consistent support on both the mailing list and at the Dallas ARIN meeting
> for incorporating this mechanism into NRPM.
>
> Problem Statement:
>
> ARIN transfer policy currently inherits all its demonstrated need
> requirements for IPv4 transfers from NRPM sections 4. Because that section
> was written primarily to deal with free pool allocations, it is much more
> complicated than is really necessary for transfers.
>
> This proposal allows organizations using 80% of their current space to
> double their current holdings via 8.3 or 8.4 specified transfers, up to a
> /16 equivalent.
>
> Policy Statement:
>
> Add a new section:
>
> 8.5.7 Alternative Additional IPv4 Address Block Criteria
>
> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
> address blocks by demonstrating 80% utilization of their currently
> allocated space. If they do so, they qualify to receive one or more
> transfers up to the total size of their current ARIN IPv4 address holdings,
> with a maximum size of /16.
>
> An organization may qualify via 8.5.7 for a total of a /16 equivalent in
> any 6 month period.
> _______________________________________________
> 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.
>



-- 
_______________________________________________________
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/20170222/acceb513/attachment.htm>

From owen at delong.com  Wed Feb 22 14:15:42 2017
From: owen at delong.com (Owen DeLong)
Date: Wed, 22 Feb 2017 11:15:42 -0800
Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-3: Alternative
 simplified criteria for justifying small IPv4 transfers
In-Reply-To: <CAC4yj2VQRoes5qq_GY5V+Oa_09rZ=9j_ZmGfSWOJB6fGAtO2rg@mail.gmail.com>
References: <58AC9BC4.3040804@arin.net>
 <CAC4yj2VQRoes5qq_GY5V+Oa_09rZ=9j_ZmGfSWOJB6fGAtO2rg@mail.gmail.com>
Message-ID: <6C3DCB05-5F93-4A04-8CE7-59F1D4FCB36B@delong.com>

I disagree? First, I think it?s actually harder to understand. Second, I think it is a bad idea to create multiple specifications or specification points for the pre-authorization window because it creates a potential for accidental desynchronization in future policy efforts.

Owen

> On Feb 22, 2017, at 10:48 , Jason Schiller <jschiller at google.com> wrote:
> 
> I got the impression from Scott that alternate text was more clear and preferred.
> (note I'm not advocating for it, I believe it has no impact on implementation).
> 
> 8.5.7 Alternative Additional IPv4 Address Block Criteria
> 
> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 address blocks by demonstrating 80% utilization of their currently allocated space. If they do so, they are pre-authorized for a two year window to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16.
> 
> An organization may qualify via 8.5.7 for a total of a /16 equivalent in any 6 month period.
> 
> ___Jason
> 
> On Tue, Feb 21, 2017 at 2:57 PM, ARIN <info at arin.net <mailto:info at arin.net>> wrote:
> On 16 February 2017 the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status:
> 
> ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers
> 
> The text of the Recommended Draft Policy is below, and may also be found at:
> https://www.arin.net/policy/proposals/2016_3.html <https://www.arin.net/policy/proposals/2016_3.html>
> 
> You are encouraged to discuss all Recommended Draft Policies on PPML
> prior to their presentation at the next ARIN Public Policy Meeting (PPM) or Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus.
> 
> The PDP can be found at:
> https://www.arin.net/policy/pdp.html <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 <https://www.arin.net/policy/proposals/index.html>
> 
> Regards,
> 
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers
> 
> Version Date: 16 February 2017
> 
> AC's Statement of Conformance with ARIN's Principles of Internet Number Resource Policy
> 
> This proposal is technically sound and enables fair and impartial number policy by allowing transfers to specified recipients of blocks of a certain size to occur without a needs assessment performed by ARIN staff. The Staff and Legal Assessment raised no material issues, and there has been consistent support on both the mailing list and at the Dallas ARIN meeting for incorporating this mechanism into NRPM.
> 
> Problem Statement:
> 
> ARIN transfer policy currently inherits all its demonstrated need requirements for IPv4 transfers from NRPM sections 4. Because that section was written primarily to deal with free pool allocations, it is much more complicated than is really necessary for transfers.
> 
> This proposal allows organizations using 80% of their current space to double their current holdings via 8.3 or 8.4 specified transfers, up to a /16 equivalent.
> 
> Policy Statement:
> 
> Add a new section:
> 
> 8.5.7 Alternative Additional IPv4 Address Block Criteria
> 
> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 address blocks by demonstrating 80% utilization of their currently allocated space. If they do so, they qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16.
> 
> An organization may qualify via 8.5.7 for a total of a /16 equivalent in any 6 month period.
> _______________________________________________
> 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 <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
> 
> 
> 
> -- 
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com <mailto: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.

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

From jschiller at google.com  Wed Feb 22 15:00:52 2017
From: jschiller at google.com (Jason Schiller)
Date: Wed, 22 Feb 2017 15:00:52 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-3: Alternative
 simplified criteria for justifying small IPv4 transfers
In-Reply-To: <6C3DCB05-5F93-4A04-8CE7-59F1D4FCB36B@delong.com>
References: <58AC9BC4.3040804@arin.net>
 <CAC4yj2VQRoes5qq_GY5V+Oa_09rZ=9j_ZmGfSWOJB6fGAtO2rg@mail.gmail.com>
 <6C3DCB05-5F93-4A04-8CE7-59F1D4FCB36B@delong.com>
Message-ID: <CAC4yj2XPnx9D4PpxAVwR7qsh1aoW=F9+rzd9PJvRsNwwJjvDfg@mail.gmail.com>

Owen,

Just to be clear.  You think the text as written is better, more
understandable, and clearer, but you believe it will still operate the same
way regardless of the text, namely:

Once approved for a certain size block, you can complete multiple transfers
that add up to that size within a two year window.

___Jason

On Wed, Feb 22, 2017 at 2:15 PM, Owen DeLong <owen at delong.com> wrote:

> I disagree? First, I think it?s actually harder to understand. Second, I
> think it is a bad idea to create multiple specifications or specification
> points for the pre-authorization window because it creates a potential for
> accidental desynchronization in future policy efforts.
>
> Owen
>
> On Feb 22, 2017, at 10:48 , Jason Schiller <jschiller at google.com> wrote:
>
> I got the impression from Scott that alternate text was more clear and
> preferred.
> (note I'm not advocating for it, I believe it has no impact on
> implementation).
>
> 8.5.7 Alternative Additional IPv4 Address Block Criteria
>
> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
> address blocks by demonstrating 80% utilization of their currently
> allocated space. If they do so, they are pre-authorized for a two year
> window to receive one or more transfers up to the total size of their
> current ARIN IPv4 address holdings, with a maximum size of /16.
>
> An organization may qualify via 8.5.7 for a total of a /16 equivalent in
> any 6 month period.
>
> ___Jason
>
> On Tue, Feb 21, 2017 at 2:57 PM, ARIN <info at arin.net> wrote:
>
>> On 16 February 2017 the ARIN Advisory Council (AC) advanced the following
>> Draft Policy to Recommended Draft Policy status:
>>
>> ARIN-2016-3: Alternative simplified criteria for justifying small IPv4
>> transfers
>>
>> The text of the Recommended Draft Policy is below, and may also be found
>> at:
>> https://www.arin.net/policy/proposals/2016_3.html
>>
>> You are encouraged to discuss all Recommended Draft Policies on PPML
>> prior to their presentation at the next ARIN Public Policy Meeting (PPM)
>> or Public Policy Consultation (PPC). PPML and PPC discussions are
>> invaluable to the AC when determining community consensus.
>>
>> The PDP 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,
>>
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria for
>> justifying small IPv4 transfers
>>
>> Version Date: 16 February 2017
>>
>> AC's Statement of Conformance with ARIN's Principles of Internet Number
>> Resource Policy
>>
>> This proposal is technically sound and enables fair and impartial number
>> policy by allowing transfers to specified recipients of blocks of a certain
>> size to occur without a needs assessment performed by ARIN staff. The Staff
>> and Legal Assessment raised no material issues, and there has been
>> consistent support on both the mailing list and at the Dallas ARIN meeting
>> for incorporating this mechanism into NRPM.
>>
>> Problem Statement:
>>
>> ARIN transfer policy currently inherits all its demonstrated need
>> requirements for IPv4 transfers from NRPM sections 4. Because that section
>> was written primarily to deal with free pool allocations, it is much more
>> complicated than is really necessary for transfers.
>>
>> This proposal allows organizations using 80% of their current space to
>> double their current holdings via 8.3 or 8.4 specified transfers, up to a
>> /16 equivalent.
>>
>> Policy Statement:
>>
>> Add a new section:
>>
>> 8.5.7 Alternative Additional IPv4 Address Block Criteria
>>
>> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
>> address blocks by demonstrating 80% utilization of their currently
>> allocated space. If they do so, they qualify to receive one or more
>> transfers up to the total size of their current ARIN IPv4 address holdings,
>> with a maximum size of /16.
>>
>> An organization may qualify via 8.5.7 for a total of a /16 equivalent in
>> any 6 month period.
>> _______________________________________________
>> 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.
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-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.
>
>
>


-- 
_______________________________________________________
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/20170222/16985a88/attachment.htm>

From info at arin.net  Thu Feb 23 16:16:28 2017
From: info at arin.net (ARIN)
Date: Thu, 23 Feb 2017 16:16:28 -0500
Subject: [arin-ppml] NRPM 2017.2 - New Policy Implemented
Message-ID: <58AF512C.2020102@arin.net>

On 21 February 2017, ARIN implemented several policies into the Number 
Resource Policy Manual (NRPM) that had been recently adopted by the 
Board of Trustees. Since that time, an oversight has been noted in the 
implementation of ARIN-2016-4. Specifically, language from sections 
4.2.2 and 4.3.3 had not been removed, as was specified by the adopted 
policy. As such, a corrected NRPM has been published to the ARIN website.

NRPM version 2017.2 is effective 23 February 2017 and supersedes the 
previous version.

The NRPM is available at:
https://www.arin.net/policy/nrpm.html

Board minutes are available at:
https://www.arin.net/about_us/bot/index.html

Draft policies and proposals are available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process (PDP) is available at:
https://www.arin.net/policy/pdp.html

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)


From narten at us.ibm.com  Fri Feb 24 00:53:24 2017
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 24 Feb 2017 00:53:24 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201702240553.v1O5rOrt011566@rotala.raleigh.ibm.com>

Total of 10 messages in the last 7 days.
 
script run at: Fri Feb 24 00:53:19 EST 2017
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 50.00% |    5 | 29.71% |    33292 | info at arin.net
 20.00% |    2 | 34.59% |    38766 | jschiller at google.com
 20.00% |    2 | 27.86% |    31220 | owen at delong.com
 10.00% |    1 |  7.85% |     8795 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |   10 |100.00% |   112073 | Total