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: Utilization policy is not aggregate (Scott Leibrand)
2. Re: Utilization policy is not aggregate (Scott Leibrand)
3. Re: Utilization policy is not aggregate (Milton L Mueller)
4. Re: Utilization policy is not aggregate (Steven Ryerse)
----------------------------------------------------------------------
Message: 1
Date: Fri, 16 Nov 2012 07:06:59 -0700
From: Scott Leibrand <[email protected]>
To: Matthew Wilder <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Utilization policy is not aggregate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Matthew and Ron,
Excellent points, and agreed. I think you just wrote a good rationale for the
policy.
So what remains IMO is to ensure that this doesn't introduce a loophole for
draining the free pool when all that's left are small blocks. Re-reading 4.1.8,
I think the "one block every three months" restriction would be sufficient
there.
I look forward to seeing policy text, and will be happy to help in any way I
can.
Scott
On Nov 16, 2012, at 2:52 AM, Matthew Wilder <[email protected]> wrote:
> Respectfully, I have to agree with Ron. The policy should be biased toward
> allowing entities access to the resources they need, rather than biased
> toward the attempt to ensure each resource is immediately utilized. In the
> network world, we all know that things take time. Migrations occur.
> Subscribers come and go. Utilization on any given resource goes up and down.
> In general I would love to see the policy focus more on aggregate
> utilization and justification.
>
> I agree that in Ron's example an entity that can justify 4 x /20 for their 2
> year need should be allowed to acquire up to those 4 x /20 at any point in
> the 2 years beginning with their first transfer in which they acquire the
> /20, regardless of utilization of the individual /20 ranges, BUT holding the
> overall 80% utilization requirement as a necessary condition for subsequent
> allocations / transfers. This approach could lead to a balanced policy in my
> mind and one which accomplishes what RIR policy should do; namely to get
> number resources to those who need them.
>
> mw
> ________________________________________
> From: [email protected] [[email protected]] On Behalf Of
> Ron Grant [[email protected]]
> Sent: November 15, 2012 10:53 PM
> To: [email protected]
> Subject: Re: [arin-ppml] Utilization policy is not aggregate
>
> We're very near exhaustion so any new policy should be framed with the
> transfer market in mind.
>
> If somebody's willing to sell, and somebody else is willing to buy, but
> they can't justify it because of a math problem - well, I'd be in favour
> of changing it.
>
> So the example is really this:
>
> "if you are at 90% of a /16, and all that's available for purchase is a
> /20, is it really a problem if after purchase you'd be able to buy more?"
>
>
> On 12-11-15 9:53 PM, Scott Leibrand wrote:
>> On Nov 15, 2012, at 10:44 PM, Jeffrey Lyon <[email protected]>
>> wrote:
>>
>>> On Wed, Nov 14, 2012 at 12:04 AM, Matthew Wilder
>>> <[email protected]> wrote:
>>>> <snip>
>>>>
>>>>
>>>
>>> Are there any other opinions on this matter? I would like to hear any
>>> opposition that may exist before moving forward with drafting a policy
>>> proposal.
>>>
>> Not necessarily opposed, but one reason for the existing language is: if you
>> are at 90% of a /16, and your 3 month need is only for a /20, then you would
>> still be at >80% immediately after getting your /20, without using a bit of
>> it. If you have to use 80% (or even 50%) of all allocations, that eliminates
>> that loophole.
>>
>> Scott
>> _______________________________________________
>> 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.
>
> Forgot to CC: List. Sorry for the duplicate, Scott.
>
>
>
> --
> Ron Grant Managed DSL/T1/Wireless/Fibre
> Skyway West Business Internet Internet and Private Networking
> [email protected] Bonding and Fail Over Solutions
> ph: 604 737 2113 Virtual Data Centre and Private Clouds
> fax: 604 482 1299 http://www.skywaywest.com
>
> Sales, Support and Billing http://www.skywaywest.com/contact-us.htm
>
> _______________________________________________
> 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.
------------------------------
Message: 2
Date: Fri, 16 Nov 2012 06:44:35 -0800
From: Scott Leibrand <[email protected]>
To: William Herrin <[email protected]>
Cc: Jeffrey Lyon <[email protected]>, "[email protected]
List" <[email protected]>
Subject: Re: [arin-ppml] Utilization policy is not aggregate
Message-ID:
<cagkmwz5poab+lhxxq9h4hzzfnc26e+ywucmyjvclua63jvj...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Fri, Nov 16, 2012 at 6:01 AM, William Herrin <[email protected]> wrote:
> On Fri, Nov 16, 2012 at 12:53 AM, Scott Leibrand
> <[email protected]> wrote:
> > Not necessarily opposed, but one reason for the existing
> > language is: if you are at 90% of a /16, and your 3 month
> > need is only for a /20, then you would still be at >80%
> > immediately after getting your /20, without using a bit of it.
> > If you have to use 80% (or even 50%) of all allocations,
> > that eliminates that loophole.
>
> Do you have to use 80% on all allocations? Or just the most recent one?
>
That's not very clear in the ISP additional allocation policy.
https://www.arin.net/policy/nrpm.html#four24 for ISPs says:
4.2.4.1. Utilization percentage (80%)
ISPs must have efficiently utilized all previous allocations and at least
80% of their most recent allocation in order to receive additional space.
This includes all space reassigned to their customers. Please note that
until your prior utilization is verified to meet the 80% requirement, ARIN
can neither process nor approve a request for additional addresses.
https://www.arin.net/policy/nrpm.html#four361 for end users is more clear:
4.3.6.1 Utilization Requirements for Additional Assignment
In order to justify an additional assignment, end-users must have
efficiently utilized at least 80% of all previous assignments, and must
provide ARIN with utilization details.
On the other hand, the Multiple Discrete Networks policy at
https://www.arin.net/policy/nrpm.html#four5 only requires 50% overall (but
80% of each site at the time it was assigned).
-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20121116/c1640998/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 16 Nov 2012 14:17:48 +0000
From: Milton L Mueller <[email protected]>
To: "'Ron Grant'" <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [arin-ppml] Utilization policy is not aggregate
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
I agree with this framing of the problem and as a new AC member will be willing
to work on getting a new, well-thought-out policy through.
--MM
> -----Original Message-----
>
> We're very near exhaustion so any new policy should be framed with the
> transfer market in mind.
>
> If somebody's willing to sell, and somebody else is willing to buy, but
> they can't justify it because of a math problem - well, I'd be in favour
> of changing it.
>
> So the example is really this:
>
> "if you are at 90% of a /16, and all that's available for purchase is a
> /20, is it really a problem if after purchase you'd be able to buy more?"
>
issues.
------------------------------
Message: 4
Date: Fri, 16 Nov 2012 15:50:46 +0000
From: Steven Ryerse <[email protected]>
To: Jeffrey Lyon <[email protected]>
Cc: "[email protected] List" <[email protected]>
Subject: Re: [arin-ppml] Utilization policy is not aggregate
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
I agree with the change. Fairness needs to prevail.
Sent from my iPhone
On Nov 16, 2012, at 12:45 AM, "Jeffrey Lyon" <[email protected]>
wrote:
> On Wed, Nov 14, 2012 at 12:04 AM, Matthew Wilder
> <[email protected]> wrote:
>> I would absolutely support a change in this policy. I agree it is currently
>> highly unfavorable to those with multiple allocations. I know because I
>> have quite a few allocations, and trying to get them all up to 80%
>> utilization is like tacking jello to the wall. Not a fun exercise. You
>> have my +1.
>>
>> Matthew Wilder
>> TELUS
>> ________________________________________
>> From: [email protected] [[email protected]] On Behalf Of
>> Jeffrey Lyon [[email protected]]
>> Sent: November 13, 2012 7:36 PM
>> To: [email protected] List
>> Subject: [arin-ppml] Utilization policy is not aggregate
>>
>> All,
>>
>> I put in a IPv4 request today and received this reply:
>>
>> -- snip --
>>
>> Message:Hello Jeffrey,
>>
>> Thank you for the reply. We don't aggregate your holdings to come up
>> with a utilization percent. Each individual block must be efficiently
>> utilized. That's how policy is written, and that's how ARIN's operated
>> since our inception. 2% of a /21 isn't a lot, you're right, but policy
>> is policy, and it says 80%, so it's best if we don't make exceptions
>> and hold everyone to the same rule, dont you agree?
>>
>> -- snip --
>>
>> We hold 2 x /21 and it seems that 78% + 92% = 85% aggregate
>> utilization is not sufficient under current policy. I do not believe
>> it is equitable that we're ineligible to request resources because our
>> space is deaggregated where a network operator with contiguous /20
>> would be eligible.
>>
>> Would anyone else be in favor of amending this?
>>
>> --
>> Jeffrey A. Lyon, CISSP
>> President, Black Lotus Communications
>> mobile: (757) 304-0668 | gtalk: [email protected] | skype:
>> blacklotus.net
>> _______________________________________________
>> 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.
>
>
> Are there any other opinions on this matter? I would like to hear any
> opposition that may exist before moving forward with drafting a policy
> proposal.
>
> Thanks,
> --
> Jeffrey A. Lyon, CISSP
> President, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: [email protected] | skype: blacklotus.net
> _______________________________________________
> 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.
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 89, Issue 8
****************************************
