[arin-ppml] Draft Policy ARIN-2014-18:

[Rudolph Daniel]

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> wrote:

> Send ARIN-PPML mailing list submissions to
>         arin-ppml at arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
>         arin-ppml-request at arin.net
>
> You can reach the person managing the list at
>         arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
>    1. Re: 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>
> To: Owen DeLong <owen at delong.com>
> Cc: "arin-ppml at arin.net" <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>
> 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> 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
> >
> > 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 - Cell
> > > 770.399.9099- Office
> > >
> > > ? Eclipse Networks, Inc.
> > >                     Conquering Complex Networks?
> > >
> > > -----Original Message-----
> > > From: Owen DeLong [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
> > > 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>
> > 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 - Cell
> > >> 770.399.9099- Office
> > >>
> > >> ? Eclipse Networks, Inc.
> > >>                    Conquering Complex Networks?
> > >>
> > >> -----Original Message-----
> > >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> > >> On Behalf Of Gary Buhrmaster
> > >> Sent: Wednesday, July 23, 2014 12:59 PM
> > >> To: ARIN
> > >> Cc: 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> 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).
> > >> 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: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20140903/caf8543b/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 111, Issue 10
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140904/66810a1f/attachment.htm>