Point is that the current proposal which just concluded last call definitely gets it better than the current circumstance. If the community decides to develop your proposal, we can always add the pieces needed to integrate it.
In short, we can get 2014-13 right and right now, and we can, if there is consensus, get your proposal right later. Putting 2014-13 in place as is does nothing to harm that process and it provides much needed relief to a number of organizations sooner rather than later. I'm at a bit of a disadvantage in commenting further as I am not at liberty to disclose the AC actions today. However, irrespective of what actually happened, I think it is a good idea not to delay 2014-13 for the sake of possibly improving how it integrates with your proposal. Instead, we can make all the necessary changes under the banner of your proposal, if it gains traction with the community. In short, it's no less right to adopt 2014-13 as is and just make the changes in your proposal later. There's absolutely no harm and significant benefit. Owen On Jul 17, 2014, at 12:12 , Steven Ryerse <[email protected]> wrote: > Owen, I think you usually advocate getting it right instead of getting it > fast and I would prefer to get it right on this one for sure. Maybe it would > be a good idea to solicit input now from this Community for a change in > 2014-13 to a Range vs. just a /24. My two cents. > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099- Office > > <image001.jpg>℠ Eclipse Networks, Inc. > Conquering Complex Networks℠ > > From: Owen DeLong [mailto:[email protected]] > Sent: Thursday, July 17, 2014 5:27 AM > To: Steven Ryerse > Cc: John Curran; Kevin Blumberg; [email protected] > Subject: Re: [arin-ppml] ARIN 2014-13 > > Member of the AC hat on (though not speaking on behalf of the AC): > > If this proposal gains traction and 2014-13 is adopted, the AC and the > community can make the necessary adjustments to it in light of 2014-13 if > 2014-13 is adopted. > > Changing 2014-13 so substantially at this time would only serve to delay its > potential implementation without actually benefiting this proposal. If such a > range is desired to go with this proposal, the necessary changes can be added > to this proposal without significant difficulty. > > AC hat off -- Speaking only as myself and a member of the community at large: > > I fail to see the logic in establishing a "minimum range". A minimum is just > that... A minimum. Anything larger than the minimum is not the minimum, so a > minimum range is a minimum and some other numbers that happen to be larger > than the minimum. > > Even if 2014-13 were somehow modified and we were able to work past the > lexical cognitive dissonance inherent in the idea of a "minimum range", I > don't see how this proposal would work without significant modification to > deal with the issue of how a request is mapped to a particular "minimum" > within the "minimum range" that applies by as yet unspecified criteria. > > Perhaps if you could clarify how you see this idea of a "minimum range" > working and how it could actually be implemented or what it is you hope > having such a thing would provide that the existing policy and/or 2014-13 > does not provide, it would be helpful. > > Owen > > On Jul 13, 2014, at 10:39 , Steven Ryerse <[email protected]> > wrote: > > > Its more complicated than that. I’ve submitted the proposed policy change > below to the AC. Obviously at this early stage I don’t know if the Community > will accept this or not but 2014-13 complicates this proposal. That is part > of the reason why I suggested changing 2014-13 to specify a range rather than > a fixed allocation. I would be fine with having this proposal included with > 2014-13 if the AC though that made sense. Otherwise it can remain separate. > > > TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0 > > 1. Policy Proposal Name: Simplifying Minimum Allocations and Assignments > > 2. Proposal Originator > a. name: Steven Ryerse > b. email: [email protected] > c. telephone: 770.656.1460 (c) 770.399.9099 (w) > d. organization: Eclipse Networks Inc. > > 3. Date: 06-JUN-2014 > > 4. Problem Statement: > > New and small organizations are having a difficult time receiving > resource allocations from ARIN because of the economic, administrative > and time burdens of making their way through ARIN's needs testing > process. For small allocations, the burdens of needs testing may > exceed the value of the resources, or may deter small, less > well-funded organizations' ability to receive an allocation from ARIN. > As ARIN was created to provide Internet resources to ALL organizations > within its geographic territory, this disparity in the Policy Manual > needs to be addressed. The problem can be remedied by removing needs > testing for any organization that applies to receive the current > minimum block size allocation. > > > 5. Policy statement: > > "A Minimum IP allocation size(s) has been defined per Section 4 of > the ARIN Number Resource Policy Manual. Regardless of any policy > requirement(s) defined in any other active Section of the Policy > Manual, all organizations may apply and shall automatically qualify > for the current Minimum IP Block Allocation upon completing the > normal administrative application process and fee requirements, and > all organizations shall be eligible for such an allocation once > every 12 months. Where this is in conflict with any other Section > in the Policy Manual, this Section shall be controlling." > > > 6. Comments: > a. Timetable for implementation: Immediate > b. Anything else: > > > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > www.eclipse-networks.com > 770.656.1460 - Cell > 770.399.9099- Office > > <image001.jpg>℠ Eclipse Networks, Inc. > Conquering Complex Networks℠ > > From: John Curran [mailto:[email protected]] > Sent: Sunday, July 13, 2014 8:47 AM > To: Kevin Blumberg > Cc: Steven Ryerse; [email protected] > Subject: Re: [arin-ppml] ARIN 2014-13 > > On Jul 12, 2014, at 10:02 AM, Kevin Blumberg <[email protected]> wrote: > > > > Steven, > > I’ve double checked with staff and this proposal will not make allocations or > assignments larger than /24 more difficult than today. > > In the revised section 4.2.1.5 Minimum allocation the text allows for /24 and > larger prefixes, it isn’t limited to only a /24. > > Correct. An updated staff assessment is forthcoming which adds the sentence: > > "If implemented, staff would continue using these well established criteria > and > guidelines for initial requests larger than /24." > > FYI, > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > 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.
