gt; in my opinion, for any "sense of the room" to make sense.
> >>
> >> David R Huberman
> >> Microsoft Corporation
> >> Senior IT/OPS Program Manager (GFS)
> >>
> >>
> >> From: arin-ppml-b
se.
>>
>> David R Huberman
>> Microsoft Corporation
>> Senior IT/OPS Program Manager (GFS)
>>
>> ________________
>> From: arin-ppml-boun...@arin.net on behalf of
>> Andrew Dul
>> Sent: Monday, June 16, 2014 10:53:15 AM
&
> >
> >
> > -Original Message-----
> > From: arin-ppml-boun...@arin.net
> <mailto:arin-ppml-boun...@arin.net>
> [mailto:arin-ppml-boun...@arin.net
> <mailto:arin-ppml-boun...@arin.net>] On Behalf Of Jeffrey Lyon
> > Sent:
ve that fits, but my advanced maths
> > are limited to Pythagoras.
> >
> >
> > -Original Message-----
> > From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On
> Behalf Of Jeffrey Lyon
> > Sent: Friday, June 13, 2014 2:41 PM
> > To: Ti
nager (GFS)
From: arin-ppml-boun...@arin.net on behalf of
Andrew Dul
Sent: Monday, June 16, 2014 10:53:15 AM
To: arin-ppml@arin.net
Subject: Re: [arin-ppml] Policy discussion - Method of calculating utilization
ARIN-2014-17
Hello,
I sent a longer summary of where this policy discussi
Tim Gimmel
>> Metronet | Senior Network Engineer
>> 3701 Communications Way | Evansville, IN 47715
>> Office: 812.456.4750
>> www.MetronetInc.com
>>
>>
>>> -Original Message-----
>>> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@ari
sage-
>> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net]
>> On Behalf Of Owen DeLong
>> Sent: Friday, May 02, 2014 8:14 PM
>> To: Jeffrey Lyon
>> Cc: arin-ppml@arin.net List
>> Subject: Re: [arin-ppml] Policy discussion - Method of calcu
t; From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On
>> Behalf Of Owen DeLong
>> Sent: Friday, May 02, 2014 8:14 PM
>> To: Jeffrey Lyon
>> Cc: arin-ppml@arin.net List
>> Subject: Re: [arin-ppml] Policy discussion - Method of calculating
>&
MetronetInc.com
> -Original Message-
> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On
> Behalf Of Owen DeLong
> Sent: Friday, May 02, 2014 8:14 PM
> To: Jeffrey Lyon
> Cc: arin-ppml@arin.net List
> Subject: Re: [arin-ppml] Policy discussion -
Support aggregate. Also support tiered aggregate changes, although I
feel the effort is unnecessary at this point, and would prefer to see
them as separate proposals.
-Blake
On Mon, May 5, 2014 at 8:29 AM, Brett Frankenberger
wrote:
> On Fri, May 02, 2014 at 09:05:06PM -0500, Jimmy Hess wrote:
>
On Fri, May 02, 2014 at 09:05:06PM -0500, Jimmy Hess wrote:
> On Fri, May 2, 2014 at 8:52 PM, Brett Frankenberger
> wrote:
> > Why is it not OK to get more space when you have an unused /21 that
> > is not adjacent to your other space, but it's OK to get more space if
> > you have an unused /21 hi
On Fri, May 2, 2014 at 8:52 PM, Brett Frankenberger
wrote:
> Why is it not OK to get more space when you have an unused /21 that
> is not adjacent to your other space, but it's OK to get more space if
> you have an unused /21 hidden inside a /16?
> I support the proposal.
You assert both should
On Fri, May 02, 2014 at 07:10:13PM -0500, Jimmy Hess wrote:
>
> While just an aggregate utilization criterion interesting. I don't
> believe a /16 resource holder should be able to obtain more address
> space, if they have a separate /21 or /20 allocation completely (or
> mostly) unused; it
On Sat, May 3, 2014 at 10:42 AM, Jimmy Hess wrote:
> On Fri, May 2, 2014 at 8:04 PM, Jeffrey Lyon
> wrote:
>> Jimmy,
>> I would not support scaling this beyond 80% except at the larger
>> allocation levels (eg. perhaps /17 and shorter, aggregate).
>
> The essence of it is, that the 80% utilizati
It would seem so.
Jeff
On May 3, 2014 10:38 AM, "Martin Hannigan" wrote:
>
>
> On Friday, May 2, 2014, Jeffrey Lyon wrote:
>
>> On Sat, May 3, 2014 at 10:31 AM, Martin Hannigan
>> wrote:
>> >
>> > Jeffrey,
>> >
>> > Let's be clear without political statements. I suggest we stamp all new
>> v4
On Fri, May 2, 2014 at 8:04 PM, Jeffrey Lyon
wrote:
> Jimmy,
> I would not support scaling this beyond 80% except at the larger
> allocation levels (eg. perhaps /17 and shorter, aggregate).
The essence of it is, that the 80% utilization criterion is ancient,
and before resource scarcity, before
On Friday, May 2, 2014, Jeffrey Lyon wrote:
> On Sat, May 3, 2014 at 10:31 AM, Martin Hannigan
> wrote:
> >
> > Jeffrey,
> >
> > Let's be clear without political statements. I suggest we stamp all new
> v4 proposals "post exhaustion implementation" from here. Aside from the MAU
> reduction, I c
On Sat, May 3, 2014 at 10:31 AM, Martin Hannigan wrote:
>
> Jeffrey,
>
> Let's be clear without political statements. I suggest we stamp all new v4
> proposals "post exhaustion implementation" from here. Aside from the MAU
> reduction, I can't imagine anything else worthy of the effort.
>
> Agr
Jeffrey,
Let's be clear without political statements. I suggest we stamp all new v4
proposals "post exhaustion implementation" from here. Aside from the MAU
reduction, I can't imagine anything else worthy of the effort.
Agree or not?
Best,
-M<
> On May 2, 2014, at 21:25, Jeffrey Lyo
On Sat, May 3, 2014 at 10:20 AM, Martin Hannigan wrote:
>
> Yes it is. Are you expecting such a change to happen before or after? The
> recent fury of v4 policy seems geared towards sooner. I think a moratorium
> is in order except for transfer related policy at this juncture.
>
> Best,
>
> -M<
>
Yes it is. Are you expecting such a change to happen before or after? The
recent fury of v4 policy seems geared towards sooner. I think a moratorium
is in order except for transfer related policy at this juncture.
Best,
-M<
On Friday, May 2, 2014, Jeffrey Lyon wrote:
> On Sat, May 3, 2014 at
While I support Jeffry’s proposal for changing the calculation method, in terms
of changing the threshold, I’d like to say that I really think it is time to
stop trying to re-arrange the IPv4 deck chairs and get on board the IPv6 luxury
liners that have come to rescue us from the sinking IPv4 sh
On Sat, May 3, 2014 at 10:12 AM, Martin Hannigan wrote:
>
> All,
>
> Why should entities get a break on a standard in existence and applied to all
> for years?
>
> And why is tbe aggregate, in examples given, broken? ARIN already applies
> that to some applicants.
>
> No support.
>
> Support po
All,
Why should entities get a break on a standard in existence and applied to all
for years?
And why is tbe aggregate, in examples given, broken? ARIN already applies that
to some applicants.
No support.
Support post exhaustion.
Best,
Martin
> On May 2, 2014, at 20:52, Jimmy Hess
On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess wrote:
> On Fri, May 2, 2014 at 7:33 PM, John Santos wrote:
>> On Fri, 2 May 2014, Jimmy Hess wrote:
>
>> I think 95% is too high, if the previous example of 3 /24's at 100% and
>> 1 /24 at 75% is realistic. That works out to 93.75% aggregate utilizatio
On Fri, May 2, 2014 at 7:33 PM, John Santos wrote:
> On Fri, 2 May 2014, Jimmy Hess wrote:
> I think 95% is too high, if the previous example of 3 /24's at 100% and
> 1 /24 at 75% is realistic. That works out to 93.75% aggregate utilization,
> not quite reaching the bar, so 90% might be a better
On Sat, May 3, 2014 at 9:33 AM, John Santos wrote:
> On Fri, 2 May 2014, Jimmy Hess wrote:
>
>> On Thu, May 1, 2014 at 1:04 PM, Leif Sawyer wrote:
>> > On behalf of myself, I support this proposal.
>> > On behalf of my company, which finds itself in the position
>> > of 8 large allocations above
On Fri, 2 May 2014, Jimmy Hess wrote:
> On Thu, May 1, 2014 at 1:04 PM, Leif Sawyer wrote:
> > On behalf of myself, I support this proposal.
> > On behalf of my company, which finds itself in the position
> > of 8 large allocations above 93% and 1 small allocation below the 80% mark,
> > I suppor
On Thu, May 1, 2014 at 1:04 PM, Leif Sawyer wrote:
> On behalf of myself, I support this proposal.
> On behalf of my company, which finds itself in the position
> of 8 large allocations above 93% and 1 small allocation below the 80% mark,
> I support this proposal.
I believe there should be both
> -Original Message-
> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On
> Behalf Of Jeffrey Lyon
> Sent: Wednesday, April 30, 2014 7:49 AM
>
> Friends, Colleagues,
>
> A couple of years ago I brought up an issue I had run into where the
> utilization requirement fo
...@arin.net] On Behalf
Of Jeffrey Lyon
Sent: Wednesday, April 30, 2014 6:49 AM
To: arin-ppml@arin.net List
Subject: [arin-ppml] Policy discussion - Method of calculating utilization
Friends, Colleagues,
A couple of years ago I brought up an issue I had run into where the
utilization requirement for
If this was actually drafted, I would too.
Doesn't seem like a bad thing.
On 5/1/2014 午後 03:19, Owen DeLong wrote:
I would support.
Owen
On Apr 30, 2014, at 7:49 AM, Jeffrey Lyon wrote:
Friends, Colleagues,
A couple of years ago I brought up an issue I had run into where the
utilization r
I would support.
Owen
On Apr 30, 2014, at 7:49 AM, Jeffrey Lyon wrote:
> Friends, Colleagues,
>
> A couple of years ago I brought up an issue I had run into where the
> utilization requirement for new requests is being calculated on a per
> allocation basis rather than in aggregate. For exampl
I'd support this proposal being implemented post runout. Otherwise,
opposed. This is a pass on the needs test that the rest of us have been
subject to. Do away with all need, not small bits.
Best,
-M<
On Wed, Apr 30, 2014 at 12:08 PM, Scott Leibrand
>
wrote:
> No, but I think it will be befor
Martin,
I disagree that this proposal would in any way eliminate needs basis.
The intent is to make sure that all allocations are considered in
aggregate so that those requesting space only have to have 80%
utilization vs. 90%+ that happens in many cases where allocations are
considered independen
I'd support this proposal being implemented post runout. Otherwise,
opposed. This is a pass on the needs test that the rest of us have been
subject to. Do away with all need, not small bits.
Best,
-M<
On Wed, Apr 30, 2014 at 12:08 PM, Scott Leibrand
>
wrote:
> No, but I think it will be befor
Scott,
How do we define free pool exhaustion? We're already at < 1 x /8 and
RIPE has already stopped issuing new IPv4 space (not sure what APNIC
et al are up to) but the situation is dire enough that I feel we
should consider ourselves at the exhaustion point.
Thanks, Jeff
On Thu, May 1, 2014 at
Paul,
The problem I see is in the manner of calculation. Right now each and
every allocation must be individually utilized at 80%. This means I
can have 3 x /22 utilized at 100% and 1 x /22 at 79% and would not be
eligible for more space where an organization with 80% utilization on
a single /20 w
No, but I think it will be before any new policy proposal moving at "normal"
speed takes effect. (The /24 minimum allocation size might take effect before
then. If so, that will probably accelerate runout further.)
If you think (as I do) that this policy change would still be useful after
runou
Jeffrey,
While the idea is great, isn't ARIN supposed to already be implementing
this in one way?
i.e: You get one allocation, and until you can show 80% usage --
applying again generally does not get you anywhere.
Going by this, shouldn't all previous allocs ("aggregated / per
organizatio
Scott,
Also, we're already in Phase 4, so isn't it fair to say that the free
pool is essentially exhausted?
Thanks, Jeff
On Thu, May 1, 2014 at 12:44 AM, Scott Leibrand wrote:
> This seems to me like a reasonable operational practice for ARIN to use to
> help prevent a run on the remaining free
Scott,
In my mind this does not have anything to do with free pool or
transfers, rather it is a measure to save time both for the applicant
and ARIN and to fix a disparity between how small organizations
request space versus large. Right now it is easier for organizations
with large allocations to
This seems to me like a reasonable operational practice for ARIN to use
to help prevent a run on the remaining free pool from organizations with
large quantities of existing space.
Are you trying to change this before free pool runout, or are you concerned
with making needs justification a bit eas
Friends, Colleagues,
A couple of years ago I brought up an issue I had run into where the
utilization requirement for new requests is being calculated on a per
allocation basis rather than in aggregate. For example, if an
organization has 4 x /22 and 3 of them are utilized 100% and the
fourth util
44 matches
Mail list logo
