Obviously Milton doesn’t share that opinion per his comments below and neither 
do I.

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

[Description: Description: Eclipse Networks Logo_small.png]℠ Eclipse Networks, 
Inc.
        Conquering Complex Networks℠

From: Owen DeLong [mailto:o...@delong.com]
Sent: Tuesday, March 1, 2016 5:00 PM
To: Steven Ryerse <srye...@eclipse-networks.com>
Cc: Mueller, Milton L <mil...@gatech.edu>; Jason Schiller 
<jschil...@google.com>; ARIN PPML <arin-ppml@arin.net>
Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based 
evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks

This policy is an example of rearranging the IPv4 deck chairs.

So your statement is not consistent with your support of the policy.

Owen

On Feb 18, 2016, at 20:07 , Steven Ryerse 
<srye...@eclipse-networks.com<mailto:srye...@eclipse-networks.com>> wrote:

Milton is right!  We are one of those small ISPs and the deck is stacked 
against us on purpose by larger organizations.  It is time to move on and stop 
arranging the deck chairs on the IPv4 Titanic like other regions have.  It’s 
2016 not 2001.  I support this policy!


Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
www.eclipse-networks.com<http://www.eclipse-networks.com/>
770.656.1460 - Cell
770.399.9099- Office

<image001.jpg>℠ Eclipse Networks, Inc.
        Conquering Complex Networks℠

From: arin-ppml-boun...@arin.net<mailto:arin-ppml-boun...@arin.net> 
[mailto:arin-ppml-boun...@arin.net] On Behalf Of Mueller, Milton L
Sent: Thursday, February 18, 2016 10:47 PM
To: Jason Schiller <jschil...@google.com<mailto:jschil...@google.com>>
Cc: ARIN PPML <arin-ppml@arin.net<mailto:arin-ppml@arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based 
evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks


Really. Am I going to have to be the first to point out the irony of Google 
employees complaining that companies with "deep pockets" and "the most 
profitable services" will dominate the address market if we make minor 
relaxations of need assessments?

What's wrong with this picture? Think, folks.

Isn't it obvious that companies like Google are in a very good position to get 
the addresses they want - via less than transparent market mechanisms such as 
options contracts and acquisitions? And isn't it possible that they might be 
trying to prevent smaller companies from participating in the market by 
throwing up artificial barriers?

All this talk of "fairness" overlooks the fact that it's more fair to have 
simple, transparent bidding and less bureaucracy. Smaller bidders can easily 
afford smaller chunks of numbers, and they benefit from the reduced 
administrative burden and delays associated with pointless and restrictive 
needs assessments. When I hear smaller ISPs who need addresses making Jason's 
arguments, I might take them seriously.  Until then, no.

--MM

From: arin-ppml-boun...@arin.net<mailto:arin-ppml-boun...@arin.net> 
<arin-ppml-boun...@arin.net<mailto:arin-ppml-boun...@arin.net>> on behalf of 
Jason Schiller <jschil...@google.com<mailto:jschil...@google.com>>
Sent: Thursday, February 18, 2016 3:11 PM
To: Vaughn Thurman - Swift Systems
Cc: ARIN PPML
Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based 
evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks

+1 to what MCTim, Owen, and Vaughn said.

In general I oppose transfers with no need.

If there are "networks in need of additional IPv4 addresses", surely they 
should be able to show this, in accord with long standing practice.

I'd rather us not move to a situation which enables/encourages speculation and 
profit taking (or rent-seeking if you will) in re: IP resource distribution.

I'd also rather not encourage one competitor in a business segment to be able 
to better stockpile addresses and for that to become a competitive advantage
against other providers in the space.  Additionally if this is done in a wide 
enough scale it can sufficiently lengthen wide spread IPv6 adoption.

This policy would also allow for companies with the deepest pockets and the 
most profitable services to concentrate IPv4 space.  I'm not sure that is more 
"fair"
than the pre-existing framework for "fair".

__Jason



On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems 
<vau...@swiftsystems.com<mailto:vau...@swiftsystems.com>> wrote:
+1

Sent from my mobile device, please forgive brevity and typos.

On Feb 18, 2016, at 2:16 PM, Owen DeLong 
<o...@delong.com<mailto:o...@delong.com>> wrote:
+1 — McTim said it very well.

Owen

