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, <[email protected]> wrote:
> Send ARIN-PPML mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: Owen DeLong <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying > MinimumAllocations and Assignments > Message-ID: > <CAC4yj2VSx2sXK5Myi65+pDT8uFpoASvQw= > [email protected]> > 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 <[email protected]> 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 <[email protected] > > > > 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:[email protected]] > > > Sent: Wednesday, September 3, 2014 1:05 PM > > > To: Steven Ryerse > > > Cc: Gary Buhrmaster; ARIN; [email protected] > > > 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 < > [email protected]> > > 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: [email protected] [mailto:[email protected]] > > >> On Behalf Of Gary Buhrmaster > > >> Sent: Wednesday, July 23, 2014 12:59 PM > > >> To: ARIN > > >> Cc: [email protected] > > >> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-18: Simplifying > > >> MinimumAllocations and Assignments > > >> > > >> On Wed, Jul 23, 2014 at 2:58 PM, ARIN <[email protected]> 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 ([email protected]). > > >> Unsubscribe or manage your mailing list subscription at: > > >> http://lists.arin.net/mailman/listinfo/arin-ppml > > >> Please contact [email protected] if you experience any issues. > > >> _______________________________________________ > > >> PPML > > >> You are receiving this message because you are subscribed to the ARIN > > >> Public Policy Mailing List ([email protected]). > > >> Unsubscribe or manage your mailing list subscription at: > > >> http://lists.arin.net/mailman/listinfo/arin-ppml > > >> Please contact [email protected] if you experience any issues. > > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List ([email protected]). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact [email protected] if you experience any issues. > > > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|[email protected]|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 > [email protected] > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 111, Issue 10 > ****************************************** >
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
