[arin-ppml] Draft Policy ARIN-2014-18:
Steven Ryerse
SRyerse at eclipse-networks.com
Thu Sep 4 13:20:39 EDT 2014
Since the Minimum is being changed this month in policy to be a /24 in most cases, ARIN 2014-18 essentially boils down to an Org that is of a size that they need the Minimum allocation - thus a /24. I assume this would mostly be requested by smaller Orgs but there might be cases where a larger Org only needs a /24. Hope this info helps.
Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA 30338
770.656.1460 - Cell
770.399.9099- Office
[Description: Description: Eclipse Networks Logo_small.png]℠ Eclipse Networks, Inc.
Conquering Complex Networks℠
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Rudolph Daniel
Sent: Thursday, September 4, 2014 1:14 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-18:
Straight away, I would have a problem relating to this proposal when there is continual mention of small, medium and large without appropriate definition ...in fact, I am not sure that we can hinge a policy proposal on such an arbitrary measure.
RD
On Sep 3, 2014 8:18 PM, <arin-ppml-request at arin.net<mailto:arin-ppml-request at arin.net>> wrote:
Send ARIN-PPML mailing list submissions to
arin-ppml at arin.net<mailto:arin-ppml at arin.net>
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
arin-ppml-request at arin.net<mailto:arin-ppml-request at arin.net>
You can reach the person managing the list at
arin-ppml-owner at arin.net<mailto:arin-ppml-owner at arin.net>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Re: Draft Policy ARIN-2014-18: Simplifying MinimumAllocations
and Assignments (Jason Schiller)
----------------------------------------------------------------------
Message: 1
Date: Wed, 3 Sep 2014 20:17:18 -0400
From: Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>>
To: Owen DeLong <owen at delong.com<mailto:owen at delong.com>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying
MinimumAllocations and Assignments
Message-ID:
<CAC4yj2VSx2sXK5Myi65+pDT8uFpoASvQw=O0D-OQaM657iFkjQ at mail.gmail.com<mailto:O0D-OQaM657iFkjQ at mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"
Steven,
I didn't see a specific response to the specific question Owen asked.
"Is it your argument that anyone with a single host should be able to
obtain a /24 per year? If so, then we can agree to disagree and move on.
If not, where, between 1 and 63 do you think that bar should be set? You
clearly seem to think that 63 is too high.
"
Every keeps throwing around the term "small" but it is not clear what is
meant by it. Please define where is the bar for a small end-user and a
small ISP (end-user and ISP in the ARIN sense of if you get an assignment
to use in your own network, or an allocation to use in your own network,
and for your down stream customers).
If you claim of ARIN policy is unfair to small end-users and you mean small
to be an organization that does not have plans for 63 machines in 30 days
and 127 machines in 1 year, then yes, I agree the policy is unfair and
locks them out.
If you claim of ARIN policy is unfair to small ISPs and you mean small to
be an ISP that does not have a plan to 205 IP addresses within 90 days,
then yes, I agree the policy is unfair and locks them out.
But remember the ISP gets to count each IP in use on their own
infrastructure as used. They also get to count 100% of each subnet that is
re-allocated or re-assigned to each down stream customers if that customer
has demonstrated that they will be using more than 50% of their subnet.
Four routers that are cross-meshed (connected in a box with a cross inside)
using a /30 on each of the six point-to-point links and each with a /32
loopback would account for
4*1+6*4 = 28 IPs for infrastructure
Twelve static customers with 6 hosts each (+ router LAN address + network +
broadcast) is a /28 each
12*16=192
192 + 28 = 220 or 85.93% utilization of a /24.
--
If your claim is slightly larger ISPs (say one that has pre-orders for
customer subnets totaling up to a /20) are locked out because even though
they already have need, they cannot first get and put into service IPs from
their upstream (as the upstream is unwilling to re-allocate so many IPs),
and they can't actually deploy all these customers in 30 days and therefor
do not meet immediate need... Then I would suggest you look at
https://www.arin.net/policy/proposals/2014_20.html
One of the goals is to address the problem of ISP slow-start when they can
no longer get IPs from their upstream.
--
If you goal is to dole out all of the small fragments that are left, then
you might consider changing the policy to be implemented when the largest
block available from ARIN is a /24.
--
If you goal is to allow organizations with only a single host to get a /24,
you might consider not permitting them an additional /24 a year later,
unless they can demonstrate efficient use of what they already have.
I also suspect there will need to be some provision to avoid abuse from
people spinning up organizations just to get space that they only intend to
sell, or space that they want to stockpile for use more than two years from
now.
___Jason
On Wed, Sep 3, 2014 at 5:11 PM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:
> Steven,
>
> You are properly following the procedure just fine. Please don?t take my
> comments personally, they were not intended as any form of personal slight.
> This is the proper forum to effect policy change and I applaud your
> choosing to participate in the process and bringing a proposal to try and
> solve what you perceive as a problem.
>
> However, I believe that the policy you have proposed would be
> irresponsible for the reasons I outlined.
>
> I?m not sure what you mean about ?what goes on during the allocation
> process for medium and larger organizations?. You claim to be trying to
> help smaller organizations, so I?m not sure what you think is different for
> them than for smaller organizations when they apply.
>
> In my experience (and I have done applications for organizations of
> virtually every size category available), they are all treated exactly the
> same and held to the same standards for documentation, validation,
> verification, utilization, etc. Effective September 17 (or thereabouts)
> when ARIN implements the recently ratified policy change, the minimum size
> will be a /24. The requirement to get a /24 for an end user will be to show
> utilization of 63 addresses immediately and 127 addresses within 1 year.
> The requirement for an ISP to get a /24 will be to show efficient
> utilization of a /24 from an upstream provider or immediate need for a /24
> (I don?t know the exact minimum host quantity used by ARIN for this, but I
> have a hard time imagining how I could build anything I would call an ISP
> with downstream assignments that wouldn?t justify at least a /24).
>
> As such, I believe that any legitimate need for a /24 or more is well
> served by policy already adopted.
>
> Is it your argument that anyone with a single host should be able to
> obtain a /24 per year? If so, then we can agree to disagree and move on.
>
> If not, where, between 1 and 63 do you think that bar should be set? You
> clearly seem to think that 63 is too high.
>
> Owen
>
> On Sep 3, 2014, at 12:38 PM, Steven Ryerse <SRyerse at eclipse-networks.com<mailto:SRyerse at eclipse-networks.com>>
> wrote:
>
> > Owen, I appreciate the dialog but I think you are ignoring what goes on
> during the allocation process for medium and larger organizations. You and
> I disagree that the current policies are fair and I do not think I'm being
> irresponsible to try and correct that! I've been told this is the proper
> forum to effect policy change by you and others and I am trying to follow
> the change procedure as best I can.
> >
> > As I've noted before:
> >
> > When a medium or larger organization requests a medium or larger block
> they probably will come away from it with an allocation, possibly smaller
> than requested but they are likely to receive an allocation none the less.
> When a small organization requests the minimum block size and that request
> is refused because of policy, they get nothing at all and no offer of
> something smaller because there isn't anything smaller. So, no matter how
> you slice it, that is an un-even playing field - and it is arbitrary,
> unfair, and discriminatory against small organizations in favor of larger
> ones. I have been pointing this out for years and I've said it just about
> every way I know how. The have's get more and the have not's don't. It is
> time this gets corrected to level the playing field for all as that is
> ARINs Mission and raison d'etre.
> >
> > My proposal ARIN 2014-18 is specifically designed to rectify and level
> the playing field so that regardless of what size allocation was requested,
> a small organization can at least get the Minimum size block. This then
> makes it so the larger org gets what they requested or something smaller,
> and the medium size org gets what they requested or something smaller, and
> the smaller org gets what they requested or the current Minimum. This
> proposed policy Minimum allocation is limited to once per year per this
> policy proposal.
> >
> > As I said many times before the needs testing policies should be
> replaced by right-sizing policies, BUT, ARIN 2014-18 is only intended to
> correct the unfairness of current policies for allocations to smaller
> organizations and does not attempt to change any other aspect of the
> currently policies.
> >
> > Also, as there is a lot of policy talent in this community, I would
> welcome constructive comments and possible changes to this policy as long
> as they don't change the intended purpose of this policy proposal.
> >
> > Steven Ryerse
> > President
> > 100 Ashford Center North, Suite 110, Atlanta, GA 30338
> > 770.656.1460<tel:770.656.1460> - Cell
> > 770.399.9099<tel:770.399.9099>- Office
> >
> > ? Eclipse Networks, Inc.
> > Conquering Complex Networks?
> >
> > -----Original Message-----
> > From: Owen DeLong [mailto:owen at delong.com<mailto:owen at delong.com>]
> > Sent: Wednesday, September 3, 2014 1:05 PM
> > To: Steven Ryerse
> > Cc: Gary Buhrmaster; ARIN; arin-ppml at arin.net<mailto:arin-ppml at arin.net>
> > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying
> MinimumAllocations and Assignments
> >
> > Steven, many of your statements are patently false.
> >
> > First of all, the current allocation/assignment process is fair.
> Everyone is subject to the same policies and it is quite easy for small
> organizations to obtain IP space under the existing process. I have
> obtained legitimate assignments for organizations as small as a sole
> proprietorship with no employees and have obtained allocations for
> extremely small ISPs.
> >
> > I have yet to see an organization so small that they could not obtain
> addresses under current policy because of their size.
> >
> > Needs testing is not merely a vehicle to save the remaining free pool.
> If that were true, then we would not have subjected the transfer policies
> to needs testing. Further, I?m all for distributing the remaining IPv4 free
> pool to organizations with legitimate need as quickly as possible. I
> believe that the longer we have an IPv4 free pool at this point, the longer
> we will have to deal with the pain of this transition process and the
> longer people will continue to procrastinate the necessary move to IPv6. So
> if I truly believed that needs testing was really a vehicle to save the
> free pool, I would be leading the charge to eliminate needs testing.
> Instead, I?ve remained strongly opposed to eliminating needs basis from
> ARIN policy and preserved needs basis when I proposed a significant rewrite
> of the IPv6 allocation policy (which was adopted).
> >
> > I don?t believe any of Gary?s comments were at all related to
> organization size, so your retort to his kitchen comment seems non-sequiter.
> >
> > ARIN2014-18 is an irresponsible attempt to streamline the process of
> hoarding address space by creating multiple ORG-IDs and I cannot support it
> as such. ARIN2014-18 would not only affect the remaining free pool (which I
> doubt will be meaningful by the time any policy now being discussed could
> be implemented), but would also not only allow, but encourage an
> irresponsible fragmentation of address space for the purpose of monetary
> gains through specified transfers.
> >
> > Opposition to 2014-18 is not about discriminating against small
> organizations (anyone who has followed my involvement with ARIN or looks at
> my voting record would have a very hard time claiming I support such
> discrimination). While I don?t believe that the policy is intended to do
> what I have said above, nonetheless, the consequences described are, IMHO,
> the inevitable result should this policy be adopted and therefore, I oppose
> the policy as written.
> >
> > Owen
> >
> > On Sep 3, 2014, at 9:22 AM, Steven Ryerse <SRyerse at eclipse-networks.com<mailto:SRyerse at eclipse-networks.com>>
> wrote:
> >
> >> I've been on projects extensively the last month and a half and only
> now are getting back to this proposal. Gary, I take your comment below to
> mean that you are not in favor of making the allocation fair to small
> organizations. I think there has been a consensus building that it is more
> difficult for a small organization to get an allocation than a larger one,
> and I don't see anywhere in ARINs Mission that it is OK to discriminate
> against small organizations.
> >>
> >> I would also add that needs testing is really a vehicle to somehow save
> the remaining ipv4 pool we all know the only way to stop that is to stop
> allocating altogether which of course isn't ARINs mission. As to your
> comment about being in the Kitchen I would ask you where in ARINs Mission
> does it say that it is OK to discriminate based on an Organizations size.
> >>
> >> ARIN 2014-18 is a reasonable attempt to rectify that and I would ask
> for this communities support. As the Minimum was just reduced to a /24, it
> is really going to save the remaining ipv4 pool to stop small organizations
> from getting a /24? When do we stop rearranging deck chairs on the ipv4
> Titanic that can't be saved?
> >>
> >> Steven Ryerse
> >> President
> >> 100 Ashford Center North, Suite 110, Atlanta, GA 30338
> >> 770.656.1460<tel:770.656.1460> - Cell
> >> 770.399.9099<tel:770.399.9099>- Office
> >>
> >> ? Eclipse Networks, Inc.
> >> Conquering Complex Networks?
> >>
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>]
> >> On Behalf Of Gary Buhrmaster
> >> Sent: Wednesday, July 23, 2014 12:59 PM
> >> To: ARIN
> >> Cc: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
> >> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying
> >> MinimumAllocations and Assignments
> >>
> >> On Wed, Jul 23, 2014 at 2:58 PM, ARIN <info at arin.net<mailto:info at arin.net>> wrote:
> >>> On 17 July 2014 the ARIN Advisory Council (AC) accepted
> >>> "ARIN-prop-210 Simplifying Minimum Allocations and Assignments" as a
> Draft Policy.
> >>>
> >>> Draft Policy ARIN-2014-18 is below and can be found at:
> >>> https://www.arin.net/policy/proposals/2014_18.html
> >>
> >> Opposed as written. I believe that continued needs testing is an
> important criteria for receiving resources, and this proposal would
> eliminate justified needs testing.
> >>
> >> As to the costs of doing business, well, while I can understand the
> >> those seeking resources may not have properly planned for the costs of
> >> their start up and/or expansion, that is a failure of the requesting
> >> organization(s) leaders and their staff, and requesting relief from
> ARIN policy because of that failure is not an appropriate response. If it
> gets too hot in the kitchen, do not be a cook.
> >> _______________________________________________
> >> 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-266-0006>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140903/caf8543b/attachment.html>
------------------------------
_______________________________________________
ARIN-PPML mailing list
ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 111, Issue 10
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140904/b127a839/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: image001.jpg
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140904/b127a839/attachment.jpg>
More information about the ARIN-PPML
mailing list