On Feb 18, 2016, at 10:34 , McTim 
<dogwal...@gmail.com<mailto:dogwal...@gmail.com>> wrote:

I am opposed.

If there are "networks in need of additional IPv4 addresses", surely they 
should be able to show this, in accord with long standing practice.

I'd rather us not move to a situation which enables/encourages speculation and 
profit taking (or rent-seeking if you will) in re: IP resource distribution.

Regards,

McTim


On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer 
<lsaw...@gci.com<mailto:lsaw...@gci.com>> wrote:
Good afternoon -

  Based on feedback from Montreal as well as internal discussions, I've 
reworked this policy.
AC members and ARIN staff are looking for additional feedback, as well as your 
position in terms
of supporting or opposing this draft policy.

  We'll be discussing this policy, as well as any feedback provided on this 
week's AC teleconference,
so I'm very appreciative of your input.

Thanks,

  Leif Sawyer
  Shepherd - ARIN-2015-9

NRPM section 8: https://www.arin.net/policy/nrpm.html#eight

Most current draft policy text follows:
--

Draft Policy ARIN-2015-9
    Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of 
IPv4 netblocks
Original Date: 23 September 2015
Updated: 16 February, 2016

Problem statement:
The current needs-based evaluation language in NRPM sections 8.2 and 8.3, 
regarding transfer of IPv4
netblocks from one organization to another, may cause a recipient organization 
to bypass the ARIN
registry entirely in order to secure the needed IPv4 netblocks in a more timely 
fashion directly from the
current holder. The result is that the data visible in ARIN registry may become 
more inaccurate over
time.

Policy statement:
This proposal eliminates all needs-based evaluation language for sections 8.2 
and 8.3, allowing
transfers to be reflected in the database as they occur following an agreement 
of transfer from the
resource provider to the recipient.

Section 8.1 Principles:
- Strike the fragment from the 3rd paragraph which reads
        ", based on justified need, "
so the resulting text reads
"Number resources are issued to organizations, not to individuals representing 
those organizations."
Section 8.2 Mergers and Acquisitions:
- Change the 4th bullet from:
"The resources to be transferred will be subject to ARIN policies."
to:
"The resources to be transferred will be subject to ARIN policies, excluding 
any policies related to needs-based justification."

- Strike the final paragraph which begins "In the event that number resources 
of the combined organizations are no longer justified under ARIN policy ..."

Section 8.3 Transfers between Specified Recipients within the ARIN Region:
- Change the first bullet under "Conditions on recipient of the transfer" from:
"The recipient must demonstrate the need for up to a 24-month supply of IP 
address resources under current ARIN policies and sign an RSA."
to:
"The recipient must sign an RSA."

- Change the 2nd bullet under "Conditions on recipient of the transfer" from:
"The resources to be transferred will be subject to ARIN policies."
to:
"The resources to be transferred will be subject to ARIN policies, excluding 
any policies related to needs-based justification."

Comments:
a. Timetable for implementation: Immediate
b. Anything else
As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and ARIN) 
have now been
exhausted, networks in need of additional IPv4 addresses have shifted away from 
the practice of
receiving them from the RIR's resource pool. Instead, networks in need are 
seeking out current holders
of IPv4 resources who are willing to transfer them in order to fulfill that 
need. Accordingly, the RIR's
primary responsibility vis-à-vis IPv4 netblock governance has shifted from 
"allocation" to ensuring an
accurate registry database.

The RIPE registry can be used as a reference of one which has evolved over the 
past couple years to
shift their focus away from conservation/allocation and towards database 
accuracy. IPv4 netblock
transfers within that RIR consist merely of validating authenticity of the 
parties requesting a transfer.
Provided the organizations meet the basic requirement of RIR membership, and 
that the transferring
organization has the valid authority to request the transfer, the transaction 
completes without any
"needs-based" review.

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



--
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A route 
indicates how we get there."  Jon Postel
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List 
(ARIN-PPML@arin.net<mailto:ARIN-PPML@arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net<mailto:i...@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@arin.net<mailto:ARIN-PPML@arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net<mailto:i...@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@arin.net<mailto:ARIN-PPML@arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net<mailto:i...@arin.net> if you experience any issues.



--
_______________________________________________________
Jason 
Schiller|NetOps|jschil...@google.com<mailto:jschil...@google.com>|571-266-0006

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

Reply via email to