From springer at inlandnet.com  Thu May  1 00:00:21 2014
From: springer at inlandnet.com (John Springer)
Date: Wed, 30 Apr 2014 21:00:21 -0700 (PDT)
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (fwd)
In-Reply-To: <CAMApp37pQ4eVevjZPFLaYbgD5JS8mDiGb7arw_H9i633=QB6SA@mail.gmail.com>
References: <alpine.BSF.2.00.1404282234570.7664@mail.inlandnet.com>
	<CAMApp37pQ4eVevjZPFLaYbgD5JS8mDiGb7arw_H9i633=QB6SA@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1404302009000.17122@mail.inlandnet.com>

Hi Bill,

Sorry for not answering in order.

On Tue, 29 Apr 2014, Bill Darte wrote:

> Hi John,
> Couple of questions..... could the solution for staff effort be solved more directly by modifying the protocol that establishes team
> testing for each and every request through exhaustion? ?I wonder about the need for these extraordinary measures.

Possibly. But the new (1/2013) PDP seems to channel us rather straitly at 
this point. The author still owns the proposal here and the shepherds (AD 
and I) have what appears to be criteria met for moving to advance to DP. 
AD has made some observations of late that seem to suggest a rewrite based 
on some concerns I haven't assimilated yet. As for extraordinary, and at 
the risk of another nautical metaphor, a rising tide lifts all boats.

> Is /16 small? ?Did you consider a different boundary....say, /20?

The author is willing to discuss this number, others suggest similar.

> How much of a record do we have for transfer requests yet? ?

This will go on the list of subjects for discussing this as DP assuming it 
gets there. These subjects do not appear to be precluded from discussion 
at this point so much as preparatory. As shepherd, I am focused on clear 
problem statement and in scope. Andrew is his usual incisive self. The 
author appears (mirabile dictu, and most welcome), to be willing to adapt 
to the process. We have time for the work. (I wonder if every other phrase 
should be IMO?)

> Until exhaustion we don't know what the run rate will be or the average 
> size block request. ?Though I believe the that those metrics should 
> mimic pre-exhaustion as I see nothing magic affecting network build out
> and business demands in the pre-post time frames.

Thankfully, not a question. :) I do see the math as being important, but I 
think we are are bordering on the time when appeals to math mimic Zeno's 
Paradox. I know that is not what you are doing, but I feel that continued 
call for math analysis of the decreasing pool or past behavior will be of 
increasingly limited utility. Particularly if the community also rises
supporting sweeping changes.

All of this my own opinion and not applicable to anything from God on
down.

> So, I neither support, nor oppose this proposal but hope to inform the discussion through my questions.

I am very glad to have this volume of response for this proposal. I hope 
you will assist in its processing, as always.

John Springer

> bd
> 
> 
> 
> 
> On Tue, Apr 29, 2014 at 12:35 AM, John Springer <springer at inlandnet.com> wrote:
>       Hi All,
>
>       The following timely policy proposal is presented for your consideration, discussion and comment. Will you please comment?
>
>       As always, expressions of support or opposition (and their reasons) are given slightly more weight than reasons why you
>       might be in neither condition.
>
>       John Springer
> 
>
>       ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers
>
>       Date: 16 April 2014
>       Problem Statement:
>       ARIN staff, faced with a surge in near-exhaust allocations and subsequent transfer requests and a requirement for team
>       review of these, is spending scarce staff time on needs testing of small transfers. This proposal seeks to decrease overall
>       ARIN processing time through elimination of that needs test.
>       Policy statement:
>       Change the language in NRPM 8.3 after Conditions on the recipient of the transfer: from "The recipient must demonstrate the
>       need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." to "For transfers
>       larger than a /16 equivalent, the recipient must demonstrate the need for up to a 24-month supply of IP address resources
>       under current ARIN policies and sign an RSA."
>       Change the language in the third bullet point in NRPM 8.4 after Conditions on the recipient of the transfer: from
>       "Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space." to "For
>       transfers larger than a /16 equivalent, recipients in the ARIN region must demonstrate the need for up to a 24-month supply
>       of IP address resources under current ARIN policies and sign an RSA."
>       Comments:
>       Needs testing has been maintained for transfers largely because the community wishes to ensure protection against hoarding
>       and speculation in the IPv4 market. This proposal seeks a middle ground between the elimination of needs tests for transfers
>       altogether, and the continuance of needs tests for every transfer. This should help ARIN staff to reduce transfer processing
>       time, since most transfers have been smaller than /16.
>       Timetable for implementation: Immediate
>
>       _______________________________________________
>       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.
> 
> 
> 
>

From owen at delong.com  Thu May  1 02:19:57 2014
From: owen at delong.com (Owen DeLong)
Date: Wed, 30 Apr 2014 23:19:57 -0700
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
Message-ID: <B099050A-760A-48EF-BF64-90463D8382D8@delong.com>

I would support.

Owen

On Apr 30, 2014, at 7:49 AM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> 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 example, if an
> organization has 4 x /22 and 3 of them are utilized 100% and the
> fourth utilized at 75%, that request would be denied. This is a bit
> out of balance as an organization with a single /20 utilized at 80%
> would have less efficient utilization but would be eligible to request
> additional space.
> 
> The last time this was discussed it sounded as if the community would
> support a policy proposal to change this calculation to be considered
> in aggregate vs. per assignment. Does this remain the case?
> 
> Thanks,
> -- 
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net
> _______________________________________________
> 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.



From contact at winterei.se  Thu May  1 02:28:13 2014
From: contact at winterei.se (Paul S.)
Date: Thu, 01 May 2014 15:28:13 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <B099050A-760A-48EF-BF64-90463D8382D8@delong.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
	<B099050A-760A-48EF-BF64-90463D8382D8@delong.com>
Message-ID: <5361E97D.9040301@winterei.se>

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 <jeffrey.lyon at blacklotus.net> 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 example, if an
>> organization has 4 x /22 and 3 of them are utilized 100% and the
>> fourth utilized at 75%, that request would be denied. This is a bit
>> out of balance as an organization with a single /20 utilized at 80%
>> would have less efficient utilization but would be eligible to request
>> additional space.
>>
>> The last time this was discussed it sounded as if the community would
>> support a policy proposal to change this calculation to be considered
>> in aggregate vs. per assignment. Does this remain the case?
>>
>> Thanks,
>> -- 
>> Jeffrey A. Lyon, CISSP-ISSMP
>> Fellow, Black Lotus Communications
>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net
>> _______________________________________________
>> 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.



From owen at delong.com  Thu May  1 02:35:00 2014
From: owen at delong.com (Owen DeLong)
Date: Wed, 30 Apr 2014 23:35:00 -0700
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
	Allocation/Assignment units to /24
In-Reply-To: <7E7773B523E82C478734E793E58F69E78D6FB9DF@SBS2011.thewireinc.local>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<CAAAwwbU5ey6XzBvSxzt2RxANdkAPWTAG3ON+wk_6UuQKKn3Leg@mail.gmail.com>
	<CAMDXq5P23TN_1EPxwTN+rXO+bSqOTsLt9BbzJEyve5X_PJcrGw@mail.gmail.com>,
	<53604E20.4020503@cnets.net>
	<aa681e3571a147b281b4a8842ebdc532@DM2PR03MB398.namprd03.prod.outlook.com>
	<alpine.BSF.2.00.1404301108190.66806@mail.inlandnet.com>
	<7E7773B523E82C478734E793E58F69E78D6FB9DF@SBS2011.thewireinc.local>
Message-ID: <D06BA96D-391D-485E-8450-FB5EE1AEF87F@delong.com>

I support this change.

Owen

On Apr 30, 2014, at 12:10 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> Bill Darte and myself will be the Sheppard's for this proposal. At this time we are working on the policy changes and vetting
> them against the text of the NRPM. 
> 
> I would appreciate feedback in regards to section 4.9 which is not mentioned in the current policy text but should probably be
> removed as part of this policy.
> 
> 4.9 Minimum Allocation in the Caribbean Region and North Atlantic Islands
> 
> The minimum IPv4 allocation size for ISPs from the Caribbean and North Atlantic Islands sector of the ARIN region is /22.
> 
> 4.9.1. Allocation Criteria
> 
> The requesting organization must show the efficient utilization of an entire previously allocated /22 from their upstream ISP. This allocation (/22) may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space. The organization must meet the requirement of efficient use of 4 /24s.    Utilization Reporting and Justification. All other ARIN policies regarding the reporting of justification information for the allocation of IPv4 and IPv6 address space will remain in effect.
> 
> Thanks,
> 
> Kevin Blumberg
> 
> 
> 
> 
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of John Springer
>> Sent: Wednesday, April 30, 2014 2:22 PM
>> To: David Huberman
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Policy Proposal: Reduce all Minimum
>> Allocation/Assignment units to /24
>> 
>> The analysis by David is, in my opinion, correct. This policy proposal is
>> receiving what in my experience is an unprecedented amount of community
>> support, _AS_WRITTEN_. Changes to the text require support be reiterated,
>> which might be unwanted and harmful to the text speed of the process.
>> Further desired changes should be submitted separately to avoid
>> interfering with the momentum that has been generated.
>> 
>> The community is speaking and the AC is listening. What I am hearing is
>> get busy and get 'er done. If the policy proposal can be supported as
>> written, it should be. Any changes to the text as written will have to be
>> listened to and responded to and cannot speed things up.
>> 
>> I am _NOT_ saying do not dissent, only that the conversation that ensues
>> will take time.
>> 
>> Not to put words in Marty's mouth, but that is how I interpret what he is
>> saying.
>> 
>> John Springer
>> 
>> On Wed, 30 Apr 2014, David Huberman wrote:
>> 
>>> 
>>> Derek,
>>> 
>>> 
>>> 
>>> Marty can be a bit gruff - it's part of his charm :)  He's actually trying very
>> hard to help you achieve your goals.  His observation you quoted is borne of
>> wisdom of
>>> dealing with the policy process for many years.   Some may agree, or may
>> not agree.  I happened to agree strongly with him.
>>> 
>>> 
>>> 
>>> Owen's proposal, without modifications (or at least, not the one proposed
>> so far), has the best chance of succeeding, and doing so quickly.
>>> 
>>> 
>>> 
>>> Just my opinion.
>>> 
>>> 
>>> 
>>> /david
>>> 
>>> David R Huberman
>>> Microsoft Corporation
>>> Senior IT/OPS Program Manager (GFS)
>>> 
>>> 
>> __________________________________________________________
>> __________________________________________________________
>> ___________________________________________________
>>> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on
>> behalf of Derek Calanchini <derekc at cnets.net>
>>> Sent: Tuesday, April 29, 2014 6:13 PM
>>> To: arin-ppml at arin.net
>>> Subject: Re: [arin-ppml] Policy Proposal: Reduce all Minimum
>> Allocation/Assignment units to /24
>>> Martin,
>>> 
>>> You seem very negative about this, disagreeing for the sake of disagreeing
>> is counter productive.  Perhaps you could explain your concerns giving actual
>> reasons,
>>> potential fallout, issues, etc in the hopes of making it better....
>>> 
>>>  Best regards,
>>> 
>>>    Derek Calanchini
>>>    Owner
>>>    Creative Network Solutions
>>>    Phone: 916-852-2890
>>>    Fax: 916-852-2899
>>> 
>>> "Adopt the metric system!"
>>> 
>>> CNS LOGO
>>> On 4/29/2014 5:15 PM, Martin Hannigan wrote:
>>> 
>>> Owens change is simple and fast. Meddling beyond that is asking for
>> trouble.  It's a no op. Leave it alone.
>>> Bring that to the PPC at NANOG and this is dead.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Tuesday, April 29, 2014, Jimmy Hess <mysidia at gmail.com> wrote:
>>>      On Tue, Apr 29, 2014 at 12:58 PM, Owen DeLong <owen at delong.com>
>> wrote:
>>> 
>>>      I support the proposed change as written.
>>> 
>>>      In addition,  since Multihomed ISPs no longer have a different minimum
>>>      allocation, I suggest    removing the distinction between Multihomed
>>>      and non-Multihomed ISPs:
>>> 
>>>         o 4.2.1.5     Delete the sentence that says "For multihomed ISPs...."
>>>         Remove multi-homed distinction and requirements for initial
>>>      allocations to ISPs.
>>>            o Delete section  4.2.2.1  Standard or non-multihomed  and
>> subsections.
>>> 
>>>            o Rename section 4.2.2.2 to  remove references to Multihomed
>>> 
>>>      Prepend     "When requesting a  /24,  demonstrate the efficient
>>>      utilization of a minimum contiguous or non-contiguous  /27  (two /28s)
>>>      from an upstream."
>>> 
>>>      [Regardless if multihomed or not]
>>> 
>>> 
>>> 
>>>> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>>>> 
>>>> 1. Policy Proposal Name: Reduce all Minimum Allocation/Assignment
>> units to
>>>> /24
>>>> 2. Proposal Originator
>>>> a. name: Owen DeLong
>>>> b. email: owen at delong.com
>>>> c. telephone: 408-890-7992
>>>> d. organization: Hurricane Electric
>>>> 3. Date: 29 April, 2014
>>>> 4. Problem Statement:
>>>> 
>>>> As we approach runout, more and more end users and smaller ISPs
>> will be
>>>> unable to obtain space from their upstreams and will be seeking space
>> from
>>>> ARIN. In order to meet these needs to the extent possible and to
>> make policy
>>>> more fair to a broader range of the ARIN constituency, we should
>> reduce the
>>>> minimum assignment and allocation units to /24 across the board.
>>>> 
>>>> 5. Policy statement:
>>>> 
>>>> Change the minimum allocation and assignment unit for all IPv4 single
>> and
>>>> multi homed instances to /20. This would include:
>>>> 
>>>> 
>>>> 4.2.1.5 Change all occurrences of /20 and /22 to /24
>>>> 
>>>> 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1
>> /24.
>>>> Remove the example about 12 /24s.
>>>> 
>>>> 4.3.2.1 Change both occurrences of /20 to /24
>>>> 
>>>> 4.9 Change /22 to /24
>>>> 
>>>> 4.9.1 Change all instances of /22 to /24. Remove the reference to 4
>> /24s.
>>>> 
>>>> 
>>>> 6. Comments:
>>>> a. Timetable for implementation: Immediate, possibly through board
>> action.
>>>> b. Anything else
>>>> 
>>>> END OF TEMPLATE
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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.
>>> 
>>> 
>>> 
>>>      --
>>>      -JH
>>>      _______________________________________________
>>>      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.
>>> 
>>> 
>>> 
>>> 
>>> 
>> __________________________________________________________
>> __________________________________________________________
>> ___________________________________________________
>>> [avast-mail-stamp.png]
>>> 
>>> This email is free from viruses and malware because avast! Antivirus
>> protection is active.
>>> 
>>> 
>>> 
>>> 
> _______________________________________________
> 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.



From owen at delong.com  Thu May  1 02:33:07 2014
From: owen at delong.com (Owen DeLong)
Date: Wed, 30 Apr 2014 23:33:07 -0700
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
	Allocation/Assignment units to /24
In-Reply-To: <alpine.BSF.2.00.1404301108190.66806@mail.inlandnet.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<CAAAwwbU5ey6XzBvSxzt2RxANdkAPWTAG3ON+wk_6UuQKKn3Leg@mail.gmail.com>
	<CAMDXq5P23TN_1EPxwTN+rXO+bSqOTsLt9BbzJEyve5X_PJcrGw@mail.gmail.com>,
	<53604E20.4020503@cnets.net>
	<aa681e3571a147b281b4a8842ebdc532@DM2PR03MB398.namprd03.prod.outlook.com>
	<alpine.BSF.2.00.1404301108190.66806@mail.inlandnet.com>
Message-ID: <9BDDB97F-C368-449C-BFDA-E0465919D625@delong.com>

I am assuming that the change to correct the typo where I said /20 instead of /24 will still have the support of the community. This has been mentioned elsewhere during the discussion, but otherwise, yes, I agree with you and David.

Owen

On Apr 30, 2014, at 11:22 AM, John Springer <springer at inlandnet.com> wrote:

> The analysis by David is, in my opinion, correct. This policy proposal is receiving what in my experience is an unprecedented amount of community support, _AS_WRITTEN_. Changes to the text require support be reiterated, which might be unwanted and harmful to the text speed of the process. Further desired changes should be submitted separately to avoid interfering with the momentum that has been generated.
> 
> The community is speaking and the AC is listening. What I am hearing is get busy and get 'er done. If the policy proposal can be supported as written, it should be. Any changes to the text as written will have to be listened to and responded to and cannot speed things up.
> 
> I am _NOT_ saying do not dissent, only that the conversation that ensues will take time.
> 
> Not to put words in Marty's mouth, but that is how I interpret what he is saying.
> 
> John Springer
> 
> On Wed, 30 Apr 2014, David Huberman wrote:
> 
>> Derek,
>>  
>> Marty can be a bit gruff - it's part of his charm :)  He's actually trying very hard to help you achieve your goals.  His observation you quoted is borne of wisdom of
>> dealing with the policy process for many years.   Some may agree, or may not agree.  I happened to agree strongly with him.
>>  
>> Owen's proposal, without modifications (or at least, not the one proposed so far), has the best chance of succeeding, and doing so quickly.
>>  
>> Just my opinion.
>>  
>> /david
>> David R Huberman
>> Microsoft Corporation
>> Senior IT/OPS Program Manager (GFS)
>> _______________________________________________________________________________________________________________________________________________________________________
>> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of Derek Calanchini <derekc at cnets.net>
>> Sent: Tuesday, April 29, 2014 6:13 PM
>> To: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Policy Proposal: Reduce all Minimum Allocation/Assignment units to /24  
>> Martin,
>> You seem very negative about this, disagreeing for the sake of disagreeing is counter productive.  Perhaps you could explain your concerns giving actual reasons,
>> potential fallout, issues, etc in the hopes of making it better....
>>  Best regards,
>>    Derek Calanchini
>>    Owner
>>    Creative Network Solutions
>>    Phone: 916-852-2890
>>    Fax: 916-852-2899
>> "Adopt the metric system!"
>> CNS LOGO
>> On 4/29/2014 5:15 PM, Martin Hannigan wrote:
>> Owens change is simple and fast. Meddling beyond that is asking for trouble.  It's a no op. Leave it alone. 
>> Bring that to the PPC at NANOG and this is dead. 
>> On Tuesday, April 29, 2014, Jimmy Hess <mysidia at gmail.com> wrote:
>>      On Tue, Apr 29, 2014 at 12:58 PM, Owen DeLong <owen at delong.com> wrote:
>> 
>>      I support the proposed change as written.
>> 
>>      In addition,  since Multihomed ISPs no longer have a different minimum
>>      allocation, I suggest    removing the distinction between Multihomed
>>      and non-Multihomed ISPs:
>> 
>>         o 4.2.1.5     Delete the sentence that says "For multihomed ISPs...."
>>         Remove multi-homed distinction and requirements for initial
>>      allocations to ISPs.
>>            o Delete section  4.2.2.1  Standard or non-multihomed  and subsections.
>> 
>>            o Rename section 4.2.2.2 to  remove references to Multihomed
>> 
>>      Prepend     "When requesting a  /24,  demonstrate the efficient
>>      utilization of a minimum contiguous or non-contiguous  /27  (two /28s)
>>      from an upstream."
>> 
>>      [Regardless if multihomed or not]
>> 
>>      > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>>      >
>>      > 1. Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to
>>      > /24
>>      > 2. Proposal Originator
>>      > a. name: Owen DeLong
>>      > b. email: owen at delong.com
>>      > c. telephone: 408-890-7992
>>      > d. organization: Hurricane Electric
>>      > 3. Date: 29 April, 2014
>>      > 4. Problem Statement:
>>      >
>>      > As we approach runout, more and more end users and smaller ISPs will be
>>      > unable to obtain space from their upstreams and will be seeking space from
>>      > ARIN. In order to meet these needs to the extent possible and to make policy
>>      > more fair to a broader range of the ARIN constituency, we should reduce the
>>      > minimum assignment and allocation units to /24 across the board.
>>      >
>>      > 5. Policy statement:
>>      >
>>      > Change the minimum allocation and assignment unit for all IPv4 single and
>>      > multi homed instances to /20. This would include:
>>      >
>>      >
>>      > 4.2.1.5 Change all occurrences of /20 and /22 to /24
>>      >
>>      > 4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24.
>>      > Remove the example about 12 /24s.
>>      >
>>      > 4.3.2.1 Change both occurrences of /20 to /24
>>      >
>>      > 4.9 Change /22 to /24
>>      >
>>      > 4.9.1 Change all instances of /22 to /24. Remove the reference to 4 /24s.
>>      >
>>      >
>>      > 6. Comments:
>>      > a. Timetable for implementation: Immediate, possibly through board action.
>>      > b. Anything else
>>      >
>>      > END OF TEMPLATE
>>      >
>>      >
>>      >
>>      > _______________________________________________
>>      > 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.
>> 
>>      --
>>      -JH
>>      _______________________________________________
>>      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.
>> _______________________________________________________________________________________________________________________________________________________________________
>> [avast-mail-stamp.png]
>> This email is free from viruses and malware because avast! Antivirus protection is active.
> _______________________________________________
> 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.



From george.herbert at gmail.com  Thu May  1 04:28:20 2014
From: george.herbert at gmail.com (George William Herbert)
Date: Thu, 1 May 2014 01:28:20 -0700
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum
	Allocation/Assignment units to /24
In-Reply-To: <9BDDB97F-C368-449C-BFDA-E0465919D625@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<CAAAwwbU5ey6XzBvSxzt2RxANdkAPWTAG3ON+wk_6UuQKKn3Leg@mail.gmail.com>
	<CAMDXq5P23TN_1EPxwTN+rXO+bSqOTsLt9BbzJEyve5X_PJcrGw@mail.gmail.com>
	<53604E20.4020503@cnets.net>
	<aa681e3571a147b281b4a8842ebdc532@DM2PR03MB398.namprd03.prod.outlook.com>
	<alpine.BSF.2.00.1404301108190.66806@mail.inlandnet.com>
	<9BDDB97F-C368-449C-BFDA-E0465919D625@delong.com>
Message-ID: <3C03250D-1D0E-42A8-B358-DF4F5C590847@gmail.com>



On Apr 30, 2014, at 11:33 PM, Owen DeLong <owen at delong.com> wrote:

> I am assuming that the change to correct the typo where I said /20 instead of /24 will still have the support of the community.


Damn, someone noticed it.  I was going to let it lie and use it as an example of why we want to move swiftly, but not *too* swiftly, in policymaking...


-george william herbert
george.herbert at gmail.com

Sent from Kangphone

From jcurran at arin.net  Thu May  1 07:51:33 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 1 May 2014 11:51:33 +0000
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (Sandra Brown)
In-Reply-To: <5361ABEB.7060606@quark.net>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<53618AFE.8090903@quark.net>
	<F28793E3-EFFE-47D9-9EC3-BB13684D3A01@gmail.com>
	<53618F76.9040905@quark.net>
	<E227D6B9-ACC3-44F3-BCCA-28CD444F5694@gmail.com>
	<5361ABEB.7060606@quark.net>
Message-ID: <4A624304-C4C3-4E55-B728-CE89D341C9F3@corp.arin.net>

On Apr 30, 2014, at 7:05 PM, Andrew Dul <andrew.dul at quark.net> wrote:

> On 4/30/2014 6:40 PM, Scott Leibrand wrote:
>> ...
>> It's hiding in 4.1.8: 
>> 
>> Repeated requests, in a manner that would circumvent 4.1.6, are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. 
>> 
> Fair enough, but one could also argue that 4.1.8 doesn't apply to transfers because the whole section is about ARIN issued space, not transfer obtained space.  They key is how ARIN would implement the proposed policy, which will happen latter in the staff assessment after the proposal is a draft policy. 

Andrew - 
 
  We actually consider that paragraph regarding "repeated requests" within the context 
  of the policy section in which it was adopted, so 'requests' refers to requests for ARIN-
  issued resources (i.e. those that could lead to "Unmet Requests"), and hence do not 
  consider it to be applicable to transfers.   

  If the community desires such a restriction, clearer policy language would be required.

Thanks!
/John

John Curran
President and CEO
ARIN



From mike at nationwideinc.com  Thu May  1 10:05:26 2014
From: mike at nationwideinc.com (Mike Burns)
Date: Thu, 1 May 2014 10:05:26 -0400
Subject: [arin-ppml] Policy discussion - Method of calculatingutilization
In-Reply-To: <B099050A-760A-48EF-BF64-90463D8382D8@delong.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
	<B099050A-760A-48EF-BF64-90463D8382D8@delong.com>
Message-ID: <F7366FC85407465481BAF116B61A80DE@MPC>

Support.


-----Original Message----- 
From: Owen DeLong
Sent: Thursday, May 01, 2014 2:19 AM
To: Jeffrey Lyon
Cc: arin-ppml at arin.net List
Subject: Re: [arin-ppml] Policy discussion - Method of 
calculatingutilization

I would support.

Owen

On Apr 30, 2014, at 7:49 AM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> 
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 example, if an
> organization has 4 x /22 and 3 of them are utilized 100% and the
> fourth utilized at 75%, that request would be denied. This is a bit
> out of balance as an organization with a single /20 utilized at 80%
> would have less efficient utilization but would be eligible to request
> additional space.
>
> The last time this was discussed it sounded as if the community would
> support a policy proposal to change this calculation to be considered
> in aggregate vs. per assignment. Does this remain the case?
>
> Thanks,
> -- 
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: 
> blacklotus.net
> _______________________________________________
> 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. 



From mike at nationwideinc.com  Thu May  1 10:54:06 2014
From: mike at nationwideinc.com (Mike Burns)
Date: Thu, 1 May 2014 10:54:06 -0400
Subject: [arin-ppml] Revision of ARIN-prop-204 Removing Needs Test from
	Small IPv4 Transfers
Message-ID: <72E7EE254D774B938B942C5955F4FB42@MPC>

Hi John and list,

Since my intention was to allow a maximum of one needs-free transfer per 
year, I have changed the proposal to better reflect that.
The proposed change will be a preface to ?the recipient must demonstrate the 
need for up to a 24 month supply of IP address resources...?

The preface will be ?For transfers larger than a /16 equivalent or for 
recipients who have completed a transfer in the prior year..?

The intended effect will be to retain needs testing of all transfers to 
recipients who have already completed a transfer in the prior year, and for 
all transfers larger than a /16.

If we want to be more permissive and allow for many transfers but only one 
being a need-free transfer, the preface would be:

?For transfers larger than a /16 equivalent or for recipients who have 
completed a need-free transfer in the prior year..?

And of course the /16 might end up being a different size if we can discover 
a supported-size through list discussion.


Regards,
Mike  Burns










ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers
>
> Date: 16 April 2014
> Problem Statement:
> ARIN staff, faced with a surge in near-exhaust allocations and subsequent 
> transfer requests and a requirement for team review of these, is spending 
> scarce staff time on needs testing of small transfers. This proposal seeks 
> to decrease overall ARIN processing time through elimination of that needs 
> test.
> Policy statement:
> Change the language in NRPM 8.3 after Conditions on the recipient of the 
> transfer: from "The recipient must demonstrate the need for up to a 
> 24-month supply of IP address resources under current ARIN policies and 
> sign an RSA." to "For transfers larger than a /16 equivalent or for 
> recipients who have completed a transfer in the prior year, the recipient 
> must demonstrate the need for up to a 24-month supply of IP address 
> resources under current ARIN policies and sign an RSA."
> Change the language in the third bullet point in NRPM 8.4 after Conditions 
> on the recipient of the transfer: from "Recipients within the ARIN region 
> must demonstrate the need for up to a 24-month supply of IPv4 address 
> space." to "For transfers larger than a /16 equivalent or for recipients 
> who have completed a transfer in the prior year, recipients in the ARIN 
> region must demonstrate the need for up to a 24-month supply of IP address 
> resources under current ARIN policies and sign an RSA."
> Comments:
> Needs testing has been maintained for transfers largely because the 
> community wishes to ensure protection against hoarding and speculation in 
> the IPv4 market. This proposal seeks a middle ground between the 
> elimination of needs tests for transfers altogether, and the continuance 
> of needs tests for every transfer. This should help ARIN staff to reduce 
> transfer processing time, since most transfers have been smaller than /16.
> Timetable for implementation: Immediate
>





From scottleibrand at gmail.com  Thu May  1 13:14:19 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 1 May 2014 10:14:19 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers (Sandra Brown)
In-Reply-To: <4A624304-C4C3-4E55-B728-CE89D341C9F3@corp.arin.net>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<53618AFE.8090903@quark.net>
	<F28793E3-EFFE-47D9-9EC3-BB13684D3A01@gmail.com>
	<53618F76.9040905@quark.net>
	<E227D6B9-ACC3-44F3-BCCA-28CD444F5694@gmail.com>
	<5361ABEB.7060606@quark.net>
	<4A624304-C4C3-4E55-B728-CE89D341C9F3@corp.arin.net>
Message-ID: <00A68F34-CF31-499A-9DAA-06D7C1B5CFD2@gmail.com>


> On May 1, 2014, at 4:51 AM, John Curran <jcurran at arin.net> wrote:
> 
>> On Apr 30, 2014, at 7:05 PM, Andrew Dul <andrew.dul at quark.net> wrote:
>> 
>>> On 4/30/2014 6:40 PM, Scott Leibrand wrote:
>>> ...
>>> It's hiding in 4.1.8: 
>>> 
>>> Repeated requests, in a manner that would circumvent 4.1.6, are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space.
>> Fair enough, but one could also argue that 4.1.8 doesn't apply to transfers because the whole section is about ARIN issued space, not transfer obtained space.  They key is how ARIN would implement the proposed policy, which will happen latter in the staff assessment after the proposal is a draft policy.
> 
> Andrew - 
> 
>  We actually consider that paragraph regarding "repeated requests" within the context 
>  of the policy section in which it was adopted, so 'requests' refers to requests for ARIN-
>  issued resources (i.e. those that could lead to "Unmet Requests"), and hence do not 
>  consider it to be applicable to transfers.

How do you square that with the presence of the words "or transfer"? In full, "an organization may only receive one allocation, assignment, or transfer every 3 months". 


>  If the community desires such a restriction, clearer policy language would be required.

Seems pretty unambiguous to me. 

-Scott



From jeffmehlenbacher at ipv4marketgroup.com  Thu May  1 13:33:49 2014
From: jeffmehlenbacher at ipv4marketgroup.com (jeffmehlenbacher at ipv4marketgroup.com)
Date: Thu, 01 May 2014 10:33:49 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
	Transfers
Message-ID: <20140501103349.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.0c6435ceb1.wbe@email17.secureserver.net>

In February 2012, I authored an ARIN policy proposal to eliminate any
needs-based justification on paid transfers.  It was not adopted
obviously.  Interestingly, the RIPE NCC adopted policy to remove
needs-based justification on paid transfers in February 2014.  With the
benefit of two plus years facilitating transfers in ARIN, APNIC and RIPE
regions since my original policy proposal, I would still prefer ARIN
remove all needs analysis on paid transfers rather than compromising on
a /16 maximum transfer without demonstrated need but only ONCE per year.
 It seems to me such a compromise is intended solely to appease rather
than doing what is right for ARIN region businesses that shortly, may
have no recourse but to enter the transfer market to obtain IPv4
resources that ARIN can no longer supply regardless of whether or not
need is demonstrated.  While it has only been a few months since RIPE
region buyers have not been directed to demonstrate need in order to
obtain transfer approval, I can tell the ARIN community one thing with
certainty: the requested block sizes we receive may or may not be larger
than truly "needed", but once market pricing is applied based on the
most recent transfers completed, a /18 block request may quickly be
modified by the prospective buyer to a /19 if the cost/benefit cannot be
realized for their business within acceptable timelines.  It is not
about demonstrating justified need to the RIR, it is about balancing
expense with the need to maintain business continuity and accommodating
growth forecasts.  The market has an interesting correction mechanism
without RIR resources being applied to interrogate need regardless of
block size requested/desired.  If the ARIN community is concerned about
speculation and hoarding with no needs assessment, I would invite you to
review the RIPE transfer market statistics paying particular attention
to block size (with or without need):
http://www.ripe.net/lir-services/resource-management/ipv4-transfers/table-of-transfers.


So for those ARIN region companies that will have impending requirements
for IPv4 resources based on previous allocations (consumption) and
future growth, now is the time for you to weigh in with a position on
the PPML.  If you believe paying for transferred IPv4 resources with an
officer attestation is sufficient justification in order to obtain
blocks that inevitably, ARIN can no longer distribute, your comments
would be most meaningful .


Jeff Mehlenbacher
IPv4 Market Group



From lsawyer at gci.com  Thu May  1 14:04:04 2014
From: lsawyer at gci.com (Leif Sawyer)
Date: Thu, 1 May 2014 10:04:04 -0800
Subject: [arin-ppml] Policy discussion - Method of calculating
 utilization
In-Reply-To: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102C779D4C0@fnb1mbx01.gci.com>

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.


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon
Sent: Wednesday, April 30, 2014 6:49 AM
To: arin-ppml at 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 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 utilized at 75%, that request would be denied. This is a bit out of balance as an organization with a single /20 utilized at 80% would have less efficient utilization but would be eligible to request additional space.

The last time this was discussed it sounded as if the community would support a policy proposal to change this calculation to be considered in aggregate vs. per assignment. Does this remain the case?

Thanks,
--
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net _______________________________________________
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.



From jcurran at arin.net  Thu May  1 14:16:52 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 1 May 2014 18:16:52 +0000
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (Sandra Brown)
In-Reply-To: <00A68F34-CF31-499A-9DAA-06D7C1B5CFD2@gmail.com>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<53618AFE.8090903@quark.net>
	<F28793E3-EFFE-47D9-9EC3-BB13684D3A01@gmail.com>
	<53618F76.9040905@quark.net>
	<E227D6B9-ACC3-44F3-BCCA-28CD444F5694@gmail.com>
	<5361ABEB.7060606@quark.net>
	<4A624304-C4C3-4E55-B728-CE89D341C9F3@corp.arin.net>
	<00A68F34-CF31-499A-9DAA-06D7C1B5CFD2@gmail.com>
Message-ID: <06C58213-A435-4141-83CE-4536A389779F@arin.net>

On May 1, 2014, at 1:14 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> We actually consider that paragraph regarding "repeated requests" within the context 
>> of the policy section in which it was adopted, so 'requests' refers to requests for ARIN-
>> issued resources (i.e. those that could lead to "Unmet Requests"), and hence do not 
>> consider it to be applicable to transfers.
> 
> How do you square that with the presence of the words "or transfer"? In full, "an organization may only receive one allocation, assignment, or transfer every 3 months". 

This section ("Unmet Requests") is setting policy with regards to resource 
requests once there are "unmet requests" due to lack of regional IPv4 free 
pool.  

If an organization has received an allocation or assignment or transfer 
within the last 3 months, it may not make a request for additional space 
to be issued from ARIN "in a manner that would circumvent 4.1.6" (which
is ARIN's issuance of address space on CIDR boundaries for aggregation 
purposes.)  

So, those who have received a recent transfer will be precluded from 
requesting an assignment or allocation from ARIN; they should have 
waited instead and ended up with the issuance of a single slightly 
larger block if possible.

Transfers are never "unmet requests" and do not involve the issuance 
of address space from ARIN.  This entire paragraph is intended to 
prohibit people from factoring their assignment/allocation requests 
to game their use of the waiting list system; this prohibition on 
repeated issuance of space and its intent was noted clearly in the 
staff assessment - 

  <http://lists.arin.net/pipermail/arin-ppml/2010-January/016211.html>

" Staff understands that this proposal would create a waiting list for
  requestors whose IPv4 address needs cannot be fulfilled by ARIN at the
  time of the request approval. The proposal includes text to prevent
  requestors from gaming the policy's intent by forbidding requestors from
  making multiple requests of a small size and limiting the issuance of
  space to no more than once every 3 months."

Note: "prevent requests from gaming the (waiting list) policy", 
       and "limiting _the issuance_ of space"

The paragraph is in IPv4 general principles, and is applicable to all 
types of requests for ARIN to issue space (since all of these requests 
could end up in the waiting list), but no plain reading of it would 
support it as a general prohibition against multiple transfers, nor 
would such a purpose support its addition to the policy manual embedded 
in new section entitled  "Unmet Requests" whose primarily purpose was 
establishment of an IPv4 waiting list.

Again, if there is a desire to create a restriction on repeated transfers
within a 3 month period, clear policy language to the effect should be 
adopted.  Note that such a policy proposal is also likely to get adequate 
community discussion of the proposed prohibition, something that creative
reinterpretation of the existing policy text does not provide.

Thanks,
/John

John Curran
President and CEO
ARIN

From scottleibrand at gmail.com  Thu May  1 14:45:54 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 1 May 2014 11:45:54 -0700
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4
 Transfers (Sandra Brown)
In-Reply-To: <06C58213-A435-4141-83CE-4536A389779F@arin.net>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<53618AFE.8090903@quark.net>
	<F28793E3-EFFE-47D9-9EC3-BB13684D3A01@gmail.com>
	<53618F76.9040905@quark.net>
	<E227D6B9-ACC3-44F3-BCCA-28CD444F5694@gmail.com>
	<5361ABEB.7060606@quark.net>
	<4A624304-C4C3-4E55-B728-CE89D341C9F3@corp.arin.net>
	<00A68F34-CF31-499A-9DAA-06D7C1B5CFD2@gmail.com>
	<06C58213-A435-4141-83CE-4536A389779F@arin.net>
Message-ID: <CAGkMwz4=8d1HmcqD0tf_24bSarL8ah9Q4qbQ9pmG14g+KppLUg@mail.gmail.com>

Ok.  Sounds like Mike has added a clearer restriction to his policy
proposal, so I'm satisfied with that.

Thanks,
Scott


On Thu, May 1, 2014 at 11:16 AM, John Curran <jcurran at arin.net> wrote:

> On May 1, 2014, at 1:14 PM, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
> >> We actually consider that paragraph regarding "repeated requests"
> within the context
> >> of the policy section in which it was adopted, so 'requests' refers to
> requests for ARIN-
> >> issued resources (i.e. those that could lead to "Unmet Requests"), and
> hence do not
> >> consider it to be applicable to transfers.
> >
> > How do you square that with the presence of the words "or transfer"? In
> full, "an organization may only receive one allocation, assignment, or
> transfer every 3 months".
>
> This section ("Unmet Requests") is setting policy with regards to resource
> requests once there are "unmet requests" due to lack of regional IPv4 free
> pool.
>
> If an organization has received an allocation or assignment or transfer
> within the last 3 months, it may not make a request for additional space
> to be issued from ARIN "in a manner that would circumvent 4.1.6" (which
> is ARIN's issuance of address space on CIDR boundaries for aggregation
> purposes.)
>
> So, those who have received a recent transfer will be precluded from
> requesting an assignment or allocation from ARIN; they should have
> waited instead and ended up with the issuance of a single slightly
> larger block if possible.
>
> Transfers are never "unmet requests" and do not involve the issuance
> of address space from ARIN.  This entire paragraph is intended to
> prohibit people from factoring their assignment/allocation requests
> to game their use of the waiting list system; this prohibition on
> repeated issuance of space and its intent was noted clearly in the
> staff assessment -
>
>   <http://lists.arin.net/pipermail/arin-ppml/2010-January/016211.html>
>
> " Staff understands that this proposal would create a waiting list for
>   requestors whose IPv4 address needs cannot be fulfilled by ARIN at the
>   time of the request approval. The proposal includes text to prevent
>   requestors from gaming the policy's intent by forbidding requestors from
>   making multiple requests of a small size and limiting the issuance of
>   space to no more than once every 3 months."
>
> Note: "prevent requests from gaming the (waiting list) policy",
>        and "limiting _the issuance_ of space"
>
> The paragraph is in IPv4 general principles, and is applicable to all
> types of requests for ARIN to issue space (since all of these requests
> could end up in the waiting list), but no plain reading of it would
> support it as a general prohibition against multiple transfers, nor
> would such a purpose support its addition to the policy manual embedded
> in new section entitled  "Unmet Requests" whose primarily purpose was
> establishment of an IPv4 waiting list.
>
> Again, if there is a desire to create a restriction on repeated transfers
> within a 3 month period, clear policy language to the effect should be
> adopted.  Note that such a policy proposal is also likely to get adequate
> community discussion of the proposed prohibition, something that creative
> reinterpretation of the existing policy text does not provide.
>
> Thanks,
> /John
>
> John Curran
> President and CEO
> ARIN
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140501/eaa8f084/attachment.htm>

From narten at us.ibm.com  Fri May  2 00:53:01 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 02 May 2014 00:53:01 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201405020453.s424r231005558@rotala.raleigh.ibm.com>

Total of 137 messages in the last 7 days.
 
script run at: Fri May  2 00:53:01 EDT 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  5.84% |    8 | 33.66% |  1011139 | derekc at cnets.net
 10.95% |   15 |  6.19% |   185829 | hannigan at gmail.com
  6.57% |    9 |  2.84% |    85446 | mike at nationwideinc.com
  5.11% |    7 |  2.29% |    68885 | michael at linuxmagic.com
  2.19% |    3 |  5.10% |   153179 | david.huberman at microsoft.com
  2.19% |    3 |  4.98% |   149509 | john.sweeting at twcable.com
  3.65% |    5 |  3.27% |    98083 | george.herbert at gmail.com
  3.65% |    5 |  2.86% |    85830 | sandrabrown at ipv4marketgroup.com
  4.38% |    6 |  2.08% |    62588 | andrew.dul at quark.net
  4.38% |    6 |  1.99% |    59904 | scottleibrand at gmail.com
  4.38% |    6 |  1.68% |    50402 | jeffrey.lyon at blacklotus.net
  3.65% |    5 |  1.97% |    59033 | owen at delong.com
  1.46% |    2 |  3.91% |   117420 | matthew at matthew.at
  3.65% |    5 |  1.63% |    48964 | drc at virtualized.org
  2.19% |    3 |  2.82% |    84813 | contact at winterei.se
  3.65% |    5 |  1.17% |    35210 | jcurran at arin.net
  1.46% |    2 |  3.18% |    95574 | jose.alvarado at allstream.com
  2.92% |    4 |  1.33% |    40059 | springer at inlandnet.com
  2.92% |    4 |  1.31% |    39288 | mike at iptrading.com
  2.19% |    3 |  1.48% |    44548 | sryerse at eclipse-networks.com
  0.73% |    1 |  2.20% |    66179 | tcoffeen at infoblox.com
  1.46% |    2 |  1.29% |    38607 | billdarte at gmail.com
  0.73% |    1 |  1.82% |    54667 | rudi.daniel at gmail.com
  1.46% |    2 |  0.74% |    22192 | lsawyer at gci.com
  1.46% |    2 |  0.67% |    20182 | farmer at umn.edu
  1.46% |    2 |  0.42% |    12607 | bill at herrin.us
  1.46% |    2 |  0.36% |    10894 | owens at nysernet.org
  0.73% |    1 |  0.77% |    23207 | rjletts at uw.edu
  0.73% |    1 |  0.59% |    17609 | paul at iosaz.net
  0.73% |    1 |  0.52% |    15497 | mje at posix.co.za
  0.73% |    1 |  0.52% |    15484 | timothy.s.morizot at irs.gov
  0.73% |    1 |  0.46% |    13858 | kevinb at thewire.ca
  0.73% |    1 |  0.40% |    12047 | cb.list6 at gmail.com
  0.73% |    1 |  0.36% |    10879 | cblecker at gmail.com
  0.73% |    1 |  0.34% |    10127 | skylar at crissic.net
  0.73% |    1 |  0.30% |     9140 | stu at actusa.net
  0.73% |    1 |  0.29% |     8674 | cgrundemann at gmail.com
  0.73% |    1 |  0.29% |     8670 | leslien at arin.net
  0.73% |    1 |  0.29% |     8581 | dogwallah at gmail.com
  0.73% |    1 |  0.26% |     7785 | mysidia at gmail.com
  0.73% |    1 |  0.24% |     7302 | rcarpen at network1.net
  0.73% |    1 |  0.23% |     7053 | jeffmehlenbacher at ipv4marketgroup.com
  0.73% |    1 |  0.23% |     6912 | narten at us.ibm.com
  0.73% |    1 |  0.23% |     6897 | john at egh.com
  0.73% |    1 |  0.22% |     6670 | hkl at softlinx.com
  0.73% |    1 |  0.22% |     6464 | ajs at anvilwalrusden.com
--------+------+--------+----------+------------------------
100.00% |  137 |100.00% |  3003887 | Total



From David.Huberman at microsoft.com  Fri May  2 02:13:47 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Fri, 2 May 2014 06:13:47 +0000
Subject: [arin-ppml] Policy Proposal: Reduce all
	Minimum	Allocation/Assignment units to /24
In-Reply-To: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
Message-ID: <05b71f6d1add421886ab3f5adfa1726d@DM2PR03MB398.namprd03.prod.outlook.com>

I support this proposal

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)
________________________________
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of Owen DeLong <owen at delong.com>
Sent: Tuesday, April 29, 2014 10:58:58 AM
To: policy at arin.net; ARIN PPML (ppml at arin.net)
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum Allocation/Assignment units to /24


Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0

        1.      Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24
        2.      Proposal Originator
                a.      name: Owen DeLong
                b.      email: owen at delong.com<mailto:owen at delong.com>
                c.      telephone: 408-890-7992
                d.      organization: Hurricane Electric
        3.      Date: 29 April, 2014
        4.      Problem Statement:

As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.

        5.      Policy statement:

Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:


4.2.1.5 Change all occurrences of /20 and /22 to /24

4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.

4.3.2.1 Change both occurrences of /20 to /24

4.9     Change /22 to /24

4.9.1   Change all instances of /22 to /24. Remove the reference to 4 /24s.


        6.      Comments:
                a.      Timetable for implementation: Immediate, possibly through board action.
                b.      Anything else

END OF TEMPLATE


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140502/6ae6bd36/attachment.htm>

From dogwallah at gmail.com  Fri May  2 05:27:05 2014
From: dogwallah at gmail.com (McTim)
Date: Fri, 2 May 2014 04:27:05 -0500
Subject: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small
 IPv4Transfers (Sandra Brown)
In-Reply-To: <5361979E.2020808@linuxmagic.com>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<5B9E90747FA2974D91A54FCFA1B8AD1201529ADAE6@ENI-MAIL.eclipse-networks.com>
	<0FDFAD20-C870-4F19-A09D-CFA33C61BE57@virtualized.org>
	<5361979E.2020808@linuxmagic.com>
Message-ID: <CACAaNxiupLb_70uH=zS_o5o-TG37Y2Mpnj=rxN6U2AfuL_N6iQ@mail.gmail.com>

Hi Michael,



On Wed, Apr 30, 2014 at 7:38 PM, Michael Peddemors
<michael at linuxmagic.com> wrote:
> On 14-04-30 05:11 PM, David Conrad wrote:

<snip>
>
>
> I recognize, any empowerment of ARIN for enforcement is a divisive topic,
> and has been for some time, but it doesn't mean we shouldn't look for a
> solution.

http://www.afrinic.net/en/community/policy-development/policy-proposals/700-no-reverse-unless-assigned

Is one possible solution.

I wrote it in less time than it took to read this entire thread, and
meant it as a straw-man, but folks seemed to like it.

YMMV.


-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel


From Fred.Wettling at bechtel.com  Fri May  2 06:45:34 2014
From: Fred.Wettling at bechtel.com (Wettling, Fred)
Date: Fri, 2 May 2014 10:45:34 +0000
Subject: [arin-ppml] Policy Proposal: Reduce
 all	Minimum	Allocation/Assignment units to /24
In-Reply-To: <05b71f6d1add421886ab3f5adfa1726d@DM2PR03MB398.namprd03.prod.outlook.com>
References: <89668261-46F6-4415-B595-032843FC9D68@delong.com>
	<05b71f6d1add421886ab3f5adfa1726d@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <E887EF9928EABB4DAE099CADE01FED9C84B604B6@ASHS91915.amers.ibechtel.com>

I support this proposal.

Fred Wettling
Bechtel Fellow
fred.wettling at bechtel.com<mailto:fred.wettling at bechtel.com> | +1 (865) 220-2993 (office) | +1 (865) 384-7662 (mobile)
________________________________
From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> <arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>> on behalf of Owen DeLong <owen at delong.com<mailto:owen at delong.com>>
Sent: Tuesday, April 29, 2014 10:58:58 AM
To: policy at arin.net<mailto:policy at arin.net>; ARIN PPML (ppml at arin.net<mailto:ppml at arin.net>)
Subject: [arin-ppml] Policy Proposal: Reduce all Minimum Allocation/Assignment units to /24


Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0



        1.      Policy Proposal Name: Reduce all Minimum Allocation/Assignment units to /24

        2.      Proposal Originator

               a.      name: Owen DeLong

               b.      email: owen at delong.com<mailto:owen at delong.com>

               c.      telephone: 408-890-7992

               d.      organization: Hurricane Electric

        3.      Date: 29 April, 2014

        4.      Problem Statement:

As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units to /24 across the board.

        5.      Policy statement:

Change the minimum allocation and assignment unit for all IPv4 single and multi homed instances to /20. This would include:



4.2.1.5 Change all occurrences of /20 and /22 to /24

4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. Remove the example about 12 /24s.

4.3.2.1 Change both occurrences of /20 to /24

4.9     Change /22 to /24

4.9.1   Change all instances of /22 to /24. Remove the reference to 4 /24s.



        6.      Comments:

               a.      Timetable for implementation: Immediate, possibly through board action.

               b.      Anything else



END OF TEMPLATE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140502/d8473418/attachment.htm>

From michael at linuxmagic.com  Fri May  2 11:39:53 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Fri, 02 May 2014 08:39:53 -0700
Subject: [arin-ppml] Adding Enforcement mandate language
In-Reply-To: <CACAaNxiupLb_70uH=zS_o5o-TG37Y2Mpnj=rxN6U2AfuL_N6iQ@mail.gmail.com>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<5B9E90747FA2974D91A54FCFA1B8AD1201529ADAE6@ENI-MAIL.eclipse-networks.com>
	<0FDFAD20-C870-4F19-A09D-CFA33C61BE57@virtualized.org>
	<5361979E.2020808@linuxmagic.com>
	<CACAaNxiupLb_70uH=zS_o5o-TG37Y2Mpnj=rxN6U2AfuL_N6iQ@mail.gmail.com>
Message-ID: <5363BC49.8070809@linuxmagic.com>

For the thread (subject changed) here is what you mean?

 From the Afrinic.net website..

"9.5 Validity of an assignment Assignments remain valid as long as the 
original criteria on which the assignment was based are still in place 
and the assignment is registered in the AfriNIC whois database. An 
assignment is therefore invalid if it is not registered in the database 
and if the purpose for which it was registered has changed or no longer 
holds. "

I think that for the ARIN policy, language like that will be hard to 
bring in, but we have to do something..

There has to be the correct balances of freedom of use, with identifying 
needs requirements..

Right now, someone can get a /16, and make the call out, and he can fill 
that in 48 hours.. but the problem is identifying who is really using 
that 'rented' IP space, and whether that /16 being rented out to others, 
is that justification for more IP Space?

The case can be made that 'speculators' can rent out IP Space to fill it 
up, so he can get more before it runs out.

I think the move to lower the /20 will help in getting IP(s) to real end 
users, instead of 'speculators'..

But we also need to give ARIN teeth do something about companies who 
aren't operating in accordance with guidelines..

But I doubt you will get consensus to give ARIN the power to revoke, 
unless there is really clearly defined conditions, and even then there 
will those concerned about the 'slippery slope'..

I think that for sure we need to prevent a company from getting more IP 
space, or allowing transfers if their whole existing space isn't 
compliant, but we do need more.

Maybe it is as simple as a pricing penalty?

IF they don't have accurate contact information on file, if they don't 
have functioning correct 'rwhois' or SWIP for 'rented' IP space, then it 
should cost more?




On 14-05-02 02:27 AM, McTim wrote:
> Hi Michael,
>
>
>
> On Wed, Apr 30, 2014 at 7:38 PM, Michael Peddemors
> <michael at linuxmagic.com> wrote:
>> On 14-04-30 05:11 PM, David Conrad wrote:
>
> <snip>
>>
>>
>> I recognize, any empowerment of ARIN for enforcement is a divisive topic,
>> and has been for some time, but it doesn't mean we shouldn't look for a
>> solution.
>
> http://www.afrinic.net/en/community/policy-development/policy-proposals/700-no-reverse-unless-assigned
>
> Is one possible solution.
>
> I wrote it in less time than it took to read this entire thread, and
> meant it as a straw-man, but folks seemed to like it.
>
> YMMV.
>
>



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From robert.cleary at bankofamerica.com  Fri May  2 12:02:08 2014
From: robert.cleary at bankofamerica.com (Cleary, Robert K)
Date: Fri, 02 May 2014 16:02:08 +0000
Subject: [arin-ppml] Ability to post to PPML list
Message-ID: <544D2233C5CE7A4DA4EFA8462605240E53CC134C@smtp_mail.bankofamerica.com>

Hi,

I would like the ability to post to the list.  My email address is Robert.cleary at bankofamerica.com<mailto:Robert.cleary at bankofamerica.com>


Regards,
Robert Cleary
Vice President
Product Manager - Data Center - DDI/IPAM
Global Networking and Infrastructure Solutions
Bank of America
FL8-060-01-01, 5000 US HWY 17 STE 75, Fleming Island, FL 32003
T 904.987.0917 M 321.863.0571
Robert.Cleary at BankofAmerica.com<mailto:first.lastname at bankofamerica.com>
Life's better when we're connected(tm)

----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140502/a35306af/attachment.htm>

From dogwallah at gmail.com  Fri May  2 13:04:53 2014
From: dogwallah at gmail.com (McTim)
Date: Fri, 2 May 2014 12:04:53 -0500
Subject: [arin-ppml] Adding Enforcement mandate language
In-Reply-To: <5363BC49.8070809@linuxmagic.com>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<5B9E90747FA2974D91A54FCFA1B8AD1201529ADAE6@ENI-MAIL.eclipse-networks.com>
	<0FDFAD20-C870-4F19-A09D-CFA33C61BE57@virtualized.org>
	<5361979E.2020808@linuxmagic.com>
	<CACAaNxiupLb_70uH=zS_o5o-TG37Y2Mpnj=rxN6U2AfuL_N6iQ@mail.gmail.com>
	<5363BC49.8070809@linuxmagic.com>
Message-ID: <CACAaNxjf3ysTvPtpnwM-6qD2-7aiEnYnxNA3M_S+R4DGbtaQWg@mail.gmail.com>

Hi,

On Fri, May 2, 2014 at 10:39 AM, Michael Peddemors
<michael at linuxmagic.com> wrote:
> For the thread (subject changed) here is what you mean?


no, that's just preamble.


>
> From the Afrinic.net website..
>
> "9.5 Validity of an assignment Assignments remain valid as long as the
> original criteria on which the assignment was based are still in place and
> the assignment is registered in the AfriNIC whois database. An assignment is
> therefore invalid if it is not registered in the database and if the purpose
> for which it was registered has changed or no longer holds. "
>
> I think that for the ARIN policy, language like that will be hard to bring
> in, but we have to do something..


"This proposal limits LIRs and End-Users from obtaining reverse
delegation (rDNS) from AFRINIC unless the address space is assigned or
sub-allocated in the AfriNIC Database."

In other words, no reverse DNS unless SWIP/rwhois.

I assume you want to improve the accuracy of the registry database
while giving ARIN the ability to enforce registration requirements,
correct?

This is one potential way to give the RIR a stick in which to enforce
the registration of assignments in the database.





>
> There has to be the correct balances of freedom of use, with identifying
> needs requirements..
>
> Right now, someone can get a /16, and make the call out, and he can fill
> that in 48 hours.. but the problem is identifying who is really using that
> 'rented' IP space, and whether that /16 being rented out to others, is that
> justification for more IP Space?
>
> The case can be made that 'speculators' can rent out IP Space to fill it up,
> so he can get more before it runs out.
>
> I think the move to lower the /20 will help in getting IP(s) to real end
> users, instead of 'speculators'..
>
> But we also need to give ARIN teeth do something about companies who aren't
> operating in accordance with guidelines..
>
> But I doubt you will get consensus to give ARIN the power to revoke,

Don't they already have the ability to revoke under clearly defined conditions?



-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel


From michael at linuxmagic.com  Fri May  2 13:39:00 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Fri, 02 May 2014 10:39:00 -0700
Subject: [arin-ppml] Adding Enforcement mandate language
In-Reply-To: <CACAaNxjf3ysTvPtpnwM-6qD2-7aiEnYnxNA3M_S+R4DGbtaQWg@mail.gmail.com>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<5B9E90747FA2974D91A54FCFA1B8AD1201529ADAE6@ENI-MAIL.eclipse-networks.com>
	<0FDFAD20-C870-4F19-A09D-CFA33C61BE57@virtualized.org>
	<5361979E.2020808@linuxmagic.com>
	<CACAaNxiupLb_70uH=zS_o5o-TG37Y2Mpnj=rxN6U2AfuL_N6iQ@mail.gmail.com>
	<5363BC49.8070809@linuxmagic.com>
	<CACAaNxjf3ysTvPtpnwM-6qD2-7aiEnYnxNA3M_S+R4DGbtaQWg@mail.gmail.com>
Message-ID: <5363D834.8010805@linuxmagic.com>

On 14-05-02 10:04 AM, McTim wrote:
> Don't they already have the ability to revoke under clearly defined conditions?

John Curran,

Maybe you can speak as to what mandates ARIN has in place for 
enforcement, as judging by the responses to tickets being placed on 
reports, and from conversations, we understand that there is a feeling 
that ARIN lacks this mandate?




-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From David.Huberman at microsoft.com  Fri May  2 13:56:24 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Fri, 2 May 2014 17:56:24 +0000
Subject: [arin-ppml] Adding Enforcement mandate language
In-Reply-To: <CACAaNxjf3ysTvPtpnwM-6qD2-7aiEnYnxNA3M_S+R4DGbtaQWg@mail.gmail.com>
References: <20140430135533.ec289651d84890fcbef5f195936e1217.66f95878e2.wbe@email17.secureserver.net>
	<5B9E90747FA2974D91A54FCFA1B8AD1201529ADAE6@ENI-MAIL.eclipse-networks.com>
	<0FDFAD20-C870-4F19-A09D-CFA33C61BE57@virtualized.org>
	<5361979E.2020808@linuxmagic.com>
	<CACAaNxiupLb_70uH=zS_o5o-TG37Y2Mpnj=rxN6U2AfuL_N6iQ@mail.gmail.com>
	<5363BC49.8070809@linuxmagic.com>,
	<CACAaNxjf3ysTvPtpnwM-6qD2-7aiEnYnxNA3M_S+R4DGbtaQWg@mail.gmail.com>
Message-ID: <229e589097914b29a426d5de6c4cdfb2@DM2PR03MB398.namprd03.prod.outlook.com>

Unfortunately, Mr McTim, this won't work here :(  We have tremendously large service providers who don't have up-to-date SWIP records as a function of changes ARIN has made to software. The providers are experiencing an inability to get changes made internally to adjust to ARIN's changes. This is mostly due to the difficulties large (100,000+ employee) companies experience when trying to be flexible.

Concisely: such a rule enforced to the spirit and letter would take down reverse for tier 1 networks. We can't put ARIN in that position, as it's a lose-lose for everyone on the Internet.

It's a tough reality to swallow (engineer's response "it shouldn't be that hard!") but it's very real :(

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

________________________________________
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of McTim <dogwallah at gmail.com>
Sent: Friday, May 2, 2014 10:04:53 AM
To: Michael Peddemors
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Adding Enforcement mandate language

Hi,

On Fri, May 2, 2014 at 10:39 AM, Michael Peddemors
<michael at linuxmagic.com> wrote:
> For the thread (subject changed) here is what you mean?


no, that's just preamble.


>
> From the Afrinic.net website..
>
> "9.5 Validity of an assignment Assignments remain valid as long as the
> original criteria on which the assignment was based are still in place and
> the assignment is registered in the AfriNIC whois database. An assignment is
> therefore invalid if it is not registered in the database and if the purpose
> for which it was registered has changed or no longer holds. "
>
> I think that for the ARIN policy, language like that will be hard to bring
> in, but we have to do something..


"This proposal limits LIRs and End-Users from obtaining reverse
delegation (rDNS) from AFRINIC unless the address space is assigned or
sub-allocated in the AfriNIC Database."

In other words, no reverse DNS unless SWIP/rwhois.

I assume you want to improve the accuracy of the registry database
while giving ARIN the ability to enforce registration requirements,
correct?

This is one potential way to give the RIR a stick in which to enforce
the registration of assignments in the database.





>
> There has to be the correct balances of freedom of use, with identifying
> needs requirements..
>
> Right now, someone can get a /16, and make the call out, and he can fill
> that in 48 hours.. but the problem is identifying who is really using that
> 'rented' IP space, and whether that /16 being rented out to others, is that
> justification for more IP Space?
>
> The case can be made that 'speculators' can rent out IP Space to fill it up,
> so he can get more before it runs out.
>
> I think the move to lower the /20 will help in getting IP(s) to real end
> users, instead of 'speculators'..
>
> But we also need to give ARIN teeth do something about companies who aren't
> operating in accordance with guidelines..
>
> But I doubt you will get consensus to give ARIN the power to revoke,

Don't they already have the ability to revoke under clearly defined conditions?



--
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel
_______________________________________________
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.


From lsawyer at gci.com  Fri May  2 14:22:55 2014
From: lsawyer at gci.com (Leif Sawyer)
Date: Fri, 2 May 2014 10:22:55 -0800
Subject: [arin-ppml] Policy Proposal: Change Utilization Requirements from
 last-allocation to total-aggregate
Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102C78E866A@fnb1mbx01.gci.com>

Based on Jeffrey Lyon's <jeffrey.lyon at blacklotus.net> email regarding
utilization requirements, I've put together a draft proposal:

---
Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0

	1.	Policy Proposal Name: Change Utilization Requirements from last-allocation to total-aggregate

	2.	Proposal Originator 
		a.	name: Leif Sawyer
		b.	email: lsawyer at gci.com
		c.	telephone: 907-265-5600
		d.	organization: General Communications, Inc

	3.	Date: 1 May, 2014

	4.	Problem Statement:?Utilization requirements 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 utilized at 75%, that request would
		be denied.
		This is a bit out of balance as an organization with a single /20
		utilized at 80% would have less efficient utilization but would be
		eligible to request additional space.

	5.	Policy statement:
      Section 4.2.4.1-  Change text to read:
		"ISPs must have efficiently utilized all previous allocations, in
		aggregate, to at least 80% 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."

	Section 4.3.6.1-  Change text to read:
		"End-users must have efficiently utilized all previous assignments,
		in aggregate, to at least 80% in order to receive additional space,
		and must provide ARIN with utilization details. The prefix size for
		an additional assignment is determined by applying the policies
		found in Section 4.3 of the NRPM."

	6.	Comments:
		a.	Timetable for implementation: Immediate, possibly through
			board action.
		b.	Per originator, This does not currently extend into MDN
		(aka 4.5.4), and I'm not really sure how to reconcile it against
		4.5.5, but OP expressed some concern that there may be undue
		restrictions there.  It might be better served by a separate
		proposal.
		c.    There should probably also be an attempt to clean up the
		language between 4.2.4.1  and 4.3.6.1, as they're both currently
		very clunky.

END OF TEMPLATE 



From michael at linuxmagic.com  Fri May  2 14:41:21 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Fri, 02 May 2014 11:41:21 -0700
Subject: [arin-ppml] Policy Proposal: Change Utilization Requirements
 from last-allocation to total-aggregate
In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102C78E866A@fnb1mbx01.gci.com>
References: <18B2C6E38A3A324986B392B2D18ABC5102C78E866A@fnb1mbx01.gci.com>
Message-ID: <5363E6D1.6080006@linuxmagic.com>

On 14-05-02 11:22 AM, Leif Sawyer wrote:
> 5.	Policy statement:
>        Section 4.2.4.1-  Change text to read:
> 		"ISPs must have efficiently utilized all previous allocations, in
> 		aggregate, to at least 80% 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."
>
> 	Section 4.3.6.1-  Change text to read:
> 		"End-users must have efficiently utilized all previous assignments,
> 		in aggregate, to at least 80% in order to receive additional space,
> 		and must provide ARIN with utilization details. The prefix size for
> 		an additional assignment is determined by applying the policies
> 		found in Section 4.3 of the NRPM."

Because we are talking about this, do we want stronger language about 
correctly configured 'rwhois' or SWIP to match the utilization provided 
to ARIN?


-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From jeffrey.lyon at blacklotus.net  Fri May  2 14:52:15 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Sat, 3 May 2014 03:52:15 +0900
Subject: [arin-ppml] Policy Proposal: Change Utilization Requirements
 from last-allocation to total-aggregate
In-Reply-To: <5363E6D1.6080006@linuxmagic.com>
References: <18B2C6E38A3A324986B392B2D18ABC5102C78E866A@fnb1mbx01.gci.com>
	<5363E6D1.6080006@linuxmagic.com>
Message-ID: <CACrmG8cEX2UJW-76kZ_AYQ+p+=b4t3ANa1PwXG+Qstqj_mTqgA@mail.gmail.com>

To clarify my concern about 4.5 requests, my intent is that each
discrete network be evaluated independently, but in aggregate, when
requesting space. For instance, Company A has Network X and Network Y.
The aggregate utilization of Network X is 80% and the aggregate
utilization of Network Y is 50%, Company A would be eligible to
request additional space for Network X only and Network Y would not be
considered in X's calculation.

Thanks, Jeff

On Sat, May 3, 2014 at 3:41 AM, Michael Peddemors
<michael at linuxmagic.com> wrote:
> On 14-05-02 11:22 AM, Leif Sawyer wrote:
>>
>> 5.      Policy statement:
>>        Section 4.2.4.1-  Change text to read:
>>                 "ISPs must have efficiently utilized all previous
>> allocations, in
>>                 aggregate, to at least 80% 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."
>>
>>         Section 4.3.6.1-  Change text to read:
>>                 "End-users must have efficiently utilized all previous
>> assignments,
>>                 in aggregate, to at least 80% in order to receive
>> additional space,
>>                 and must provide ARIN with utilization details. The prefix
>> size for
>>                 an additional assignment is determined by applying the
>> policies
>>                 found in Section 4.3 of the NRPM."
>
>
> Because we are talking about this, do we want stronger language about
> correctly configured 'rwhois' or SWIP to match the utilization provided to
> ARIN?
>
>
> --
> "Catch the Magic of Linux..."
> ------------------------------------------------------------------------
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> ------------------------------------------------------------------------
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> ------------------------------------------------------------------------
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
>
> _______________________________________________
> 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.



-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From rjletts at uw.edu  Fri May  2 15:19:17 2014
From: rjletts at uw.edu (Richard J. Letts)
Date: Fri, 2 May 2014 19:19:17 +0000
Subject: [arin-ppml] Policy discussion - Method of calculating
 utilization
In-Reply-To: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
Message-ID: <c11589d463714a88bffba49d02284a99@DM2PR08MB478.namprd08.prod.outlook.com>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at 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 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 utilized at
> 75%, that request would be denied. This is a bit out of balance as an
> organization with a single /20 utilized at 80% would have less efficient
> utilization but would be eligible to request additional space.
> 
> The last time this was discussed it sounded as if the community would
> support a policy proposal to change this calculation to be considered in
> aggregate vs. per assignment. Does this remain the case?

In the current policy legacy assignments are implicitly excluded from this calculation.
Would they be excluded or included in your aggregate suggestion?

In the case of large or multinational organizations, how far would you aggregate?
e.g. All Microsoft divisions, spanning RIRs; Comcast all markets? 

Richard Letts


From hannigan at gmail.com  Fri May  2 17:05:08 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 2 May 2014 17:05:08 -0400
Subject: [arin-ppml] Ability to post to PPML list
In-Reply-To: <544D2233C5CE7A4DA4EFA8462605240E53CC134C@smtp_mail.bankofamerica.com>
References: <544D2233C5CE7A4DA4EFA8462605240E53CC134C@smtp_mail.bankofamerica.com>
Message-ID: <CAMDXq5PqR9d5fmgGUX5LzHHQN7QbmCCC+GuhzGUiU2tQNUkH_w@mail.gmail.com>

Robert,

Looks like you have it.

Best,

Martin



On Friday, May 2, 2014, Cleary, Robert K <robert.cleary at bankofamerica.com>
wrote:

>  Hi,
>
>
>
> I would like the ability to post to the list.  My email address is
> Robert.cleary at bankofamerica.com<javascript:_e(%7B%7D,'cvml','Robert.cleary at bankofamerica.com');>
>
>
>
>
>
> Regards,
>
> *Robert Cleary*
>
> Vice President
>
> Product Manager - Data Center - DDI/IPAM
> Global Networking and Infrastructure Solutions
>
> Bank of America
> FL8-060-01-01, 5000 US HWY 17 STE 75, Fleming Island, FL 32003
> T 904.987.0917 M 321.863.0571
>
> Robert.Cleary at BankofAmerica.com<javascript:_e(%7B%7D,'cvml','first.lastname at bankofamerica.com');>
>
> Life's better when we're connected(tm)
>
>
>  ------------------------------
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.bankofamerica.com/emaildisclaimer. If you are not the intended
> recipient, please delete this message.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140502/851a9cbd/attachment.htm>

From mysidia at gmail.com  Fri May  2 20:10:13 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 2 May 2014 19:10:13 -0500
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102C779D4C0@fnb1mbx01.gci.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
	<18B2C6E38A3A324986B392B2D18ABC5102C779D4C0@fnb1mbx01.gci.com>
Message-ID: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>

On Thu, May 1, 2014 at 1:04 PM, Leif Sawyer <lsawyer at gci.com> 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 a  per-allocation utilization minimum
and an aggregate utilization criterion.

I also suggest a step-up in the utilization requirement:  the minimum
utilization criterion to say you are using the space efficiently
should be upped to 95% usage demonstrated, not 80%. It has been shown
that such efficient utilization is possible   and provides better
conservation of IP address space.

Conceivably the bar could be set at:  Minimum 50% utilization of each
previous allocation, and  95% utilization in the aggregate,  both
criteria to be met  for eligibility to receive additional address
space:   then the problem of "one small allocation"  inefficiently
used  is mitigated.

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 should either be used or returned, before another
request.

Justified needs means you efficiently utilize _all_  allocations,  not
just the last one you got,   not just the allocations you feel like
using efficiently.

--
-JH


From JOHN at egh.com  Fri May  2 20:33:24 2014
From: JOHN at egh.com (John Santos)
Date: Fri, 2 May 2014 20:33:24 -0400
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
Message-ID: <1140502201644.61785A-100000@Ives.egh.com>

On Fri, 2 May 2014, Jimmy Hess wrote:

> On Thu, May 1, 2014 at 1:04 PM, Leif Sawyer <lsawyer at gci.com> 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 a  per-allocation utilization minimum
> and an aggregate utilization criterion.
> 
> I also suggest a step-up in the utilization requirement:  the minimum
> utilization criterion to say you are using the space efficiently
> should be upped to 95% usage demonstrated, not 80%. It has been shown
> that such efficient utilization is possible   and provides better
> conservation of IP address space.

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 threshold.

OTOH, /24's are pretty small and maybe that example was just for
illustration.  If people really in this situation have much larger
allocations, they would be easier to slice and dice and thus use (relatively)
efficiently.  75% of a /24 leaves just 64 addresses (a /26) unused, which
even if contiguous are hard to redeploy for some other use.  75% of a /16
would leave 16384 unused addresses, which could be utilized much more easily.


Personally, I don't much care since my company has its /24, and that's
probably all the IPv4 we'll ever need :-)  


-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From jeffrey.lyon at blacklotus.net  Fri May  2 20:44:23 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Sat, 3 May 2014 09:44:23 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <1140502201644.61785A-100000@Ives.egh.com>
References: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<1140502201644.61785A-100000@Ives.egh.com>
Message-ID: <CACrmG8eSOGb3OJz-ksdTHkwY20_nLimUrsB8E3h-h4vykGy7tQ@mail.gmail.com>

On Sat, May 3, 2014 at 9:33 AM, John Santos <JOHN at egh.com> wrote:
> On Fri, 2 May 2014, Jimmy Hess wrote:
>
>> On Thu, May 1, 2014 at 1:04 PM, Leif Sawyer <lsawyer at gci.com> 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 a  per-allocation utilization minimum
>> and an aggregate utilization criterion.
>>
>> I also suggest a step-up in the utilization requirement:  the minimum
>> utilization criterion to say you are using the space efficiently
>> should be upped to 95% usage demonstrated, not 80%. It has been shown
>> that such efficient utilization is possible   and provides better
>> conservation of IP address space.
>
> 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 threshold.
>
> OTOH, /24's are pretty small and maybe that example was just for
> illustration.  If people really in this situation have much larger
> allocations, they would be easier to slice and dice and thus use (relatively)
> efficiently.  75% of a /24 leaves just 64 addresses (a /26) unused, which
> even if contiguous are hard to redeploy for some other use.  75% of a /16
> would leave 16384 unused addresses, which could be utilized much more easily.
>
>
> Personally, I don't much care since my company has its /24, and that's
> probably all the IPv4 we'll ever need :-)
>
>
> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
>
> _______________________________________________
> 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.

I would argue that 80% aggregate is too high, but that is an entirely
different discussion.

Attaining high levels of utilization is very difficult for service
providers. Customers often want, and properly justify, larger
assignments. These requests are often difficult to fill when
assignments are heavily fragmented for other customers only requiring
/30's or /29's. This leaves us with a condition where some allocations
are used more heavily than others depending on its specific purpose
within the organization.

My intent with this proposal was not to question the merits of the
current policies surrounding utilization, but rather to fix what I
deem an inefficiency in the current system which ends up being a huge
drain on ARIN's and the member's time. To illustrate what I mean by
this, each of my last few requests for resources have taken several
days longer because ARIN employees are trying to figure out if the
last assignment is used at 80% when all the space is aggregate is
clearly over 90%.

Thanks,
-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From mysidia at gmail.com  Fri May  2 20:52:52 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 2 May 2014 19:52:52 -0500
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <1140502201644.61785A-100000@Ives.egh.com>
References: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<1140502201644.61785A-100000@Ives.egh.com>
Message-ID: <CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>

On Fri, May 2, 2014 at 7:33 PM, John Santos <JOHN at egh.com> 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 threshold.

For 3 /24s   yes.      The difficulty here, is trying to pick a single
utilization proportion that works regardless   of the aggregate
allocation size, to allow for the loss of the oddball /26 or /27 that
can neither be returned nor reused,    perhaps another method is in
order  than presuming a single   aggregate utilization criterion  is
the most proper.


The more resources you are allocated,  the more opportunity to make
your resource allocation efficient.    By the time you get down to a
/26,   an entire  /24 is less than 0.4%.

Aggregate Resources Allocated                     Required Aggregate
Utilization criterion
more than a /25                                                75%
more than a /22,                                               80%
more than a /20                                                85%
more than a /19                                                90%
more than a /18                                                95%
more than a /17                                                97%
more than a /16                                                98%
more than a /15                                                99%



>
> OTOH, /24's are pretty small and maybe that example was just for
> illustration.  If people really in this situation have much larger
> allocations, they would be easier to slice and dice and thus use (relatively)
> efficiently.  75% of a /24 leaves just 64 addresses (a /26) unused, which
> even if contiguous are hard to redeploy for some other use.  75% of a /16
> would leave 16384 unused addresses, which could be utilized much more easily.
>
>
> Personally, I don't much care since my company has its /24, and that's
> probably all the IPv4 we'll ever need :-)
>
>
> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
>



-- 
-JH


From jeffrey.lyon at blacklotus.net  Fri May  2 21:04:31 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Sat, 3 May 2014 10:04:31 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>
References: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<1140502201644.61785A-100000@Ives.egh.com>
	<CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>
Message-ID: <CACrmG8enYfajpMfVaO0qji2=B3GHLRfhgQDXfzqPu_0Gi8v3UQ@mail.gmail.com>

On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess <mysidia at gmail.com> wrote:
> On Fri, May 2, 2014 at 7:33 PM, John Santos <JOHN at egh.com> 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 threshold.
>
> For 3 /24s   yes.      The difficulty here, is trying to pick a single
> utilization proportion that works regardless   of the aggregate
> allocation size, to allow for the loss of the oddball /26 or /27 that
> can neither be returned nor reused,    perhaps another method is in
> order  than presuming a single   aggregate utilization criterion  is
> the most proper.
>
>
> The more resources you are allocated,  the more opportunity to make
> your resource allocation efficient.    By the time you get down to a
> /26,   an entire  /24 is less than 0.4%.
>
> Aggregate Resources Allocated                     Required Aggregate
> Utilization criterion
> more than a /25                                                75%
> more than a /22,                                               80%
> more than a /20                                                85%
> more than a /19                                                90%
> more than a /18                                                95%
> more than a /17                                                97%
> more than a /16                                                98%
> more than a /15                                                99%
>
>
>
>>
>> OTOH, /24's are pretty small and maybe that example was just for
>> illustration.  If people really in this situation have much larger
>> allocations, they would be easier to slice and dice and thus use (relatively)
>> efficiently.  75% of a /24 leaves just 64 addresses (a /26) unused, which
>> even if contiguous are hard to redeploy for some other use.  75% of a /16
>> would leave 16384 unused addresses, which could be utilized much more easily.
>>
>>
>> Personally, I don't much care since my company has its /24, and that's
>> probably all the IPv4 we'll ever need :-)
>>
>>
>> --
>> John Santos
>> Evans Griffiths & Hart, Inc.
>> 781-861-0670 ext 539
>>
>
>
>
> --
> -JH
> _______________________________________________
> 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.

Jimmy,

I would not support scaling this beyond 80% except at the larger
allocation levels (eg. perhaps /17 and shorter, aggregate).

As a practical matter I believe these measures should be handled as
separate policy proposals. The current proposal should be limited to
the calculation method and perhaps you could write a new proposal if
you wanted to change the utilization threshold?

Thanks,
-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From hannigan at gmail.com  Fri May  2 21:12:16 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 2 May 2014 21:12:16 -0400
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>
References: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<1140502201644.61785A-100000@Ives.egh.com>
	<CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>
Message-ID: <37CDC9B6-8E34-4297-B4B9-DB86E132DBDB@gmail.com>


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 <mysidia at gmail.com> wrote:
> 
>> On Fri, May 2, 2014 at 7:33 PM, John Santos <JOHN at egh.com> 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 threshold.
> 
> For 3 /24s   yes.      The difficulty here, is trying to pick a single
> utilization proportion that works regardless   of the aggregate
> allocation size, to allow for the loss of the oddball /26 or /27 that
> can neither be returned nor reused,    perhaps another method is in
> order  than presuming a single   aggregate utilization criterion  is
> the most proper.
> 
> 
> The more resources you are allocated,  the more opportunity to make
> your resource allocation efficient.    By the time you get down to a
> /26,   an entire  /24 is less than 0.4%.
> 
> Aggregate Resources Allocated                     Required Aggregate
> Utilization criterion
> more than a /25                                                75%
> more than a /22,                                               80%
> more than a /20                                                85%
> more than a /19                                                90%
> more than a /18                                                95%
> more than a /17                                                97%
> more than a /16                                                98%
> more than a /15                                                99%
> 
> 
> 
>> 
>> OTOH, /24's are pretty small and maybe that example was just for
>> illustration.  If people really in this situation have much larger
>> allocations, they would be easier to slice and dice and thus use (relatively)
>> efficiently.  75% of a /24 leaves just 64 addresses (a /26) unused, which
>> even if contiguous are hard to redeploy for some other use.  75% of a /16
>> would leave 16384 unused addresses, which could be utilized much more easily.
>> 
>> 
>> Personally, I don't much care since my company has its /24, and that's
>> probably all the IPv4 we'll ever need :-)
>> 
>> 
>> --
>> John Santos
>> Evans Griffiths & Hart, Inc.
>> 781-861-0670 ext 539
> 
> 
> 
> -- 
> -JH
> _______________________________________________
> 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.


From jeffrey.lyon at blacklotus.net  Fri May  2 21:13:58 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Sat, 3 May 2014 10:13:58 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <37CDC9B6-8E34-4297-B4B9-DB86E132DBDB@gmail.com>
References: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<1140502201644.61785A-100000@Ives.egh.com>
	<CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>
	<37CDC9B6-8E34-4297-B4B9-DB86E132DBDB@gmail.com>
Message-ID: <CACrmG8duqjrVrz4RewWEKXG1n-po7FW6i69AfoDrKG-drtrQQQ@mail.gmail.com>

On Sat, May 3, 2014 at 10:12 AM, Martin  Hannigan <hannigan at gmail.com> 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 post exhaustion.
>
> Best,
>
> Martin
>
>> On May 2, 2014, at 20:52, Jimmy Hess <mysidia at gmail.com> wrote:
>>
>>> On Fri, May 2, 2014 at 7:33 PM, John Santos <JOHN at egh.com> 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 threshold.
>>
>> For 3 /24s   yes.      The difficulty here, is trying to pick a single
>> utilization proportion that works regardless   of the aggregate
>> allocation size, to allow for the loss of the oddball /26 or /27 that
>> can neither be returned nor reused,    perhaps another method is in
>> order  than presuming a single   aggregate utilization criterion  is
>> the most proper.
>>
>>
>> The more resources you are allocated,  the more opportunity to make
>> your resource allocation efficient.    By the time you get down to a
>> /26,   an entire  /24 is less than 0.4%.
>>
>> Aggregate Resources Allocated                     Required Aggregate
>> Utilization criterion
>> more than a /25                                                75%
>> more than a /22,                                               80%
>> more than a /20                                                85%
>> more than a /19                                                90%
>> more than a /18                                                95%
>> more than a /17                                                97%
>> more than a /16                                                98%
>> more than a /15                                                99%
>>
>>
>>
>>>
>>> OTOH, /24's are pretty small and maybe that example was just for
>>> illustration.  If people really in this situation have much larger
>>> allocations, they would be easier to slice and dice and thus use (relatively)
>>> efficiently.  75% of a /24 leaves just 64 addresses (a /26) unused, which
>>> even if contiguous are hard to redeploy for some other use.  75% of a /16
>>> would leave 16384 unused addresses, which could be utilized much more easily.
>>>
>>>
>>> Personally, I don't much care since my company has its /24, and that's
>>> probably all the IPv4 we'll ever need :-)
>>>
>>>
>>> --
>>> John Santos
>>> Evans Griffiths & Hart, Inc.
>>> 781-861-0670 ext 539
>>
>>
>>
>> --
>> -JH
>> _______________________________________________
>> 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.

... but IPv4 is already exhausted?

-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From owen at delong.com  Fri May  2 21:14:06 2014
From: owen at delong.com (Owen DeLong)
Date: Fri, 2 May 2014 18:14:06 -0700
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CACrmG8enYfajpMfVaO0qji2=B3GHLRfhgQDXfzqPu_0Gi8v3UQ@mail.gmail.com>
References: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<1140502201644.61785A-100000@Ives.egh.com>
	<CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>
	<CACrmG8enYfajpMfVaO0qji2=B3GHLRfhgQDXfzqPu_0Gi8v3UQ@mail.gmail.com>
Message-ID: <1280296C-200D-44CF-B3A9-641E2BCC8E10@delong.com>

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 ship.

Owen

On May 2, 2014, at 6:04 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:

> On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess <mysidia at gmail.com> wrote:
>> On Fri, May 2, 2014 at 7:33 PM, John Santos <JOHN at egh.com> 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 threshold.
>> 
>> For 3 /24s   yes.      The difficulty here, is trying to pick a single
>> utilization proportion that works regardless   of the aggregate
>> allocation size, to allow for the loss of the oddball /26 or /27 that
>> can neither be returned nor reused,    perhaps another method is in
>> order  than presuming a single   aggregate utilization criterion  is
>> the most proper.
>> 
>> 
>> The more resources you are allocated,  the more opportunity to make
>> your resource allocation efficient.    By the time you get down to a
>> /26,   an entire  /24 is less than 0.4%.
>> 
>> Aggregate Resources Allocated                     Required Aggregate
>> Utilization criterion
>> more than a /25                                                75%
>> more than a /22,                                               80%
>> more than a /20                                                85%
>> more than a /19                                                90%
>> more than a /18                                                95%
>> more than a /17                                                97%
>> more than a /16                                                98%
>> more than a /15                                                99%
>> 
>> 
>> 
>>> 
>>> OTOH, /24's are pretty small and maybe that example was just for
>>> illustration.  If people really in this situation have much larger
>>> allocations, they would be easier to slice and dice and thus use (relatively)
>>> efficiently.  75% of a /24 leaves just 64 addresses (a /26) unused, which
>>> even if contiguous are hard to redeploy for some other use.  75% of a /16
>>> would leave 16384 unused addresses, which could be utilized much more easily.
>>> 
>>> 
>>> Personally, I don't much care since my company has its /24, and that's
>>> probably all the IPv4 we'll ever need :-)
>>> 
>>> 
>>> --
>>> John Santos
>>> Evans Griffiths & Hart, Inc.
>>> 781-861-0670 ext 539
>>> 
>> 
>> 
>> 
>> --
>> -JH
>> _______________________________________________
>> 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.
> 
> Jimmy,
> 
> I would not support scaling this beyond 80% except at the larger
> allocation levels (eg. perhaps /17 and shorter, aggregate).
> 
> As a practical matter I believe these measures should be handled as
> separate policy proposals. The current proposal should be limited to
> the calculation method and perhaps you could write a new proposal if
> you wanted to change the utilization threshold?
> 
> Thanks,
> -- 
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net
> _______________________________________________
> 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.



From hannigan at gmail.com  Fri May  2 21:20:40 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 2 May 2014 21:20:40 -0400
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CACrmG8duqjrVrz4RewWEKXG1n-po7FW6i69AfoDrKG-drtrQQQ@mail.gmail.com>
References: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<1140502201644.61785A-100000@Ives.egh.com>
	<CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>
	<37CDC9B6-8E34-4297-B4B9-DB86E132DBDB@gmail.com>
	<CACrmG8duqjrVrz4RewWEKXG1n-po7FW6i69AfoDrKG-drtrQQQ@mail.gmail.com>
Message-ID: <CAMDXq5NFmDExc3FAF+_AuW6w1HtOCErZ22eNscHaFr-q1ZhpXw@mail.gmail.com>

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 <jeffrey.lyon at blacklotus.net> wrote:

> On Sat, May 3, 2014 at 10:12 AM, Martin  Hannigan <hannigan at gmail.com>
> 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 post exhaustion.
> >
> > Best,
> >
> > Martin
> >
> >> On May 2, 2014, at 20:52, Jimmy Hess <mysidia at gmail.com> wrote:
> >>
> >>> On Fri, May 2, 2014 at 7:33 PM, John Santos <JOHN at egh.com> 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 threshold.
> >>
> >> For 3 /24s   yes.      The difficulty here, is trying to pick a single
> >> utilization proportion that works regardless   of the aggregate
> >> allocation size, to allow for the loss of the oddball /26 or /27 that
> >> can neither be returned nor reused,    perhaps another method is in
> >> order  than presuming a single   aggregate utilization criterion  is
> >> the most proper.
> >>
> >>
> >> The more resources you are allocated,  the more opportunity to make
> >> your resource allocation efficient.    By the time you get down to a
> >> /26,   an entire  /24 is less than 0.4%.
> >>
> >> Aggregate Resources Allocated                     Required Aggregate
> >> Utilization criterion
> >> more than a /25                                                75%
> >> more than a /22,                                               80%
> >> more than a /20                                                85%
> >> more than a /19                                                90%
> >> more than a /18                                                95%
> >> more than a /17                                                97%
> >> more than a /16                                                98%
> >> more than a /15                                                99%
> >>
> >>
> >>
> >>>
> >>> OTOH, /24's are pretty small and maybe that example was just for
> >>> illustration.  If people really in this situation have much larger
> >>> allocations, they would be easier to slice and dice and thus use
> (relatively)
> >>> efficiently.  75% of a /24 leaves just 64 addresses (a /26) unused,
> which
> >>> even if contiguous are hard to redeploy for some other use.  75% of a
> /16
> >>> would leave 16384 unused addresses, which could be utilized much more
> easily.
> >>>
> >>>
> >>> Personally, I don't much care since my company has its /24, and that's
> >>> probably all the IPv4 we'll ever need :-)
> >>>
> >>>
> >>> --
> >>> John Santos
> >>> Evans Griffiths & Hart, Inc.
> >>> 781-861-0670 ext 539
> >>
> >>
> >>
> >> --
> >> -JH
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> t... but IPv4 is already exhausted?
>
> --
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com <javascript:;> |
> skype: blacklotus.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140502/4b637f8d/attachment.htm>

From jeffrey.lyon at blacklotus.net  Fri May  2 21:25:04 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Sat, 3 May 2014 10:25:04 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CAMDXq5NFmDExc3FAF+_AuW6w1HtOCErZ22eNscHaFr-q1ZhpXw@mail.gmail.com>
References: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<1140502201644.61785A-100000@Ives.egh.com>
	<CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>
	<37CDC9B6-8E34-4297-B4B9-DB86E132DBDB@gmail.com>
	<CACrmG8duqjrVrz4RewWEKXG1n-po7FW6i69AfoDrKG-drtrQQQ@mail.gmail.com>
	<CAMDXq5NFmDExc3FAF+_AuW6w1HtOCErZ22eNscHaFr-q1ZhpXw@mail.gmail.com>
Message-ID: <CACrmG8f-teBJH=KRtD_3BXXdiDPhE-2XmcGrSwW5NGLRZ00yeA@mail.gmail.com>

On Sat, May 3, 2014 at 10:20 AM, Martin Hannigan <hannigan at gmail.com> 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<
>
>
>
> On Friday, May 2, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
>>
>> On Sat, May 3, 2014 at 10:12 AM, Martin  Hannigan <hannigan at gmail.com>
>> 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 post exhaustion.
>> >
>> > Best,
>> >
>> > Martin
>> >
>> >> On May 2, 2014, at 20:52, Jimmy Hess <mysidia at gmail.com> wrote:
>> >>
>> >>> On Fri, May 2, 2014 at 7:33 PM, John Santos <JOHN at egh.com> 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 threshold.
>> >>
>> >> For 3 /24s   yes.      The difficulty here, is trying to pick a single
>> >> utilization proportion that works regardless   of the aggregate
>> >> allocation size, to allow for the loss of the oddball /26 or /27 that
>> >> can neither be returned nor reused,    perhaps another method is in
>> >> order  than presuming a single   aggregate utilization criterion  is
>> >> the most proper.
>> >>
>> >>
>> >> The more resources you are allocated,  the more opportunity to make
>> >> your resource allocation efficient.    By the time you get down to a
>> >> /26,   an entire  /24 is less than 0.4%.
>> >>
>> >> Aggregate Resources Allocated                     Required Aggregate
>> >> Utilization criterion
>> >> more than a /25                                                75%
>> >> more than a /22,                                               80%
>> >> more than a /20                                                85%
>> >> more than a /19                                                90%
>> >> more than a /18                                                95%
>> >> more than a /17                                                97%
>> >> more than a /16                                                98%
>> >> more than a /15                                                99%
>> >>
>> >>
>> >>
>> >>>
>> >>> OTOH, /24's are pretty small and maybe that example was just for
>> >>> illustration.  If people really in this situation have much larger
>> >>> allocations, they would be easier to slice and dice and thus use
>> >>> (relatively)
>> >>> efficiently.  75% of a /24 leaves just 64 addresses (a /26) unused,
>> >>> which
>> >>> even if contiguous are hard to redeploy for some other use.  75% of a
>> >>> /16
>> >>> would leave 16384 unused addresses, which could be utilized much more
>> >>> easily.
>> >>>
>> >>>
>> >>> Personally, I don't much care since my company has its /24, and that's
>> >>> probably all the IPv4 we'll ever need :-)
>> >>>
>> >>>
>> >>> --
>> >>> John Santos
>> >>> Evans Griffiths & Hart, Inc.
>> >>> 781-861-0670 ext 539
>> >>
>> >>
>> >>
>> >> --
>> >> -JH
>> >> _______________________________________________
>> >> PPML
>> >> You are receiving this message because you are subscribed to
>> >> t... but IPv4 is already exhausted?
>>
>>
>> --
>> Jeffrey A. Lyon, CISSP-ISSMP
>> Fellow, Black Lotus Communications
>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>> blacklotus.net

Martin,

My point is that we're already exhausted. We're in Phase 4, it doesn't
get much more exhausted than this. Are you suggesting that we wait
until there is a massive backlog of requests before supporting the
proposal?

-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From hannigan at gmail.com  Fri May  2 21:31:22 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 2 May 2014 21:31:22 -0400
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CACrmG8f-teBJH=KRtD_3BXXdiDPhE-2XmcGrSwW5NGLRZ00yeA@mail.gmail.com>
References: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<1140502201644.61785A-100000@Ives.egh.com>
	<CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>
	<37CDC9B6-8E34-4297-B4B9-DB86E132DBDB@gmail.com>
	<CACrmG8duqjrVrz4RewWEKXG1n-po7FW6i69AfoDrKG-drtrQQQ@mail.gmail.com>
	<CAMDXq5NFmDExc3FAF+_AuW6w1HtOCErZ22eNscHaFr-q1ZhpXw@mail.gmail.com>
	<CACrmG8f-teBJH=KRtD_3BXXdiDPhE-2XmcGrSwW5NGLRZ00yeA@mail.gmail.com>
Message-ID: <EA524A04-40DB-432E-AEE1-87975E2E3069@gmail.com>


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 Lyon <jeffrey.lyon at blacklotus.net> wrote:
> 
>> On Sat, May 3, 2014 at 10:20 AM, Martin Hannigan <hannigan at gmail.com> 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<
>> 
>> 
>> 
>>> On Friday, May 2, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
>>> 
>>> On Sat, May 3, 2014 at 10:12 AM, Martin  Hannigan <hannigan at gmail.com>
>>> 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 post exhaustion.
>>>> 
>>>> Best,
>>>> 
>>>> Martin
>>>> 
>>>>>> On May 2, 2014, at 20:52, Jimmy Hess <mysidia at gmail.com> wrote:
>>>>>> 
>>>>>>> On Fri, May 2, 2014 at 7:33 PM, John Santos <JOHN at egh.com> 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 threshold.
>>>>> 
>>>>> For 3 /24s   yes.      The difficulty here, is trying to pick a single
>>>>> utilization proportion that works regardless   of the aggregate
>>>>> allocation size, to allow for the loss of the oddball /26 or /27 that
>>>>> can neither be returned nor reused,    perhaps another method is in
>>>>> order  than presuming a single   aggregate utilization criterion  is
>>>>> the most proper.
>>>>> 
>>>>> 
>>>>> The more resources you are allocated,  the more opportunity to make
>>>>> your resource allocation efficient.    By the time you get down to a
>>>>> /26,   an entire  /24 is less than 0.4%.
>>>>> 
>>>>> Aggregate Resources Allocated                     Required Aggregate
>>>>> Utilization criterion
>>>>> more than a /25                                                75%
>>>>> more than a /22,                                               80%
>>>>> more than a /20                                                85%
>>>>> more than a /19                                                90%
>>>>> more than a /18                                                95%
>>>>> more than a /17                                                97%
>>>>> more than a /16                                                98%
>>>>> more than a /15                                                99%
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> OTOH, /24's are pretty small and maybe that example was just for
>>>>>> illustration.  If people really in this situation have much larger
>>>>>> allocations, they would be easier to slice and dice and thus use
>>>>>> (relatively)
>>>>>> efficiently.  75% of a /24 leaves just 64 addresses (a /26) unused,
>>>>>> which
>>>>>> even if contiguous are hard to redeploy for some other use.  75% of a
>>>>>> /16
>>>>>> would leave 16384 unused addresses, which could be utilized much more
>>>>>> easily.
>>>>>> 
>>>>>> 
>>>>>> Personally, I don't much care since my company has its /24, and that's
>>>>>> probably all the IPv4 we'll ever need :-)
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> John Santos
>>>>>> Evans Griffiths & Hart, Inc.
>>>>>> 781-861-0670 ext 539
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> -JH
>>>>> _______________________________________________
>>>>> PPML
>>>>> You are receiving this message because you are subscribed to
>>>>> t... but IPv4 is already exhausted?
>>> 
>>> 
>>> --
>>> Jeffrey A. Lyon, CISSP-ISSMP
>>> Fellow, Black Lotus Communications
>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>>> blacklotus.net
> 
> Martin,
> 
> My point is that we're already exhausted. We're in Phase 4, it doesn't
> get much more exhausted than this. Are you suggesting that we wait
> until there is a massive backlog of requests before supporting the
> proposal?
> 
> -- 
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From jeffrey.lyon at blacklotus.net  Fri May  2 21:35:06 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Sat, 3 May 2014 10:35:06 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <EA524A04-40DB-432E-AEE1-87975E2E3069@gmail.com>
References: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<1140502201644.61785A-100000@Ives.egh.com>
	<CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>
	<37CDC9B6-8E34-4297-B4B9-DB86E132DBDB@gmail.com>
	<CACrmG8duqjrVrz4RewWEKXG1n-po7FW6i69AfoDrKG-drtrQQQ@mail.gmail.com>
	<CAMDXq5NFmDExc3FAF+_AuW6w1HtOCErZ22eNscHaFr-q1ZhpXw@mail.gmail.com>
	<CACrmG8f-teBJH=KRtD_3BXXdiDPhE-2XmcGrSwW5NGLRZ00yeA@mail.gmail.com>
	<EA524A04-40DB-432E-AEE1-87975E2E3069@gmail.com>
Message-ID: <CACrmG8ebsk92WHehGcXNRn403y4MaC==U+Pb-4Dpsgs2Aq=pEQ@mail.gmail.com>

On Sat, May 3, 2014 at 10:31 AM, Martin  Hannigan <hannigan at gmail.com> 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.
>
> Agree or not?
>
> Best,
>
> -M<
>
>
>
>
>
>> On May 2, 2014, at 21:25, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
>>
>>> On Sat, May 3, 2014 at 10:20 AM, Martin Hannigan <hannigan at gmail.com> 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<
>>>
>>>
>>>
>>>> On Friday, May 2, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
>>>>
>>>> On Sat, May 3, 2014 at 10:12 AM, Martin  Hannigan <hannigan at gmail.com>
>>>> 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 post exhaustion.
>>>>>
>>>>> Best,
>>>>>
>>>>> Martin
>>>>>
>>>>>>> On May 2, 2014, at 20:52, Jimmy Hess <mysidia at gmail.com> wrote:
>>>>>>>
>>>>>>>> On Fri, May 2, 2014 at 7:33 PM, John Santos <JOHN at egh.com> 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 threshold.
>>>>>>
>>>>>> For 3 /24s   yes.      The difficulty here, is trying to pick a single
>>>>>> utilization proportion that works regardless   of the aggregate
>>>>>> allocation size, to allow for the loss of the oddball /26 or /27 that
>>>>>> can neither be returned nor reused,    perhaps another method is in
>>>>>> order  than presuming a single   aggregate utilization criterion  is
>>>>>> the most proper.
>>>>>>
>>>>>>
>>>>>> The more resources you are allocated,  the more opportunity to make
>>>>>> your resource allocation efficient.    By the time you get down to a
>>>>>> /26,   an entire  /24 is less than 0.4%.
>>>>>>
>>>>>> Aggregate Resources Allocated                     Required Aggregate
>>>>>> Utilization criterion
>>>>>> more than a /25                                                75%
>>>>>> more than a /22,                                               80%
>>>>>> more than a /20                                                85%
>>>>>> more than a /19                                                90%
>>>>>> more than a /18                                                95%
>>>>>> more than a /17                                                97%
>>>>>> more than a /16                                                98%
>>>>>> more than a /15                                                99%
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> OTOH, /24's are pretty small and maybe that example was just for
>>>>>>> illustration.  If people really in this situation have much larger
>>>>>>> allocations, they would be easier to slice and dice and thus use
>>>>>>> (relatively)
>>>>>>> efficiently.  75% of a /24 leaves just 64 addresses (a /26) unused,
>>>>>>> which
>>>>>>> even if contiguous are hard to redeploy for some other use.  75% of a
>>>>>>> /16
>>>>>>> would leave 16384 unused addresses, which could be utilized much more
>>>>>>> easily.
>>>>>>>
>>>>>>>
>>>>>>> Personally, I don't much care since my company has its /24, and that's
>>>>>>> probably all the IPv4 we'll ever need :-)
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> John Santos
>>>>>>> Evans Griffiths & Hart, Inc.
>>>>>>> 781-861-0670 ext 539
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -JH
>>>>>> _______________________________________________
>>>>>> PPML
>>>>>> You are receiving this message because you are subscribed to
>>>>>> t... but IPv4 is already exhausted?
>>>>
>>>>
>>>> --
>>>> Jeffrey A. Lyon, CISSP-ISSMP
>>>> Fellow, Black Lotus Communications
>>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>>>> blacklotus.net
>>
>> Martin,
>>
>> My point is that we're already exhausted. We're in Phase 4, it doesn't
>> get much more exhausted than this. Are you suggesting that we wait
>> until there is a massive backlog of requests before supporting the
>> proposal?
>>
>> --
>> Jeffrey A. Lyon, CISSP-ISSMP
>> Fellow, Black Lotus Communications
>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net

Martin,

Please forgive me if I am just confused or ignorant, but I agree we
are now exhausted and whether a proposal is stamped post-exhaustion or
otherwise, its implementation would have an immediate effect.

What am I missing?

Thanks,
-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From hannigan at gmail.com  Fri May  2 21:38:53 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 2 May 2014 21:38:53 -0400
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CACrmG8ebsk92WHehGcXNRn403y4MaC==U+Pb-4Dpsgs2Aq=pEQ@mail.gmail.com>
References: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<1140502201644.61785A-100000@Ives.egh.com>
	<CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>
	<37CDC9B6-8E34-4297-B4B9-DB86E132DBDB@gmail.com>
	<CACrmG8duqjrVrz4RewWEKXG1n-po7FW6i69AfoDrKG-drtrQQQ@mail.gmail.com>
	<CAMDXq5NFmDExc3FAF+_AuW6w1HtOCErZ22eNscHaFr-q1ZhpXw@mail.gmail.com>
	<CACrmG8f-teBJH=KRtD_3BXXdiDPhE-2XmcGrSwW5NGLRZ00yeA@mail.gmail.com>
	<EA524A04-40DB-432E-AEE1-87975E2E3069@gmail.com>
	<CACrmG8ebsk92WHehGcXNRn403y4MaC==U+Pb-4Dpsgs2Aq=pEQ@mail.gmail.com>
Message-ID: <CAMDXq5N-ndZNdS+9Sud6RSid2pXsF7vKCur7bT6-QO0W4NbN4g@mail.gmail.com>

On Friday, May 2, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:

> On Sat, May 3, 2014 at 10:31 AM, Martin  Hannigan <hannigan at gmail.com>
> 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.
> >
> > Agree or not?
> >
> > Best,
> >
> > -M<
> >
> >
> >
> >
> >
> >> On May 2, 2014, at 21:25, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
> wrote:
> >>
> >>> On Sat, May 3, 2014 at 10:20 AM, Martin Hannigan <hannigan at gmail.com>
> 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.
> >>>
>
>
[clip]


>
>
> Please forgive me if I am just confused or ignorant, but I agree we
> are now exhausted and whether a proposal is stamped post-exhaustion or
> otherwise, its implementation would have an immediate effect.
>
> What am I missing?
>
>

So we agree then?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140502/fef0c1a6/attachment.htm>

From mysidia at gmail.com  Fri May  2 21:42:04 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 2 May 2014 20:42:04 -0500
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CACrmG8enYfajpMfVaO0qji2=B3GHLRfhgQDXfzqPu_0Gi8v3UQ@mail.gmail.com>
References: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<1140502201644.61785A-100000@Ives.egh.com>
	<CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>
	<CACrmG8enYfajpMfVaO0qji2=B3GHLRfhgQDXfzqPu_0Gi8v3UQ@mail.gmail.com>
Message-ID: <CAAAwwbUAuoJyZaeDCpSYVg1r7etMXEJ=_sTg6fPTz0q=oJxCNQ@mail.gmail.com>

On Fri, May 2, 2014 at 8:04 PM, Jeffrey Lyon
<jeffrey.lyon at blacklotus.net> 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 technical improvements such as
unnumbered interfaces, before host-based virtual hosting,  and  /31s
as point to point links.  And  a greater utilization requirement may
slow exhaustion.

The number allows plenty of extra wiggle-room luxury, in addition to
the occasional oddball patch which can't be allocated even in an
efficient planned address allocation strategy,  which the free
resources don't exist for, any longer.

80% in the aggregate criterion is unfairly strict against resource
holders  that have  a small total allocation size.  And unfairly
lenient against resource holders that have a large total allocation
size.

And removing the per-allocation utilization requirement would serve to
exacerbate this problem.

For example, under the current rules a holder of a /10 equivalent, can
 call their existing allocations "efficiently utilized",   even if
there are most recent allocation, an entire  contiguous /20s  has been
completely untouched and unused.

Whereas the resource holder that has a /20,   cannot have a single
/23's worth  untouched.

--
-JH


From jeffrey.lyon at blacklotus.net  Fri May  2 21:42:14 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Sat, 3 May 2014 10:42:14 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CAMDXq5N-ndZNdS+9Sud6RSid2pXsF7vKCur7bT6-QO0W4NbN4g@mail.gmail.com>
References: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<1140502201644.61785A-100000@Ives.egh.com>
	<CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>
	<37CDC9B6-8E34-4297-B4B9-DB86E132DBDB@gmail.com>
	<CACrmG8duqjrVrz4RewWEKXG1n-po7FW6i69AfoDrKG-drtrQQQ@mail.gmail.com>
	<CAMDXq5NFmDExc3FAF+_AuW6w1HtOCErZ22eNscHaFr-q1ZhpXw@mail.gmail.com>
	<CACrmG8f-teBJH=KRtD_3BXXdiDPhE-2XmcGrSwW5NGLRZ00yeA@mail.gmail.com>
	<EA524A04-40DB-432E-AEE1-87975E2E3069@gmail.com>
	<CACrmG8ebsk92WHehGcXNRn403y4MaC==U+Pb-4Dpsgs2Aq=pEQ@mail.gmail.com>
	<CAMDXq5N-ndZNdS+9Sud6RSid2pXsF7vKCur7bT6-QO0W4NbN4g@mail.gmail.com>
Message-ID: <CACrmG8fp6r0k4hGD=1jvAX1v933sYyyCELGp=_UsNvBCfKRZYA@mail.gmail.com>

It would seem so.

Jeff
On May 3, 2014 10:38 AM, "Martin Hannigan" <hannigan at gmail.com> wrote:

>
>
> On Friday, May 2, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
>
>> On Sat, May 3, 2014 at 10:31 AM, Martin  Hannigan <hannigan at gmail.com>
>> 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.
>> >
>> > Agree or not?
>> >
>> > Best,
>> >
>> > -M<
>> >
>> >
>> >
>> >
>> >
>> >> On May 2, 2014, at 21:25, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
>> wrote:
>> >>
>> >>> On Sat, May 3, 2014 at 10:20 AM, Martin Hannigan <hannigan at gmail.com>
>> 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.
>> >>>
>>
>>
> [clip]
>
>
>>
>>
>> Please forgive me if I am just confused or ignorant, but I agree we
>> are now exhausted and whether a proposal is stamped post-exhaustion or
>> otherwise, its implementation would have an immediate effect.
>>
>> What am I missing?
>>
>>
>
> So we agree then?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140503/d89182d6/attachment.htm>

From jeffrey.lyon at blacklotus.net  Fri May  2 21:44:45 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Sat, 3 May 2014 10:44:45 +0900
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CAAAwwbUAuoJyZaeDCpSYVg1r7etMXEJ=_sTg6fPTz0q=oJxCNQ@mail.gmail.com>
References: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<1140502201644.61785A-100000@Ives.egh.com>
	<CAAAwwbVxcfujMmg+DJjhDLNB0eqdm8mMDzM5a-=5X8Lq5eg1VQ@mail.gmail.com>
	<CACrmG8enYfajpMfVaO0qji2=B3GHLRfhgQDXfzqPu_0Gi8v3UQ@mail.gmail.com>
	<CAAAwwbUAuoJyZaeDCpSYVg1r7etMXEJ=_sTg6fPTz0q=oJxCNQ@mail.gmail.com>
Message-ID: <CACrmG8eLBTU737S_oWentTx99ZAr5O9pV=XGiGRS-i_GMFgAEQ@mail.gmail.com>

On Sat, May 3, 2014 at 10:42 AM, Jimmy Hess <mysidia at gmail.com> wrote:
> On Fri, May 2, 2014 at 8:04 PM, Jeffrey Lyon
> <jeffrey.lyon at blacklotus.net> 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 technical improvements such as
> unnumbered interfaces, before host-based virtual hosting,  and  /31s
> as point to point links.  And  a greater utilization requirement may
> slow exhaustion.
>
> The number allows plenty of extra wiggle-room luxury, in addition to
> the occasional oddball patch which can't be allocated even in an
> efficient planned address allocation strategy,  which the free
> resources don't exist for, any longer.
>
> 80% in the aggregate criterion is unfairly strict against resource
> holders  that have  a small total allocation size.  And unfairly
> lenient against resource holders that have a large total allocation
> size.
>
> And removing the per-allocation utilization requirement would serve to
> exacerbate this problem.
>
> For example, under the current rules a holder of a /10 equivalent, can
>  call their existing allocations "efficiently utilized",   even if
> there are most recent allocation, an entire  contiguous /20s  has been
> completely untouched and unused.
>
> Whereas the resource holder that has a /20,   cannot have a single
> /23's worth  untouched.
>
> --
> -JH

Jimmy,

I think there is room to have that discussion but it should judged on
its own merits, independent of a proposal to change the calculation
*method*.

Thanks,
-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From rbf+arin-ppml at panix.com  Fri May  2 21:52:54 2014
From: rbf+arin-ppml at panix.com (Brett Frankenberger)
Date: Fri, 2 May 2014 20:52:54 -0500
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
	<18B2C6E38A3A324986B392B2D18ABC5102C779D4C0@fnb1mbx01.gci.com>
	<CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
Message-ID: <20140503015254.GA16654@panix.com>

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 should either be used or returned, before another
> request.

Or they could just renumber some subnets out of the very heavily used
/16 into the lightly used /21 and then be eligible for more space. 
Doing so would not violate policy, and their actual efficiency after
that exercise would be exactly what it was before that exercise.  But
they'd be able to get more space.

> Justified needs means you efficiently utilize _all_  allocations,  not
> just the last one you got,   not just the allocations you feel like
> using efficiently.

That's arbitrary.  The organization with a /16 and /21 effectively has
33 /21s.  To get more space, it has to use the 33rd /21 efficiently,
but gets to aggregate the other 32 /21s into a /16 for the efficient
utilization calculation.  Why are those 32 /21s special?  Because they
happen to be in the database as one /16 instead of 32 /21s?)

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?

(Also, I don't agree with the "back in my day we had to walk uphill
both ways in the snow" justification for maintaining the status quo.)

I support the proposal.

     -- Brett


From mysidia at gmail.com  Fri May  2 22:05:06 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 2 May 2014 21:05:06 -0500
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <20140503015254.GA16654@panix.com>
References: <CACrmG8eofs941spMQHAt=n_0V4YQ2PdDgFRAaY55AWDF4fp1iA@mail.gmail.com>
	<18B2C6E38A3A324986B392B2D18ABC5102C779D4C0@fnb1mbx01.gci.com>
	<CAAAwwbXzMF4MN+iDHdxAr7WGE+1qvNpJ5ECE8etMHWFn9Vt_4A@mail.gmail.com>
	<20140503015254.GA16654@panix.com>
Message-ID: <CAAAwwbXyL88r7tY5cG5LOLRXZrqT=MJv_ei7D7Ezpi2=NZKQSw@mail.gmail.com>

On Fri, May 2, 2014 at 8:52 PM, Brett Frankenberger
<rbf+arin-ppml at panix.com> 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 be OK.   I assert neither should be OK,
favoring the more rigorous justification criterion as better
stewardship.

And whether each individual allocation has to be utilized or not, the
calculation method, is inherently entangled with the utilization
criterion.

It may be more work (more required renumbering or greater cost / more
local router entries required)  to efficiently utilize the /21 hidden
inside the /16,   in case this is not a contiguous  /21,   but a
fragmented group of a few hundred /28s and /27s  spread around the
entire  /16  due to  lots of number releases over time, or an
ineffective allocation plan.


>      -- Brett
-- 
-JH


From james.duncan20 at yahoo.com  Sun May  4 10:40:22 2014
From: james.duncan20 at yahoo.com (james duncan)
Date: Sun, 4 May 2014 07:40:22 -0700 (PDT)
Subject: [arin-ppml]  Ip allocation
Message-ID: <1399214422.61186.YahooMailNeo@web140006.mail.bf1.yahoo.com>



Hello Derek and German,

In the final stage, even if we have ARIN?s policy, still, there?s unfairness in terms of locating the IP addresses. These are some of my thoughts, that I would like to share with all of you and hoping that we can bring people?s attention to this issue.
The IPV4 review team of ARIN obviously have different interpretations of the policy. For some cases, the review is all extremely strict; while on the other hand, some other cases, the review is very loose. And these applications actually don?t have a whole of differences.
In fact, there?s a mole or more moles inside the ARIN IPv4 review team, who cut some slacks for his or her associate applicants during the application review process, and granted them IP addresses or more. While for the applicants he or she don?t know personally, no matter how reasonable your application material, your ground for need of IP addresses are, they just won?t approve your application and grant you nothing but a big refusal. By doing this, this mole( or these moles) stocks these IP addresses by manipulating the policy and then plans to profit from it by selling the precious IP addresses to the market one year later.
I know John Curran would definitely stand up and defend their team.? Well, try to spend some time on ethic education on the review team, less time defending.
Now there?s only 0.99 /8 IP addresses left. I know some people would think they can still apply if they really need it, but the truth is they are ?pre-ordered? under ARIN?s inside arrangement. Funny thing is that every single time when anyone questions how they review applicants or they way they review, ARIN can always get away using NDA. ?
Each quarter, ARIN issues a fraud report to show the public that they?ve done this and that to prevent fraud, and not a single time have they ever disclosed any fraud incident. Either they?ve really done an ?amazing? job to prevent fraud or this so-called fraud report is auto-generated just for show, and no serious effort was ever made in terms of preventing or investigating fraud.

We are all grown-ups here, everyone knows how the game plays.

Sincerely,
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140504/1ec30d9b/attachment.htm>

From jcurran at arin.net  Sun May  4 12:21:17 2014
From: jcurran at arin.net (John Curran)
Date: Sun, 4 May 2014 16:21:17 +0000
Subject: [arin-ppml] Ip allocation
In-Reply-To: <1399214422.61186.YahooMailNeo@web140006.mail.bf1.yahoo.com>
References: <1399214422.61186.YahooMailNeo@web140006.mail.bf1.yahoo.com>
Message-ID: <32B6D619-0626-4341-B034-3397479A7970@arin.net>

On May 4, 2014, at 10:40 AM, james duncan <james.duncan20 at yahoo.com<mailto:james.duncan20 at yahoo.com>> wrote:

Hello Derek and German,

In the final stage, even if we have ARIN?s policy, still, there?s unfairness in terms of locating the IP addresses. These are some of my thoughts, that I would like to share with all of you and hoping that we can bring people?s attention to this issue.
The IPV4 review team of ARIN obviously have different interpretations of the policy. For some cases, the review is all extremely strict; while on the other hand, some other cases, the review is very loose. And these applications actually don?t have a whole of differences.

James -

As it turns out, the same criteria apply to all requests, but it is true that some parties
are more experienced with the policy and the processes for supplying providing the
supporting materials.

In fact, there?s a mole or more moles inside the ARIN IPv4 review team, who cut some slacks for his or her associate applicants during the application review process, and granted them IP addresses or more. While for the applicants he or she don?t know personally, no matter how reasonable your application material, your ground for need of IP addresses are, they just won?t approve your application and grant you nothing but a big refusal. By doing this, this mole( or these moles) stocks these IP addresses by manipulating the policy and then plans to profit from it by selling the precious IP addresses to the market one year later.

Interesting theory - note that all requests are subject to appeal (which is personally
reviewed by me) and further there is the opportunity for third-party arbitration if you
feel that the policy was incorrectly applied to your situation...
<https://www.arin.net/resources/resource_requests/appeal_process.html>
Care to explain how that did not work for your reasonable resource request?

Gven the second issue that you raise (possibility of a mole on the ARIN staff), I would
be happy to investigate, but if you'd prefer someone outside of the the staff, you also
have the option of supplying the relevant details to the ARIN Board of Trustees
<arin-board at arin.net<mailto:arin-board at arin.net>>, and I am certain that they would also take the issue quite
seriously.

I know John Curran would definitely stand up and defend their team.  Well, try to spend some time on ethic education on the review team, less time defending.

No point in defending - in fact, the only thing to be done is to perform a proper
investigation.  Please avail yourself of either of the options provided above so
that we may do so.  We do have a very strict ethics and conflict policy; have done
training in same, but none of that provides 100% assurance and hence my
request for your help.

Now there?s only 0.99 /8 IP addresses left. I know some people would think they can still apply if they really need it, but the truth is they are ?pre-ordered? under ARIN?s inside arrangement. Funny thing is that every single time when anyone questions how they review applicants or they way they review, ARIN can always get away using NDA.

"Pre-ordered" is an amazing concept, given that we neither know who is going to
request next, nor whether they will be approved.  As the person who handles the
appeals, I can state that those folks who seek appeal certainly don't know the result,
since I don't know it until I've reviewed the request and our processing against the
community-developed policy in laborious detail.  If there is a secret "pre-order"
queue, I've almost certainty disappointed some folks since it's certainly not
something I am aware (or nor part of appeal review process.)

Each quarter, ARIN issues a fraud report to show the public that they?ve done this and that to prevent fraud, and not a single time have they ever disclosed any fraud incident. Either they?ve really done an ?amazing? job to prevent fraud or this so-called fraud report is auto-generated just for show, and no serious effort was ever made in terms of preventing or investigating fraud.

The vast majority of reports that we receive are allegations of misuse of address
space (e.g. spamming); there is no policy prohibition against using IP addresses
for bulk unsolicited commercial email, so those reports are generally non-actionable.
We do followup on each report, and have detected resource hijacking and reverted
the changes when appropriate.  ( You can see all of the reports here:
<https://www.arin.net/resources/fraud/results/>)

If you believe that ARIN is improperly, I actively encourage you to bring the details
to my attention _or_ the ARIN Board of Trustees - you can find all of their email
addresses here: <https://www.arin.net/about_us/bot.html>

Thanks!
/John

John Curran
President and CEO
ARIN

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140504/ffc40f36/attachment.htm>

From rbf+arin-ppml at panix.com  Mon May  5 09:29:21 2014
From: rbf+arin-ppml at panix.com (Brett Frankenberger)
Date: Mon, 5 May 2014 08:29:21 -0500
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
Message-ID: <20140505132921.GA28854@panix.com>

On Fri, May 02, 2014 at 09:05:06PM -0500, Jimmy Hess wrote:
> On Fri, May 2, 2014 at 8:52 PM, Brett Frankenberger
> <rbf+arin-ppml at panix.com> 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 be OK.   I assert neither should be OK,
> favoring the more rigorous justification criterion as better
> stewardship.

Actually, I assert that both should be the same.  I agree with Jeff's
point that, for example, 32 /21s are the same whether you got them at
one time as part of a /16 or on 8 separate occasions as part of 8
separate /19s ... and that we should fix that, and, separately, if
there are problems with the utilization requirement (for example, if
80% is not stringent enough) that should be handled separately.

> And whether each individual allocation has to be utilized or not, the
> calculation method, is inherently entangled with the utilization
> criterion.
> 
> It may be more work (more required renumbering or greater cost / more
> local router entries required)  to efficiently utilize the /21 hidden
> inside the /16,   in case this is not a contiguous  /21,   but a
> fragmented group of a few hundred /28s and /27s  spread around the
> entire  /16  due to  lots of number releases over time, or an
> ineffective allocation plan.

Well, sure.  And perhaps policy should take into consideration not only
the utilization percentage, but also the distribution of the unused
space.  For a number of reasons, I disagree with that, but my point in
this thread is that it's separate from question of whether or not we
should calculate utilization differently for two organizations that
have exactly the same amount of address space and exactly the same
utilization, when one org got its address space as a smaller number of
larger blocks, and the other got its space as a larger number of
smaller blocks.

If the right thing to do is to count smaller blocks of unused space
differently from larger blocks of unused space, that should be a
separate proposal.

(Note that the contiguous free /21 is not the common case here.  The
more common case that is relevant to the proposal at hand here would be
the most recently assigned space being 50% or so utilized -- and
perhaps as fragmented as you describe above -- while all space that the
organization has been allocated, in aggregate, is well over 80%
utilized.)

     -- Brett


From billdarte at gmail.com  Mon May  5 15:14:44 2014
From: billdarte at gmail.com (Bill Darte)
Date: Mon, 5 May 2014 14:14:44 -0500
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
	Language
Message-ID: <CAMApp36hWBU=05a9LiLMJywHex=yG18Mos8R4vpf6Y_ZZD1faw@mail.gmail.com>

Should we abandon this Draft?

After the Chicago Public Policy Meeting, based upon the community's
suggestion that the AC continue to work on this Draft.  I sent an email to
PPML asking for support or opposition to this Draft and received just 2
responses....both in opposition.

I reiterate that PPML message below and once again ask for your support or
opposition. Failing to generate greater support for this Draft and given
that the AC has approximately 20 proposals and drafts on its docket.....I
plan to make a motion at the next AC monthly meeting recommending
abandoning this Draft Policy for lack of community support......

Now is your opportunity to convince the community that this a worthwhile
effort....or not.

Thanks,

Bill Darte
AC Shepherd for 2014-2


Draft Policy Issue:
Simply, the author wishes the Anti-Flip language currently used in the NRPM
to be relaxed, allowing an Inter-RIR transfer within their own organization
of previously existing addresses....though they may have received a new
allocation or assignment within the last 12 months.

Current draft language states that the organization may do such a transfer,
but may not use the actual addresses which were received from ARIN (or
through transfer) in the previous 12 months.  But they could therefore
transfer other resources holdings.

Request for feedback:
In order to further this discussion and gain a consensus, I would like to
once again ask the community to speak in favor or against this Draft Policy
so that it may be presented and discussed at our next Public Policy
Consultation at NANOG in June.

1. Yes or No.  Should the community relax existing policy which attempts to
limit the transfer of ARIN resources out of region, in order to allow an
organization flexibility to move address blocks to another portion of their
own organization in another region, even though they might have received
different addresses within ARIN in the last 12 months?

(Note current policy would still restrict availability of new addresses to
the organization for a period of 12 months after the transfer and is not
being changed by this draft).

2.  If YES above, are there any other qualifications or limits that should
be imposed on the resources transferred or the organization?

(Note that a vote of NO to question #1 would essentially ask the Advisory
Council to abandon this draft policy leaving existing policy in place.)

Thanks to all who continue to work within the community to exercise their
right and duty to craft appropriate policy guiding ARIN's important role in
Internet number resource management.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/55d822ef/attachment.htm>

From David.Huberman at microsoft.com  Mon May  5 15:32:18 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 5 May 2014 19:32:18 +0000
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4
	Anti-Flip	Language
In-Reply-To: <CAMApp36hWBU=05a9LiLMJywHex=yG18Mos8R4vpf6Y_ZZD1faw@mail.gmail.com>
References: <CAMApp36hWBU=05a9LiLMJywHex=yG18Mos8R4vpf6Y_ZZD1faw@mail.gmail.com>
Message-ID: <00c1dcf529784e0d86445053be144359@DM2PR03MB398.namprd03.prod.outlook.com>

From the ARIN 33 meeting notes:

"At the end of discussion, the moderator asked for the following straw poll (remote participants were invited to participate). Poll results were provided to the Advisory Council for use in its deliberations.
Straw poll for/against continuing work on the proposal:
- Total attendees/remote participants: 103
- In favor: 36
- Against: 2 "

The participating members of this community spoke widely in favor of working on this.  Abandoning this seems contrary to the explicit wishes of the community's participants

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Darte
Sent: Monday, May 5, 2014 12:15 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip Language

Should we abandon this Draft?

After the Chicago Public Policy Meeting, based upon the community's suggestion that the AC continue to work on this Draft. ?I sent an email to PPML asking for support or opposition to this Draft and received just 2 responses....both in opposition.

I reiterate that PPML message below and once again ask for your support or opposition. Failing to generate greater support for this Draft and given that the AC has approximately 20 proposals and drafts on its docket.....I plan to make a motion at the next AC monthly meeting recommending abandoning this Draft Policy for lack of community support......

Now is your opportunity to convince the community that this a worthwhile effort....or not.

Thanks,

Bill Darte
AC Shepherd for 2014-2


Draft Policy Issue:
Simply, the author wishes the Anti-Flip language currently used in the NRPM to be relaxed, allowing an Inter-RIR transfer within their own organization of previously existing addresses....though they may have received a new allocation or assignment within the last 12 months.

Current draft language states that the organization may do such a transfer, but may not use the actual addresses which were received from ARIN (or through transfer) in the previous 12 months. ?But they could therefore transfer other resources holdings.

Request for feedback:
In order to further this discussion and gain a consensus, I would like to once again ask the community to speak in favor or against this Draft Policy so that it may be presented and discussed at our next Public Policy Consultation at NANOG in June.

1. Yes or No. ?Should the community relax existing policy which attempts to limit the transfer of ARIN resources out of region, in order to allow an organization flexibility to move address blocks to another portion of their own organization in another region, even though they might have received different addresses within ARIN in the last 12 months??

(Note current policy would still restrict availability of new addresses to the organization for a period of 12 months after the transfer and is not being changed by this draft).

2. ?If YES above, are there any other qualifications or limits that should be imposed on the resources transferred or the organization?

(Note that a vote of NO to question #1 would essentially ask the Advisory Council to abandon this draft policy leaving existing policy in place.)

Thanks to all who continue to work within the community to exercise their right and duty to craft appropriate policy guiding ARIN's important role in Internet number resource management.

From billdarte at gmail.com  Mon May  5 16:00:06 2014
From: billdarte at gmail.com (Bill Darte)
Date: Mon, 5 May 2014 15:00:06 -0500
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
	Language
In-Reply-To: <00c1dcf529784e0d86445053be144359@DM2PR03MB398.namprd03.prod.outlook.com>
References: <CAMApp36hWBU=05a9LiLMJywHex=yG18Mos8R4vpf6Y_ZZD1faw@mail.gmail.com>
	<00c1dcf529784e0d86445053be144359@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAMApp34J+dsvregSt7gSQeG-=uSBfgV_+QiDN_VPDgAg6pkq6Q@mail.gmail.com>

Yes....a significant vote in favor or continuing to work on it...but I have
asked...now repeatedly for support for the language or suggested
improvements to the language..... nada.

I do not wish to abandon, I wish to create good policy that the community
supports.

I await the community's affirmation that this draft is worthy of continuing
support.

bd


On Mon, May 5, 2014 at 2:32 PM, David Huberman <David.Huberman at microsoft.com
> wrote:

> From the ARIN 33 meeting notes:
>
> "At the end of discussion, the moderator asked for the following straw
> poll (remote participants were invited to participate). Poll results were
> provided to the Advisory Council for use in its deliberations.
> Straw poll for/against continuing work on the proposal:
> - Total attendees/remote participants: 103
> - In favor: 36
> - Against: 2 "
>
> The participating members of this community spoke widely in favor of
> working on this.  Abandoning this seems contrary to the explicit wishes of
> the community's participants
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Bill Darte
> Sent: Monday, May 5, 2014 12:15 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
> Language
>
> Should we abandon this Draft?
>
> After the Chicago Public Policy Meeting, based upon the community's
> suggestion that the AC continue to work on this Draft.  I sent an email to
> PPML asking for support or opposition to this Draft and received just 2
> responses....both in opposition.
>
> I reiterate that PPML message below and once again ask for your support or
> opposition. Failing to generate greater support for this Draft and given
> that the AC has approximately 20 proposals and drafts on its docket.....I
> plan to make a motion at the next AC monthly meeting recommending
> abandoning this Draft Policy for lack of community support......
>
> Now is your opportunity to convince the community that this a worthwhile
> effort....or not.
>
> Thanks,
>
> Bill Darte
> AC Shepherd for 2014-2
>
>
> Draft Policy Issue:
> Simply, the author wishes the Anti-Flip language currently used in the
> NRPM to be relaxed, allowing an Inter-RIR transfer within their own
> organization of previously existing addresses....though they may have
> received a new allocation or assignment within the last 12 months.
>
> Current draft language states that the organization may do such a
> transfer, but may not use the actual addresses which were received from
> ARIN (or through transfer) in the previous 12 months.  But they could
> therefore transfer other resources holdings.
>
> Request for feedback:
> In order to further this discussion and gain a consensus, I would like to
> once again ask the community to speak in favor or against this Draft Policy
> so that it may be presented and discussed at our next Public Policy
> Consultation at NANOG in June.
>
> 1. Yes or No.  Should the community relax existing policy which attempts
> to limit the transfer of ARIN resources out of region, in order to allow an
> organization flexibility to move address blocks to another portion of their
> own organization in another region, even though they might have received
> different addresses within ARIN in the last 12 months?
>
> (Note current policy would still restrict availability of new addresses to
> the organization for a period of 12 months after the transfer and is not
> being changed by this draft).
>
> 2.  If YES above, are there any other qualifications or limits that should
> be imposed on the resources transferred or the organization?
>
> (Note that a vote of NO to question #1 would essentially ask the Advisory
> Council to abandon this draft policy leaving existing policy in place.)
>
> Thanks to all who continue to work within the community to exercise their
> right and duty to craft appropriate policy guiding ARIN's important role in
> Internet number resource management.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/aac14efe/attachment.htm>

From bill at herrin.us  Mon May  5 16:15:03 2014
From: bill at herrin.us (William Herrin)
Date: Mon, 5 May 2014 16:15:03 -0400
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
	Language
In-Reply-To: <00c1dcf529784e0d86445053be144359@DM2PR03MB398.namprd03.prod.outlook.com>
References: <CAMApp36hWBU=05a9LiLMJywHex=yG18Mos8R4vpf6Y_ZZD1faw@mail.gmail.com>
	<00c1dcf529784e0d86445053be144359@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAP-guGUjyo7Lpn-Uc12j0AHQV6Kh_etpo8V3YbHKEoyRrA70qw@mail.gmail.com>

On Mon, May 5, 2014 at 3:32 PM, David Huberman
<David.Huberman at microsoft.com> wrote:
> "At the end of discussion, the moderator asked for the following straw poll (remote participants were invited to participate). Poll results were provided to the Advisory Council for use in its deliberations.
> Straw poll for/against continuing work on the proposal:
> - Total attendees/remote participants: 103
> - In favor: 36
> - Against: 2 "
>
> The participating members of this community spoke widely
> in favor of working on this.  Abandoning this seems contrary
> to the explicit wishes of the community's participants

Hi David,

What do you suggest as the next step? Bill rightly points out that he
got only two responses to his query, both against the proposal.

>From my point of view, the original language works as desired. The
proposed language creates a revolving door for addresses -- get some
new ones from the free pool and sell some old ones to foreign
organizations. Given than addresses can be used by a subsidiary
without any harm to the parent and without changing the registration,
the direct need for this proposal is only slightly above nonexistent.
The problem isn't real. So it's stated function is a no-op while the
abuse function for someone ready to navigate the byzantine depths of
ARIN policy is substantial.

Call me crazy, but I think the 36 who asked for further work really
want a more generalized relaxation of ARIN transfer policies. Call
their votes an expression of frustration. Personally, I think relaxing
the needs test for transfers is worthy of more discussion. The
back-door approach in 2014-2 is not.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From michael at linuxmagic.com  Mon May  5 17:13:36 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Mon, 05 May 2014 14:13:36 -0700
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
 Language
In-Reply-To: <CAMApp34J+dsvregSt7gSQeG-=uSBfgV_+QiDN_VPDgAg6pkq6Q@mail.gmail.com>
References: <CAMApp36hWBU=05a9LiLMJywHex=yG18Mos8R4vpf6Y_ZZD1faw@mail.gmail.com>	<00c1dcf529784e0d86445053be144359@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAMApp34J+dsvregSt7gSQeG-=uSBfgV_+QiDN_VPDgAg6pkq6Q@mail.gmail.com>
Message-ID: <5367FF00.6090005@linuxmagic.com>

On 14-05-05 01:00 PM, Bill Darte wrote:
> 1. Yes or No.  Should the community relax existing policy which attempts
> to limit the transfer of ARIN resources out of region, in order to allow
> an organization flexibility to move address blocks to another portion of
> their own organization in another region, even though they might have
> received different addresses within ARIN in the last 12 months?

I see that it 'could' also be used to try to get around restrictions 
meant to prevent abuse..

While I can understand the case in theory for it, without seeing the 
language that controls the ability for 'pseudo' organizations, or 
organizations that are forged/created strictly to bypass current 
restrictions, I cannot comment in support of this.

The lack of comment might mean that while supported in principle at the 
CPPM, maybe it isn't supported enough, or the feeling is that it is 
supported, but not strongly supported.

Maybe with the whole language of the 'exemption' reasons has to be in 
place to get stronger support.


-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From David.Huberman at microsoft.com  Mon May  5 17:12:50 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 5 May 2014 21:12:50 +0000
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
 Language
In-Reply-To: <CAP-guGUjyo7Lpn-Uc12j0AHQV6Kh_etpo8V3YbHKEoyRrA70qw@mail.gmail.com>
References: <CAMApp36hWBU=05a9LiLMJywHex=yG18Mos8R4vpf6Y_ZZD1faw@mail.gmail.com>
	<00c1dcf529784e0d86445053be144359@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAP-guGUjyo7Lpn-Uc12j0AHQV6Kh_etpo8V3YbHKEoyRrA70qw@mail.gmail.com>
Message-ID: <4c047e203b6c4f1e81bd49f6edc0118e@DM2PR03MB398.namprd03.prod.outlook.com>

Bill Herrin wrote:

> What do you suggest as the next step? 
[snip]
> From my point of view, the original language works as desired.

Are you sure? I typed out an entire simplistic gaming technique so that speculators and flippers can easily achieve their goals in the existing language. I backspaced it from this reply so I didn't teach those folks, even though it's my most powerful argument: that the existing language is no-op for anyone who puts a few minutes of thought into getting around it.

At the same time, the existing language is restricting global network operators from moving blocks to different RIRs for various reasons, including geolocation and tax purposes. 

What do I suggest? I suggest we scrap the section altogether, as it affords the community no meaningful protection against those who wish to game it, and it impedes proper administration for global network operators.


From ajs at anvilwalrusden.com  Mon May  5 17:47:31 2014
From: ajs at anvilwalrusden.com (Andrew Sullivan)
Date: Mon, 5 May 2014 17:47:31 -0400
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
 Language
In-Reply-To: <4c047e203b6c4f1e81bd49f6edc0118e@DM2PR03MB398.namprd03.prod.outlook.com>
References: <CAMApp36hWBU=05a9LiLMJywHex=yG18Mos8R4vpf6Y_ZZD1faw@mail.gmail.com>
	<00c1dcf529784e0d86445053be144359@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAP-guGUjyo7Lpn-Uc12j0AHQV6Kh_etpo8V3YbHKEoyRrA70qw@mail.gmail.com>
	<4c047e203b6c4f1e81bd49f6edc0118e@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <20140505214730.GD4924@mx1.yitter.info>

On Mon, May 05, 2014 at 09:12:50PM +0000, David Huberman wrote:
> 
> What do I suggest? I suggest we scrap the section altogether, as it affords the community no meaningful protection against those who wish to game it, and it impedes proper administration for global network operators.
> 

FWIW, that's my impression too.  

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com


From scottleibrand at gmail.com  Mon May  5 17:48:15 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 5 May 2014 14:48:15 -0700
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
	Language
In-Reply-To: <CAMApp34J+dsvregSt7gSQeG-=uSBfgV_+QiDN_VPDgAg6pkq6Q@mail.gmail.com>
References: <CAMApp36hWBU=05a9LiLMJywHex=yG18Mos8R4vpf6Y_ZZD1faw@mail.gmail.com>
	<00c1dcf529784e0d86445053be144359@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAMApp34J+dsvregSt7gSQeG-=uSBfgV_+QiDN_VPDgAg6pkq6Q@mail.gmail.com>
Message-ID: <CAGkMwz44=YNLCSRtdyRer5pPYEBxGJ88OoHsuk5yz1SgCaXNqA@mail.gmail.com>

I think David is right here: the community has asked us to keep working on
this and come up with a better draft.

My own personal opinion (not speaking for anyone else) is:

1. YES, it should be perfectly acceptable for an organization to transfer
their IP space to the RIR responsible for the region in which they are
using it.

2. If an organization has received address space from the ARIN free pool
within the last 12 months, they should still be able to transfer address
space to their own subsidiaries.

Bill Herrin makes a good point: many of the ideas we've been discussing in
the context of 2014-2 are really a more general relaxation of transfer
policies, and probably should be considered separately.  However, I think
that statement (#2 above) represents something pretty close to the
consensus I heard in Chicago.  Given that it also addresses the 2014-2
problem statement, I think that might be the direction we need to be going
here.  Thoughts?

-Scott





On Mon, May 5, 2014 at 1:00 PM, Bill Darte <billdarte at gmail.com> wrote:

> Yes....a significant vote in favor or continuing to work on it...but I
> have asked...now repeatedly for support for the language or suggested
> improvements to the language..... nada.
>
> I do not wish to abandon, I wish to create good policy that the community
> supports.
>
> I await the community's affirmation that this draft is worthy of
> continuing support.
>
> bd
>
>
> On Mon, May 5, 2014 at 2:32 PM, David Huberman <
> David.Huberman at microsoft.com> wrote:
>
>> From the ARIN 33 meeting notes:
>>
>> "At the end of discussion, the moderator asked for the following straw
>> poll (remote participants were invited to participate). Poll results were
>> provided to the Advisory Council for use in its deliberations.
>> Straw poll for/against continuing work on the proposal:
>> - Total attendees/remote participants: 103
>> - In favor: 36
>> - Against: 2 "
>>
>> The participating members of this community spoke widely in favor of
>> working on this.  Abandoning this seems contrary to the explicit wishes of
>> the community's participants
>>
>> David R Huberman
>> Microsoft Corporation
>> Senior IT/OPS Program Manager (GFS)
>>
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Bill Darte
>> Sent: Monday, May 5, 2014 12:15 PM
>> To: arin-ppml at arin.net
>> Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
>> Language
>>
>> Should we abandon this Draft?
>>
>> After the Chicago Public Policy Meeting, based upon the community's
>> suggestion that the AC continue to work on this Draft.  I sent an email to
>> PPML asking for support or opposition to this Draft and received just 2
>> responses....both in opposition.
>>
>> I reiterate that PPML message below and once again ask for your support
>> or opposition. Failing to generate greater support for this Draft and given
>> that the AC has approximately 20 proposals and drafts on its docket.....I
>> plan to make a motion at the next AC monthly meeting recommending
>> abandoning this Draft Policy for lack of community support......
>>
>> Now is your opportunity to convince the community that this a worthwhile
>> effort....or not.
>>
>> Thanks,
>>
>> Bill Darte
>> AC Shepherd for 2014-2
>>
>>
>> Draft Policy Issue:
>> Simply, the author wishes the Anti-Flip language currently used in the
>> NRPM to be relaxed, allowing an Inter-RIR transfer within their own
>> organization of previously existing addresses....though they may have
>> received a new allocation or assignment within the last 12 months.
>>
>> Current draft language states that the organization may do such a
>> transfer, but may not use the actual addresses which were received from
>> ARIN (or through transfer) in the previous 12 months.  But they could
>> therefore transfer other resources holdings.
>>
>> Request for feedback:
>> In order to further this discussion and gain a consensus, I would like to
>> once again ask the community to speak in favor or against this Draft Policy
>> so that it may be presented and discussed at our next Public Policy
>> Consultation at NANOG in June.
>>
>> 1. Yes or No.  Should the community relax existing policy which attempts
>> to limit the transfer of ARIN resources out of region, in order to allow an
>> organization flexibility to move address blocks to another portion of their
>> own organization in another region, even though they might have received
>> different addresses within ARIN in the last 12 months?
>>
>> (Note current policy would still restrict availability of new addresses
>> to the organization for a period of 12 months after the transfer and is not
>> being changed by this draft).
>>
>> 2.  If YES above, are there any other qualifications or limits that
>> should be imposed on the resources transferred or the organization?
>>
>> (Note that a vote of NO to question #1 would essentially ask the Advisory
>> Council to abandon this draft policy leaving existing policy in place.)
>>
>> Thanks to all who continue to work within the community to exercise their
>> right and duty to craft appropriate policy guiding ARIN's important role in
>> Internet number resource management.
>>
>
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/0baa4115/attachment.htm>

From bill at herrin.us  Mon May  5 18:12:43 2014
From: bill at herrin.us (William Herrin)
Date: Mon, 5 May 2014 18:12:43 -0400
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
	Language
In-Reply-To: <CAGkMwz44=YNLCSRtdyRer5pPYEBxGJ88OoHsuk5yz1SgCaXNqA@mail.gmail.com>
References: <CAMApp36hWBU=05a9LiLMJywHex=yG18Mos8R4vpf6Y_ZZD1faw@mail.gmail.com>
	<00c1dcf529784e0d86445053be144359@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAMApp34J+dsvregSt7gSQeG-=uSBfgV_+QiDN_VPDgAg6pkq6Q@mail.gmail.com>
	<CAGkMwz44=YNLCSRtdyRer5pPYEBxGJ88OoHsuk5yz1SgCaXNqA@mail.gmail.com>
Message-ID: <CAP-guGXc+Wakjqm+kJcnzwdoK8y_znROd5aPEoccC9OLvKe1=Q@mail.gmail.com>

On Mon, May 5, 2014 at 5:48 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> Bill Herrin makes a good point: many of the ideas we've been discussing in
> the context of 2014-2 are really a more general relaxation of transfer
> policies, and probably should be considered separately.  However, I think
> that statement (#2 above) represents something pretty close to the consensus
> I heard in Chicago.  Given that it also addresses the 2014-2 problem
> statement, I think that might be the direction we need to be going here.
> Thoughts?

Hi Scott,

That defeats the anti-flipping provisions entirely. It costs all of a
couple hundred dollars ($2000 if you jump through -all- the hoops) to
create a subsidiary. It's trivial. You then sell the subsidiary
replete with addresses. The buyer doesn't even have to register
separately with the RIR. $10 domain name for the POC and google voice
account included.

Worse, as implemented in this proposal it creates an unfair bias
favoring out-migration of addresses since transfers to subsidiaries
within the region are covered by a different policy. This policy
proposal is biased against the domestic folks it is ARIN's core
mission to serve!

My view now is the same as it was in February:

http://lists.arin.net/pipermail/arin-ppml/2014-February/027835.html

"Loopholes = bad. Allow open transfers or don't, but please don't
create loopholes for folks to abuse."

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From sandrabrown at ipv4marketgroup.com  Mon May  5 19:23:42 2014
From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com)
Date: Mon, 05 May 2014 16:23:42 -0700
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
	Language
Message-ID: <20140505162342.ec289651d84890fcbef5f195936e1217.407e051ae1.wbe@email17.secureserver.net>

I support the policy in that it helps companies in the region and I do
not see any harm to any entities in the region. The problem David
Huberman is trying to solve is that there are IP's being used out of
region, and we all know out of region use has lots of geo-location
issues, and for some companies, routing issues, and he needs these IP's
to be registered in the region they are used. Coupled with the fact
there would not be any IP's available to his company from the free pool
for the next 12 months, there is no harm.  

The only thing we don't know is whether this is a one-off problem, or
whether other companies have the same issue.  I would think other
companies have the same problem but are not commenting.  I suspect the
people at ARIN33 felt the problem should be solved, but that it didn't
apply to them so they are not being as vocal now.  The shepherds could
contact companies with a profile similar to David Huberman's and see if
it would be of service to them. 

It would seem that the more freedom there is to transfer IP's between
registries, the easier it will be to conduct business globally, and the
more critical the role of the RIR in the future.  

It is not a harmful policy.

Sandra Brown
IPv4 Market Group.


Should we abandon this Draft?

After the Chicago Public Policy Meeting, based upon the community's
suggestion that the AC continue to work on this Draft. ?I sent an email
to PPML asking for support or opposition to this Draft and received just
2 responses....both in opposition.

I reiterate that PPML message below and once again ask for your support
or opposition. Failing to generate greater support for this Draft and
given that the AC has approximately 20 proposals and drafts on its
docket.....I plan to make a motion at the next AC monthly meeting
recommending abandoning this Draft Policy for lack of community
support......

Now is your opportunity to convince the community that this a worthwhile
effort....or not.

Thanks,

Bill Darte
AC Shepherd for 2014-2


Draft Policy Issue:
Simply, the author wishes the Anti-Flip language currently used in the
NRPM to be relaxed, allowing an Inter-RIR transfer within their own
organization of previously existing addresses....though they may have
received a new allocation or assignment within the last 12 months.

Current draft language states that the organization may do such a
transfer, but may not use the actual addresses which were received from
ARIN (or through transfer) in the previous 12 months. ?But they could
therefore transfer other resources holdings.

Request for feedback:
In order to further this discussion and gain a consensus, I would like
to once again ask the community to speak in favor or against this Draft
Policy so that it may be presented and discussed at our next Public
Policy Consultation at NANOG in June.

1. Yes or No. ?Should the community relax existing policy which attempts
to limit the transfer of ARIN resources out of region, in order to allow
an organization flexibility to move address blocks to another portion of
their own organization in another region, even though they might have
received different addresses within ARIN in the last 12 months??

(Note current policy would still restrict availability of new addresses
to the organization for a period of 12 months after the transfer and is
not being changed by this draft).

2. ?If YES above, are there any other qualifications or limits that
should be imposed on the resources transferred or the organization?

(Note that a vote of NO to question #1 would essentially ask the
Advisory Council to abandon this draft policy leaving existing policy in
place.)

Thanks to all who continue to work within the community to exercise
their right and duty to craft appropriate policy guiding ARIN's
important role in Internet number resource management.




From mpetach at netflight.com  Mon May  5 19:36:43 2014
From: mpetach at netflight.com (Matthew Petach)
Date: Mon, 5 May 2014 16:36:43 -0700
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
	Language
In-Reply-To: <20140505162342.ec289651d84890fcbef5f195936e1217.407e051ae1.wbe@email17.secureserver.net>
References: <20140505162342.ec289651d84890fcbef5f195936e1217.407e051ae1.wbe@email17.secureserver.net>
Message-ID: <CAEmG1=o3C=WsfhjM+d4EXpPwdk6ExKnYSkQo9iqBv6wUai0eRQ@mail.gmail.com>

On Mon, May 5, 2014 at 4:23 PM, <sandrabrown at ipv4marketgroup.com> wrote:

> [...]
> The only thing we don't know is whether this is a one-off problem, or
> whether other companies have the same issue.  I would think other
> companies have the same problem but are not commenting.  I suspect the
> people at ARIN33 felt the problem should be solved, but that it didn't
> apply to them so they are not being as vocal now.  The shepherds could
> contact companies with a profile similar to David Huberman's and see if
> it would be of service to them.
>

I suspect the number of companies with a profile
similar to Microsoft's can be counted on one hand.  ^_^;

I have no qualms about shuffling addresses to wherever
they may be needed around the planet, regardless of where
they were first issued, so I haven't spoken up about this
policy, because I think it's a solution in search of a
problem.  Do others feel constrained to use IP space
only in one region?

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/bada2b91/attachment.htm>

From owen at delong.com  Mon May  5 19:41:09 2014
From: owen at delong.com (Owen DeLong)
Date: Mon, 5 May 2014 16:41:09 -0700
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
	Language
In-Reply-To: <20140505162342.ec289651d84890fcbef5f195936e1217.407e051ae1.wbe@email17.secureserver.net>
References: <20140505162342.ec289651d84890fcbef5f195936e1217.407e051ae1.wbe@email17.secureserver.net>
Message-ID: <664CD85F-9286-4C7E-85A1-2C988AC28FC6@delong.com>

Given that the existing wording definitely had a lack of consensus and that there has been no proposed wording to address the issues raised by the community, unless someone has a proposal for wording that is more likely to gain consensus, I am inclined to support Bill?s idea of abandoning this proposal.

Reiterating support for the existing failed language is not useful in this context. The community as a whole clearly did not achieve consensus on this language.

There has been very limited support expressed for the idea in general.

Owen

On May 5, 2014, at 4:23 PM, <sandrabrown at ipv4marketgroup.com> <sandrabrown at ipv4marketgroup.com> wrote:

> I support the policy in that it helps companies in the region and I do
> not see any harm to any entities in the region. The problem David
> Huberman is trying to solve is that there are IP's being used out of
> region, and we all know out of region use has lots of geo-location
> issues, and for some companies, routing issues, and he needs these IP's
> to be registered in the region they are used. Coupled with the fact
> there would not be any IP's available to his company from the free pool
> for the next 12 months, there is no harm.  
> 
> The only thing we don't know is whether this is a one-off problem, or
> whether other companies have the same issue.  I would think other
> companies have the same problem but are not commenting.  I suspect the
> people at ARIN33 felt the problem should be solved, but that it didn't
> apply to them so they are not being as vocal now.  The shepherds could
> contact companies with a profile similar to David Huberman's and see if
> it would be of service to them. 
> 
> It would seem that the more freedom there is to transfer IP's between
> registries, the easier it will be to conduct business globally, and the
> more critical the role of the RIR in the future.  
> 
> It is not a harmful policy.
> 
> Sandra Brown
> IPv4 Market Group.
> 
> 
> Should we abandon this Draft?
> 
> After the Chicago Public Policy Meeting, based upon the community's
> suggestion that the AC continue to work on this Draft. ?I sent an email
> to PPML asking for support or opposition to this Draft and received just
> 2 responses....both in opposition.
> 
> I reiterate that PPML message below and once again ask for your support
> or opposition. Failing to generate greater support for this Draft and
> given that the AC has approximately 20 proposals and drafts on its
> docket.....I plan to make a motion at the next AC monthly meeting
> recommending abandoning this Draft Policy for lack of community
> support......
> 
> Now is your opportunity to convince the community that this a worthwhile
> effort....or not.
> 
> Thanks,
> 
> Bill Darte
> AC Shepherd for 2014-2
> 
> 
> Draft Policy Issue:
> Simply, the author wishes the Anti-Flip language currently used in the
> NRPM to be relaxed, allowing an Inter-RIR transfer within their own
> organization of previously existing addresses....though they may have
> received a new allocation or assignment within the last 12 months.
> 
> Current draft language states that the organization may do such a
> transfer, but may not use the actual addresses which were received from
> ARIN (or through transfer) in the previous 12 months. ?But they could
> therefore transfer other resources holdings.
> 
> Request for feedback:
> In order to further this discussion and gain a consensus, I would like
> to once again ask the community to speak in favor or against this Draft
> Policy so that it may be presented and discussed at our next Public
> Policy Consultation at NANOG in June.
> 
> 1. Yes or No. ?Should the community relax existing policy which attempts
> to limit the transfer of ARIN resources out of region, in order to allow
> an organization flexibility to move address blocks to another portion of
> their own organization in another region, even though they might have
> received different addresses within ARIN in the last 12 months??
> 
> (Note current policy would still restrict availability of new addresses
> to the organization for a period of 12 months after the transfer and is
> not being changed by this draft).
> 
> 2. ?If YES above, are there any other qualifications or limits that
> should be imposed on the resources transferred or the organization?
> 
> (Note that a vote of NO to question #1 would essentially ask the
> Advisory Council to abandon this draft policy leaving existing policy in
> place.)
> 
> Thanks to all who continue to work within the community to exercise
> their right and duty to craft appropriate policy guiding ARIN's
> important role in Internet number resource management.
> 
> 
> _______________________________________________
> 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.



From farmer at umn.edu  Mon May  5 20:28:43 2014
From: farmer at umn.edu (David Farmer)
Date: Mon, 05 May 2014 19:28:43 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <5351A972.6000702@umn.edu>
References: <5331CA99.2000806@arin.net> <5351A972.6000702@umn.edu>
Message-ID: <53682CBB.3080800@umn.edu>

I also realized that "and prohibit LOA's without allocations" needed to 
be removed from the description of the policy statement, for much the 
same reason as #2 below.  The annotated text below has been modified to 
strike-through this text as well.  There are no changes to the policy 
text that would go in the NRPM.  Also included below is a final clean 
version of the text.

If there are any comments, please get them in soon, otherwise I'll 
assume continued support for this draft as modified.

Thanks.

On 4/18/14, 17:38 , David Farmer wrote:
>
> Draft Policy ARIN-2014-12 "Anti-hijack Policy," was discussed at ARIN 
> 33 in Chicago this week, it was generally supported. However, there 
> were two modifications to the Policy Text suggested;
>
> 1.  In the first paragraph; change "previously" to "currently".
>
> 2.  Remove the last sentence of the second paragraph;  This sentence 
> implies that ARIN should issue an LOA, where as ARIN should NOT issue 
> any LOA at all, expect for resources assigned to ARIN for its 
> operational use. ARIN should record the allocation to the receiving 
> organization in its public database, then the organization with the 
> allocation may issue any LOA necessary.
>
> Are there any additional comments or suggestions for the AC to consider?
>
> Otherwise, the AC will consider the advancement of the modified text 
> to Recommended Draft Policy status.
>
> -----
>
> Draft Policy ARIN-2014-12
> Anti-hijack Policy
>
> Problem Statement:
>
> ARIN should not give research organizations permission to hijack 
> prefixes that have already been allocated. Research organizations 
> announcing lit aggregates may receive sensitive production traffic 
> belonging to live networks during periods of instability.
>
> Section 11.7 describes more than allocation size therefore updating 
> the section heading to something more accurate is appropriate.
>
> Policy statement:
>
> Modify the section 11.7 heading to be more accurate. Modify the first 
> sentence to prohibit overlapping assignments. Add text at the end to 
> define how research allocations should be designated and prohibit 
> LOA's without allocations.
>
> Annotated text
>
> 11.7 Policy Text for NRPM
> Original 2014-12 Policy Text
> Proposed Changes to 2014-12 Policy Text
>
> 11.7 Resource Allocation SizeGuidelines
>
>
> The Numbering Resources requested come from the global Internet 
> Resource space, do not overlap previouslycurrentlyassigned space, and 
> are not from private or other non-routable Internet Resource space. 
> The allocation size should be consistent with the existing ARIN 
> minimum allocation sizes, unless small allocations are intended to be 
> explicitly part of the experiment. If an organization requires more 
> resource than stipulated by the minimum allocation sizes in force at 
> the time of their request, their experimental documentation should 
> have clearly described and justified why this is required.
>
> All research allocations must be registered publicly in whois. Each 
> research allocation will be designated as a research allocation with a 
> comment indicating when the allocation will end. ARIN will not issue a 
> Letter of Authority (LOA) to route a research prefix unless the 
> allocation is properly registered in whois.

Here is the final clean version of the text;

Draft Policy ARIN-2014-12: Anti-hijack Policy

Date: 5 May 2014

Problem Statement:

ARIN should not give research organizations permission to hijack prefixes that have already been allocated. Research organizations announcing lit aggregates may receive sensitive production traffic belonging to live networks during periods of instability.

Section 11.7 describes more than allocation size therefore updating the section heading to something more accurate is appropriate.

Policy statement:

Modify the section 11.7 heading to be more accurate. Modify the first sentence to prohibit overlapping assignments. Add text at the end to define how research allocations should be designated.

11.7 Resource Allocation Guidelines

The Numbering Resources requested come from the global Internet Resource space, do not overlap currently assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required.

All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end.

Comments:
a. Timetable for implementation: Immediate
b. Anything else:

-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/3edfeecc/attachment.htm>

From kevinb at thewire.ca  Mon May  5 21:44:55 2014
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Tue, 6 May 2014 01:44:55 +0000
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum Allocation/Assignment
	Units to /24
Message-ID: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>

I'm sending out a revised version of prop-208. Included is an attachment with a redline version to assist. 

I would appreciate any feedback of support or questions. 

Thanks,

Kevin Blumberg

ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24 
Proposal Originator: Owen DeLong
Date: 5 May 2014
Problem Statement: 
As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units for IPv4 to /24 across the board.

Policy statement:

Remove all references to minimum allocations /20 and /22 replacing them with the term allocation or with /24 when referencing minimum size blocks.

Change the title of 4.2.2.1 to "ISP Requirements" with revised text stating:?

All ISP organizations must satisfy the following requirements...thus eliminating the entire Multi-homed section and subsections along with other superfluous example text. 

Delete the special case allocations/assignments for the Caribbean as the new /24 minimums are an improvement.

Comments:
a. Timetable for implementation: Immediate b. A red line version has been included

Full text version of changes for easy reference:

4.2.1.5. Minimum allocation
In general, ARIN allocates /24 and larger IP address prefixes to ISPs. If allocations smaller than /24 are needed, ISPs should request address space from their upstream provider. 

4.2.2.1 ISP Requirements
All ISP organizations must satisfy the following requirements:

4.2.2.1.1 Use of /24
The efficient utilization of an entire previously allocated /24 from their upstream ISP. This allocation may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space.

4.2.2.1.4. Renumber and return
ISPs receiving a new allocation may wish to renumber out of their previously allocated space. In this case, an ISP must use the new allocation to renumber out of that previously allocated block of address space and must return the space to its upstream provider. 

4.2.2.2. [section number retired]

4.3.2 Minimum assignment

4.3.2.1. [section moved to 4.3.2]
The minimum block of IP address space assigned by ARIN to end-users is a /24. If assignments smaller than /24 are needed, end-users should contact their upstream provider. 

4.3.2.2 [section number retired]

4.9 [section number retired]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Proposal 208 Redline 2014-05-05.pdf
Type: application/pdf
Size: 76074 bytes
Desc: Proposal 208 Redline 2014-05-05.pdf
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140506/4ef93994/attachment.pdf>

From hannigan at gmail.com  Mon May  5 21:50:07 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 5 May 2014 21:50:07 -0400
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
Message-ID: <CAMDXq5PxCwoLH9bjvnK3oORB_0GqezpMtTsq4vUBCgK0Czf70g@mail.gmail.com>

Why couldn't the AC simply implement the changes that were massively agreed
upon here, as is -- which was also part of the discussion?


Best,

-M<




On Mon, May 5, 2014 at 9:44 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> I'm sending out a revised version of prop-208. Included is an attachment
> with a redline version to assist.
>
> I would appreciate any feedback of support or questions.
>
> Thanks,
>
> Kevin Blumberg
>
> ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24
> Proposal Originator: Owen DeLong
> Date: 5 May 2014
> Problem Statement:
> As we approach runout, more and more end users and smaller ISPs will be
> unable to obtain space from their upstreams and will be seeking space from
> ARIN. In order to meet these needs to the extent possible and to make
> policy more fair to a broader range of the ARIN constituency, we should
> reduce the minimum assignment and allocation units for IPv4 to /24 across
> the board.
>
> Policy statement:
>
> Remove all references to minimum allocations /20 and /22 replacing them
> with the term allocation or with /24 when referencing minimum size blocks.
>
> Change the title of 4.2.2.1 to "ISP Requirements" with revised text
> stating:
>
> All ISP organizations must satisfy the following requirements...thus
> eliminating the entire Multi-homed section and subsections along with other
> superfluous example text.
>
> Delete the special case allocations/assignments for the Caribbean as the
> new /24 minimums are an improvement.
>
> Comments:
> a. Timetable for implementation: Immediate b. A red line version has been
> included
>
> Full text version of changes for easy reference:
>
> 4.2.1.5. Minimum allocation
> In general, ARIN allocates /24 and larger IP address prefixes to ISPs. If
> allocations smaller than /24 are needed, ISPs should request address space
> from their upstream provider.
>
> 4.2.2.1 ISP Requirements
> All ISP organizations must satisfy the following requirements:
>
> 4.2.2.1.1 Use of /24
> The efficient utilization of an entire previously allocated /24 from their
> upstream ISP. This allocation may have been provided by an ISP's upstream
> provider(s), and does not have to be contiguous address space.
>
> 4.2.2.1.4. Renumber and return
> ISPs receiving a new allocation may wish to renumber out of their
> previously allocated space. In this case, an ISP must use the new
> allocation to renumber out of that previously allocated block of address
> space and must return the space to its upstream provider.
>
> 4.2.2.2. [section number retired]
>
> 4.3.2 Minimum assignment
>
> 4.3.2.1. [section moved to 4.3.2]
> The minimum block of IP address space assigned by ARIN to end-users is a
> /24. If assignments smaller than /24 are needed, end-users should contact
> their upstream provider.
>
> 4.3.2.2 [section number retired]
>
> 4.9 [section number retired]
>
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/5008436c/attachment.htm>

From owen at delong.com  Mon May  5 21:57:14 2014
From: owen at delong.com (Owen DeLong)
Date: Mon, 5 May 2014 18:57:14 -0700
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
	Allocation/Assignment Units to /24
In-Reply-To: <CAMDXq5PxCwoLH9bjvnK3oORB_0GqezpMtTsq4vUBCgK0Czf70g@mail.gmail.com>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
	<CAMDXq5PxCwoLH9bjvnK3oORB_0GqezpMtTsq4vUBCgK0Czf70g@mail.gmail.com>
Message-ID: <B2596208-D661-4088-B7C1-55D14D52557E@delong.com>

In short, because as specified, the changes ended up with the NRPM being somewhat nonsensical.

This revision does not change any of the original inent, preserves most of the original text of the proposal, and leaves the NRPM in tact with legible text after making the changes.

Do you have a problem with some specific aspect of the new version? If so, please enumerate it so we can address your concern.

Owen

On May 5, 2014, at 18:50 , Martin Hannigan <hannigan at gmail.com> wrote:

> 
> 
> Why couldn't the AC simply implement the changes that were massively agreed upon here, as is -- which was also part of the discussion?
> 
> 
> Best,
> 
> -M<
> 
> 
> 
> 
> On Mon, May 5, 2014 at 9:44 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:
> I'm sending out a revised version of prop-208. Included is an attachment with a redline version to assist.
> 
> I would appreciate any feedback of support or questions.
> 
> Thanks,
> 
> Kevin Blumberg
> 
> ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24
> Proposal Originator: Owen DeLong
> Date: 5 May 2014
> Problem Statement:
> As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units for IPv4 to /24 across the board.
> 
> Policy statement:
> 
> Remove all references to minimum allocations /20 and /22 replacing them with the term allocation or with /24 when referencing minimum size blocks.
> 
> Change the title of 4.2.2.1 to "ISP Requirements" with revised text stating: 
> 
> All ISP organizations must satisfy the following requirements...thus eliminating the entire Multi-homed section and subsections along with other superfluous example text.
> 
> Delete the special case allocations/assignments for the Caribbean as the new /24 minimums are an improvement.
> 
> Comments:
> a. Timetable for implementation: Immediate b. A red line version has been included
> 
> Full text version of changes for easy reference:
> 
> 4.2.1.5. Minimum allocation
> In general, ARIN allocates /24 and larger IP address prefixes to ISPs. If allocations smaller than /24 are needed, ISPs should request address space from their upstream provider.
> 
> 4.2.2.1 ISP Requirements
> All ISP organizations must satisfy the following requirements:
> 
> 4.2.2.1.1 Use of /24
> The efficient utilization of an entire previously allocated /24 from their upstream ISP. This allocation may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space.
> 
> 4.2.2.1.4. Renumber and return
> ISPs receiving a new allocation may wish to renumber out of their previously allocated space. In this case, an ISP must use the new allocation to renumber out of that previously allocated block of address space and must return the space to its upstream provider.
> 
> 4.2.2.2. [section number retired]
> 
> 4.3.2 Minimum assignment
> 
> 4.3.2.1. [section moved to 4.3.2]
> The minimum block of IP address space assigned by ARIN to end-users is a /24. If assignments smaller than /24 are needed, end-users should contact their upstream provider.
> 
> 4.3.2.2 [section number retired]
> 
> 4.9 [section number retired]
> 
> 
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/b1047d5c/attachment.htm>

From hannigan at gmail.com  Mon May  5 22:08:41 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 5 May 2014 22:08:41 -0400
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <B2596208-D661-4088-B7C1-55D14D52557E@delong.com>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
	<CAMDXq5PxCwoLH9bjvnK3oORB_0GqezpMtTsq4vUBCgK0Czf70g@mail.gmail.com>
	<B2596208-D661-4088-B7C1-55D14D52557E@delong.com>
Message-ID: <CAMDXq5OOfq8KUSWRB_Pi8j8xAcrkQB5G9yx4cGRo5_iCRwSCHQ@mail.gmail.com>

Estimated thirty changes to text. It appears that the AC just couldn't
resist modifying what we all agreed on en masse.

It'll take some time to evaluate all thirty plus changes. I'll reserve my
comments for the NANOG PPC in Bellevue.

Best,

-M<




On Mon, May 5, 2014 at 9:57 PM, Owen DeLong <owen at delong.com> wrote:

> In short, because as specified, the changes ended up with the NRPM being
> somewhat nonsensical.
>
> This revision does not change any of the original inent, preserves most of
> the original text of the proposal, and leaves the NRPM in tact with legible
> text after making the changes.
>
> Do you have a problem with some specific aspect of the new version? If so,
> please enumerate it so we can address your concern.
>
> Owen
>
> On May 5, 2014, at 18:50 , Martin Hannigan <hannigan at gmail.com> wrote:
>
>
>
> Why couldn't the AC simply implement the changes that were massively
> agreed upon here, as is -- which was also part of the discussion?
>
>
> Best,
>
> -M<
>
>
>
>
> On Mon, May 5, 2014 at 9:44 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:
>
>> I'm sending out a revised version of prop-208. Included is an attachment
>> with a redline version to assist.
>>
>> I would appreciate any feedback of support or questions.
>>
>> Thanks,
>>
>> Kevin Blumberg
>>
>> ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24
>> Proposal Originator: Owen DeLong
>> Date: 5 May 2014
>> Problem Statement:
>> As we approach runout, more and more end users and smaller ISPs will be
>> unable to obtain space from their upstreams and will be seeking space from
>> ARIN. In order to meet these needs to the extent possible and to make
>> policy more fair to a broader range of the ARIN constituency, we should
>> reduce the minimum assignment and allocation units for IPv4 to /24 across
>> the board.
>>
>> Policy statement:
>>
>> Remove all references to minimum allocations /20 and /22 replacing them
>> with the term allocation or with /24 when referencing minimum size blocks.
>>
>> Change the title of 4.2.2.1 to "ISP Requirements" with revised text
>> stating:
>>
>> All ISP organizations must satisfy the following requirements...thus
>> eliminating the entire Multi-homed section and subsections along with other
>> superfluous example text.
>>
>> Delete the special case allocations/assignments for the Caribbean as the
>> new /24 minimums are an improvement.
>>
>> Comments:
>> a. Timetable for implementation: Immediate b. A red line version has been
>> included
>>
>> Full text version of changes for easy reference:
>>
>> 4.2.1.5. Minimum allocation
>> In general, ARIN allocates /24 and larger IP address prefixes to ISPs. If
>> allocations smaller than /24 are needed, ISPs should request address space
>> from their upstream provider.
>>
>> 4.2.2.1 ISP Requirements
>> All ISP organizations must satisfy the following requirements:
>>
>> 4.2.2.1.1 Use of /24
>> The efficient utilization of an entire previously allocated /24 from
>> their upstream ISP. This allocation may have been provided by an ISP's
>> upstream provider(s), and does not have to be contiguous address space.
>>
>> 4.2.2.1.4. Renumber and return
>> ISPs receiving a new allocation may wish to renumber out of their
>> previously allocated space. In this case, an ISP must use the new
>> allocation to renumber out of that previously allocated block of address
>> space and must return the space to its upstream provider.
>>
>> 4.2.2.2. [section number retired]
>>
>> 4.3.2 Minimum assignment
>>
>> 4.3.2.1. [section moved to 4.3.2]
>> The minimum block of IP address space assigned by ARIN to end-users is a
>> /24. If assignments smaller than /24 are needed, end-users should contact
>> their upstream provider.
>>
>> 4.3.2.2 [section number retired]
>>
>> 4.9 [section number retired]
>>
>>
>> _______________________________________________
>> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/8275361b/attachment.htm>

From SRyerse at eclipse-networks.com  Mon May  5 22:14:09 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Tue, 6 May 2014 02:14:09 +0000
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4
 Anti-FlipLanguage
In-Reply-To: <20140505171021.ec289651d84890fcbef5f195936e1217.48a58b2797.wbe@email17.secureserver.net>
References: <20140505171021.ec289651d84890fcbef5f195936e1217.48a58b2797.wbe@email17.secureserver.net>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201532FE5DC@ENI-MAIL.eclipse-networks.com>

I support.


Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
www.eclipse-networks.com
770.656.1460 - Cell
770.399.9099- Office

[Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc.
        Conquering Complex Networks?

> On May 5, 2014, at 7:23 PM, "sandrabrown at ipv4marketgroup.com<mailto:sandrabrown at ipv4marketgroup.com>" <sandrabrown at ipv4marketgroup.com<mailto:sandrabrown at ipv4marketgroup.com>> wrote:
>
> I support the policy in that it helps companies in the region and I do
> not see any harm to any entities in the region. The problem David
> Huberman is trying to solve is that there are IP's being used out of
> region, and we all know out of region use has lots of geo-location
> issues, and for some companies, routing issues, and he needs these IP's
> to be registered in the region they are used. Coupled with the fact
> there would not be any IP's available to his company from the free pool
> for the next 12 months, there is no harm.
>
> The only thing we don't know is whether this is a one-off problem, or
> whether other companies have the same issue. I would think other
> companies have the same problem but are not commenting. I suspect the
> people at ARIN33 felt the problem should be solved, but that it didn't
> apply to them so they are not being as vocal now. The shepherds could
> contact companies with a profile similar to David Huberman's and see if
> it would be of service to them.
>
> It would seem that the more freedom there is to transfer IP's between
> registries, the easier it will be to conduct business globally, and the
> more critical the role of the RIR in the future.
>
> It is not a harmful policy.
>
> Sandra Brown
> IPv4 Market Group.
>
>
> Should we abandon this Draft?
>
> After the Chicago Public Policy Meeting, based upon the community's
> suggestion that the AC continue to work on this Draft. ?I sent an email
> to PPML asking for support or opposition to this Draft and received just
> 2 responses....both in opposition.
>
> I reiterate that PPML message below and once again ask for your support
> or opposition. Failing to generate greater support for this Draft and
> given that the AC has approximately 20 proposals and drafts on its
> docket.....I plan to make a motion at the next AC monthly meeting
> recommending abandoning this Draft Policy for lack of community
> support......
>
> Now is your opportunity to convince the community that this a worthwhile
> effort....or not.
>
> Thanks,
>
> Bill Darte
> AC Shepherd for 2014-2
>
>
> Draft Policy Issue:
> Simply, the author wishes the Anti-Flip language currently used in the
> NRPM to be relaxed, allowing an Inter-RIR transfer within their own
> organization of previously existing addresses....though they may have
> received a new allocation or assignment within the last 12 months.
>
> Current draft language states that the organization may do such a
> transfer, but may not use the actual addresses which were received from
> ARIN (or through transfer) in the previous 12 months. ?But they could
> therefore transfer other resources holdings.
>
> Request for feedback:
> In order to further this discussion and gain a consensus, I would like
> to once again ask the community to speak in favor or against this Draft
> Policy so that it may be presented and discussed at our next Public
> Policy Consultation at NANOG in June.
>
> 1. Yes or No. ?Should the community relax existing policy which attempts
> to limit the transfer of ARIN resources out of region, in order to allow
> an organization flexibility to move address blocks to another portion of
> their own organization in another region, even though they might have
> received different addresses within ARIN in the last 12 months??
>
> (Note current policy would still restrict availability of new addresses
> to the organization for a period of 12 months after the transfer and is
> not being changed by this draft).
>
> 2. ?If YES above, are there any other qualifications or limits that
> should be imposed on the resources transferred or the organization?
>
> (Note that a vote of NO to question #1 would essentially ask the
> Advisory Council to abandon this draft policy leaving existing policy in
> place.)
>
> Thanks to all who continue to work within the community to exercise
> their right and duty to craft appropriate policy guiding ARIN's
> important role in Internet number resource management.
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140506/415d1464/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: image001.jpg
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140506/415d1464/attachment.jpg>

From billdarte at gmail.com  Mon May  5 22:22:38 2014
From: billdarte at gmail.com (Bill Darte)
Date: Mon, 5 May 2014 21:22:38 -0500
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <CAMDXq5OOfq8KUSWRB_Pi8j8xAcrkQB5G9yx4cGRo5_iCRwSCHQ@mail.gmail.com>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
	<CAMDXq5PxCwoLH9bjvnK3oORB_0GqezpMtTsq4vUBCgK0Czf70g@mail.gmail.com>
	<B2596208-D661-4088-B7C1-55D14D52557E@delong.com>
	<CAMDXq5OOfq8KUSWRB_Pi8j8xAcrkQB5G9yx4cGRo5_iCRwSCHQ@mail.gmail.com>
Message-ID: <CAMApp36r_8T7LoiRAvQOAN2BLBsT8RpEgbubpBug6d0Zqcs9-w@mail.gmail.com>

Great.  Digest it and then determine if you support it or not.  This
proposal is the same as that which has received all the popular support
only it is now a complete, comprehensive proposal that does not leave the
NRPM in tatters.

bd



On Mon, May 5, 2014 at 9:08 PM, Martin Hannigan <hannigan at gmail.com> wrote:

>
>
> Estimated thirty changes to text. It appears that the AC just couldn't
> resist modifying what we all agreed on en masse.
>
> It'll take some time to evaluate all thirty plus changes. I'll reserve my
> comments for the NANOG PPC in Bellevue.
>
> Best,
>
> -M<
>
>
>
>
> On Mon, May 5, 2014 at 9:57 PM, Owen DeLong <owen at delong.com> wrote:
>
>> In short, because as specified, the changes ended up with the NRPM being
>> somewhat nonsensical.
>>
>> This revision does not change any of the original inent, preserves most
>> of the original text of the proposal, and leaves the NRPM in tact with
>> legible text after making the changes.
>>
>> Do you have a problem with some specific aspect of the new version? If
>> so, please enumerate it so we can address your concern.
>>
>> Owen
>>
>> On May 5, 2014, at 18:50 , Martin Hannigan <hannigan at gmail.com> wrote:
>>
>>
>>
>> Why couldn't the AC simply implement the changes that were massively
>> agreed upon here, as is -- which was also part of the discussion?
>>
>>
>> Best,
>>
>> -M<
>>
>>
>>
>>
>> On Mon, May 5, 2014 at 9:44 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:
>>
>>> I'm sending out a revised version of prop-208. Included is an attachment
>>> with a redline version to assist.
>>>
>>> I would appreciate any feedback of support or questions.
>>>
>>> Thanks,
>>>
>>> Kevin Blumberg
>>>
>>> ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24
>>> Proposal Originator: Owen DeLong
>>> Date: 5 May 2014
>>> Problem Statement:
>>> As we approach runout, more and more end users and smaller ISPs will be
>>> unable to obtain space from their upstreams and will be seeking space from
>>> ARIN. In order to meet these needs to the extent possible and to make
>>> policy more fair to a broader range of the ARIN constituency, we should
>>> reduce the minimum assignment and allocation units for IPv4 to /24 across
>>> the board.
>>>
>>> Policy statement:
>>>
>>> Remove all references to minimum allocations /20 and /22 replacing them
>>> with the term allocation or with /24 when referencing minimum size blocks.
>>>
>>> Change the title of 4.2.2.1 to "ISP Requirements" with revised text
>>> stating:
>>>
>>> All ISP organizations must satisfy the following requirements...thus
>>> eliminating the entire Multi-homed section and subsections along with other
>>> superfluous example text.
>>>
>>> Delete the special case allocations/assignments for the Caribbean as the
>>> new /24 minimums are an improvement.
>>>
>>> Comments:
>>> a. Timetable for implementation: Immediate b. A red line version has
>>> been included
>>>
>>> Full text version of changes for easy reference:
>>>
>>> 4.2.1.5. Minimum allocation
>>> In general, ARIN allocates /24 and larger IP address prefixes to ISPs.
>>> If allocations smaller than /24 are needed, ISPs should request address
>>> space from their upstream provider.
>>>
>>> 4.2.2.1 ISP Requirements
>>> All ISP organizations must satisfy the following requirements:
>>>
>>> 4.2.2.1.1 Use of /24
>>> The efficient utilization of an entire previously allocated /24 from
>>> their upstream ISP. This allocation may have been provided by an ISP's
>>> upstream provider(s), and does not have to be contiguous address space.
>>>
>>> 4.2.2.1.4. Renumber and return
>>> ISPs receiving a new allocation may wish to renumber out of their
>>> previously allocated space. In this case, an ISP must use the new
>>> allocation to renumber out of that previously allocated block of address
>>> space and must return the space to its upstream provider.
>>>
>>> 4.2.2.2. [section number retired]
>>>
>>> 4.3.2 Minimum assignment
>>>
>>> 4.3.2.1. [section moved to 4.3.2]
>>> The minimum block of IP address space assigned by ARIN to end-users is a
>>> /24. If assignments smaller than /24 are needed, end-users should contact
>>> their upstream provider.
>>>
>>> 4.3.2.2 [section number retired]
>>>
>>> 4.9 [section number retired]
>>>
>>>
>>> _______________________________________________
>>> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/93891a6a/attachment.htm>

From george.herbert at gmail.com  Mon May  5 22:26:54 2014
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 5 May 2014 19:26:54 -0700
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
Message-ID: <CAK__Kzugo0gKsFahkp9bMdLr4Q8nfWf0OkU1=GDi8rkJGsA=dQ@mail.gmail.com>

Support the fully fleshed out redline etc version.

-george


On Mon, May 5, 2014 at 6:44 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> I'm sending out a revised version of prop-208. Included is an attachment
> with a redline version to assist.
>
> I would appreciate any feedback of support or questions.
>
> Thanks,
>
> Kevin Blumberg
>
> ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24
> Proposal Originator: Owen DeLong
> Date: 5 May 2014
> Problem Statement:
> As we approach runout, more and more end users and smaller ISPs will be
> unable to obtain space from their upstreams and will be seeking space from
> ARIN. In order to meet these needs to the extent possible and to make
> policy more fair to a broader range of the ARIN constituency, we should
> reduce the minimum assignment and allocation units for IPv4 to /24 across
> the board.
>
> Policy statement:
>
> Remove all references to minimum allocations /20 and /22 replacing them
> with the term allocation or with /24 when referencing minimum size blocks.
>
> Change the title of 4.2.2.1 to "ISP Requirements" with revised text
> stating:
>
> All ISP organizations must satisfy the following requirements...thus
> eliminating the entire Multi-homed section and subsections along with other
> superfluous example text.
>
> Delete the special case allocations/assignments for the Caribbean as the
> new /24 minimums are an improvement.
>
> Comments:
> a. Timetable for implementation: Immediate b. A red line version has been
> included
>
> Full text version of changes for easy reference:
>
> 4.2.1.5. Minimum allocation
> In general, ARIN allocates /24 and larger IP address prefixes to ISPs. If
> allocations smaller than /24 are needed, ISPs should request address space
> from their upstream provider.
>
> 4.2.2.1 ISP Requirements
> All ISP organizations must satisfy the following requirements:
>
> 4.2.2.1.1 Use of /24
> The efficient utilization of an entire previously allocated /24 from their
> upstream ISP. This allocation may have been provided by an ISP's upstream
> provider(s), and does not have to be contiguous address space.
>
> 4.2.2.1.4. Renumber and return
> ISPs receiving a new allocation may wish to renumber out of their
> previously allocated space. In this case, an ISP must use the new
> allocation to renumber out of that previously allocated block of address
> space and must return the space to its upstream provider.
>
> 4.2.2.2. [section number retired]
>
> 4.3.2 Minimum assignment
>
> 4.3.2.1. [section moved to 4.3.2]
> The minimum block of IP address space assigned by ARIN to end-users is a
> /24. If assignments smaller than /24 are needed, end-users should contact
> their upstream provider.
>
> 4.3.2.2 [section number retired]
>
> 4.9 [section number retired]
>
>
> _______________________________________________
> 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.
>



-- 
-george william herbert
george.herbert at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/7ede6412/attachment.htm>

From hannigan at gmail.com  Mon May  5 22:27:05 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 5 May 2014 22:27:05 -0400
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
	Language
In-Reply-To: <CAMApp36hWBU=05a9LiLMJywHex=yG18Mos8R4vpf6Y_ZZD1faw@mail.gmail.com>
References: <CAMApp36hWBU=05a9LiLMJywHex=yG18Mos8R4vpf6Y_ZZD1faw@mail.gmail.com>
Message-ID: <CAMDXq5PvApvp050=HiaArsWkSfUu=5-fQY8Nfj9OY_veZ3VFBQ@mail.gmail.com>

Abandon. As David Huberman pointed out, easy to game and doesn't solve the
real problem with efficient use of resources where we need them, whether
its complying with policies like the German privacy laws or embarking upon
legal and efficient financial strategies that are in compliance with the
intended and legitimate in policy uses of resources.


I will also add, however, that completely discounting the voices of folks
that did comment in support because we don't appear to like their comments
or we decided to discount the venue is extremely negative. I consider my
opinion  here to be in the minority - hopefully influential to those who
disagreed previously. My suggestion to them is to instead support Mr.
Hubermans comments and to insist that they try again -- differently.

I still believe the geo location argument is weak, but I plan to research
that additionally and provide more feedback on that later.

Best,

-M<






On Mon, May 5, 2014 at 3:14 PM, Bill Darte <billdarte at gmail.com> wrote:

> Should we abandon this Draft?
>
> After the Chicago Public Policy Meeting, based upon the community's
> suggestion that the AC continue to work on this Draft.  I sent an email to
> PPML asking for support or opposition to this Draft and received just 2
> responses....both in opposition.
>
> I reiterate that PPML message below and once again ask for your support or
> opposition. Failing to generate greater support for this Draft and given
> that the AC has approximately 20 proposals and drafts on its docket.....I
> plan to make a motion at the next AC monthly meeting recommending
> abandoning this Draft Policy for lack of community support......
>
> Now is your opportunity to convince the community that this a worthwhile
> effort....or not.
>
> Thanks,
>
> Bill Darte
> AC Shepherd for 2014-2
>
>
> Draft Policy Issue:
> Simply, the author wishes the Anti-Flip language currently used in the
> NRPM to be relaxed, allowing an Inter-RIR transfer within their own
> organization of previously existing addresses....though they may have
> received a new allocation or assignment within the last 12 months.
>
> Current draft language states that the organization may do such a
> transfer, but may not use the actual addresses which were received from
> ARIN (or through transfer) in the previous 12 months.  But they could
> therefore transfer other resources holdings.
>
> Request for feedback:
> In order to further this discussion and gain a consensus, I would like to
> once again ask the community to speak in favor or against this Draft Policy
> so that it may be presented and discussed at our next Public Policy
> Consultation at NANOG in June.
>
> 1. Yes or No.  Should the community relax existing policy which attempts
> to limit the transfer of ARIN resources out of region, in order to allow an
> organization flexibility to move address blocks to another portion of their
> own organization in another region, even though they might have received
> different addresses within ARIN in the last 12 months?
>
> (Note current policy would still restrict availability of new addresses to
> the organization for a period of 12 months after the transfer and is not
> being changed by this draft).
>
> 2.  If YES above, are there any other qualifications or limits that should
> be imposed on the resources transferred or the organization?
>
> (Note that a vote of NO to question #1 would essentially ask the Advisory
> Council to abandon this draft policy leaving existing policy in place.)
>
> Thanks to all who continue to work within the community to exercise their
> right and duty to craft appropriate policy guiding ARIN's important role in
> Internet number resource management.
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/41e47b74/attachment.htm>

From hannigan at gmail.com  Mon May  5 22:31:04 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 5 May 2014 22:31:04 -0400
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <CAMApp36r_8T7LoiRAvQOAN2BLBsT8RpEgbubpBug6d0Zqcs9-w@mail.gmail.com>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
	<CAMDXq5PxCwoLH9bjvnK3oORB_0GqezpMtTsq4vUBCgK0Czf70g@mail.gmail.com>
	<B2596208-D661-4088-B7C1-55D14D52557E@delong.com>
	<CAMDXq5OOfq8KUSWRB_Pi8j8xAcrkQB5G9yx4cGRo5_iCRwSCHQ@mail.gmail.com>
	<CAMApp36r_8T7LoiRAvQOAN2BLBsT8RpEgbubpBug6d0Zqcs9-w@mail.gmail.com>
Message-ID: <CAMDXq5OW0iCwkp86Eh4E9zaRK7SZ1wWNNN-130Chr17LUzvEZg@mail.gmail.com>

Actually, Bill, it's not. There are significant changes in the tone and
tenor and therefore how it will be interpreted and how people familiar with
the previous iteration will now have to adapt to figure out how to satisfy
the borg with this iteration. It may appear easy, that the staff is super
helpful and non discriminate. That's not the case at all. ARIN does not
treat everyone equal and when you change policy with thirty some-odd
changes, you change everything.

BTW, When is the last time you asked ARIN for a significant chunk of
resources?


Best,

-M<




On Mon, May 5, 2014 at 10:22 PM, Bill Darte <billdarte at gmail.com> wrote:

> Great.  Digest it and then determine if you support it or not.  This
> proposal is the same as that which has received all the popular support
> only it is now a complete, comprehensive proposal that does not leave the
> NRPM in tatters.
>
> bd
>
>
>
> On Mon, May 5, 2014 at 9:08 PM, Martin Hannigan <hannigan at gmail.com>wrote:
>
>>
>>
>> Estimated thirty changes to text. It appears that the AC just couldn't
>> resist modifying what we all agreed on en masse.
>>
>> It'll take some time to evaluate all thirty plus changes. I'll reserve my
>> comments for the NANOG PPC in Bellevue.
>>
>> Best,
>>
>> -M<
>>
>>
>>
>>
>> On Mon, May 5, 2014 at 9:57 PM, Owen DeLong <owen at delong.com> wrote:
>>
>>> In short, because as specified, the changes ended up with the NRPM being
>>> somewhat nonsensical.
>>>
>>> This revision does not change any of the original inent, preserves most
>>> of the original text of the proposal, and leaves the NRPM in tact with
>>> legible text after making the changes.
>>>
>>> Do you have a problem with some specific aspect of the new version? If
>>> so, please enumerate it so we can address your concern.
>>>
>>> Owen
>>>
>>> On May 5, 2014, at 18:50 , Martin Hannigan <hannigan at gmail.com> wrote:
>>>
>>>
>>>
>>> Why couldn't the AC simply implement the changes that were massively
>>> agreed upon here, as is -- which was also part of the discussion?
>>>
>>>
>>> Best,
>>>
>>> -M<
>>>
>>>
>>>
>>>
>>> On Mon, May 5, 2014 at 9:44 PM, Kevin Blumberg <kevinb at thewire.ca>wrote:
>>>
>>>> I'm sending out a revised version of prop-208. Included is an
>>>> attachment with a redline version to assist.
>>>>
>>>> I would appreciate any feedback of support or questions.
>>>>
>>>> Thanks,
>>>>
>>>> Kevin Blumberg
>>>>
>>>> ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24
>>>> Proposal Originator: Owen DeLong
>>>> Date: 5 May 2014
>>>> Problem Statement:
>>>> As we approach runout, more and more end users and smaller ISPs will be
>>>> unable to obtain space from their upstreams and will be seeking space from
>>>> ARIN. In order to meet these needs to the extent possible and to make
>>>> policy more fair to a broader range of the ARIN constituency, we should
>>>> reduce the minimum assignment and allocation units for IPv4 to /24 across
>>>> the board.
>>>>
>>>> Policy statement:
>>>>
>>>> Remove all references to minimum allocations /20 and /22 replacing them
>>>> with the term allocation or with /24 when referencing minimum size blocks.
>>>>
>>>> Change the title of 4.2.2.1 to "ISP Requirements" with revised text
>>>> stating:
>>>>
>>>> All ISP organizations must satisfy the following requirements...thus
>>>> eliminating the entire Multi-homed section and subsections along with other
>>>> superfluous example text.
>>>>
>>>> Delete the special case allocations/assignments for the Caribbean as
>>>> the new /24 minimums are an improvement.
>>>>
>>>> Comments:
>>>> a. Timetable for implementation: Immediate b. A red line version has
>>>> been included
>>>>
>>>> Full text version of changes for easy reference:
>>>>
>>>> 4.2.1.5. Minimum allocation
>>>> In general, ARIN allocates /24 and larger IP address prefixes to ISPs.
>>>> If allocations smaller than /24 are needed, ISPs should request address
>>>> space from their upstream provider.
>>>>
>>>> 4.2.2.1 ISP Requirements
>>>> All ISP organizations must satisfy the following requirements:
>>>>
>>>> 4.2.2.1.1 Use of /24
>>>> The efficient utilization of an entire previously allocated /24 from
>>>> their upstream ISP. This allocation may have been provided by an ISP's
>>>> upstream provider(s), and does not have to be contiguous address space.
>>>>
>>>> 4.2.2.1.4. Renumber and return
>>>> ISPs receiving a new allocation may wish to renumber out of their
>>>> previously allocated space. In this case, an ISP must use the new
>>>> allocation to renumber out of that previously allocated block of address
>>>> space and must return the space to its upstream provider.
>>>>
>>>> 4.2.2.2. [section number retired]
>>>>
>>>> 4.3.2 Minimum assignment
>>>>
>>>> 4.3.2.1. [section moved to 4.3.2]
>>>> The minimum block of IP address space assigned by ARIN to end-users is
>>>> a /24. If assignments smaller than /24 are needed, end-users should contact
>>>> their upstream provider.
>>>>
>>>> 4.3.2.2 [section number retired]
>>>>
>>>> 4.9 [section number retired]
>>>>
>>>>
>>>> _______________________________________________
>>>> 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.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/316a8d80/attachment.htm>

From owen at delong.com  Mon May  5 22:29:09 2014
From: owen at delong.com (Owen DeLong)
Date: Mon, 5 May 2014 19:29:09 -0700
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
	Allocation/Assignment Units to /24
In-Reply-To: <CAMDXq5OOfq8KUSWRB_Pi8j8xAcrkQB5G9yx4cGRo5_iCRwSCHQ@mail.gmail.com>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
	<CAMDXq5PxCwoLH9bjvnK3oORB_0GqezpMtTsq4vUBCgK0Czf70g@mail.gmail.com>
	<B2596208-D661-4088-B7C1-55D14D52557E@delong.com>
	<CAMDXq5OOfq8KUSWRB_Pi8j8xAcrkQB5G9yx4cGRo5_iCRwSCHQ@mail.gmail.com>
Message-ID: <965E1C5B-A86B-4292-BB06-CB7AB0AC25D6@delong.com>

Interesting estimate.

The policy text contains a total of 9 NRPM sections which are modified. I suppose if you want to contemplate each single deletion and insertion as a separate text change, then there are, in fact, exactly 30 total changes, but most of them were, in fact, part of the original proposal.

If you don't count changing a word or phrase as 2 changes (a deletion + an insertion), but count it as 1 modification, then there are only 17 changes to the NRPM text contemplated.

You are certainly free to comment at any time you wish, however, if you want modification to the policy prior to it becoming a recommended draft, it would be preferable for you to get those comments in prior to the AC conference call on May 15th.

Owen

On May 5, 2014, at 19:08 , Martin Hannigan <hannigan at gmail.com> wrote:

> 
> 
> Estimated thirty changes to text. It appears that the AC just couldn't resist modifying what we all agreed on en masse.
> 
> It'll take some time to evaluate all thirty plus changes. I'll reserve my comments for the NANOG PPC in Bellevue.
> 
> Best,
> 
> -M<
> 
> 
> 
> 
> On Mon, May 5, 2014 at 9:57 PM, Owen DeLong <owen at delong.com> wrote:
> In short, because as specified, the changes ended up with the NRPM being somewhat nonsensical.
> 
> This revision does not change any of the original inent, preserves most of the original text of the proposal, and leaves the NRPM in tact with legible text after making the changes.
> 
> Do you have a problem with some specific aspect of the new version? If so, please enumerate it so we can address your concern.
> 
> Owen
> 
> On May 5, 2014, at 18:50 , Martin Hannigan <hannigan at gmail.com> wrote:
> 
>> 
>> 
>> Why couldn't the AC simply implement the changes that were massively agreed upon here, as is -- which was also part of the discussion?
>> 
>> 
>> Best,
>> 
>> -M<
>> 
>> 
>> 
>> 
>> On Mon, May 5, 2014 at 9:44 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:
>> I'm sending out a revised version of prop-208. Included is an attachment with a redline version to assist.
>> 
>> I would appreciate any feedback of support or questions.
>> 
>> Thanks,
>> 
>> Kevin Blumberg
>> 
>> ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24
>> Proposal Originator: Owen DeLong
>> Date: 5 May 2014
>> Problem Statement:
>> As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units for IPv4 to /24 across the board.
>> 
>> Policy statement:
>> 
>> Remove all references to minimum allocations /20 and /22 replacing them with the term allocation or with /24 when referencing minimum size blocks.
>> 
>> Change the title of 4.2.2.1 to "ISP Requirements" with revised text stating: 
>> 
>> All ISP organizations must satisfy the following requirements...thus eliminating the entire Multi-homed section and subsections along with other superfluous example text.
>> 
>> Delete the special case allocations/assignments for the Caribbean as the new /24 minimums are an improvement.
>> 
>> Comments:
>> a. Timetable for implementation: Immediate b. A red line version has been included
>> 
>> Full text version of changes for easy reference:
>> 
>> 4.2.1.5. Minimum allocation
>> In general, ARIN allocates /24 and larger IP address prefixes to ISPs. If allocations smaller than /24 are needed, ISPs should request address space from their upstream provider.
>> 
>> 4.2.2.1 ISP Requirements
>> All ISP organizations must satisfy the following requirements:
>> 
>> 4.2.2.1.1 Use of /24
>> The efficient utilization of an entire previously allocated /24 from their upstream ISP. This allocation may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space.
>> 
>> 4.2.2.1.4. Renumber and return
>> ISPs receiving a new allocation may wish to renumber out of their previously allocated space. In this case, an ISP must use the new allocation to renumber out of that previously allocated block of address space and must return the space to its upstream provider.
>> 
>> 4.2.2.2. [section number retired]
>> 
>> 4.3.2 Minimum assignment
>> 
>> 4.3.2.1. [section moved to 4.3.2]
>> The minimum block of IP address space assigned by ARIN to end-users is a /24. If assignments smaller than /24 are needed, end-users should contact their upstream provider.
>> 
>> 4.3.2.2 [section number retired]
>> 
>> 4.9 [section number retired]
>> 
>> 
>> _______________________________________________
>> 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.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/5db5c3bc/attachment.htm>

From hannigan at gmail.com  Mon May  5 22:45:34 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 5 May 2014 22:45:34 -0400
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <965E1C5B-A86B-4292-BB06-CB7AB0AC25D6@delong.com>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
	<CAMDXq5PxCwoLH9bjvnK3oORB_0GqezpMtTsq4vUBCgK0Czf70g@mail.gmail.com>
	<B2596208-D661-4088-B7C1-55D14D52557E@delong.com>
	<CAMDXq5OOfq8KUSWRB_Pi8j8xAcrkQB5G9yx4cGRo5_iCRwSCHQ@mail.gmail.com>
	<965E1C5B-A86B-4292-BB06-CB7AB0AC25D6@delong.com>
Message-ID: <CAMDXq5Oj9qeFqYtLGBnUw=YJoDuYM2YgZ+bT86PSBcwP9-EE4A@mail.gmail.com>

Owen, no one is surprised you're minimizing the changes. Of course you are.
:-) That's alright. The point here is that if this is to become "law"
sooner than later ARIN needs much more than the usual weak support.

The redline that you all chose to put forth appears to be little more than
lipstick on a pig. It certainly appears that you are adding more vagueness
to policy than clarity, thereby increasing the potential for misapplication
by the organization. You should be concerned.

Best,

-M<




On Mon, May 5, 2014 at 10:29 PM, Owen DeLong <owen at delong.com> wrote:

> Interesting estimate.
>
> The policy text contains a total of 9 NRPM sections which are modified. I
> suppose if you want to contemplate each single deletion and insertion as a
> separate text change, then there are, in fact, exactly 30 total changes,
> but most of them were, in fact, part of the original proposal.
>
> If you don't count changing a word or phrase as 2 changes (a deletion + an
> insertion), but count it as 1 modification, then there are only 17 changes
> to the NRPM text contemplated.
>
> You are certainly free to comment at any time you wish, however, if you
> want modification to the policy prior to it becoming a recommended draft,
> it would be preferable for you to get those comments in prior to the AC
> conference call on May 15th.
>
> Owen
>
> On May 5, 2014, at 19:08 , Martin Hannigan <hannigan at gmail.com> wrote:
>
>
>
> Estimated thirty changes to text. It appears that the AC just couldn't
> resist modifying what we all agreed on en masse.
>
> It'll take some time to evaluate all thirty plus changes. I'll reserve my
> comments for the NANOG PPC in Bellevue.
>
> Best,
>
> -M<
>
>
>
>
> On Mon, May 5, 2014 at 9:57 PM, Owen DeLong <owen at delong.com> wrote:
>
>> In short, because as specified, the changes ended up with the NRPM being
>> somewhat nonsensical.
>>
>> This revision does not change any of the original inent, preserves most
>> of the original text of the proposal, and leaves the NRPM in tact with
>> legible text after making the changes.
>>
>> Do you have a problem with some specific aspect of the new version? If
>> so, please enumerate it so we can address your concern.
>>
>> Owen
>>
>> On May 5, 2014, at 18:50 , Martin Hannigan <hannigan at gmail.com> wrote:
>>
>>
>>
>> Why couldn't the AC simply implement the changes that were massively
>> agreed upon here, as is -- which was also part of the discussion?
>>
>>
>> Best,
>>
>> -M<
>>
>>
>>
>>
>> On Mon, May 5, 2014 at 9:44 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:
>>
>>> I'm sending out a revised version of prop-208. Included is an attachment
>>> with a redline version to assist.
>>>
>>> I would appreciate any feedback of support or questions.
>>>
>>> Thanks,
>>>
>>> Kevin Blumberg
>>>
>>> ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24
>>> Proposal Originator: Owen DeLong
>>> Date: 5 May 2014
>>> Problem Statement:
>>> As we approach runout, more and more end users and smaller ISPs will be
>>> unable to obtain space from their upstreams and will be seeking space from
>>> ARIN. In order to meet these needs to the extent possible and to make
>>> policy more fair to a broader range of the ARIN constituency, we should
>>> reduce the minimum assignment and allocation units for IPv4 to /24 across
>>> the board.
>>>
>>> Policy statement:
>>>
>>> Remove all references to minimum allocations /20 and /22 replacing them
>>> with the term allocation or with /24 when referencing minimum size blocks.
>>>
>>> Change the title of 4.2.2.1 to "ISP Requirements" with revised text
>>> stating:
>>>
>>> All ISP organizations must satisfy the following requirements...thus
>>> eliminating the entire Multi-homed section and subsections along with other
>>> superfluous example text.
>>>
>>> Delete the special case allocations/assignments for the Caribbean as the
>>> new /24 minimums are an improvement.
>>>
>>> Comments:
>>> a. Timetable for implementation: Immediate b. A red line version has
>>> been included
>>>
>>> Full text version of changes for easy reference:
>>>
>>> 4.2.1.5. Minimum allocation
>>> In general, ARIN allocates /24 and larger IP address prefixes to ISPs.
>>> If allocations smaller than /24 are needed, ISPs should request address
>>> space from their upstream provider.
>>>
>>> 4.2.2.1 ISP Requirements
>>> All ISP organizations must satisfy the following requirements:
>>>
>>> 4.2.2.1.1 Use of /24
>>> The efficient utilization of an entire previously allocated /24 from
>>> their upstream ISP. This allocation may have been provided by an ISP's
>>> upstream provider(s), and does not have to be contiguous address space.
>>>
>>> 4.2.2.1.4. Renumber and return
>>> ISPs receiving a new allocation may wish to renumber out of their
>>> previously allocated space. In this case, an ISP must use the new
>>> allocation to renumber out of that previously allocated block of address
>>> space and must return the space to its upstream provider.
>>>
>>> 4.2.2.2. [section number retired]
>>>
>>> 4.3.2 Minimum assignment
>>>
>>> 4.3.2.1. [section moved to 4.3.2]
>>> The minimum block of IP address space assigned by ARIN to end-users is a
>>> /24. If assignments smaller than /24 are needed, end-users should contact
>>> their upstream provider.
>>>
>>> 4.3.2.2 [section number retired]
>>>
>>> 4.9 [section number retired]
>>>
>>>
>>> _______________________________________________
>>> 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.
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/f0727ffb/attachment.htm>

From george.herbert at gmail.com  Mon May  5 23:17:49 2014
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 5 May 2014 20:17:49 -0700
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <CAMDXq5Oj9qeFqYtLGBnUw=YJoDuYM2YgZ+bT86PSBcwP9-EE4A@mail.gmail.com>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
	<CAMDXq5PxCwoLH9bjvnK3oORB_0GqezpMtTsq4vUBCgK0Czf70g@mail.gmail.com>
	<B2596208-D661-4088-B7C1-55D14D52557E@delong.com>
	<CAMDXq5OOfq8KUSWRB_Pi8j8xAcrkQB5G9yx4cGRo5_iCRwSCHQ@mail.gmail.com>
	<965E1C5B-A86B-4292-BB06-CB7AB0AC25D6@delong.com>
	<CAMDXq5Oj9qeFqYtLGBnUw=YJoDuYM2YgZ+bT86PSBcwP9-EE4A@mail.gmail.com>
Message-ID: <CAK__KzthcjRzL4GVQvcUV5L6pL-fVdf5h_0isz3pFPrkpjwZcw@mail.gmail.com>

Martin -

The original proposal and this draft both seemed straightforwards (and
easily supportable) to me.

Can you please articulate in more detail what your objections are, both in
theory and in the textual changes/details?

I honestly do not currently understand what your issue(s) are.  I would
very much like to - My worry with anything people are encouraging to
fast-track is that a rapid consensus will fast-track something with a
poorly understood flaw.  If you think you see the flaw(s) please call them
out so we can have wider proper review.

Thank you.



On Mon, May 5, 2014 at 7:45 PM, Martin Hannigan <hannigan at gmail.com> wrote:

>
>
> Owen, no one is surprised you're minimizing the changes. Of course you
> are. :-) That's alright. The point here is that if this is to become "law"
> sooner than later ARIN needs much more than the usual weak support.
>
> The redline that you all chose to put forth appears to be little more than
> lipstick on a pig. It certainly appears that you are adding more vagueness
> to policy than clarity, thereby increasing the potential for misapplication
> by the organization. You should be concerned.
>
> Best,
>
> -M<
>
>
>
>
> On Mon, May 5, 2014 at 10:29 PM, Owen DeLong <owen at delong.com> wrote:
>
>> Interesting estimate.
>>
>> The policy text contains a total of 9 NRPM sections which are modified. I
>> suppose if you want to contemplate each single deletion and insertion as a
>> separate text change, then there are, in fact, exactly 30 total changes,
>> but most of them were, in fact, part of the original proposal.
>>
>> If you don't count changing a word or phrase as 2 changes (a deletion +
>> an insertion), but count it as 1 modification, then there are only 17
>> changes to the NRPM text contemplated.
>>
>> You are certainly free to comment at any time you wish, however, if you
>> want modification to the policy prior to it becoming a recommended draft,
>> it would be preferable for you to get those comments in prior to the AC
>> conference call on May 15th.
>>
>> Owen
>>
>> On May 5, 2014, at 19:08 , Martin Hannigan <hannigan at gmail.com> wrote:
>>
>>
>>
>> Estimated thirty changes to text. It appears that the AC just couldn't
>> resist modifying what we all agreed on en masse.
>>
>> It'll take some time to evaluate all thirty plus changes. I'll reserve my
>> comments for the NANOG PPC in Bellevue.
>>
>> Best,
>>
>> -M<
>>
>>
>>
>>
>> On Mon, May 5, 2014 at 9:57 PM, Owen DeLong <owen at delong.com> wrote:
>>
>>> In short, because as specified, the changes ended up with the NRPM being
>>> somewhat nonsensical.
>>>
>>> This revision does not change any of the original inent, preserves most
>>> of the original text of the proposal, and leaves the NRPM in tact with
>>> legible text after making the changes.
>>>
>>> Do you have a problem with some specific aspect of the new version? If
>>> so, please enumerate it so we can address your concern.
>>>
>>> Owen
>>>
>>> On May 5, 2014, at 18:50 , Martin Hannigan <hannigan at gmail.com> wrote:
>>>
>>>
>>>
>>> Why couldn't the AC simply implement the changes that were massively
>>> agreed upon here, as is -- which was also part of the discussion?
>>>
>>>
>>> Best,
>>>
>>> -M<
>>>
>>>
>>>
>>>
>>> On Mon, May 5, 2014 at 9:44 PM, Kevin Blumberg <kevinb at thewire.ca>wrote:
>>>
>>>> I'm sending out a revised version of prop-208. Included is an
>>>> attachment with a redline version to assist.
>>>>
>>>> I would appreciate any feedback of support or questions.
>>>>
>>>> Thanks,
>>>>
>>>> Kevin Blumberg
>>>>
>>>> ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24
>>>> Proposal Originator: Owen DeLong
>>>> Date: 5 May 2014
>>>> Problem Statement:
>>>> As we approach runout, more and more end users and smaller ISPs will be
>>>> unable to obtain space from their upstreams and will be seeking space from
>>>> ARIN. In order to meet these needs to the extent possible and to make
>>>> policy more fair to a broader range of the ARIN constituency, we should
>>>> reduce the minimum assignment and allocation units for IPv4 to /24 across
>>>> the board.
>>>>
>>>> Policy statement:
>>>>
>>>> Remove all references to minimum allocations /20 and /22 replacing them
>>>> with the term allocation or with /24 when referencing minimum size blocks.
>>>>
>>>> Change the title of 4.2.2.1 to "ISP Requirements" with revised text
>>>> stating:
>>>>
>>>> All ISP organizations must satisfy the following requirements...thus
>>>> eliminating the entire Multi-homed section and subsections along with other
>>>> superfluous example text.
>>>>
>>>> Delete the special case allocations/assignments for the Caribbean as
>>>> the new /24 minimums are an improvement.
>>>>
>>>> Comments:
>>>> a. Timetable for implementation: Immediate b. A red line version has
>>>> been included
>>>>
>>>> Full text version of changes for easy reference:
>>>>
>>>> 4.2.1.5. Minimum allocation
>>>> In general, ARIN allocates /24 and larger IP address prefixes to ISPs.
>>>> If allocations smaller than /24 are needed, ISPs should request address
>>>> space from their upstream provider.
>>>>
>>>> 4.2.2.1 ISP Requirements
>>>> All ISP organizations must satisfy the following requirements:
>>>>
>>>> 4.2.2.1.1 Use of /24
>>>> The efficient utilization of an entire previously allocated /24 from
>>>> their upstream ISP. This allocation may have been provided by an ISP's
>>>> upstream provider(s), and does not have to be contiguous address space.
>>>>
>>>> 4.2.2.1.4. Renumber and return
>>>> ISPs receiving a new allocation may wish to renumber out of their
>>>> previously allocated space. In this case, an ISP must use the new
>>>> allocation to renumber out of that previously allocated block of address
>>>> space and must return the space to its upstream provider.
>>>>
>>>> 4.2.2.2. [section number retired]
>>>>
>>>> 4.3.2 Minimum assignment
>>>>
>>>> 4.3.2.1. [section moved to 4.3.2]
>>>> The minimum block of IP address space assigned by ARIN to end-users is
>>>> a /24. If assignments smaller than /24 are needed, end-users should contact
>>>> their upstream provider.
>>>>
>>>> 4.3.2.2 [section number retired]
>>>>
>>>> 4.9 [section number retired]
>>>>
>>>>
>>>> _______________________________________________
>>>> 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.
>



-- 
-george william herbert
george.herbert at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140505/f909f969/attachment.htm>

From bill at herrin.us  Tue May  6 00:29:41 2014
From: bill at herrin.us (William Herrin)
Date: Tue, 6 May 2014 00:29:41 -0400
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
Message-ID: <CAP-guGU0LAoe8L5=jnz96E7rE7SfhzNCpBradyCw+RqiZDSFxw@mail.gmail.com>

On Mon, May 5, 2014 at 9:44 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:
> I'm sending out a revised version of prop-208. Included is an attachment with a redline version to assist.
>
> I would appreciate any feedback of support or questions.

I OPPOSE the draft as written.

Don't collapse singlehomed and multihomed. You'll just have to put
them back when we accept being multihomed as qualification for a /24
regardless of host count. If you must make changes this extensive, fix
that too. Multihomed and cash already qualifies you for a /24 from
your ISP anyway.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From kevinb at thewire.ca  Tue May  6 02:10:24 2014
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Tue, 6 May 2014 06:10:24 +0000
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <CAP-guGU0LAoe8L5=jnz96E7rE7SfhzNCpBradyCw+RqiZDSFxw@mail.gmail.com>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
	<CAP-guGU0LAoe8L5=jnz96E7rE7SfhzNCpBradyCw+RqiZDSFxw@mail.gmail.com>
Message-ID: <7E7773B523E82C478734E793E58F69E78D709D7A@SBS2011.thewireinc.local>

Bill,

The current section 4.2.3.6 currently deals with multi homing and host count for end users and is not changed by this policy. A simple option would be to change 4.2.3.6 in a future proposal to include allocations. The change to remove the host count requirement would probably also affect a number of other area's including slow start. 

The multi homing section would of needed a number of changes and removals to move to the /24 allocation size. Once that section had changed it would have been essentially duplicative.

Do you support the substantive changes in this policy? Are there any suggestions you might have to fix the issue that doesn't leave duplicate text in the NRPM?

Thanks,

Kevin Blumberg

-----Original Message-----
From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin
Sent: May 6, 2014 12:30 AM
To: Kevin Blumberg
Cc: arin-ppml at arin.net List (arin-ppml at arin.net)
Subject: Re: [arin-ppml] ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24

On Mon, May 5, 2014 at 9:44 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:
> I'm sending out a revised version of prop-208. Included is an attachment with a redline version to assist.
>
> I would appreciate any feedback of support or questions.

I OPPOSE the draft as written.

Don't collapse singlehomed and multihomed. You'll just have to put them back when we accept being multihomed as qualification for a /24 regardless of host count. If you must make changes this extensive, fix that too. Multihomed and cash already qualifies you for a /24 from your ISP anyway.

Regards,
Bill Herrin


--
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

From mje at posix.co.za  Tue May  6 02:45:04 2014
From: mje at posix.co.za (Mark Elkins)
Date: Tue, 06 May 2014 08:45:04 +0200
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
Message-ID: <1399358704.12025.29.camel@dhcp15.posix.co.za>

I support.

On Tue, 2014-05-06 at 01:44 +0000, Kevin Blumberg wrote:
> I'm sending out a revised version of prop-208. Included is an attachment with a redline version to assist. 
> 
> I would appreciate any feedback of support or questions. 
> 
> Thanks,
> 
> Kevin Blumberg
> 
> ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24 
> Proposal Originator: Owen DeLong
> Date: 5 May 2014
> Problem Statement: 
> As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units for IPv4 to /24 across the board.
> 
> Policy statement:
> 
> Remove all references to minimum allocations /20 and /22 replacing them with the term allocation or with /24 when referencing minimum size blocks.
> 
> Change the title of 4.2.2.1 to "ISP Requirements" with revised text stating: 
> 
> All ISP organizations must satisfy the following requirements...thus eliminating the entire Multi-homed section and subsections along with other superfluous example text. 
> 
> Delete the special case allocations/assignments for the Caribbean as the new /24 minimums are an improvement.
> 
> Comments:
> a. Timetable for implementation: Immediate b. A red line version has been included
> 
> Full text version of changes for easy reference:
> 
> 4.2.1.5. Minimum allocation
> In general, ARIN allocates /24 and larger IP address prefixes to ISPs. If allocations smaller than /24 are needed, ISPs should request address space from their upstream provider. 
> 
> 4.2.2.1 ISP Requirements
> All ISP organizations must satisfy the following requirements:
> 
> 4.2.2.1.1 Use of /24
> The efficient utilization of an entire previously allocated /24 from their upstream ISP. This allocation may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space.
> 
> 4.2.2.1.4. Renumber and return
> ISPs receiving a new allocation may wish to renumber out of their previously allocated space. In this case, an ISP must use the new allocation to renumber out of that previously allocated block of address space and must return the space to its upstream provider. 
> 
> 4.2.2.2. [section number retired]
> 
> 4.3.2 Minimum assignment
> 
> 4.3.2.1. [section moved to 4.3.2]
> The minimum block of IP address space assigned by ARIN to end-users is a /24. If assignments smaller than /24 are needed, end-users should contact their upstream provider. 
> 
> 4.3.2.2 [section number retired]
> 
> 4.9 [section number retired]

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
mje at posix.co.za       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5810 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140506/fcead1b0/attachment.bin>

From contact at winterei.se  Tue May  6 02:47:03 2014
From: contact at winterei.se (Paul S.)
Date: Tue, 06 May 2014 12:47:03 +0600
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
Message-ID: <53688567.2040608@winterei.se>

Not seeing anything I disagree with in the PDF, so just as I supported 
the original, I support this too.


On 5/6/2014 7:44 AM, Kevin Blumberg wrote:
> I'm sending out a revised version of prop-208. Included is an attachment with a redline version to assist.
>
> I would appreciate any feedback of support or questions.
>
> Thanks,
>
> Kevin Blumberg
>
> ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24
> Proposal Originator: Owen DeLong
> Date: 5 May 2014
> Problem Statement:
> As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units for IPv4 to /24 across the board.
>
> Policy statement:
>
> Remove all references to minimum allocations /20 and /22 replacing them with the term allocation or with /24 when referencing minimum size blocks.
>
> Change the title of 4.2.2.1 to "ISP Requirements" with revised text stating:
>
> All ISP organizations must satisfy the following requirements...thus eliminating the entire Multi-homed section and subsections along with other superfluous example text.
>
> Delete the special case allocations/assignments for the Caribbean as the new /24 minimums are an improvement.
>
> Comments:
> a. Timetable for implementation: Immediate b. A red line version has been included
>
> Full text version of changes for easy reference:
>
> 4.2.1.5. Minimum allocation
> In general, ARIN allocates /24 and larger IP address prefixes to ISPs. If allocations smaller than /24 are needed, ISPs should request address space from their upstream provider.
>
> 4.2.2.1 ISP Requirements
> All ISP organizations must satisfy the following requirements:
>
> 4.2.2.1.1 Use of /24
> The efficient utilization of an entire previously allocated /24 from their upstream ISP. This allocation may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space.
>
> 4.2.2.1.4. Renumber and return
> ISPs receiving a new allocation may wish to renumber out of their previously allocated space. In this case, an ISP must use the new allocation to renumber out of that previously allocated block of address space and must return the space to its upstream provider.
>
> 4.2.2.2. [section number retired]
>
> 4.3.2 Minimum assignment
>
> 4.3.2.1. [section moved to 4.3.2]
> The minimum block of IP address space assigned by ARIN to end-users is a /24. If assignments smaller than /24 are needed, end-users should contact their upstream provider.
>
> 4.3.2.2 [section number retired]
>
> 4.9 [section number retired]
>
>
>
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140506/d072453b/attachment.htm>

From bill at herrin.us  Tue May  6 02:49:38 2014
From: bill at herrin.us (William Herrin)
Date: Tue, 6 May 2014 02:49:38 -0400
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <7E7773B523E82C478734E793E58F69E78D709D7A@SBS2011.thewireinc.local>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
	<CAP-guGU0LAoe8L5=jnz96E7rE7SfhzNCpBradyCw+RqiZDSFxw@mail.gmail.com>
	<7E7773B523E82C478734E793E58F69E78D709D7A@SBS2011.thewireinc.local>
Message-ID: <CAP-guGUGaWdgSuiesNkZuWR-aD3VjqM4jWSOfFaOBZNF+EHbNQ@mail.gmail.com>

On Tue, May 6, 2014 at 2:10 AM, Kevin Blumberg <kevinb at thewire.ca> wrote:
> Do you support the substantive changes in this policy?

I support Owen's original policy with the minor tweaks to deal with
the couple of things he missed.

I do not support the policy as rewritten. The rewrite is, I believe,
egregious and harms prospects for further policy development based on
the distinction between multihomed and singlehomed.


> Are there any suggestions you might have to fix the issue that doesn't leave duplicate text in the NRPM?

Intentionally leave the duplicate text in the NRPM and pursue further
policy development from there. If there isn't any further policy
development you can come back and collapse it in a cleanup next year.

Eliminating the distinction between singlehomed and multihomed
entities was not the purpose of Owen's policy proposal and is, in my
opinion, a bad idea.  Leave the distinction in place so that when we
re-examine multihomed versus singlehomed in light of the new minimums
we don't have to re-create it from the whole cloth with all the
attendant trouble that will cause.

Seriously, look beyond the immediate policy proposal before you
consider ripping out huge chunks of the NRPM. It took a long time and
a lot of debate to craft that language. Don't throw it away until
we're sure we won't need it again.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From owen at delong.com  Tue May  6 03:59:53 2014
From: owen at delong.com (Owen DeLong)
Date: Tue, 6 May 2014 00:59:53 -0700
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
	Allocation/Assignment Units to /24
In-Reply-To: <CAP-guGUGaWdgSuiesNkZuWR-aD3VjqM4jWSOfFaOBZNF+EHbNQ@mail.gmail.com>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
	<CAP-guGU0LAoe8L5=jnz96E7rE7SfhzNCpBradyCw+RqiZDSFxw@mail.gmail.com>
	<7E7773B523E82C478734E793E58F69E78D709D7A@SBS2011.thewireinc.local>
	<CAP-guGUGaWdgSuiesNkZuWR-aD3VjqM4jWSOfFaOBZNF+EHbNQ@mail.gmail.com>
Message-ID: <35173AB8-1CE3-41F8-92EA-AFDF1593C4AB@delong.com>


On May 5, 2014, at 23:49 , William Herrin <bill at herrin.us> wrote:

> On Tue, May 6, 2014 at 2:10 AM, Kevin Blumberg <kevinb at thewire.ca> wrote:
>> Do you support the substantive changes in this policy?
> 
> I support Owen's original policy with the minor tweaks to deal with
> the couple of things he missed.
> 
> I do not support the policy as rewritten. The rewrite is, I believe,
> egregious and harms prospects for further policy development based on
> the distinction between multihomed and singlehomed.

It really doesn't. The distinction could be easily resurrected if necessary (though I think that is actually unlikely to become necessary).

However, having it in the NRPM as a distinction without a difference (as would have been the case in the original policy) would be confusing, unnecessarily complex, redundant.

>> Are there any suggestions you might have to fix the issue that doesn't leave duplicate text in the NRPM?
> 
> Intentionally leave the duplicate text in the NRPM and pursue further
> policy development from there. If there isn't any further policy
> development you can come back and collapse it in a cleanup next year.

We looked at this, and, frankly, leaving it in required more futzing with it than taking it out.

> Eliminating the distinction between singlehomed and multihomed
> entities was not the purpose of Owen's policy proposal and is, in my
> opinion, a bad idea.  Leave the distinction in place so that when we
> re-examine multihomed versus singlehomed in light of the new minimums
> we don't have to re-create it from the whole cloth with all the
> attendant trouble that will cause.

The existing text is archived and can easily be included as a re-insertion with
modifications for any new policy development. None of the section numbers being
retired are being reused at this time. It's actually easier to resurrect it from the archives
and modify to fit whatever future policy development may require it than it would be to
make enough changes to have it make sense in the context of this proposal.

> Seriously, look beyond the immediate policy proposal before you
> consider ripping out huge chunks of the NRPM. It took a long time and
> a lot of debate to craft that language. Don't throw it away until
> we're sure we won't need it again.

The use of the term "huge chunks" is a bit odd to my thinking here.

Ripped out:
	2 sentences of 4.2.1.5
	1 phrase in 4.2.2.1
	2 sentences in 4.2.2.1.1 (unrelated to the single/multihome issue)
	Section 4.2.2.2 (which would need a major rewrite if it were to stay in unless you actually wanted
	the policy to make it only possible to get a /24 if you were single-homed, but you could get a /22 as
	multihomed, which I don't believe was anyone's intent, certainly not mine)
	Title 4.3.2.1 (whois text is moved to 4.3.2)
	Section 4.3.2.2 (which would have to have been almost entirely rewritten if it remained in)
	Sections 4.9 and 4.9.1 (unrelated to the single/multihome issue)

I was on the call with the shepherds and others when these changes were discussed and most of them are actually my own recommendations to prevent the policy from making the NRPM nonsensical. All of the text that is removed can easily be put back by any future policy proposal if it becomes useful to do so, so there would not be any need to recreate said text from whole cloth for any future policy work.

Owen




From mike at nationwideinc.com  Tue May  6 10:36:01 2014
From: mike at nationwideinc.com (Mike Burns)
Date: Tue, 6 May 2014 10:36:01 -0400
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
	Allocation/Assignment Units to /24
In-Reply-To: <CAP-guGU0LAoe8L5=jnz96E7rE7SfhzNCpBradyCw+RqiZDSFxw@mail.gmail.com>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
	<CAP-guGU0LAoe8L5=jnz96E7rE7SfhzNCpBradyCw+RqiZDSFxw@mail.gmail.com>
Message-ID: <2E85CB1D696D48D1B7F11EAA01A424BA@MPC>

Or support the change I proposed allowing one small needs-free transfer per 
year.
Two simple clauses solves many of the MAU issues.
NRPM tatter-free.

Regards,
Mike Burns




-----Original Message----- 
From: William Herrin
Sent: Tuesday, May 06, 2014 12:29 AM
To: Kevin Blumberg
Cc: arin-ppml at arin.net List (arin-ppml at arin.net)
Subject: Re: [arin-ppml] ARIN-prop-208 Reduce All Minimum 
Allocation/Assignment Units to /24

On Mon, May 5, 2014 at 9:44 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:
> I'm sending out a revised version of prop-208. Included is an attachment 
> with a redline version to assist.
>
> I would appreciate any feedback of support or questions.

I OPPOSE the draft as written.

Don't collapse singlehomed and multihomed. You'll just have to put
them back when we accept being multihomed as qualification for a /24
regardless of host count. If you must make changes this extensive, fix
that too. Multihomed and cash already qualifies you for a /24 from
your ISP anyway.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
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. 



From michael at linuxmagic.com  Tue May  6 11:26:29 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Tue, 06 May 2014 08:26:29 -0700
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
Message-ID: <5368FF25.1060409@linuxmagic.com>

+1 Support

On 14-05-05 06:44 PM, Kevin Blumberg wrote:
> I'm sending out a revised version of prop-208. Included is an attachment with a redline version to assist.
>
> I would appreciate any feedback of support or questions.
>
> Thanks,
>
> Kevin Blumberg
>
> ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24
> Proposal Originator: Owen DeLong
> Date: 5 May 2014
> Problem Statement:
> As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units for IPv4 to /24 across the board.
>
> Policy statement:
>
> Remove all references to minimum allocations /20 and /22 replacing them with the term allocation or with /24 when referencing minimum size blocks.
>
> Change the title of 4.2.2.1 to "ISP Requirements" with revised text stating:
>
> All ISP organizations must satisfy the following requirements...thus eliminating the entire Multi-homed section and subsections along with other superfluous example text.
>
> Delete the special case allocations/assignments for the Caribbean as the new /24 minimums are an improvement.
>
> Comments:
> a. Timetable for implementation: Immediate b. A red line version has been included
>
> Full text version of changes for easy reference:
>
> 4.2.1.5. Minimum allocation
> In general, ARIN allocates /24 and larger IP address prefixes to ISPs. If allocations smaller than /24 are needed, ISPs should request address space from their upstream provider.
>
> 4.2.2.1 ISP Requirements
> All ISP organizations must satisfy the following requirements:
>
> 4.2.2.1.1 Use of /24
> The efficient utilization of an entire previously allocated /24 from their upstream ISP. This allocation may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space.
>
> 4.2.2.1.4. Renumber and return
> ISPs receiving a new allocation may wish to renumber out of their previously allocated space. In this case, an ISP must use the new allocation to renumber out of that previously allocated block of address space and must return the space to its upstream provider.
>
> 4.2.2.2. [section number retired]
>
> 4.3.2 Minimum assignment
>
> 4.3.2.1. [section moved to 4.3.2]
> The minimum block of IP address space assigned by ARIN to end-users is a /24. If assignments smaller than /24 are needed, end-users should contact their upstream provider.
>
> 4.3.2.2 [section number retired]
>
> 4.9 [section number retired]
>
>
>
> _______________________________________________
> 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.
>



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From michael at linuxmagic.com  Tue May  6 12:40:16 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Tue, 06 May 2014 09:40:16 -0700
Subject: [arin-ppml] *Grumble* 21 days from ARIN registration to Spam
	Source..
Message-ID: <53691070.2020607@linuxmagic.com>

Not to point fingers.. just wanted to make a reminder, large hosting 
providers getting fresh /20's and there is a waiting market to use up 
all those clean IP(s) for spamming..  not hard to 'justify' their next 
/20 requirements...

I know, not ARIN's job to determine what people want to use the IP(s) 
for, it's just that the 'justification' process does seem to an area it 
would be nice to work on, so that the new companies can get some, before 
the incumbents take it all..


  
-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.



From ikiris at gmail.com  Wed May  7 17:18:09 2014
From: ikiris at gmail.com (Blake Dunlap)
Date: Wed, 7 May 2014 16:18:09 -0500
Subject: [arin-ppml] Policy discussion - Method of calculating
	utilization
In-Reply-To: <20140505132921.GA28854@panix.com>
References: <20140505132921.GA28854@panix.com>
Message-ID: <CAJvB4tm9GBtCPPOSULFOK0ufLCDrdpVH8DdQL3oGbWQb9nC4ag@mail.gmail.com>

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
<rbf+arin-ppml at panix.com> 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
>> <rbf+arin-ppml at panix.com> 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 be OK.   I assert neither should be OK,
>> favoring the more rigorous justification criterion as better
>> stewardship.
>
> Actually, I assert that both should be the same.  I agree with Jeff's
> point that, for example, 32 /21s are the same whether you got them at
> one time as part of a /16 or on 8 separate occasions as part of 8
> separate /19s ... and that we should fix that, and, separately, if
> there are problems with the utilization requirement (for example, if
> 80% is not stringent enough) that should be handled separately.
>
>> And whether each individual allocation has to be utilized or not, the
>> calculation method, is inherently entangled with the utilization
>> criterion.
>>
>> It may be more work (more required renumbering or greater cost / more
>> local router entries required)  to efficiently utilize the /21 hidden
>> inside the /16,   in case this is not a contiguous  /21,   but a
>> fragmented group of a few hundred /28s and /27s  spread around the
>> entire  /16  due to  lots of number releases over time, or an
>> ineffective allocation plan.
>
> Well, sure.  And perhaps policy should take into consideration not only
> the utilization percentage, but also the distribution of the unused
> space.  For a number of reasons, I disagree with that, but my point in
> this thread is that it's separate from question of whether or not we
> should calculate utilization differently for two organizations that
> have exactly the same amount of address space and exactly the same
> utilization, when one org got its address space as a smaller number of
> larger blocks, and the other got its space as a larger number of
> smaller blocks.
>
> If the right thing to do is to count smaller blocks of unused space
> differently from larger blocks of unused space, that should be a
> separate proposal.
>
> (Note that the contiguous free /21 is not the common case here.  The
> more common case that is relevant to the proposal at hand here would be
> the most recently assigned space being 50% or so utilized -- and
> perhaps as fragmented as you describe above -- while all space that the
> organization has been allocated, in aggregate, is well over 80%
> utilized.)
>
>      -- Brett
> _______________________________________________
> 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.


From narten at us.ibm.com  Fri May  9 00:53:03 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 09 May 2014 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201405090453.s494r3UJ030496@rotala.raleigh.ibm.com>

Total of 70 messages in the last 7 days.
 
script run at: Fri May  9 00:53:02 EDT 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 14.29% |   10 | 15.84% |   140426 | hannigan at gmail.com
 11.43% |    8 |  8.29% |    73489 | jeffrey.lyon at blacklotus.net
  2.86% |    2 | 13.29% |   117859 | kevinb at thewire.ca
  7.14% |    5 |  7.23% |    64075 | owen at delong.com
  8.57% |    6 |  4.89% |    43355 | michael at linuxmagic.com
  5.71% |    4 |  4.35% |    38542 | david.huberman at microsoft.com
  4.29% |    3 |  5.18% |    45952 | billdarte at gmail.com
  5.71% |    4 |  3.16% |    28022 | bill at herrin.us
  5.71% |    4 |  3.10% |    27528 | mysidia at gmail.com
  2.86% |    2 |  4.14% |    36747 | george.herbert at gmail.com
  1.43% |    1 |  3.38% |    30009 | farmer at umn.edu
  1.43% |    1 |  3.33% |    29534 | sryerse at eclipse-networks.com
  2.86% |    2 |  1.56% |    13851 | dogwallah at gmail.com
  2.86% |    2 |  1.53% |    13602 | rbf+arin-ppml at panix.com
  1.43% |    1 |  2.44% |    21653 | fred.wettling at bechtel.com
  1.43% |    1 |  2.32% |    20587 | jcurran at arin.net
  1.43% |    1 |  2.09% |    18540 | scottleibrand at gmail.com
  1.43% |    1 |  1.84% |    16297 | mje at posix.co.za
  1.43% |    1 |  1.71% |    15186 | james.duncan20 at yahoo.com
  1.43% |    1 |  1.50% |    13332 | contact at winterei.se
  1.43% |    1 |  1.17% |    10378 | robert.cleary at bankofamerica.com
  1.43% |    1 |  0.98% |     8703 | narten at us.ibm.com
  1.43% |    1 |  0.98% |     8669 | rjletts at uw.edu
  1.43% |    1 |  0.97% |     8573 | mpetach at netflight.com
  1.43% |    1 |  0.95% |     8431 | ikiris at gmail.com
  1.43% |    1 |  0.93% |     8262 | sandrabrown at ipv4marketgroup.com
  1.43% |    1 |  0.84% |     7404 | lsawyer at gci.com
  1.43% |    1 |  0.72% |     6406 | mike at nationwideinc.com
  1.43% |    1 |  0.66% |     5810 | john at egh.com
  1.43% |    1 |  0.61% |     5378 | ajs at anvilwalrusden.com
--------+------+--------+----------+------------------------
100.00% |   70 |100.00% |   886600 | Total



From kelly.hays at jkhfamily.org  Fri May  9 14:20:02 2014
From: kelly.hays at jkhfamily.org (Kelly Hays)
Date: Fri, 9 May 2014 13:20:02 -0500
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
Message-ID: <CA+SWn33Fg3vpH8spevr0ZSYmdXB6tZF9Zhi2wtCEyaxU8pO48w@mail.gmail.com>

I support this.


On Mon, May 5, 2014 at 8:44 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> I'm sending out a revised version of prop-208. Included is an attachment
> with a redline version to assist.
>
> I would appreciate any feedback of support or questions.
>
> Thanks,
>
> Kevin Blumberg
>
> ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24
> Proposal Originator: Owen DeLong
> Date: 5 May 2014
> Problem Statement:
> As we approach runout, more and more end users and smaller ISPs will be
> unable to obtain space from their upstreams and will be seeking space from
> ARIN. In order to meet these needs to the extent possible and to make
> policy more fair to a broader range of the ARIN constituency, we should
> reduce the minimum assignment and allocation units for IPv4 to /24 across
> the board.
>
> Policy statement:
>
> Remove all references to minimum allocations /20 and /22 replacing them
> with the term allocation or with /24 when referencing minimum size blocks.
>
> Change the title of 4.2.2.1 to "ISP Requirements" with revised text
> stating:
>
> All ISP organizations must satisfy the following requirements...thus
> eliminating the entire Multi-homed section and subsections along with other
> superfluous example text.
>
> Delete the special case allocations/assignments for the Caribbean as the
> new /24 minimums are an improvement.
>
> Comments:
> a. Timetable for implementation: Immediate b. A red line version has been
> included
>
> Full text version of changes for easy reference:
>
> 4.2.1.5. Minimum allocation
> In general, ARIN allocates /24 and larger IP address prefixes to ISPs. If
> allocations smaller than /24 are needed, ISPs should request address space
> from their upstream provider.
>
> 4.2.2.1 ISP Requirements
> All ISP organizations must satisfy the following requirements:
>
> 4.2.2.1.1 Use of /24
> The efficient utilization of an entire previously allocated /24 from their
> upstream ISP. This allocation may have been provided by an ISP's upstream
> provider(s), and does not have to be contiguous address space.
>
> 4.2.2.1.4. Renumber and return
> ISPs receiving a new allocation may wish to renumber out of their
> previously allocated space. In this case, an ISP must use the new
> allocation to renumber out of that previously allocated block of address
> space and must return the space to its upstream provider.
>
> 4.2.2.2. [section number retired]
>
> 4.3.2 Minimum assignment
>
> 4.3.2.1. [section moved to 4.3.2]
> The minimum block of IP address space assigned by ARIN to end-users is a
> /24. If assignments smaller than /24 are needed, end-users should contact
> their upstream provider.
>
> 4.3.2.2 [section number retired]
>
> 4.9 [section number retired]
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140509/0d2858dc/attachment.htm>

From skylar at crissic.net  Fri May  9 14:21:25 2014
From: skylar at crissic.net (Skylar MacMinn)
Date: Fri, 9 May 2014 18:21:25 +0000
Subject: [arin-ppml] ARIN-prop-208 Reduce All Minimum
 Allocation/Assignment Units to /24
In-Reply-To: <CA+SWn33Fg3vpH8spevr0ZSYmdXB6tZF9Zhi2wtCEyaxU8pO48w@mail.gmail.com>
References: <7E7773B523E82C478734E793E58F69E78D709771@SBS2011.thewireinc.local>
	<CA+SWn33Fg3vpH8spevr0ZSYmdXB6tZF9Zhi2wtCEyaxU8pO48w@mail.gmail.com>
Message-ID: <cf6b9eac99c74b04a84d0b13434b51a7@DM2PR0801MB569.namprd08.prod.outlook.com>

I support this.
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kelly Hays
Sent: Friday, May 9, 2014 1:20 PM
To: Kevin Blumberg
Cc: arin-ppml at arin.net List (arin-ppml at arin.net)
Subject: Re: [arin-ppml] ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24

I support this.

On Mon, May 5, 2014 at 8:44 PM, Kevin Blumberg <kevinb at thewire.ca<mailto:kevinb at thewire.ca>> wrote:
I'm sending out a revised version of prop-208. Included is an attachment with a redline version to assist.

I would appreciate any feedback of support or questions.

Thanks,

Kevin Blumberg

ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24
Proposal Originator: Owen DeLong
Date: 5 May 2014
Problem Statement:
As we approach runout, more and more end users and smaller ISPs will be unable to obtain space from their upstreams and will be seeking space from ARIN. In order to meet these needs to the extent possible and to make policy more fair to a broader range of the ARIN constituency, we should reduce the minimum assignment and allocation units for IPv4 to /24 across the board.

Policy statement:

Remove all references to minimum allocations /20 and /22 replacing them with the term allocation or with /24 when referencing minimum size blocks.

Change the title of 4.2.2.1 to "ISP Requirements" with revised text stating:

All ISP organizations must satisfy the following requirements...thus eliminating the entire Multi-homed section and subsections along with other superfluous example text.

Delete the special case allocations/assignments for the Caribbean as the new /24 minimums are an improvement.

Comments:
a. Timetable for implementation: Immediate b. A red line version has been included

Full text version of changes for easy reference:

4.2.1.5. Minimum allocation
In general, ARIN allocates /24 and larger IP address prefixes to ISPs. If allocations smaller than /24 are needed, ISPs should request address space from their upstream provider.

4.2.2.1 ISP Requirements
All ISP organizations must satisfy the following requirements:

4.2.2.1.1 Use of /24
The efficient utilization of an entire previously allocated /24 from their upstream ISP. This allocation may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space.

4.2.2.1.4. Renumber and return
ISPs receiving a new allocation may wish to renumber out of their previously allocated space. In this case, an ISP must use the new allocation to renumber out of that previously allocated block of address space and must return the space to its upstream provider.

4.2.2.2. [section number retired]

4.3.2 Minimum assignment

4.3.2.1. [section moved to 4.3.2]
The minimum block of IP address space assigned by ARIN to end-users is a /24. If assignments smaller than /24 are needed, end-users should contact their upstream provider.

4.3.2.2 [section number retired]

4.9 [section number retired]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140509/c04d6bbc/attachment.htm>

From narten at us.ibm.com  Fri May 16 00:53:02 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 16 May 2014 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201405160453.s4G4r2IQ016933@rotala.raleigh.ibm.com>

Total of 3 messages in the last 7 days.
 
script run at: Fri May 16 00:53:02 EDT 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 33.33% |    1 | 48.73% |    19141 | skylar at crissic.net
 33.33% |    1 | 30.66% |    12045 | kelly.hays at jkhfamily.org
 33.33% |    1 | 20.61% |     8096 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    3 |100.00% |    39282 | Total



From info at arin.net  Fri May 16 16:18:51 2014
From: info at arin.net (ARIN)
Date: Fri, 16 May 2014 16:18:51 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - May 2014
Message-ID: <537672AB.1060606@arin.net>

In accordance with the ARIN Policy Development Process (PDP), the ARIN 
Advisory Council (AC) met on 15 May 2014.

The AC recommended the following to the ARIN Board for adoption:

   Recommended Draft Policy ARIN-2014-4: Remove 4.2.5 Web Hosting Policy
   Recommended Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation 
Conservation Update
   Recommended Draft Policy ARIN-2014-10: Remove Sections 4.6 and 4.7

The AC moved the following to last call:

   Recommended Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup

The AC accepted the following as Draft Policies. They will be
posted separately to the Public Policy Mailing List (PPML).

   ARIN-prop-209 Change Utilization Requirements from last-allocation to 
total-aggregate
   ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24
   ARIN-prop-207 Section 4.10 Austerity Policy Update
   ARIN-prop-205 Allow Inter-RIR ASN Transfers	
   ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers

Having found the following to be fully developed and meeting ARIN's 
Principles of Internet Number Resource Policy, the AC recommended these 
for adoption (each to be posted separately for discussion as a 
Recommended Draft Policy):

   Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple 
Discrete Networks
   Draft Policy ARIN-2414-12: Anti-hijack Policy
   Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment 
Units to /24

The AC remanded the following proposal to the originator after the 
proposal originator asked to withdraw the proposal.

   ARIN-prop-206 Implement IPv6 from IPv4 Without an Outage

The AC abandoned the following:

   Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip Language

The AC provided the following statement:

"Review of the PPML, the record of discussion and polling at the Chicago 
PPM and the original author's statement of willingness to withdraw the 
proposal indicate a lack of consensus. The ARIN AC has therefore decided 
to abandon Draft Policy 2014-2 Improving 8.4 Anti-Flip Language. The AC 
recognizes that some community members believe this to be an important 
issue and encourages those members to investigate a means to solve the 
problem statement that the Draft Policy was focused upon. You may find a 
record of this on the ARIN website."

The AC abandoned ARIN-2014-2. Anyone dissatisfied with this decision may 
initiate a petition. The deadline to begin a petition will be five 
business days after the AC's draft meeting minutes are published. For 
more information on starting and participating in petitions, see PDP 
Petitions at: https://www.arin.net/policy/pdp_petitions.html

The AC is continuing to work on the following:

   Draft Policy ARIN-2014-1: Out of Region Use
   Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and 8.4 Minimum IPv4 
Block Size Requirements
   Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations
   Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs]
   Draft Policy ARIN-2014-8: Alignment of 8.3 Needs Requirements to 
Reality of Business
   Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 
Utilization Requirements
   Draft Policy ARIN-2014-11: Improved Registry Accuracy Proposal

Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)



From info at arin.net  Fri May 16 16:20:04 2014
From: info at arin.net (ARIN)
Date: Fri, 16 May 2014 16:20:04 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-14: Removing Needs Test from
	Small IPv4 Transfers
Message-ID: <537672F4.2060804@arin.net>

On 15 May 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-204 
Removing Needs Test from Small IPv4 Transfers" as a Draft Policy.

Draft Policy ARIN-2014-14 is below and can be found at:
https://www.arin.net/policy/proposals/2014_14.html

You are encouraged to discuss the merits and your concerns of Draft
Policy 2014-14 on the Public Policy Mailing List.

The AC will evaluate the discussion in order to assess the conformance
of this draft policy with ARIN's Principles of Internet Number Resource
Policy as stated in the PDP. Specifically, these principles are:

   * Enabling Fair and Impartial Number Resource Administration
   * Technically Sound
   * Supported by the Community

The ARIN Policy Development Process (PDP) can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2014-14
Removing Needs Test from Small IPv4 Transfers

Date: 16 May 2014

Problem Statement:

ARIN staff, faced with a surge in near-exhaust allocations and 
subsequent transfer requests and a requirement for team review of these, 
is spending scarce staff time on needs testing of small transfers. This 
proposal seeks to decrease overall ARIN processing time through 
elimination of that needs test.

Policy statement:

Change the language in NRPM 8.3 after Conditions on the recipient of the 
transfer: from "The recipient must demonstrate the need for up to a 
24-month supply of IP address resources under current ARIN policies and 
sign an RSA." to "For transfers larger than a /16 equivalent or for 
recipients who have completed a needs-free transfer in the prior year, 
the recipient must demonstrate the need for up to a 24-month supply of 
IP address resources under current ARIN policies and sign an RSA."

Change the language in the third bullet point in NRPM 8.4 after 
Conditions on the recipient of the transfer: from "Recipients within the 
ARIN region must demonstrate the need for up to a 24-month supply of 
IPv4 address space." to "For transfers larger than a /16 equivalent or 
for recipients who have completed a needs-free transfer in the prior 
year, recipients in the ARIN region must demonstrate the need for up to 
a 24-month supply of IP address resources under current ARIN policies 
and sign an RSA."

Comments:

Needs testing has been maintained for transfers largely because the 
community wishes to ensure protection against hoarding and speculation 
in the IPv4 market. This proposal seeks a middle ground between the 
elimination of needs tests for transfers altogether, and the continuance 
of needs tests for every transfer. This should help ARIN staff to reduce 
transfer processing time, since most transfers have been smaller than /16.

Timetable for implementation: Immediate


From info at arin.net  Fri May 16 16:20:26 2014
From: info at arin.net (ARIN)
Date: Fri, 16 May 2014 16:20:26 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers
Message-ID: <5376730A.3000504@arin.net>

On 15 May 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-205 
Allow Inter-RIR ASN Transfers" as a Draft Policy.

Draft Policy ARIN-2014-15 is below and can be found at:
https://www.arin.net/policy/proposals/2014_15.html

You are encouraged to discuss the merits and your concerns of Draft
Policy 2014-15 on the Public Policy Mailing List.

The AC will evaluate the discussion in order to assess the conformance
of this draft policy with ARIN's Principles of Internet Number Resource
Policy as stated in the PDP. Specifically, these principles are:

   * Enabling Fair and Impartial Number Resource Administration
   * Technically Sound
   * Supported by the Community

The ARIN Policy Development Process (PDP) can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2014-15
Allow Inter-RIR ASN Transfers

Date: 16 May 2014

Problem Statement:

We already allow transfer of ASNs within the ARIN region. Recently APNIC 
implemented a policy allowing for Inter-regional ASN transfers to RIRs 
with reciprocal policies. This change in language would allow for ASN 
transfers to and from the APNIC region.

Policy Statement:

Add "or ASNs to be transferred, as" to the first bullet point under 
Conditions on source of the transfer, so that it reads: "The source 
entity must be the current rights holder of the IPv4 address resources 
or ASNs to be transferred, as recognized by the RIR responsible for the 
resources, and not be involved in any dispute as to the status of those 
resources."

Change "IPv4 number resources" to "IPv4 number resources or ASNs", so 
that the fourth bullet point reads: "Source entities within the ARIN 
region must not have received a transfer, allocation, or assignment of 
IPv4 number resources or ASNs from ARIN for the 12 months prior to the 
approval of a transfer request. This restriction does not include M&A 
transfers."

Timetable for implementation: Immediate


From info at arin.net  Fri May 16 16:20:47 2014
From: info at arin.net (ARIN)
Date: Fri, 16 May 2014 16:20:47 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-16: Section 4.10 Austerity
	Policy Update
Message-ID: <5376731F.2050004@arin.net>

On 15 May 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-207 
Section 4.10 Austerity Policy Update" as a Draft Policy.

Draft Policy ARIN-2014-16 is below and can be found at:
https://www.arin.net/policy/proposals/2014_16.html

You are encouraged to discuss the merits and your concerns of Draft
Policy 2014-16 on the Public Policy Mailing List.

The AC will evaluate the discussion in order to assess the conformance
of this draft policy with ARIN's Principles of Internet Number Resource
Policy as stated in the PDP. Specifically, these principles are:

   * Enabling Fair and Impartial Number Resource Administration
   * Technically Sound
   * Supported by the Community

The ARIN Policy Development Process (PDP) can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2014-16
Section 4.10 Austerity Policy Update

Date: 16 May 2014

Problem Statement:

NRPM section 4.10 defines an IPv4 to IPv6 transition pool which was 
intended to be used by new entrants after the IPv4 free pool has been 
exhausted. This policy was written prior to exhaustion in the APNIC and 
RIPE region and has largely not been used to date. It is believed that 
the current policy may be too restrictive to be useful to many 
organizations within the ARIN region. Furthermore the during the ARIN 33 
public policy meeting experience report (1), ARIN staff noted issues 
with the current IPv4 policy after the IPv4 free pool is exhausted.

RIPE & APNIC adopted an ?austerity? policy which allows organizations to 
obtain a small single block directly from the registry. These policies 
appear to have been quite effective at getting IPv4 resources to 
organizations without address space after IPv4 exhaustion. Learning from 
other regions, we have crafted a policy to update section 4.10 to adopt 
some of the policy text from the RIPE & APNIC region while looking at 
the unique aspects of the ARIN region?s number resource needs.

Policy statement:

Replace Section 4.10 with the following policy.

4.10 Dedicated IPv4 block to facilitate IPv6 Deployment

When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous 
/10 IPv4 block will be set aside and dedicated to facilitate IPv6 
deployment and continued transition from IPv4 to IPv6.

Address space received from IANA under the ?Global Policy for Post 
Exhaustion IPv4 Allocation Mechanisms by the IANA (NRPM 10.5)? by ARIN 
shall be allocated or assigned under this section.

Allocations and assignments from this block must be justified by 
immediate IPv6 deployment requirements. Organizations must obtain an 
IPv6 block to receive a block under section 4.10 and show documentation 
on how the IPv6 and IPv4 block will be used to facilitate an 
organization?s operational needs.

This block will be subject to a minimum size allocation of /28 and a 
maximum size allocation of /22. ARIN shall use sparse allocation within 
these blocks.

In order to receive an allocation or assignment under this policy:

1. the organization, nor it parent(s) or subsidiary organizations, may 
not have received IPv4 resources greater than or equal to a /22 from 
ARIN or any other RIR;

2. the organization must show immediate use (within 30 days) of 25% of 
the allocation;

3. the organization is eligible to receive only one contiguous IPv4 
block under this section;

4. the organization may apply to ARIN for an increase in their 
allocation up to a /22, if the previous allocation under this section 
shows a utilization of at least 80%, increases will only be granted if 
adjacent bit-boundary aligned space is available at the time of request.

Comments:

a. Timetable for implementation: immediately

b. Anything else: (1) 
https://www.arin.net/participate/meetings/reports/ARIN_33/PDF/monday/nobile_policy.pdf 



From info at arin.net  Fri May 16 16:21:10 2014
From: info at arin.net (ARIN)
Date: Fri, 16 May 2014 16:21:10 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization
 Requirements from last-allocation to total-aggregate
Message-ID: <53767336.4080001@arin.net>

On 15 May 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-209 
Change Utilization Requirements from last-allocation to total-aggregate" 
as a Draft Policy.

Draft Policy ARIN-2014-17 is below and can be found at:
https://www.arin.net/policy/proposals/2014_17.html

You are encouraged to discuss the merits and your concerns of Draft
Policy 2014-17 on the Public Policy Mailing List.

The AC will evaluate the discussion in order to assess the conformance
of this draft policy with ARIN's Principles of Internet Number Resource
Policy as stated in the PDP. Specifically, these principles are:

   * Enabling Fair and Impartial Number Resource Administration
   * Technically Sound
   * Supported by the Community

The ARIN Policy Development Process (PDP) can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2014-17
Change Utilization Requirements from last-allocation to total-aggregate

Date: 16 May 2014

Problem Statement:

Utilization requirements 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 
utilized at 75%, that request would be denied. This is a bit out of 
balance as an organization with a single /20 utilized at 80% would have 
less efficient utilization but would be eligible to request additional 
space.

Policy statement:

Section 4.2.4.1- Change text to read: "ISPs must have efficiently 
utilized all previous allocations, in aggregate, to at least 80% 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."

Section 4.3.6.1- Change text to read: "End-users must have efficiently 
utilized all previous assignments, in aggregate, to at least 80% in 
order to receive additional space, and must provide ARIN with 
utilization details. The prefix size for an additional assignment is 
determined by applying the policies found in Section 4.3 of the NRPM."

Comments:

a. Timetable for implementation: Immediate, possibly through board action.
b. Per originator, This does not currently extend into MDN (aka 4.5.4), 
and I'm not really sure how to reconcile it against 4.5.5, but OP 
expressed some concern that there may be undue restrictions there. It 
might be better served by a separate proposal.
c. There should probably also be an attempt to clean up the language 
between 4.2.4.1 and 4.3.6.1, as they're both currently very clunky.


From info at arin.net  Fri May 16 16:21:39 2014
From: info at arin.net (ARIN)
Date: Fri, 16 May 2014 16:21:39 -0400
Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-7: NRPM 4
 (IPv4) Policy Cleanup
Message-ID: <53767353.4020506@arin.net>

The ARIN Advisory Council (AC) met on 15 May 2014 and decided to
send the following to last call:

   Recommended Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup

2013-7 was revised. The following sentence was added to 4.2.4.3:
"Determination of the appropriate allocation to be issued is based on 
efficient utilization of space within this time frame, consistent with 
the principles in 4.2.1."

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. This last call will
expire on 2 June 2014. After last call the AC will conduct their
last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Recommended Draft Policy ARIN-2013-7
NRPM 4 (IPv4) Policy Cleanup

Date: 16 May 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

"ARIN-2013-7: "NRPM 4 (IPv4) Policy Cleanup" enables fair and impartial 
number resource administration by removing no-longer-relevant sections 
of the NRPM, and clarifying other sections. All of the remaining changes 
in this draft policy have proven uncontroversial thus far."

Problem Statement: Parts of NRPM 4 are irrelevant, especially after IPv4 
run-out, and should be cleaned up for clarity.

Policy statement:

Short list of changes with details explained below.

Remove section 4.1.1 Routability

Update section 4.1.5 Determination of resource requests

Remove section 4.1.7 RFC2050

Remove section 4.1.9 Returned IPv4 Addresses

Replace and retitle section 4.2.4.3 Subscriber Members Less Than One Year

Remove section 4.2.4.4. Subscriber Members After One Year

Details:

Remove section 4.1.1 Routability

It is no longer necessary for the NRPM to suggest where an organization 
obtains resources from.

Retitle and rewrite section (4.1.5 Determination of IP address 
allocation size)

Remove: "Determination of IP address allocation size is the 
responsibility of ARIN."

Replace with: (4.1.5 Resource request size) "Determining the validity of 
the amount of requested IP address resources is the responsibility of ARIN."

Rationale: Clarify that it is the validity of the request that is more 
the focus than the amount of resources requested. This does not prevent 
ARIN from suggesting that a smaller block would be justified where a 
larger one would not, but also does not suggest that it is ARIN's sole 
discretion to judge the size of the blocks needed.

Remove section 4.1.7 RFC2050

Now that RFC2050 has been replaced with RFC 7020 and ARIN-2013-4 RIR 
Principles has been adopted, this section is no longer needed.

Remove section 4.2.4.3 Subscriber Members Less Than One Year and 
4.2.4.4. Subscriber Members After One Year

Replace with: (4.2.4.3 Request size) "ISPs may request up to a 3-month 
supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 or 8.4 
transfer. Determination of the appropriate allocation to be issued is 
based on efficient utilization of space within this time frame, 
consistent with the principles in 4.2.1."

Rationale: Since ARIN received its last /8, by IANA implementing section 
10.4.2.2, this is now a distinction without a difference.

Timetable for implementation: Immediate


From info at arin.net  Fri May 16 16:22:20 2014
From: info at arin.net (ARIN)
Date: Fri, 16 May 2014 16:22:20 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks
Message-ID: <5376737C.70409@arin.net>

Recommended Draft Policy ARIN-2013-8
Subsequent Allocations for New Multiple Discrete Networks

On 15 May 2014 the ARIN Advisory Council (AC) recommended
ARIN-2013-8 for adoption, making it a Recommended Draft Policy.

ARIN-2013-8 is below and can be found at:
https://www.arin.net/policy/proposals/2013-8.html

You are encouraged to discuss Draft Policy 2013-8 on the PPML prior to
the upcoming ARIN Public Policy Consultation at NANOG 61. Both the 
discussion on the list and at the meeting will be used by the ARIN 
Advisory Council to determine the community consensus for adopting this 
as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Recommended Draft Policy ARIN-2013-8
Subsequent Allocations for New Multiple Discrete Networks

Date: 16 May 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

This proposal enables fair and impartial number resource administration 
by documenting how to get a new block for a new discrete network. 
Previous versions of the policy did have this information and over time 
it has been removed.

This proposal is technically sound.  There is a need for discrete 
networks and an organization should have a policy that would allow it to 
create a new discrete network.

This proposal is supported by the community.  There has been some 
concern about the criterial that will be used and this version has been 
updated with the current thinking on the criteria.

Policy Statement:

IPv4:
Add the following statement to section 4.5.4.
Upon verification that the organization has shown evidence of deployment 
of the new discrete network site, the new network(s) shall be allocated 
the minimum allocation size under section 4.2.1.5 unless the 
organization can demonstrate additional need using the immediate need 
criteria (4.2.1.6).

IPv6:
Add an additional reference to section 6.11.5.b such that it references 
both the initial allocation and subsequent allocation sections of the 
IPv6 LIR policy.
"Each network will be judged against the existing utilization criteria 
specified in 6.5.2 and 6.5.3 as if it were a separate organization..."

Comments:
a. Timetable for implementation: immediate
b. This policy is being proposed based upon the Policy Implementation & 
Experience Report from ARIN 32.
https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf
c: Older versions of the MDN policy did contain new network criteria. 
This criteria appears to have been dropped during subsequent rewrites of 
the MDN policy. "The organization must not allocate a CIDR block larger 
than the current minimum assignment size of the RIR (currently /20 for 
ARIN) to a new network." 
(https://www.arin.net/policy/archive/nrpm_20041015.pdf)





From scottleibrand at gmail.com  Fri May 16 18:06:20 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 16 May 2014 15:06:20 -0700
Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-7:
 NRPM 4 (IPv4) Policy Cleanup
In-Reply-To: <53767353.4020506@arin.net>
References: <53767353.4020506@arin.net>
Message-ID: <CAGkMwz5GZ+7dwB0BNdWDZPHOFJ5H7iB9fNqWEStJhw1HG190UA@mail.gmail.com>

On Fri, May 16, 2014 at 1:21 PM, ARIN <info at arin.net> wrote:

> The ARIN Advisory Council (AC) met on 15 May 2014 and decided to
> send the following to last call:
>
>   Recommended Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup
>
> 2013-7 was revised. The following sentence was added to 4.2.4.3:
> "Determination of the appropriate allocation to be issued is based on
> efficient utilization of space within this time frame, consistent with the
> principles in 4.2.1."
>

For context, we re-added this sentence from the existing 4.2.4.3 text, and
added the "consistent with the principles" clause, to address the concern
raised by Jason Schiller at the ARIN Public Policy Meeting in Chicago.
 Specifically, Jason's concern was that the new text would unintentionally
remove slow-start, if it "allows a new ISP to simply present what their
anticipated use is over the next three months and get that amount of
address space."  As I mentioned in Chicago, 4.2.1.4. Slow start already
(and still) states that "IP address space is allocated to ISPs using a
slow-start model. Allocations are based on justified need, not solely on a
predicted customer base."  I believe that actually addresses his concern on
its own, but to ensure that it is absolutely clear that nothing is changing
here, we thought it would be appropriate to re-incorporate the additional
sentence from the existing text.  Jason also mentioned (and I agreed) that
it was also a good clarification to add an explicit reference to 4.2.1 (the
principles section in which the Slow start language resides), to make clear
that those principles (including slow start) apply to this text.  As that
is consistent with and does not change ARIN staff's current implementation,
we updated the restored sentence to read "Determination of the appropriate
allocation to be issued is based on efficient utilization of space within
this time frame, consistent with the principles in 4.2.1."

This is not a change in current policy or practice, and simply clarifies
the text presented in Chicago by re-adding some existing policy text and
making a reference to existing principles.  As such, I believe this
qualifies as a minor change, so I recommended that the AC send the revised
policy to the community for last call.  If you believe that this additional
text would constitute a significant change to the policy proposal as
presented in Chicago and requires another round of discussion, or if you
have any other substantial concerns that you don't believe were addressed
in the discussion there, please let us know.

Thanks,
Scott


>
> Feedback is encouraged during the last call period. All comments should
> be provided to the Public Policy Mailing List. This last call will
> expire on 2 June 2014. After last call the AC will conduct their
> last call review.
>
> The draft policy text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Recommended Draft Policy ARIN-2013-7
> NRPM 4 (IPv4) Policy Cleanup
>
> Date: 16 May 2014
>
> AC's assessment of conformance with the Principles of Internet Number
> Resource Policy:
>
> "ARIN-2013-7: "NRPM 4 (IPv4) Policy Cleanup" enables fair and impartial
> number resource administration by removing no-longer-relevant sections of
> the NRPM, and clarifying other sections. All of the remaining changes in
> this draft policy have proven uncontroversial thus far."
>
> Problem Statement: Parts of NRPM 4 are irrelevant, especially after IPv4
> run-out, and should be cleaned up for clarity.
>
> Policy statement:
>
> Short list of changes with details explained below.
>
> Remove section 4.1.1 Routability
>
> Update section 4.1.5 Determination of resource requests
>
> Remove section 4.1.7 RFC2050
>
> Remove section 4.1.9 Returned IPv4 Addresses
>
> Replace and retitle section 4.2.4.3 Subscriber Members Less Than One Year
>
> Remove section 4.2.4.4. Subscriber Members After One Year
>
> Details:
>
> Remove section 4.1.1 Routability
>
> It is no longer necessary for the NRPM to suggest where an organization
> obtains resources from.
>
> Retitle and rewrite section (4.1.5 Determination of IP address allocation
> size)
>
> Remove: "Determination of IP address allocation size is the responsibility
> of ARIN."
>
> Replace with: (4.1.5 Resource request size) "Determining the validity of
> the amount of requested IP address resources is the responsibility of ARIN."
>
> Rationale: Clarify that it is the validity of the request that is more the
> focus than the amount of resources requested. This does not prevent ARIN
> from suggesting that a smaller block would be justified where a larger one
> would not, but also does not suggest that it is ARIN's sole discretion to
> judge the size of the blocks needed.
>
> Remove section 4.1.7 RFC2050
>
> Now that RFC2050 has been replaced with RFC 7020 and ARIN-2013-4 RIR
> Principles has been adopted, this section is no longer needed.
>
> Remove section 4.2.4.3 Subscriber Members Less Than One Year and 4.2.4.4.
> Subscriber Members After One Year
>
> Replace with: (4.2.4.3 Request size) "ISPs may request up to a 3-month
> supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 or 8.4
> transfer. Determination of the appropriate allocation to be issued is based
> on efficient utilization of space within this time frame, consistent with
> the principles in 4.2.1."
>
> Rationale: Since ARIN received its last /8, by IANA implementing section
> 10.4.2.2, this is now a distinction without a difference.
>
> Timetable for implementation: Immediate
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140516/2f4f6fd9/attachment.htm>

From jeffrey.lyon at blacklotus.net  Fri May 16 20:31:40 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Sat, 17 May 2014 09:31:40 +0900
Subject: [arin-ppml] Draft Policy ARIN-2014-17: Change Utilization
 Requirements from last-allocation to total-aggregate
In-Reply-To: <53767336.4080001@arin.net>
References: <53767336.4080001@arin.net>
Message-ID: <CACrmG8c7-L7RGnwDg4dAuFmCe1WRRyMEV-M_5P+L+O5aeKr4Pg@mail.gmail.com>

On Sat, May 17, 2014 at 5:21 AM, ARIN <info at arin.net> wrote:
> On 15 May 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-209 Change
> Utilization Requirements from last-allocation to total-aggregate" as a Draft
> Policy.
>
> Draft Policy ARIN-2014-17 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_17.html
>
> You are encouraged to discuss the merits and your concerns of Draft
> Policy 2014-17 on the Public Policy Mailing List.
>
> The AC will evaluate the discussion in order to assess the conformance
> of this draft policy with ARIN's Principles of Internet Number Resource
> Policy as stated in the PDP. Specifically, these principles are:
>
>   * Enabling Fair and Impartial Number Resource Administration
>   * Technically Sound
>   * Supported by the Community
>
> The ARIN Policy Development Process (PDP) can be found at:
> https://www.arin.net/policy/pdp.html
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy ARIN-2014-17
> Change Utilization Requirements from last-allocation to total-aggregate
>
> Date: 16 May 2014
>
> Problem Statement:
>
> Utilization requirements 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 utilized at 75%,
> that request would be denied. This is a bit out of balance as an
> organization with a single /20 utilized at 80% would have less efficient
> utilization but would be eligible to request additional space.
>
> Policy statement:
>
> Section 4.2.4.1- Change text to read: "ISPs must have efficiently utilized
> all previous allocations, in aggregate, to at least 80% 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."
>
> Section 4.3.6.1- Change text to read: "End-users must have efficiently
> utilized all previous assignments, in aggregate, to at least 80% in order to
> receive additional space, and must provide ARIN with utilization details.
> The prefix size for an additional assignment is determined by applying the
> policies found in Section 4.3 of the NRPM."
>
> Comments:
>
> a. Timetable for implementation: Immediate, possibly through board action.
> b. Per originator, This does not currently extend into MDN (aka 4.5.4), and
> I'm not really sure how to reconcile it against 4.5.5, but OP expressed some
> concern that there may be undue restrictions there. It might be better
> served by a separate proposal.
> c. There should probably also be an attempt to clean up the language between
> 4.2.4.1 and 4.3.6.1, as they're both currently very clunky.
> _______________________________________________
> 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.

My concern re: MDN requests is that the draft policy, if enacted,
should consider each discrete network in aggregate (vs. all MDN in
aggregate).

-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From Meows at techie.com  Sun May 18 09:41:51 2014
From: Meows at techie.com (Meows)
Date: Sun, 18 May 2014 06:41:51 -0700
Subject: [arin-ppml] Federal Communication Commission
Message-ID: <5378B89F.4070700@techie.com>


Hundreds of thousands of us worked with groups like Demand Progress, 
CREDO and Free Press, flooding the FCC with so many calls that they had 
to literally turn their phones off.

*That still wasn't enough to stop Chairman Tom Wheeler from backing an 
Internet for the 1 percent ? 
<http://www.washingtonpost.com/blogs/the-switch/wp/2014/05/15/fcc-approves-plan-to-allow-for-paid-pri...>
**We need to make it crystal clear to all five FCC commissioners that 
the public demands Net Neutrality.

Seems all the talk here is redundant,, in face of government control of 
every facet of the internet. Who is going to care about *

Policy Proposal Name: Reduce all Minimum Allocation/Assignment units
Re: [arin-ppml] Adding Enforcement mandate language
when the us government is taking total control of it,

**
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140518/02b4f2da/attachment.htm>

From contact at winterei.se  Sun May 18 10:38:47 2014
From: contact at winterei.se (Paul S.)
Date: Sun, 18 May 2014 23:38:47 +0900
Subject: [arin-ppml] Federal Communication Commission
In-Reply-To: <5378B89F.4070700@techie.com>
References: <5378B89F.4070700@techie.com>
Message-ID: <5378C5F7.1070502@winterei.se>

Err so,

what are you actually proposing?

On 5/18/2014 ?? 10:41, Meows wrote:
>
> Hundreds of thousands of us worked with groups like Demand Progress, 
> CREDO and Free Press, flooding the FCC with so many calls that they 
> had to literally turn their phones off.
>
> *That still wasn't enough to stop Chairman Tom Wheeler from backing an 
> Internet for the 1 percent --- 
> <http://www.washingtonpost.com/blogs/the-switch/wp/2014/05/15/fcc-approves-plan-to-allow-for-paid-pri...>
> **We need to make it crystal clear to all five FCC commissioners that 
> the public demands Net Neutrality.
>
> Seems all the talk here is redundant,, in face of government control 
> of every facet of the internet. Who is going to care about *
> Policy Proposal Name: Reduce all Minimum Allocation/Assignment units
> Re: [arin-ppml] Adding Enforcement mandate language
> when the us government is taking total control of it,
>
> **
>
>
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140518/d5ad71d3/attachment.htm>

From info at arin.net  Mon May 19 19:26:57 2014
From: info at arin.net (ARIN)
Date: Mon, 19 May 2014 17:26:57 -0600
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack
	Policy
Message-ID: <537A9341.9080804@arin.net>

Recommended Draft Policy ARIN-2014-12
Anti-hijack Policy

On 15 May 2014 the ARIN Advisory Council (AC) recommended
ARIN-2014-12 for adoption, making it a Recommended Draft Policy.

ARIN-2014-12 is below and can be found at:
https://www.arin.net/policy/proposals/2014_12.html

You are encouraged to discuss Draft Policy 2014-12 on the PPML prior to
the upcoming ARIN Public Policy Consultation at NANOG 61. Both the 
discussion on the list and at the meeting will be used by the ARIN 
Advisory Council to determine the community consensus for adopting this 
as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Recommended Draft Policy ARIN-2014-12
Anti-hijack Policy

Date: 19 May 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

ARIN-2014-12: Anti-hijack Policy enables fair, impartial, and
technically sound number resource administration by updating the
guidelines for the allocation of experimental resources to ensure all
such allocation are documented in Whois, noting their experimental
status, and provides these allocations may not overlap any other
allocations.  This policy appears strongly supported and non-controversial.

Problem Statement:

ARIN should not give research organizations permission to hijack 
prefixes that have already been allocated. Research organizations 
announcing lit aggregates may receive sensitive production traffic 
belonging to live networks during periods of instability.

Section 11.7 describes more than allocation size therefore updating the 
section heading to something more accurate is appropriate.

Policy statement:

Modify the section 11.7 heading to be more accurate. Modify the first 
sentence to prohibit overlapping assignments. Add text at the end to 
define how research allocations should be designated.

11.7 Resource Allocation Guidelines

The Numbering Resources requested come from the global Internet Resource 
space, do not overlap currently assigned space, and are not from private 
or other non-routable Internet Resource space. The allocation size 
should be consistent with the existing ARIN minimum allocation sizes, 
unless small allocations are intended to be explicitly part of the 
experiment. If an organization requires more resource than stipulated by 
the minimum allocation sizes in force at the time of their request, 
their experimental documentation should have clearly described and 
justified why this is required.

All research allocations must be registered publicly in whois. Each 
research allocation will be designated as a research allocation with a 
comment indicating when the allocation will end.

Comments:

a. Timetable for implementation: Immediate

b. Anything else:

#####

ARIN STAFF ASSESSMENT

Assessment of: Draft Policy ARIN-2014-12: Anti-hijack Policy

Date of Assessment:

1. Summary (Staff Understanding)

This  policy would clarify expectations for experimental allocations by 
requiring that all experimental allocations come from ARIN's Internet 
Resource space,  do not overlap any existing registrations, not be 
private or otherwise un-routable space, and be registered in Whois with 
a designation indicating that the registration is experimental with a 
comment indicating the end date of the experiment.

2. Comments

A.    ARIN Staff Comments

This policy could be implemented as written.

B.    ARIN General Counsel - Legal Assessment

The policy poses no significant legal issues.

3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect.  It is estimated that implementation would occur within 3 months
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:

?      Updated guidelines and internal procedures

?      Staff training

4. Proposal/Draft Policy Text Assessed


Draft Policy ARIN-2014-12: Anti-hijack Policy

Date: 18 April 2014

Problem Statement:

ARIN should not give research organizations permission to hijack

prefixes that have already been allocated. Research organizations

announcing lit aggregates may receive sensitive production traffic

belonging to live networks during periods of instability.


Section 11.7 describes more than allocation size therefore updating the

section heading to something more accurate is appropriate.


Policy statement:

Modify the section 11.7 heading to be more accurate. Modify the first

sentence to prohibit overlapping assignments. Add text at the end to

define how research allocations should be designated.


11.7 Resource Allocation Guidelines

The Numbering Resources requested come from the global Internet Resource

space, do not overlap currently assigned space, and are not from private

or other non-routable Internet Resource space. The allocation size

should be consistent with the existing ARIN minimum allocation sizes,

unless small allocations are intended to be explicitly part of the

experiment. If an organization requires more resource than stipulated by

the minimum allocation sizes in force at the time of their request,

their experimental documentation should have clearly described and

justified why this is required.


All research allocations must be registered publicly in whois. Each

research allocation will be designated as a research allocation with a

comment indicating when the allocation will end.


Comments:

a. Timetable for implementation: Immediate

b. Anything else:


From JOHN at egh.com  Mon May 19 22:56:14 2014
From: JOHN at egh.com (John Santos)
Date: Mon, 19 May 2014 22:56:14 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack
	Policy
In-Reply-To: <537A9341.9080804@arin.net>
Message-ID: <1140519223408.47993A-100000@Ives.egh.com>

On Mon, 19 May 2014, ARIN wrote:

> Recommended Draft Policy ARIN-2014-12
Anti-hijack Policy


11.7 Resource Allocation Guidelines

[...]
   If an organization requires more resource than stipulated by 
the minimum allocation sizes in force at the time of their request, 
their experimental documentation should have clearly described and 
justified why this is required.

Maybe I'm being overly pedantic, but I had trouble parsing this
sentence.  At first I thought it was missing the direct object
or there was a strange shift of tenses, then I realized it does
parse, but is awkward.

Missing direct object:  "... their experimental documentation should have
clearly described and justified *REASONS* (or some other equivalent word)
why this is required." 

I.E. insert an noun to fix it.

Tense shift:  "... their experimental documentation should [have] clearly 
describe[d] and justif*y*[ied] why this is required."

I.E. strike the past tense in brackets, making the whole thing present
tense, to make it clearer. 

Awkward, confusing reading: "... their experimental documentation should 
have (that is, when it was submitted) clearly described (past tense) and 
justified (past tense) why this is (present tense) required.

I.E. live with it, but go "Huh?  What does this mean?" when ever someone
reads it.

Unless this is the standard way lawyers express such things, which 
would go a long way to explaining why no one understands them :-)


-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From info at arin.net  Tue May 20 08:08:14 2014
From: info at arin.net (ARIN)
Date: Tue, 20 May 2014 06:08:14 -0600
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-13: Reduce All
 Minimum Allocation/Assignment Units to /24
Message-ID: <537B45AE.4040208@arin.net>

Recommended Draft Policy ARIN-2014-13
Reduce All Minimum Allocation/Assignment Units to /24

On 15 May 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-208 
Reduce All Minimum Allocation/Assignment Units to /24" as Draft Policy 
ARIN 2014-13: Reduce All Minimum Allocation/Assignment Units to /24.

The AC then recommended ARIN-2014-13 for adoption, making it a 
Recommended Draft Policy.

ARIN-2014-13 is below and can be found at:
https://www.arin.net/policy/proposals/2014_13.html

You are encouraged to discuss Draft Policy 2014-13 on the PPML prior to
the upcoming ARIN Public Policy Consultation at NANOG 61. Both the 
discussion on the list and at the meeting will be used by the ARIN 
Advisory Council to determine the community consensus for adopting this 
as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Recommended Draft Policy ARIN-2014-13
Reduce All Minimum Allocation/Assignment Units to /24

Date: 20 May 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment 
Units to /24 - This proposal will lower all allocation(s) and 
assignment(s) of IPv4 address in section 4.2 and 4.3 to a /24 minimum. 
The policy would also remove section 4.9 as the allocation and 
assignment sizes were now larger than 4.2 and 4.3. As noted in the staff 
report it will also remove the maximum initial allocation that was used 
with the examples in 4.2.2.2. The changes to the NRPM are fair in that 
they would treat all resource applicants equally. They are technically 
sound and have received support from the community.

Problem Statement:

As we approach runout, more and more end users and smaller ISPs will be 
unable to obtain space from their upstreams and will be seeking space 
from ARIN. In order to meet these needs to the extent possible and to 
make policy more fair to a broader range of the ARIN constituency, we 
should reduce the minimum assignment and allocation units for IPv4 to 
/24 across the board.

Policy statement:

Remove all references to minimum allocations /20 and /22 replacing them 
with the term allocation or with /24 when referencing minimum size blocks.

Change the title of 4.2.2.1 to "ISP Requirements" with revised text stating:

All ISP organizations must satisfy the following requirements...thus 
eliminating the entire Multi-homed section and subsections along with 
other superfluous example text.

Delete the special case allocations/assignments for the Caribbean as the 
new /24 minimums are an improvement.

Comments:
a. Timetable for implementation: Immediate b. A red line version has 
been included

Full text version of changes for easy reference:

4.2.1.5. Minimum allocation
In general, ARIN allocates /24 and larger IP address prefixes to ISPs. 
If allocations smaller than /24 are needed, ISPs should request address 
space from their upstream provider.

4.2.2.1 ISP Requirements
All ISP organizations must satisfy the following requirements:

4.2.2.1.1 Use of /24
The efficient utilization of an entire previously allocated /24 from 
their upstream ISP. This allocation may have been provided by an ISP?s 
upstream provider(s), and does not have to be contiguous address space.

4.2.2.1.3. Three months
Provide detailed information showing specifically how the requested 
allocation will be utilized within three months.

4.2.2.1.4. Renumber and return
ISPs receiving a new allocation may wish to renumber out of their 
previously allocated space. In this case, an ISP must use the new 
allocation to renumber out of that previously allocated block of address 
space and must return the space to its upstream provider.

4.2.2.2. [section number retired]

4.3.2 Minimum assignment

4.3.2.1. [section moved to 4.3.2]
The minimum block of IP address space assigned by ARIN to end-users is a 
/24. If assignments smaller than /24 are needed, end-users should 
contact their upstream provider.

4.3.2.2 [section number retired]

4.9 [section number retired]

##########

ARIN STAFF ASSESSMENT
Assessment of: ARIN-prop-208 Reduce All Minimum Allocation/Assignment 
Units to /24
Date of Assessment: 11 May 2014

1. Summary (Staff Understanding)

This policy would reduce the minimum allocation/assignment size to /24 
for all networks, whether end user or ISP and whether single or 
multi-homed. Additionally, it would eliminate the existing multi-homed 
policies.

2. Comments

A. ARIN Staff Comments

1. It is not clear in this proposal what criteria would be used to 
determine any allocation size other than a /24. Current policy provides 
clear criteria for how to qualify for a /22, /21, and a /20. Would the 
same criteria still apply for organizations that request more than an 
initial allocation of a/24?

2. Staff uses current criteria defined in 4.2.2.1.1 in conjunction with 
section 4.2.1.4 (slow start) to establish a de facto /20 maximum initial 
allocation size for ISPs new to ARIN. Staff would recommend that a 
maximum initial allocation size of a /20 be noted in section 4.2.1.5 to 
codify existing practice and provide clarity, and that it be renamed 
to ?Minimum and Maximum Allocation?.

3. This proposal would benefit smaller ISPs who are unable to qualify 
currently under ARIN IPv4 policies, and particularly would be unable to 
qualify for 8.3 and 8.4 transfers in a post-depletion world.
*Note, this was a point raised in the policy experience report in Chicago.

4. ARIN will likely have many discontiguous /24s as we near depletion 
and fewer and fewer larger prefixes. This policy would actually allow 
more organizations to use these smallest prefixes, thus ensuring the 
efficient run-out of ARIN?s IPv4 address pool.

B. ARIN General Counsel - Legal Assessment

This proposal does not appear to pose any legal risk.

3. Resource Impact
This policy would have minimal resource impact from an implementation 
aspect. It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees.

The following would be needed in order to implement:
Updated guidelines and internal procedures
Staff training

4. Proposal/Draft Policy Text Assessed
ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to /24

Problem Statement:
As we approach runout, more and more end users and smaller ISPs will be 
unable to obtain space from their upstreams and will be seeking space 
from ARIN. In order to meet these needs to the extent possible and to 
make policy more fair to a broader range of the ARIN constituency, we 
should reduce the minimum assignment and allocation units for IPv4 to 
/24 across the board.

Policy statement:
Remove all references to minimum allocations /20 and /22 replacing them 
with the term allocation or with /24 when referencing minimum size blocks.

Change the title of 4.2.2.1 to "ISP Requirements" with revised text stating:
All ISP organizations must satisfy the following requirements...thus 
eliminating the entire Multi-homed section and subsections along with 
other superfluous example text.

Delete the special case allocations/assignments for the Caribbean as the 
new /24 minimums are an improvement.

Text assessed:

4.2.1.5. Minimum allocation
In general, ARIN allocates /24 and larger IP address prefixes to ISPs. 
If allocations smaller than /24 are needed, ISPs should request address 
space from their upstream provider.

4.2.2.1 ISP Requirements
All ISP organizations must satisfy the following requirements:

4.2.2.1.1 Use of /24
The efficient utilization of an entire previously allocated /24 from 
their upstream ISP. This allocation may have been provided by an ISP?s 
upstream provider(s), and does not have to be contiguous address space.

4.2.2.1.4. Renumber and return
ISPs receiving a new allocation may wish to renumber out of their 
previously allocated space. In this case, an ISP must use the new 
allocation to renumber out of that previously allocated block of address 
space and must return the space to its upstream provider.

4.2.2.2. [section number retired]

4.3.2 Minimum assignment

4.3.2.1. [section moved to 4.3.2]
The minimum block of IP address space assigned by ARIN to end-users is a 
/24. If assignments smaller than /24 are needed, end-users should 
contact their upstream provider.

4.3.2.2 [section number retired]


From farmer at umn.edu  Tue May 20 14:02:50 2014
From: farmer at umn.edu (David Farmer)
Date: Tue, 20 May 2014 13:02:50 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack
 Policy
In-Reply-To: <1140519223408.47993A-100000@Ives.egh.com>
References: <1140519223408.47993A-100000@Ives.egh.com>
Message-ID: <537B98CA.3030106@umn.edu>

On 5/19/14, 21:56 , John Santos wrote:
> On Mon, 19 May 2014, ARIN wrote:
>
>> Recommended Draft Policy ARIN-2014-12
> Anti-hijack Policy
>
>
> 11.7 Resource Allocation Guidelines
>
> [...]
>     If an organization requires more resource than stipulated by
> the minimum allocation sizes in force at the time of their request,
> their experimental documentation should have clearly described and
> justified why this is required.
>
> Maybe I'm being overly pedantic, but I had trouble parsing this
> sentence.  At first I thought it was missing the direct object
> or there was a strange shift of tenses, then I realized it does
> parse, but is awkward.
>
> Missing direct object:  "... their experimental documentation should have
> clearly described and justified *REASONS* (or some other equivalent word)
> why this is required."
>
> I.E. insert an noun to fix it.
>
> Tense shift:  "... their experimental documentation should [have] clearly
> describe[d] and justif*y*[ied] why this is required."
>
> I.E. strike the past tense in brackets, making the whole thing present
> tense, to make it clearer.
>
> Awkward, confusing reading: "... their experimental documentation should
> have (that is, when it was submitted) clearly described (past tense) and
> justified (past tense) why this is (present tense) required.
>
> I.E. live with it, but go "Huh?  What does this mean?" when ever someone
> reads it.
>
> Unless this is the standard way lawyers express such things, which
> would go a long way to explaining why no one understands them :-)

The sentence you have a problem with is currently in the NRPM and not 
relevant to the problem statement or part of the text being changed by 
this Recommended Draft Policy.  Previous emails in the thread from when 
this was a Draft Policy have a red-lined version of text showing both 
the original text and the changes proposed by this policy.

That being said, if the community thinks making additional changes like 
you suggest will improve the overall clarity of this policy, then we 
probably should take care of this.

In looking at the sentence in question; I think the "have" in the 
sentence is extraneous, and can deleted.  Then changing "this" to "a 
larger allocation" and the tense changes you suggest, results in;

    If an organization requires more resource than stipulated by the
    minimum allocation sizes in force at the time of their request,
    their experimental documentation should clearly describe and
    justify why a larger allocation is required.

Does that parse better?  Does that represent the original intent?

However, I need to know what the rest of the community thinks.

Is this something we should clean up now or is the intent of the 
original text clear enough without any changes?

If you believe the change is necessary, in your opinion is this a minor 
editorial change that the AC could make while going from Recommended 
Draft Policy to Last Call?

Thanks.


-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================


From owen at delong.com  Wed May 21 14:33:42 2014
From: owen at delong.com (Owen DeLong)
Date: Wed, 21 May 2014 11:33:42 -0700
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack
	Policy
In-Reply-To: <537B98CA.3030106@umn.edu>
References: <1140519223408.47993A-100000@Ives.egh.com>
	<537B98CA.3030106@umn.edu>
Message-ID: <E966D949-CBE7-4BB2-AE10-0D42B27752AB@delong.com>

> 
> In looking at the sentence in question; I think the "have" in the sentence is extraneous, and can deleted.  Then changing "this" to "a larger allocation" and the tense changes you suggest, results in;
> 
>   If an organization requires more resource than stipulated by the
>   minimum allocation sizes in force at the time of their request,
>   their experimental documentation should clearly describe and
>   justify why a larger allocation is required.
> 

s/resource/resources/
s/minimum allocation sizes/applicable minimum allocation size/
s/experimental documentation/request/

result:

If an organization requires more resources than stipulated by the applicable minimum allocation in force at the time of their request, their request should clearly describe and justify why a larger allocation is required.

I think this not only parses better, but is more accurate.

The first change resolves a grammar error.
The second change avoids ambiguity between whether all requests are subject to all minimums in this case vs. the intended meaning that the minimum applicable elsewhere in policy.
The third change is because their documentation should be documentation of an experiment, not experimental documentation and what we really care about is the information provided in their ARIN request anyway.

I think since this is a minor change which does not alter the meaning of the policy and does improve readability and clarity, that we should probably go ahead and incorporate it as you proposed prior to last call.

Owen



From lsawyer at gci.com  Wed May 21 14:52:48 2014
From: lsawyer at gci.com (Leif Sawyer)
Date: Wed, 21 May 2014 10:52:48 -0800
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
	Anti-hijack	Policy
In-Reply-To: <E966D949-CBE7-4BB2-AE10-0D42B27752AB@delong.com>
References: <1140519223408.47993A-100000@Ives.egh.com>
	<537B98CA.3030106@umn.edu>
	<E966D949-CBE7-4BB2-AE10-0D42B27752AB@delong.com>
Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com>

s/should/must


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Wednesday, May 21, 2014 10:34 AM
To: David Farmer
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy

> 
> In looking at the sentence in question; I think the "have" in the 
> sentence is extraneous, and can deleted.  Then changing "this" to "a 
> larger allocation" and the tense changes you suggest, results in;
> 
>   If an organization requires more resource than stipulated by the
>   minimum allocation sizes in force at the time of their request,
>   their experimental documentation should clearly describe and
>   justify why a larger allocation is required.
> 

s/resource/resources/
s/minimum allocation sizes/applicable minimum allocation size/ s/experimental documentation/request/

result:

If an organization requires more resources than stipulated by the applicable minimum allocation in force at the time of their request, their request should clearly describe and justify why a larger allocation is required.

I think this not only parses better, but is more accurate.

The first change resolves a grammar error.
The second change avoids ambiguity between whether all requests are subject to all minimums in this case vs. the intended meaning that the minimum applicable elsewhere in policy.
The third change is because their documentation should be documentation of an experiment, not experimental documentation and what we really care about is the information provided in their ARIN request anyway.

I think since this is a minor change which does not alter the meaning of the policy and does improve readability and clarity, that we should probably go ahead and incorporate it as you proposed prior to last call.

Owen

_______________________________________________
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.



From farmer at umn.edu  Wed May 21 16:03:39 2014
From: farmer at umn.edu (David Farmer)
Date: Wed, 21 May 2014 15:03:39 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack
 Policy
In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com>
References: <1140519223408.47993A-100000@Ives.egh.com>	<537B98CA.3030106@umn.edu>
	<E966D949-CBE7-4BB2-AE10-0D42B27752AB@delong.com>
	<18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com>
Message-ID: <537D069B.5030601@umn.edu>

I think "should" is sufficiently strong, and gives ARIN Staff a little 
wiggle room to do what makes sense.  There really have never been that 
many experimental allocations.

We had a big whoopsie with all 5 RIR's authorizing /12 anchor routes. 
ARIN probably won't do that again anyway, but it's still worth a small 
fix in policy, just to be clear about it.  The sentence is question is a 
little rough, so while we are at it a little editorial clean up is 
probably in order, but please let's not over do it.

I really would like to hear from a few more people about if this 
editorial change is a good idea or not, even a few +/-1s would be helpful.

Thanks.

On 5/21/14, 13:52 , Leif Sawyer wrote:
> s/should/must
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
> Sent: Wednesday, May 21, 2014 10:34 AM
> To: David Farmer
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy
>
>>
>> In looking at the sentence in question; I think the "have" in the
>> sentence is extraneous, and can deleted.  Then changing "this" to "a
>> larger allocation" and the tense changes you suggest, results in;
>>
>>    If an organization requires more resource than stipulated by the
>>    minimum allocation sizes in force at the time of their request,
>>    their experimental documentation should clearly describe and
>>    justify why a larger allocation is required.
>>
>
> s/resource/resources/
> s/minimum allocation sizes/applicable minimum allocation size/ s/experimental documentation/request/
>
> result:
>
> If an organization requires more resources than stipulated by the applicable minimum allocation in force at the time of their request, their request should clearly describe and justify why a larger allocation is required.
>
> I think this not only parses better, but is more accurate.
>
> The first change resolves a grammar error.
> The second change avoids ambiguity between whether all requests are subject to all minimums in this case vs. the intended meaning that the minimum applicable elsewhere in policy.
> The third change is because their documentation should be documentation of an experiment, not experimental documentation and what we really care about is the information provided in their ARIN request anyway.
>
> I think since this is a minor change which does not alter the meaning of the policy and does improve readability and clarity, that we should probably go ahead and incorporate it as you proposed prior to last call.
>
> Owen
>
> _______________________________________________
> 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.
>


-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================


From derekc at cnets.net  Wed May 21 17:18:56 2014
From: derekc at cnets.net (Derek Calanchini)
Date: Wed, 21 May 2014 14:18:56 -0700
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-13: Reduce All
 Minimum Allocation/Assignment Units to /24
In-Reply-To: <537B45AE.4040208@arin.net>
References: <537B45AE.4040208@arin.net>
Message-ID: <537D1840.7020005@cnets.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140521/3f8fb7ce/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cnslogo1.bmp
Type: image/bmp
Size: 72774 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140521/3f8fb7ce/attachment.bmp>

From rudi.daniel at gmail.com  Wed May 21 17:34:13 2014
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Wed, 21 May 2014 17:34:13 -0400
Subject: [arin-ppml] 2014-12
In-Reply-To: <CA+uaoiWSfasDun1O4JkLfSwQP9F3b_XZgJNCpZQjrFFRmqkcHA@mail.gmail.com>
References: <CA+uaoiWSfasDun1O4JkLfSwQP9F3b_XZgJNCpZQjrFFRmqkcHA@mail.gmail.com>
Message-ID: <CA+uaoiWYP1fEvkCE=v_1=K-Y3-UpjLgYyxEZXHa4xi9GUcMTqQ@mail.gmail.com>

>>their experimental >>documentation (should) clearly >>describe ....

Would you consider changing 'should' to 'shall' to suggest mandatory
requirement?

And

>   justify why a larger allocation >(is required)

'is required'  to
'should be allocated'

Rudi Daniel
 On May 21, 2014 5:20 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: Recommended Draft Policy ARIN-2014-12: Anti-hijack    Policy
      (Owen DeLong)
   2. Re: Recommended Draft Policy ARIN-2014-12:        Anti-hijack
Policy
      (Leif Sawyer)
   3. Re: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy
      (David Farmer)
   4. Re: Recommended Draft Policy ARIN-2014-13: Reduce All Minimum
      Allocation/Assignment Units to /24 (Derek Calanchini)


----------------------------------------------------------------------

Message: 1
Date: Wed, 21 May 2014 11:33:42 -0700
From: Owen DeLong <owen at delong.com>
To: David Farmer <farmer at umn.edu>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
        Anti-hijack     Policy
Message-ID: <E966D949-CBE7-4BB2-AE10-0D42B27752AB at delong.com>
Content-Type: text/plain; charset=us-ascii

>
> In looking at the sentence in question; I think the "have" in the
sentence is extraneous, and can deleted.  Then changing "this" to "a larger
allocation" and the tense changes you suggest, results in;
>
>   If an organization requires more resource than stipulated by the
>   minimum allocation sizes in force at the time of their request,
>   their experimental documentation should clearly describe and
>   justify why a larger allocation is required.
>

s/resource/resources/
s/minimum allocation sizes/applicable minimum allocation size/
s/experimental documentation/request/

result:

If an organization requires more resources than stipulated by the
applicable minimum allocation in force at the time of their request, their
request should clearly describe and justify why a larger allocation is
required.

I think this not only parses better, but is more accurate.

The first change resolves a grammar error.
The second change avoids ambiguity between whether all requests are subject
to all minimums in this case vs. the intended meaning that the minimum
applicable elsewhere in policy.
The third change is because their documentation should be documentation of
an experiment, not experimental documentation and what we really care about
is the information provided in their ARIN request anyway.

I think since this is a minor change which does not alter the meaning of
the policy and does improve readability and clarity, that we should
probably go ahead and incorporate it as you proposed prior to last call.

Owen



------------------------------

Message: 2
Date: Wed, 21 May 2014 10:52:48 -0800
From: Leif Sawyer <lsawyer at gci.com>
To: Owen DeLong <owen at delong.com>, David Farmer <farmer at umn.edu>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
        Anti-hijack     Policy
Message-ID:
        <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B at fnb1mbx01.gci.com>
Content-Type: text/plain; charset=WINDOWS-1252

s/should/must


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Owen DeLong
Sent: Wednesday, May 21, 2014 10:34 AM
To: David Farmer
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack
Policy

>
> In looking at the sentence in question; I think the "have" in the
> sentence is extraneous, and can deleted.  Then changing "this" to "a
> larger allocation" and the tense changes you suggest, results in;
>
>   If an organization requires more resource than stipulated by the
>   minimum allocation sizes in force at the time of their request,
>   their experimental documentation should clearly describe and
>   justify why a larger allocation is required.
>

s/resource/resources/
s/minimum allocation sizes/applicable minimum allocation size/
s/experimental documentation/request/

result:

If an organization requires more resources than stipulated by the
applicable minimum allocation in force at the time of their request, their
request should clearly describe and justify why a larger allocation is
required.

I think this not only parses better, but is more accurate.

The first change resolves a grammar error.
The second change avoids ambiguity between whether all requests are subject
to all minimums in this case vs. the intended meaning that the minimum
applicable elsewhere in policy.
The third change is because their documentation should be documentation of
an experiment, not experimental documentation and what we really care about
is the information provided in their ARIN request anyway.

I think since this is a minor change which does not alter the meaning of
the policy and does improve readability and clarity, that we should
probably go ahead and incorporate it as you proposed prior to last call.

Owen

_______________________________________________
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.



------------------------------

Message: 3
Date: Wed, 21 May 2014 15:03:39 -0500
From: David Farmer <farmer at umn.edu>
To: Leif Sawyer <lsawyer at gci.com>,    Owen DeLong <owen at delong.com>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
        Anti-hijack Policy
Message-ID: <537D069B.5030601 at umn.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed

I think "should" is sufficiently strong, and gives ARIN Staff a little
wiggle room to do what makes sense.  There really have never been that
many experimental allocations.

We had a big whoopsie with all 5 RIR's authorizing /12 anchor routes.
ARIN probably won't do that again anyway, but it's still worth a small
fix in policy, just to be clear about it.  The sentence is question is a
little rough, so while we are at it a little editorial clean up is
probably in order, but please let's not over do it.

I really would like to hear from a few more people about if this
editorial change is a good idea or not, even a few +/-1s would be helpful.

Thanks.

On 5/21/14, 13:52 , Leif Sawyer wrote:
> s/should/must
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Owen DeLong
> Sent: Wednesday, May 21, 2014 10:34 AM
> To: David Farmer
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
Anti-hijack Policy
>
>>
>> In looking at the sentence in question; I think the "have" in the
>> sentence is extraneous, and can deleted.  Then changing "this" to "a
>> larger allocation" and the tense changes you suggest, results in;
>>
>>    If an organization requires more resource than stipulated by the
>>    minimum allocation sizes in force at the time of their request,
>>    their experimental documentation should clearly describe and
>>    justify why a larger allocation is required.
>>
>
> s/resource/resources/
> s/minimum allocation sizes/applicable minimum allocation size/
s/experimental documentation/request/
>
> result:
>
> If an organization requires more resources than stipulated by the
applicable minimum allocation in force at the time of their request, their
request should clearly describe and justify why a larger allocation is
required.
>
> I think this not only parses better, but is more accurate.
>
> The first change resolves a grammar error.
> The second change avoids ambiguity between whether all requests are
subject to all minimums in this case vs. the intended meaning that the
minimum applicable elsewhere in policy.
> The third change is because their documentation should be documentation
of an experiment, not experimental documentation and what we really care
about is the information provided in their ARIN request anyway.
>
> I think since this is a minor change which does not alter the meaning of
the policy and does improve readability and clarity, that we should
probably go ahead and incorporate it as you proposed prior to last call.
>
> Owen
>
> _______________________________________________
> 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.
>


--
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================


------------------------------

Message: 4
Date: Wed, 21 May 2014 14:18:56 -0700
From: Derek Calanchini <derekc at cnets.net>
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-13: Reduce
        All Minimum Allocation/Assignment Units to /24
Message-ID: <537D1840.7020005 at cnets.net>
Content-Type: text/plain; charset="us-ascii"

An HTML attachment was scrubbed...
URL: <
http://lists.arin.net/pipermail/arin-ppml/attachments/20140521/3f8fb7ce/attachment.html
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cnslogo1.bmp
Type: image/bmp
Size: 72774 bytes
Desc: not available
URL: <
http://lists.arin.net/pipermail/arin-ppml/attachments/20140521/3f8fb7ce/attachment.bmp
>

------------------------------

_______________________________________________
ARIN-PPML mailing list
ARIN-PPML at arin.net
http://lists.arin.net/mailman/listinfo/arin-ppml

End of ARIN-PPML Digest, Vol 107, Issue 26
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140521/6ee890d9/attachment.htm>

From lsawyer at gci.com  Wed May 21 18:23:04 2014
From: lsawyer at gci.com (Leif Sawyer)
Date: Wed, 21 May 2014 14:23:04 -0800
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack
 Policy
In-Reply-To: <537D069B.5030601@umn.edu>
References: <1140519223408.47993A-100000@Ives.egh.com>
	<537B98CA.3030106@umn.edu>
	<E966D949-CBE7-4BB2-AE10-0D42B27752AB@delong.com>
	<18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com>
	<537D069B.5030601@umn.edu>
Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com>

I just can't think of a time when 
   "experimental documentation [should] clearly describe and justify"
"should" ever be  "doesn't"


hence my suggestion to use "must".



-----Original Message-----
From: David Farmer [mailto:farmer at umn.edu] 
Sent: Wednesday, May 21, 2014 12:04 PM
To: Leif Sawyer; Owen DeLong
Cc: David Farmer; arin-ppml at arin.net
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy

I think "should" is sufficiently strong, and gives ARIN Staff a little wiggle room to do what makes sense.  There really have never been that many experimental allocations.

We had a big whoopsie with all 5 RIR's authorizing /12 anchor routes. 
ARIN probably won't do that again anyway, but it's still worth a small fix in policy, just to be clear about it.  The sentence is question is a little rough, so while we are at it a little editorial clean up is probably in order, but please let's not over do it.

I really would like to hear from a few more people about if this editorial change is a good idea or not, even a few +/-1s would be helpful.

Thanks.

On 5/21/14, 13:52 , Leif Sawyer wrote:
> s/should/must
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] 
> On Behalf Of Owen DeLong
> Sent: Wednesday, May 21, 2014 10:34 AM
> To: David Farmer
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: 
> Anti-hijack Policy
>
>>
>> In looking at the sentence in question; I think the "have" in the 
>> sentence is extraneous, and can deleted.  Then changing "this" to "a 
>> larger allocation" and the tense changes you suggest, results in;
>>
>>    If an organization requires more resource than stipulated by the
>>    minimum allocation sizes in force at the time of their request,
>>    their experimental documentation should clearly describe and
>>    justify why a larger allocation is required.
>>
>
> s/resource/resources/
> s/minimum allocation sizes/applicable minimum allocation size/ 
> s/experimental documentation/request/
>
> result:
>
> If an organization requires more resources than stipulated by the applicable minimum allocation in force at the time of their request, their request should clearly describe and justify why a larger allocation is required.
>
> I think this not only parses better, but is more accurate.
>
> The first change resolves a grammar error.
> The second change avoids ambiguity between whether all requests are subject to all minimums in this case vs. the intended meaning that the minimum applicable elsewhere in policy.
> The third change is because their documentation should be documentation of an experiment, not experimental documentation and what we really care about is the information provided in their ARIN request anyway.
>
> I think since this is a minor change which does not alter the meaning of the policy and does improve readability and clarity, that we should probably go ahead and incorporate it as you proposed prior to last call.
>
> Owen
>
> _______________________________________________
> 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.
>


--
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952 ================================================



From hannigan at gmail.com  Wed May 21 18:30:48 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 21 May 2014 18:30:48 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack
	Policy
In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com>
References: <1140519223408.47993A-100000@Ives.egh.com>
	<537B98CA.3030106@umn.edu>
	<E966D949-CBE7-4BB2-AE10-0D42B27752AB@delong.com>
	<18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com>
	<537D069B.5030601@umn.edu>
	<18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com>
Message-ID: <CAMDXq5PReE=O0yRdG3AGgFa+OWYvGpza12jE5nDwJ7Lx3bCwaw@mail.gmail.com>

The problem this proposal intended to fix was with the staff, not the
researchers.

This proposal is a no op. Who was held accountable? Who will be held
accountable if it happens again?

I suggest the intent of the policy is good enough.




On Wednesday, May 21, 2014, Leif Sawyer <lsawyer at gci.com> wrote:

> I just can't think of a time when
>    "experimental documentation [should] clearly describe and justify"
> "should" ever be  "doesn't"
>
>
> hence my suggestion to use "must".
>
>
>
> -----Original Message-----
> From: David Farmer [mailto:farmer at umn.edu]
> Sent: Wednesday, May 21, 2014 12:04 PM
> To: Leif Sawyer; Owen DeLong
> Cc: David Farmer; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
> Anti-hijack Policy
>
> I think "should" is sufficiently strong, and gives ARIN Staff a little
> wiggle room to do what makes sense.  There really have never been that many
> experimental allocations.
>
> We had a big whoopsie with all 5 RIR's authorizing /12 anchor routes.
> ARIN probably won't do that again anyway, but it's still worth a small fix
> in policy, just to be clear about it.  The sentence is question is a little
> rough, so while we are at it a little editorial clean up is probably in
> order, but please let's not over do it.
>
> I really would like to hear from a few more people about if this editorial
> change is a good idea or not, even a few +/-1s would be helpful.
>
> Thanks.
>
> On 5/21/14, 13:52 , Leif Sawyer wrote:
> > s/should/must
> >
> >
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> > On Behalf Of Owen DeLong
> > Sent: Wednesday, May 21, 2014 10:34 AM
> > To: David Farmer
> > Cc: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
> > Anti-hijack Policy
> >
> >>
> >> In looking at the sentence in question; I think the "have" in the
> >> sentence is extraneous, and can deleted.  Then changing "this" to "a
> >> larger allocation" and the tense changes you suggest, results in;
> >>
> >>    If an organization requires more resource than stipulated by the
> >>    minimum allocation sizes in force at the time of their request,
> >>    their experimental documentation should clearly describe and
> >>    justify why a larger allocation is required.
> >>
> >
> > s/resource/resources/
> > s/minimum allocation sizes/applicable minimum allocation size/
> > s/experimental documentation/request/
> >
> > result:
> >
> > If an organization requires more resources than stipulated by the
> applicable minimum allocation in force at the time of their request, their
> request should clearly describe and justify why a larger allocation is
> required.
> >
> > I think this not only parses better, but is more accurate.
> >
> > The first change resolves a grammar error.
> > The second change avoids ambiguity between whether all requests are
> subject to all minimums in this case vs. the intended meaning that the
> minimum applicable elsewhere in policy.
> > The third change is because their documentation should be documentation
> of an experiment, not experimental documentation and what we really care
> about is the information provided in their ARIN request anyway.
> >
> > I think since this is a minor change which does not alter the meaning of
> the policy and does improve readability and clarity, that we should
> probably go ahead and incorporate it as you proposed prior to last call.
> >
> > Owen
> >
> > _______________________________________________
> > 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.
> >
>
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
>
> _______________________________________________
> PPML
> You are receiving
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140521/612cc28e/attachment.htm>

From jcurran at arin.net  Thu May 22 06:47:36 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 22 May 2014 10:47:36 +0000
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-13: Reduce All
 Minimum Allocation/Assignment Units to /24
In-Reply-To: <537D1840.7020005@cnets.net>
References: <537B45AE.4040208@arin.net> <537D1840.7020005@cnets.net>
Message-ID: <99A2FE36-8896-4F54-A48B-695FDE179744@corp.arin.net>

On May 21, 2014, at 5:18 PM, Derek Calanchini <derekc at cnets.net> wrote:

> GREAT!  Does prop 208 being accepted mean I can re-request my /22 now, or do I have to wait till after NANOG 61? 

Policy proposals become accepted as Draft Policies when they have a clear 
problem statement with respect to number resource policy in the region.

Draft policies become Recommended Draft Policies when it appears that they
enable fair and impartial number resource administration, are technically sound,
and have support of the community.

Recommended Draft Policies must go to a Public Policy Consultation (such as
will occur during NANOG 61) in order to be sent to Last Call.

Recommended Draft Policies which have undergone last call may be sent to 
the ARIN Board for adoption (this occurs within 60 days of the Public Policy
Consultation.)

Once adopted by the ARIN Board, then the policy is implemented by the ARIN
staff.

i.e. if ARIN-2014-13 is supported by the community at the upcoming PPC, and 
then everything goes smoothly from that point, likely time for availability to the 
community would August or September.

FYI,
/John

John Curran
President and CEO
ARIN



From jcurran at arin.net  Thu May 22 06:54:08 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 22 May 2014 10:54:08 +0000
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
	Anti-hijack	Policy
In-Reply-To: <CAMDXq5PReE=O0yRdG3AGgFa+OWYvGpza12jE5nDwJ7Lx3bCwaw@mail.gmail.com>
References: <1140519223408.47993A-100000@Ives.egh.com>
	<537B98CA.3030106@umn.edu>
	<E966D949-CBE7-4BB2-AE10-0D42B27752AB@delong.com>
	<18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com>
	<537D069B.5030601@umn.edu>
	<18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com>
	<CAMDXq5PReE=O0yRdG3AGgFa+OWYvGpza12jE5nDwJ7Lx3bCwaw@mail.gmail.com>
Message-ID: <60D59373-880F-41D5-A5E1-B6CB101D4950@corp.arin.net>

On May 21, 2014, at 6:30 PM, Martin Hannigan <hannigan at gmail.com> wrote:
> 
> The problem this proposal intended to fix was with the staff, not the researchers. 

<http://lists.arin.net/pipermail/arin-ppml/2014-March/028104.html>

"Going forward, ARIN will not issue routing authorization that covers any
address space issued to others without community-developed policy that
specifically directs us to do so. "

<http://lists.arin.net/pipermail/arin-ppml/2014-March/028117.html>

"NRPM 11 was designed for parties requesting allocations from ARIN for
research purposes; not ARIN checking the quality/integrity of new block
received from IANA.  Given the recent occurance, I believe it is prudent
for ARIN to utilize NRPM 11 going forward for purposes of this quality
checking, as it makes visible the organization doing the testing/making
use of the space, including duration of the activity and research nature,
as well as reaffirming the expected uniqueness requirement."

> This proposal is a no op. Who was held accountable? Who will be held accountable if it happens again? 

I am accountable to the community and its elected Board for compliance.

> I suggest the intent of the policy is good enough. 

Clarity in number resource policy is always helpful in alignment with community
expectation and compliance to same.

Thanks!
/John

John Curran
President and CEO
ARIN



From kkargel at polartel.com  Thu May 22 10:08:30 2014
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 22 May 2014 09:08:30 -0500
Subject: [arin-ppml] 2014-12
In-Reply-To: <CA+uaoiWYP1fEvkCE=v_1=K-Y3-UpjLgYyxEZXHa4xi9GUcMTqQ@mail.gmail.com>
References: <CA+uaoiWSfasDun1O4JkLfSwQP9F3b_XZgJNCpZQjrFFRmqkcHA@mail.gmail.com>
	<CA+uaoiWYP1fEvkCE=v_1=K-Y3-UpjLgYyxEZXHa4xi9GUcMTqQ@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD28013850CED7@MAIL1.polartel.local>

IMHO ?Should? and ?May? have no place in policy.  They are both no-ops as they place no restrictions and carry no authority.  They would be perfectly at home in a best practices document, but serve no function in policy.
Kevin


From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Rudolph Daniel
Sent: Wednesday, May 21, 2014 4:34 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] 2014-12


>>their experimental >>documentation (should) clearly >>describe ....

Would you consider changing 'should' to 'shall' to suggest mandatory requirement?

And

>   justify why a larger allocation >(is required)

'is required'  to
'should be allocated'

Rudi Daniel
On May 21, 2014 5:20 PM, <arin-ppml-request at arin.net<mailto:arin-ppml-request at arin.net>> wrote:
Send ARIN-PPML mailing list submissions to
        arin-ppml at arin.net<mailto: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<mailto:arin-ppml-request at arin.net>

You can reach the person managing the list at
        arin-ppml-owner at arin.net<mailto: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: Recommended Draft Policy ARIN-2014-12: Anti-hijack    Policy
      (Owen DeLong)
   2. Re: Recommended Draft Policy ARIN-2014-12:        Anti-hijack     Policy
      (Leif Sawyer)
   3. Re: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy
      (David Farmer)
   4. Re: Recommended Draft Policy ARIN-2014-13: Reduce All Minimum
      Allocation/Assignment Units to /24 (Derek Calanchini)


----------------------------------------------------------------------

Message: 1
Date: Wed, 21 May 2014 11:33:42 -0700
From: Owen DeLong <owen at delong.com<mailto:owen at delong.com>>
To: David Farmer <farmer at umn.edu<mailto:farmer at umn.edu>>
Cc: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
        Anti-hijack     Policy
Message-ID: <E966D949-CBE7-4BB2-AE10-0D42B27752AB at delong.com<mailto:E966D949-CBE7-4BB2-AE10-0D42B27752AB at delong.com>>
Content-Type: text/plain; charset=us-ascii

>
> In looking at the sentence in question; I think the "have" in the sentence is extraneous, and can deleted.  Then changing "this" to "a larger allocation" and the tense changes you suggest, results in;
>
>   If an organization requires more resource than stipulated by the
>   minimum allocation sizes in force at the time of their request,
>   their experimental documentation should clearly describe and
>   justify why a larger allocation is required.
>

s/resource/resources/
s/minimum allocation sizes/applicable minimum allocation size/
s/experimental documentation/request/

result:

If an organization requires more resources than stipulated by the applicable minimum allocation in force at the time of their request, their request should clearly describe and justify why a larger allocation is required.

I think this not only parses better, but is more accurate.

The first change resolves a grammar error.
The second change avoids ambiguity between whether all requests are subject to all minimums in this case vs. the intended meaning that the minimum applicable elsewhere in policy.
The third change is because their documentation should be documentation of an experiment, not experimental documentation and what we really care about is the information provided in their ARIN request anyway.

I think since this is a minor change which does not alter the meaning of the policy and does improve readability and clarity, that we should probably go ahead and incorporate it as you proposed prior to last call.

Owen



------------------------------

Message: 2
Date: Wed, 21 May 2014 10:52:48 -0800
From: Leif Sawyer <lsawyer at gci.com<mailto:lsawyer at gci.com>>
To: Owen DeLong <owen at delong.com<mailto:owen at delong.com>>, David Farmer <farmer at umn.edu<mailto:farmer at umn.edu>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
        Anti-hijack     Policy
Message-ID:
        <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B at fnb1mbx01.gci.com<mailto:18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B at fnb1mbx01.gci.com>>
Content-Type: text/plain; charset=WINDOWS-1252

s/should/must


-----Original Message-----
From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>] On Behalf Of Owen DeLong
Sent: Wednesday, May 21, 2014 10:34 AM
To: David Farmer
Cc: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy

>
> In looking at the sentence in question; I think the "have" in the
> sentence is extraneous, and can deleted.  Then changing "this" to "a
> larger allocation" and the tense changes you suggest, results in;
>
>   If an organization requires more resource than stipulated by the
>   minimum allocation sizes in force at the time of their request,
>   their experimental documentation should clearly describe and
>   justify why a larger allocation is required.
>

s/resource/resources/
s/minimum allocation sizes/applicable minimum allocation size/ s/experimental documentation/request/

result:

If an organization requires more resources than stipulated by the applicable minimum allocation in force at the time of their request, their request should clearly describe and justify why a larger allocation is required.

I think this not only parses better, but is more accurate.

The first change resolves a grammar error.
The second change avoids ambiguity between whether all requests are subject to all minimums in this case vs. the intended meaning that the minimum applicable elsewhere in policy.
The third change is because their documentation should be documentation of an experiment, not experimental documentation and what we really care about is the information provided in their ARIN request anyway.

I think since this is a minor change which does not alter the meaning of the policy and does improve readability and clarity, that we should probably go ahead and incorporate it as you proposed prior to last call.

Owen

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.



------------------------------

Message: 3
Date: Wed, 21 May 2014 15:03:39 -0500
From: David Farmer <farmer at umn.edu<mailto:farmer at umn.edu>>
To: Leif Sawyer <lsawyer at gci.com<mailto:lsawyer at gci.com>>,    Owen DeLong <owen at delong.com<mailto:owen at delong.com>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
        Anti-hijack Policy
Message-ID: <537D069B.5030601 at umn.edu<mailto:537D069B.5030601 at umn.edu>>
Content-Type: text/plain; charset=windows-1252; format=flowed

I think "should" is sufficiently strong, and gives ARIN Staff a little
wiggle room to do what makes sense.  There really have never been that
many experimental allocations.

We had a big whoopsie with all 5 RIR's authorizing /12 anchor routes.
ARIN probably won't do that again anyway, but it's still worth a small
fix in policy, just to be clear about it.  The sentence is question is a
little rough, so while we are at it a little editorial clean up is
probably in order, but please let's not over do it.

I really would like to hear from a few more people about if this
editorial change is a good idea or not, even a few +/-1s would be helpful.

Thanks.

On 5/21/14, 13:52 , Leif Sawyer wrote:
> s/should/must
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>] On Behalf Of Owen DeLong
> Sent: Wednesday, May 21, 2014 10:34 AM
> To: David Farmer
> Cc: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy
>
>>
>> In looking at the sentence in question; I think the "have" in the
>> sentence is extraneous, and can deleted.  Then changing "this" to "a
>> larger allocation" and the tense changes you suggest, results in;
>>
>>    If an organization requires more resource than stipulated by the
>>    minimum allocation sizes in force at the time of their request,
>>    their experimental documentation should clearly describe and
>>    justify why a larger allocation is required.
>>
>
> s/resource/resources/
> s/minimum allocation sizes/applicable minimum allocation size/ s/experimental documentation/request/
>
> result:
>
> If an organization requires more resources than stipulated by the applicable minimum allocation in force at the time of their request, their request should clearly describe and justify why a larger allocation is required.
>
> I think this not only parses better, but is more accurate.
>
> The first change resolves a grammar error.
> The second change avoids ambiguity between whether all requests are subject to all minimums in this case vs. the intended meaning that the minimum applicable elsewhere in policy.
> The third change is because their documentation should be documentation of an experiment, not experimental documentation and what we really care about is the information provided in their ARIN request anyway.
>
> I think since this is a minor change which does not alter the meaning of the policy and does improve readability and clarity, that we should probably go ahead and incorporate it as you proposed prior to last call.
>
> Owen
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.
>


--
================================================
David Farmer               Email: farmer at umn.edu<mailto:farmer at umn.edu>
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815<tel:1-612-626-0815>
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952<tel:1-612-812-9952>
================================================


------------------------------

Message: 4
Date: Wed, 21 May 2014 14:18:56 -0700
From: Derek Calanchini <derekc at cnets.net<mailto:derekc at cnets.net>>
To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-13: Reduce
        All Minimum Allocation/Assignment Units to /24
Message-ID: <537D1840.7020005 at cnets.net<mailto:537D1840.7020005 at cnets.net>>
Content-Type: text/plain; charset="us-ascii"

An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140521/3f8fb7ce/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cnslogo1.bmp
Type: image/bmp
Size: 72774 bytes
Desc: not available
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20140521/3f8fb7ce/attachment.bmp>

------------------------------

_______________________________________________
ARIN-PPML mailing list
ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>
http://lists.arin.net/mailman/listinfo/arin-ppml

End of ARIN-PPML Digest, Vol 107, Issue 26
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140522/4bf93bc3/attachment.htm>

From rudi.daniel at gmail.com  Thu May 22 10:46:14 2014
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Thu, 22 May 2014 10:46:14 -0400
Subject: [arin-ppml] 2014-12
In-Reply-To: <8695009A81378E48879980039EEDAD28013850CED7@MAIL1.polartel.local>
References: <CA+uaoiWSfasDun1O4JkLfSwQP9F3b_XZgJNCpZQjrFFRmqkcHA@mail.gmail.com>
	<CA+uaoiWYP1fEvkCE=v_1=K-Y3-UpjLgYyxEZXHa4xi9GUcMTqQ@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28013850CED7@MAIL1.polartel.local>
Message-ID: <CA+uaoiVHSEp5cyPJ6sZ4RmoBB-zwT25iy2hAecqTXKsv3t7_LQ@mail.gmail.com>

I generally agree with Kevin. Buy 'should be allocated' I have no problem
with.

Rudi Daniel
On May 22, 2014 10:08 AM, "Kevin Kargel" <kkargel at polartel.com> wrote:

> IMHO ?Should? and ?May? have no place in policy.  They are both no-ops as
> they place no restrictions and carry no authority.  They would be perfectly
> at home in a best practices document, but serve no function in policy.
>
> Kevin
>
>
>
>
>
> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On
> Behalf Of *Rudolph Daniel
> *Sent:* Wednesday, May 21, 2014 4:34 PM
> *To:* arin-ppml at arin.net
> *Subject:* Re: [arin-ppml] 2014-12
>
>
>
>
> >>their experimental >>documentation (should) clearly >>describe ....
>
> Would you consider changing 'should' to 'shall' to suggest mandatory
> requirement?
>
> And
>
> >   justify why a larger allocation >(is required)
>
> 'is required'  to
> 'should be allocated'
>
> Rudi Daniel
>
> On May 21, 2014 5:20 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: Recommended Draft Policy ARIN-2014-12: Anti-hijack    Policy
>       (Owen DeLong)
>    2. Re: Recommended Draft Policy ARIN-2014-12:        Anti-hijack
> Policy
>       (Leif Sawyer)
>    3. Re: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy
>       (David Farmer)
>    4. Re: Recommended Draft Policy ARIN-2014-13: Reduce All Minimum
>       Allocation/Assignment Units to /24 (Derek Calanchini)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 21 May 2014 11:33:42 -0700
> From: Owen DeLong <owen at delong.com>
> To: David Farmer <farmer at umn.edu>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
>         Anti-hijack     Policy
> Message-ID: <E966D949-CBE7-4BB2-AE10-0D42B27752AB at delong.com>
> Content-Type: text/plain; charset=us-ascii
>
> >
> > In looking at the sentence in question; I think the "have" in the
> sentence is extraneous, and can deleted.  Then changing "this" to "a larger
> allocation" and the tense changes you suggest, results in;
> >
> >   If an organization requires more resource than stipulated by the
> >   minimum allocation sizes in force at the time of their request,
> >   their experimental documentation should clearly describe and
> >   justify why a larger allocation is required.
> >
>
> s/resource/resources/
> s/minimum allocation sizes/applicable minimum allocation size/
> s/experimental documentation/request/
>
> result:
>
> If an organization requires more resources than stipulated by the
> applicable minimum allocation in force at the time of their request, their
> request should clearly describe and justify why a larger allocation is
> required.
>
> I think this not only parses better, but is more accurate.
>
> The first change resolves a grammar error.
> The second change avoids ambiguity between whether all requests are
> subject to all minimums in this case vs. the intended meaning that the
> minimum applicable elsewhere in policy.
> The third change is because their documentation should be documentation of
> an experiment, not experimental documentation and what we really care about
> is the information provided in their ARIN request anyway.
>
> I think since this is a minor change which does not alter the meaning of
> the policy and does improve readability and clarity, that we should
> probably go ahead and incorporate it as you proposed prior to last call.
>
> Owen
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 21 May 2014 10:52:48 -0800
> From: Leif Sawyer <lsawyer at gci.com>
> To: Owen DeLong <owen at delong.com>, David Farmer <farmer at umn.edu>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
>         Anti-hijack     Policy
> Message-ID:
>         <18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B at fnb1mbx01.gci.com>
> Content-Type: text/plain; charset=WINDOWS-1252
>
> s/should/must
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Wednesday, May 21, 2014 10:34 AM
> To: David Farmer
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
> Anti-hijack Policy
>
> >
> > In looking at the sentence in question; I think the "have" in the
> > sentence is extraneous, and can deleted.  Then changing "this" to "a
> > larger allocation" and the tense changes you suggest, results in;
> >
> >   If an organization requires more resource than stipulated by the
> >   minimum allocation sizes in force at the time of their request,
> >   their experimental documentation should clearly describe and
> >   justify why a larger allocation is required.
> >
>
> s/resource/resources/
> s/minimum allocation sizes/applicable minimum allocation size/
> s/experimental documentation/request/
>
> result:
>
> If an organization requires more resources than stipulated by the
> applicable minimum allocation in force at the time of their request, their
> request should clearly describe and justify why a larger allocation is
> required.
>
> I think this not only parses better, but is more accurate.
>
> The first change resolves a grammar error.
> The second change avoids ambiguity between whether all requests are
> subject to all minimums in this case vs. the intended meaning that the
> minimum applicable elsewhere in policy.
> The third change is because their documentation should be documentation of
> an experiment, not experimental documentation and what we really care about
> is the information provided in their ARIN request anyway.
>
> I think since this is a minor change which does not alter the meaning of
> the policy and does improve readability and clarity, that we should
> probably go ahead and incorporate it as you proposed prior to last call.
>
> Owen
>
> _______________________________________________
> 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.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 21 May 2014 15:03:39 -0500
> From: David Farmer <farmer at umn.edu>
> To: Leif Sawyer <lsawyer at gci.com>,    Owen DeLong <owen at delong.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
>         Anti-hijack Policy
> Message-ID: <537D069B.5030601 at umn.edu>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> I think "should" is sufficiently strong, and gives ARIN Staff a little
> wiggle room to do what makes sense.  There really have never been that
> many experimental allocations.
>
> We had a big whoopsie with all 5 RIR's authorizing /12 anchor routes.
> ARIN probably won't do that again anyway, but it's still worth a small
> fix in policy, just to be clear about it.  The sentence is question is a
> little rough, so while we are at it a little editorial clean up is
> probably in order, but please let's not over do it.
>
> I really would like to hear from a few more people about if this
> editorial change is a good idea or not, even a few +/-1s would be helpful.
>
> Thanks.
>
> On 5/21/14, 13:52 , Leif Sawyer wrote:
> > s/should/must
> >
> >
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> > Sent: Wednesday, May 21, 2014 10:34 AM
> > To: David Farmer
> > Cc: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
> Anti-hijack Policy
> >
> >>
> >> In looking at the sentence in question; I think the "have" in the
> >> sentence is extraneous, and can deleted.  Then changing "this" to "a
> >> larger allocation" and the tense changes you suggest, results in;
> >>
> >>    If an organization requires more resource than stipulated by the
> >>    minimum allocation sizes in force at the time of their request,
> >>    their experimental documentation should clearly describe and
> >>    justify why a larger allocation is required.
> >>
> >
> > s/resource/resources/
> > s/minimum allocation sizes/applicable minimum allocation size/
> s/experimental documentation/request/
> >
> > result:
> >
> > If an organization requires more resources than stipulated by the
> applicable minimum allocation in force at the time of their request, their
> request should clearly describe and justify why a larger allocation is
> required.
> >
> > I think this not only parses better, but is more accurate.
> >
> > The first change resolves a grammar error.
> > The second change avoids ambiguity between whether all requests are
> subject to all minimums in this case vs. the intended meaning that the
> minimum applicable elsewhere in policy.
> > The third change is because their documentation should be documentation
> of an experiment, not experimental documentation and what we really care
> about is the information provided in their ARIN request anyway.
> >
> > I think since this is a minor change which does not alter the meaning of
> the policy and does improve readability and clarity, that we should
> probably go ahead and incorporate it as you proposed prior to last call.
> >
> > Owen
> >
> > _______________________________________________
> > 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.
> >
>
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 21 May 2014 14:18:56 -0700
> From: Derek Calanchini <derekc at cnets.net>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-13: Reduce
>         All Minimum Allocation/Assignment Units to /24
> Message-ID: <537D1840.7020005 at cnets.net>
> Content-Type: text/plain; charset="us-ascii"
>
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20140521/3f8fb7ce/attachment.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: cnslogo1.bmp
> Type: image/bmp
> Size: 72774 bytes
> Desc: not available
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20140521/3f8fb7ce/attachment.bmp
> >
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 107, Issue 26
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140522/3f1d8164/attachment.htm>

From narten at us.ibm.com  Fri May 23 00:53:03 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 23 May 2014 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201405230453.s4N4r3Ht017870@rotala.raleigh.ibm.com>

Total of 27 messages in the last 7 days.
 
script run at: Fri May 23 00:53:03 EDT 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 33.33% |    9 | 17.19% |    75472 | info at arin.net
  3.70% |    1 | 26.98% |   118457 | derekc at cnets.net
  7.41% |    2 | 15.56% |    68329 | rudi.daniel at gmail.com
  3.70% |    1 | 10.57% |    46409 | kkargel at polartel.com
  7.41% |    2 |  4.39% |    19266 | farmer at umn.edu
  7.41% |    2 |  3.70% |    16260 | lsawyer at gci.com
  7.41% |    2 |  3.02% |    13243 | jcurran at arin.net
  3.70% |    1 |  4.75% |    20853 | scottleibrand at gmail.com
  3.70% |    1 |  3.61% |    15859 | hannigan at gmail.com
  3.70% |    1 |  2.20% |     9672 | contact at winterei.se
  3.70% |    1 |  2.02% |     8889 | jeffrey.lyon at blacklotus.net
  3.70% |    1 |  1.69% |     7433 | meows at techie.com
  3.70% |    1 |  1.51% |     6623 | owen at delong.com
  3.70% |    1 |  1.48% |     6518 | narten at us.ibm.com
  3.70% |    1 |  1.32% |     5778 | john at egh.com
--------+------+--------+----------+------------------------
100.00% |   27 |100.00% |   439061 | Total



From andrew.dul at quark.net  Tue May 27 11:31:16 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Tue, 27 May 2014 08:31:16 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-16: Section 4.10 Austerity
 Policy Update
In-Reply-To: <5376731F.2050004@arin.net>
References: <5376731F.2050004@arin.net>
Message-ID: <5384AFC4.5080404@quark.net>

As the primary author of this draft policy, I support the policy. 

This draft policy replaces the current section 4.10 "transition
technology" allocations with a more generic "austerity policy" which
more closely aligns with other RIR's austerity policies. 

This policy does the following:

1. Changes the requirements to be non-technology IPv6 specific, which
allows for a broader group of organizations to qualify for IPv4 address
space under this section.
2. Increases the block size to a maximum /22
3. Uses sparse allocation and permits an organization to possibly grow
their allocation up to a /22, if they don't qualify for the full block
on their initial allocation.
4. Places additional IANA reclaimed blocks into this pool for allocation.
5. Limits the number of blocks per organization to one; this directly
mirrors other successful RIR austerity policies.

I believe this policy along with recommended draft policy "ARIN-2014-13:
Reduce All Minimum Allocation/Assignment Units to /24" solve many of the
immediate IPv4 policy issues that ARIN will face after the free pool is
depleted.  Therefore, I recommend this policy be moved forward as
quickly as possible.

I and the AC welcome your comments on this draft.

Andrew




On 5/16/2014 1:20 PM, ARIN wrote:
>
> ## * ##
>
>
> Draft Policy ARIN-2014-16
> Section 4.10 Austerity Policy Update
>
> Date: 16 May 2014
>
> Problem Statement:
>
> NRPM section 4.10 defines an IPv4 to IPv6 transition pool which was
> intended to be used by new entrants after the IPv4 free pool has been
> exhausted. This policy was written prior to exhaustion in the APNIC
> and RIPE region and has largely not been used to date. It is believed
> that the current policy may be too restrictive to be useful to many
> organizations within the ARIN region. Furthermore the during the ARIN
> 33 public policy meeting experience report (1), ARIN staff noted
> issues with the current IPv4 policy after the IPv4 free pool is
> exhausted.
>
> RIPE & APNIC adopted an ?austerity? policy which allows organizations
> to obtain a small single block directly from the registry. These
> policies appear to have been quite effective at getting IPv4 resources
> to organizations without address space after IPv4 exhaustion. Learning
> from other regions, we have crafted a policy to update section 4.10 to
> adopt some of the policy text from the RIPE & APNIC region while
> looking at the unique aspects of the ARIN region?s number resource needs.
>
> Policy statement:
>
> Replace Section 4.10 with the following policy.
>
> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
>
> When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
> /10 IPv4 block will be set aside and dedicated to facilitate IPv6
> deployment and continued transition from IPv4 to IPv6.
>
> Address space received from IANA under the ?Global Policy for Post
> Exhaustion IPv4 Allocation Mechanisms by the IANA (NRPM 10.5)? by ARIN
> shall be allocated or assigned under this section.
>
> Allocations and assignments from this block must be justified by
> immediate IPv6 deployment requirements. Organizations must obtain an
> IPv6 block to receive a block under section 4.10 and show
> documentation on how the IPv6 and IPv4 block will be used to
> facilitate an organization?s operational needs.
>
> This block will be subject to a minimum size allocation of /28 and a
> maximum size allocation of /22. ARIN shall use sparse allocation
> within these blocks.
>
> In order to receive an allocation or assignment under this policy:
>
> 1. the organization, nor it parent(s) or subsidiary organizations, may
> not have received IPv4 resources greater than or equal to a /22 from
> ARIN or any other RIR;
>
> 2. the organization must show immediate use (within 30 days) of 25% of
> the allocation;
>
> 3. the organization is eligible to receive only one contiguous IPv4
> block under this section;
>
> 4. the organization may apply to ARIN for an increase in their
> allocation up to a /22, if the previous allocation under this section
> shows a utilization of at least 80%, increases will only be granted if
> adjacent bit-boundary aligned space is available at the time of request.
>
> Comments:
>
> a. Timetable for implementation: immediately
>
> b. Anything else: (1)
> https://www.arin.net/participate/meetings/reports/ARIN_33/PDF/monday/nobile_policy.pdf
>
>



From farmer at umn.edu  Tue May 27 14:48:53 2014
From: farmer at umn.edu (David Farmer)
Date: Tue, 27 May 2014 13:48:53 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-16: Section 4.10 Austerity
 Policy Update
In-Reply-To: <5384AFC4.5080404@quark.net>
References: <5376731F.2050004@arin.net> <5384AFC4.5080404@quark.net>
Message-ID: <5384DE15.6080709@umn.edu>

+1 to everything below.

However in addition to the currently reserved /10, I would like to 
suggest we also designate any allocations from the IANA recovered IPv4 
pool defined in section 10.5, including the /11 just received as 
reserved for use by this Austerity Policy as well.

If the community wants to do this it would be good to get a clear 
consensus from the community ASAP.  So, if necessary the Board could 
take actions necessary to ensure events don't overtake such a change.

Thanks.

On 5/27/14, 10:31 , Andrew Dul wrote:
> As the primary author of this draft policy, I support the policy.
>
> This draft policy replaces the current section 4.10 "transition
> technology" allocations with a more generic "austerity policy" which
> more closely aligns with other RIR's austerity policies.
>
> This policy does the following:
>
> 1. Changes the requirements to be non-technology IPv6 specific, which
> allows for a broader group of organizations to qualify for IPv4 address
> space under this section.
> 2. Increases the block size to a maximum /22
> 3. Uses sparse allocation and permits an organization to possibly grow
> their allocation up to a /22, if they don't qualify for the full block
> on their initial allocation.
> 4. Places additional IANA reclaimed blocks into this pool for allocation.
> 5. Limits the number of blocks per organization to one; this directly
> mirrors other successful RIR austerity policies.
>
> I believe this policy along with recommended draft policy "ARIN-2014-13:
> Reduce All Minimum Allocation/Assignment Units to /24" solve many of the
> immediate IPv4 policy issues that ARIN will face after the free pool is
> depleted.  Therefore, I recommend this policy be moved forward as
> quickly as possible.
>
> I and the AC welcome your comments on this draft.

-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================


From mike at iptrading.com  Tue May 27 15:48:23 2014
From: mike at iptrading.com (Mike Burns)
Date: Tue, 27 May 2014 15:48:23 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-16: Section 4.10 Austerity
	Policy Update
In-Reply-To: <5384DE15.6080709@umn.edu>
References: <5376731F.2050004@arin.net> <5384AFC4.5080404@quark.net>
	<5384DE15.6080709@umn.edu>
Message-ID: <9F1805D2A6D84B019C38F7E2A6989EDB@MPC>

If this proposal is implemented, blocks recovered from IANA would be 
distributed in sizes no larger than /22.
Does anybody know if the /11 just received has to stay at that size in 
inventory, or can it also be broken down?
I would be more likely to support this proposal if the recent IANA /11 can 
not be split if it stays in the general pool, but would be split if it goes 
into the 4.10 pool.




-----Original Message----- 
From: David Farmer
Sent: Tuesday, May 27, 2014 2:48 PM
To: andrew.dul at quark.net ; arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-16: Section 4.10 Austerity 
Policy Update

+1 to everything below.

However in addition to the currently reserved /10, I would like to
suggest we also designate any allocations from the IANA recovered IPv4
pool defined in section 10.5, including the /11 just received as
reserved for use by this Austerity Policy as well.

If the community wants to do this it would be good to get a clear
consensus from the community ASAP.  So, if necessary the Board could
take actions necessary to ensure events don't overtake such a change.

Thanks.

On 5/27/14, 10:31 , Andrew Dul wrote:
> As the primary author of this draft policy, I support the policy.
>
> This draft policy replaces the current section 4.10 "transition
> technology" allocations with a more generic "austerity policy" which
> more closely aligns with other RIR's austerity policies.
>
> This policy does the following:
>
> 1. Changes the requirements to be non-technology IPv6 specific, which
> allows for a broader group of organizations to qualify for IPv4 address
> space under this section.
> 2. Increases the block size to a maximum /22
> 3. Uses sparse allocation and permits an organization to possibly grow
> their allocation up to a /22, if they don't qualify for the full block
> on their initial allocation.
> 4. Places additional IANA reclaimed blocks into this pool for allocation.
> 5. Limits the number of blocks per organization to one; this directly
> mirrors other successful RIR austerity policies.
>
> I believe this policy along with recommended draft policy "ARIN-2014-13:
> Reduce All Minimum Allocation/Assignment Units to /24" solve many of the
> immediate IPv4 policy issues that ARIN will face after the free pool is
> depleted.  Therefore, I recommend this policy be moved forward as
> quickly as possible.
>
> I and the AC welcome your comments on this draft.

-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================
_______________________________________________
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. 



From farmer at umn.edu  Tue May 27 16:30:44 2014
From: farmer at umn.edu (David Farmer)
Date: Tue, 27 May 2014 15:30:44 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-16: Section 4.10 Austerity
 Policy Update
In-Reply-To: <9F1805D2A6D84B019C38F7E2A6989EDB@MPC>
References: <5376731F.2050004@arin.net> <5384AFC4.5080404@quark.net>
	<5384DE15.6080709@umn.edu> <9F1805D2A6D84B019C38F7E2A6989EDB@MPC>
Message-ID: <5384F5F4.6060202@umn.edu>

It happens ARIN's allocation was a contiguous /11, some of other RIR's 
got contiguous /11s as well and others got a mishmash of space 
equivalent to a /11.  We can do with as we see fit with it, per policy.

If it says in the free pool, I expect it will be used whole or split 
into fragments as needed need to fulfill requests.  According to the 
inventory details, see link below, there are currently two /10s and two 
/11s. I presume the /11 just received from IANA is one of the two /11s.

So, it might go as a /11 or it may be split up, its just a question of 
what requests come when.

On 5/27/14, 14:48 , Mike Burns wrote:
> If this proposal is implemented, blocks recovered from IANA would be
> distributed in sizes no larger than /22.
> Does anybody know if the /11 just received has to stay at that size in
> inventory, or can it also be broken down?
> I would be more likely to support this proposal if the recent IANA /11
> can not be split if it stays in the general pool, but would be split if
> it goes into the 4.10 pool.
>
> -----Original Message----- From: David Farmer
> Sent: Tuesday, May 27, 2014 2:48 PM
> To: andrew.dul at quark.net ; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-16: Section 4.10
> Austerity Policy Update
>
> +1 to everything below.
>
> However in addition to the currently reserved /10, I would like to
> suggest we also designate any allocations from the IANA recovered IPv4
> pool defined in section 10.5, including the /11 just received as
> reserved for use by this Austerity Policy as well.
>
> If the community wants to do this it would be good to get a clear
> consensus from the community ASAP.  So, if necessary the Board could
> take actions necessary to ensure events don't overtake such a change.
>
> Thanks.
>
> On 5/27/14, 10:31 , Andrew Dul wrote:
>> As the primary author of this draft policy, I support the policy.
>>
>> This draft policy replaces the current section 4.10 "transition
>> technology" allocations with a more generic "austerity policy" which
>> more closely aligns with other RIR's austerity policies.
>>
>> This policy does the following:
>>
>> 1. Changes the requirements to be non-technology IPv6 specific, which
>> allows for a broader group of organizations to qualify for IPv4 address
>> space under this section.
>> 2. Increases the block size to a maximum /22
>> 3. Uses sparse allocation and permits an organization to possibly grow
>> their allocation up to a /22, if they don't qualify for the full block
>> on their initial allocation.
>> 4. Places additional IANA reclaimed blocks into this pool for allocation.
>> 5. Limits the number of blocks per organization to one; this directly
>> mirrors other successful RIR austerity policies.
>>
>> I believe this policy along with recommended draft policy "ARIN-2014-13:
>> Reduce All Minimum Allocation/Assignment Units to /24" solve many of the
>> immediate IPv4 policy issues that ARIN will face after the free pool is
>> depleted.  Therefore, I recommend this policy be moved forward as
>> quickly as possible.
>>
>> I and the AC welcome your comments on this draft.
>


-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================


From Marla.Azinger at FTR.com  Tue May 27 19:27:52 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Tue, 27 May 2014 23:27:52 +0000
Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-7:
 NRPM 4 (IPv4) Policy Cleanup
In-Reply-To: <53767353.4020506@arin.net>
References: <53767353.4020506@arin.net>
Message-ID: <e6a1fa43064c4aeb90f7d643c262ac81@DM2PR06MB845.namprd06.prod.outlook.com>

What happened to the And vs OR wording?  Seriously this is a problem.  I understand some people didn't follow the linguistics of this, but as someone who has dealt with this type of thing already, if you don't change the wording you will mess up companies. 

John Sweeting I know you understood this point.  Could you please way in here with AC and BOT before this is passed?  I don't see the added sentence changing this issue as long as the other sentence is included as is.

-Replace and retitle section 4.2.4.3 Subscriber Members Less Than One Year   
If you fix the wording this change is okay.  This needs to say AND not OR.  
A business can purchase a business set in the same year they need to do a market transfer of addresses.  this should not be limited 
to either or as that is ignorant of how organizations can function.  Replace with: (4.2.4.3 Request size)

needed change in wording:  "ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 "AND" 8.4 transfer."

Thank you
Marla

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
Sent: Friday, May 16, 2014 1:22 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup

The ARIN Advisory Council (AC) met on 15 May 2014 and decided to send the following to last call:

   Recommended Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup

2013-7 was revised. The following sentence was added to 4.2.4.3:
"Determination of the appropriate allocation to be issued is based on efficient utilization of space within this time frame, consistent with the principles in 4.2.1."

Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 2 June 2014. After last call the AC will conduct their last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Recommended Draft Policy ARIN-2013-7
NRPM 4 (IPv4) Policy Cleanup

Date: 16 May 2014

AC's assessment of conformance with the Principles of Internet Number Resource Policy:

"ARIN-2013-7: "NRPM 4 (IPv4) Policy Cleanup" enables fair and impartial number resource administration by removing no-longer-relevant sections of the NRPM, and clarifying other sections. All of the remaining changes in this draft policy have proven uncontroversial thus far."

Problem Statement: Parts of NRPM 4 are irrelevant, especially after IPv4 run-out, and should be cleaned up for clarity.

Policy statement:

Short list of changes with details explained below.

Remove section 4.1.1 Routability

Update section 4.1.5 Determination of resource requests

Remove section 4.1.7 RFC2050

Remove section 4.1.9 Returned IPv4 Addresses

Replace and retitle section 4.2.4.3 Subscriber Members Less Than One Year

Remove section 4.2.4.4. Subscriber Members After One Year

Details:

Remove section 4.1.1 Routability

It is no longer necessary for the NRPM to suggest where an organization obtains resources from.

Retitle and rewrite section (4.1.5 Determination of IP address allocation size)

Remove: "Determination of IP address allocation size is the responsibility of ARIN."

Replace with: (4.1.5 Resource request size) "Determining the validity of the amount of requested IP address resources is the responsibility of ARIN."

Rationale: Clarify that it is the validity of the request that is more the focus than the amount of resources requested. This does not prevent ARIN from suggesting that a smaller block would be justified where a larger one would not, but also does not suggest that it is ARIN's sole discretion to judge the size of the blocks needed.

Remove section 4.1.7 RFC2050

Now that RFC2050 has been replaced with RFC 7020 and ARIN-2013-4 RIR Principles has been adopted, this section is no longer needed.

Remove section 4.2.4.3 Subscriber Members Less Than One Year and 4.2.4.4. Subscriber Members After One Year

Replace with: (4.2.4.3 Request size) "ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 or 8.4 transfer. Determination of the appropriate allocation to be issued is based on efficient utilization of space within this time frame, consistent with the principles in 4.2.1."

Rationale: Since ARIN received its last /8, by IANA implementing section 10.4.2.2, this is now a distinction without a difference.

Timetable for implementation: Immediate
_______________________________________________
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.


From owen at delong.com  Wed May 28 03:42:27 2014
From: owen at delong.com (Owen DeLong)
Date: Wed, 28 May 2014 00:42:27 -0700
Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-7:
	NRPM 4 (IPv4) Policy Cleanup
In-Reply-To: <e6a1fa43064c4aeb90f7d643c262ac81@DM2PR06MB845.namprd06.prod.outlook.com>
References: <53767353.4020506@arin.net>
	<e6a1fa43064c4aeb90f7d643c262ac81@DM2PR06MB845.namprd06.prod.outlook.com>
Message-ID: <C639F40A-558B-4997-A26F-9E702DAB5C3B@delong.com>

Marla,

The policy as written with the word OR is an inclusive OR, not an exclusive OR. Further, 8.3 and 8.4 are not related to acquisitions. 8.3 is a specified transfer within the ARIN region. 8.4 is a specified transfer to or from an entity served by another RIR.

Acquisitions and Mergers are handled under 8.2 and are not subject to the restrictions in 4.2.4.3.

Given that, does your objection still stand? If so, please clarify.

Owen

On May 27, 2014, at 4:27 PM, Azinger, Marla <Marla.Azinger at FTR.com> wrote:

> What happened to the And vs OR wording?  Seriously this is a problem.  I understand some people didn't follow the linguistics of this, but as someone who has dealt with this type of thing already, if you don't change the wording you will mess up companies. 
> 
> John Sweeting I know you understood this point.  Could you please way in here with AC and BOT before this is passed?  I don't see the added sentence changing this issue as long as the other sentence is included as is.
> 
> -Replace and retitle section 4.2.4.3 Subscriber Members Less Than One Year   
> If you fix the wording this change is okay.  This needs to say AND not OR.  
> A business can purchase a business set in the same year they need to do a market transfer of addresses.  this should not be limited 
> to either or as that is ignorant of how organizations can function.  Replace with: (4.2.4.3 Request size)
> 
> needed change in wording:  "ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 "AND" 8.4 transfer."
> 
> Thank you
> Marla
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
> Sent: Friday, May 16, 2014 1:22 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup
> 
> The ARIN Advisory Council (AC) met on 15 May 2014 and decided to send the following to last call:
> 
>   Recommended Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup
> 
> 2013-7 was revised. The following sentence was added to 4.2.4.3:
> "Determination of the appropriate allocation to be issued is based on efficient utilization of space within this time frame, consistent with the principles in 4.2.1."
> 
> Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 2 June 2014. After last call the AC will conduct their last call review.
> 
> The draft policy text is below and available at:
> https://www.arin.net/policy/proposals/
> 
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Recommended Draft Policy ARIN-2013-7
> NRPM 4 (IPv4) Policy Cleanup
> 
> Date: 16 May 2014
> 
> AC's assessment of conformance with the Principles of Internet Number Resource Policy:
> 
> "ARIN-2013-7: "NRPM 4 (IPv4) Policy Cleanup" enables fair and impartial number resource administration by removing no-longer-relevant sections of the NRPM, and clarifying other sections. All of the remaining changes in this draft policy have proven uncontroversial thus far."
> 
> Problem Statement: Parts of NRPM 4 are irrelevant, especially after IPv4 run-out, and should be cleaned up for clarity.
> 
> Policy statement:
> 
> Short list of changes with details explained below.
> 
> Remove section 4.1.1 Routability
> 
> Update section 4.1.5 Determination of resource requests
> 
> Remove section 4.1.7 RFC2050
> 
> Remove section 4.1.9 Returned IPv4 Addresses
> 
> Replace and retitle section 4.2.4.3 Subscriber Members Less Than One Year
> 
> Remove section 4.2.4.4. Subscriber Members After One Year
> 
> Details:
> 
> Remove section 4.1.1 Routability
> 
> It is no longer necessary for the NRPM to suggest where an organization obtains resources from.
> 
> Retitle and rewrite section (4.1.5 Determination of IP address allocation size)
> 
> Remove: "Determination of IP address allocation size is the responsibility of ARIN."
> 
> Replace with: (4.1.5 Resource request size) "Determining the validity of the amount of requested IP address resources is the responsibility of ARIN."
> 
> Rationale: Clarify that it is the validity of the request that is more the focus than the amount of resources requested. This does not prevent ARIN from suggesting that a smaller block would be justified where a larger one would not, but also does not suggest that it is ARIN's sole discretion to judge the size of the blocks needed.
> 
> Remove section 4.1.7 RFC2050
> 
> Now that RFC2050 has been replaced with RFC 7020 and ARIN-2013-4 RIR Principles has been adopted, this section is no longer needed.
> 
> Remove section 4.2.4.3 Subscriber Members Less Than One Year and 4.2.4.4. Subscriber Members After One Year
> 
> Replace with: (4.2.4.3 Request size) "ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 or 8.4 transfer. Determination of the appropriate allocation to be issued is based on efficient utilization of space within this time frame, consistent with the principles in 4.2.1."
> 
> Rationale: Since ARIN received its last /8, by IANA implementing section 10.4.2.2, this is now a distinction without a difference.
> 
> Timetable for implementation: Immediate
> _______________________________________________
> 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.



From scottleibrand at gmail.com  Wed May 28 12:22:57 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 28 May 2014 09:22:57 -0700
Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-7:
	NRPM 4 (IPv4) Policy Cleanup
In-Reply-To: <e6a1fa43064c4aeb90f7d643c262ac81@DM2PR06MB845.namprd06.prod.outlook.com>
References: <53767353.4020506@arin.net>
	<e6a1fa43064c4aeb90f7d643c262ac81@DM2PR06MB845.namprd06.prod.outlook.com>
Message-ID: <97952893-85C0-4465-BF28-D49E04515598@gmail.com>


> On May 27, 2014, at 4:27 PM, "Azinger, Marla" <Marla.Azinger at FTR.com> wrote:
> 
> What happened to the And vs OR wording?  Seriously this is a problem.  I understand some people didn't follow the linguistics of this, but as someone who has dealt with this type of thing already, if you don't change the wording you will mess up companies. 

Can you describe in more detail the situation or scenario you are concerned about? 

> 
> John Sweeting I know you understood this point.  Could you please way in here with AC and BOT before this is passed?  I don't see the added sentence changing this issue as long as the other sentence is included as is.
> 
> -Replace and retitle section 4.2.4.3 Subscriber Members Less Than One Year   
> If you fix the wording this change is okay.  This needs to say AND not OR.  
> A business can purchase a business set in the same year they need to do a market transfer of addresses.  this should not be limited 
> to either or as that is ignorant of how organizations can function.  Replace with: (4.2.4.3 Request size)
> 
> needed change in wording:  "ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 "AND" 8.4 transfer."

I believe this means "you can get a 24-month supply via 8.3 specified (intra-ARIN) or 8.4 (inter-RIR) transfer, or some combination of the two if necessary."  This would be independent of any space acquired via 8.2 (M&A) transfer, and would not represent any chance from current policy or operational practice AFAICT. 

Are you worried about people needing to fill their 24-month need by doing a combination of 8.3 specified (intra-ARIN) and 8.4 (inter-RIR) transfers? Or are you worried about the interaction with 8.2 (M&A) transfers?

-Scott

> 
> Thank you
> Marla
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
> Sent: Friday, May 16, 2014 1:22 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup
> 
> The ARIN Advisory Council (AC) met on 15 May 2014 and decided to send the following to last call:
> 
>   Recommended Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup
> 
> 2013-7 was revised. The following sentence was added to 4.2.4.3:
> "Determination of the appropriate allocation to be issued is based on efficient utilization of space within this time frame, consistent with the principles in 4.2.1."
> 
> Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 2 June 2014. After last call the AC will conduct their last call review.
> 
> The draft policy text is below and available at:
> https://www.arin.net/policy/proposals/
> 
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Recommended Draft Policy ARIN-2013-7
> NRPM 4 (IPv4) Policy Cleanup
> 
> Date: 16 May 2014
> 
> AC's assessment of conformance with the Principles of Internet Number Resource Policy:
> 
> "ARIN-2013-7: "NRPM 4 (IPv4) Policy Cleanup" enables fair and impartial number resource administration by removing no-longer-relevant sections of the NRPM, and clarifying other sections. All of the remaining changes in this draft policy have proven uncontroversial thus far."
> 
> Problem Statement: Parts of NRPM 4 are irrelevant, especially after IPv4 run-out, and should be cleaned up for clarity.
> 
> Policy statement:
> 
> Short list of changes with details explained below.
> 
> Remove section 4.1.1 Routability
> 
> Update section 4.1.5 Determination of resource requests
> 
> Remove section 4.1.7 RFC2050
> 
> Remove section 4.1.9 Returned IPv4 Addresses
> 
> Replace and retitle section 4.2.4.3 Subscriber Members Less Than One Year
> 
> Remove section 4.2.4.4. Subscriber Members After One Year
> 
> Details:
> 
> Remove section 4.1.1 Routability
> 
> It is no longer necessary for the NRPM to suggest where an organization obtains resources from.
> 
> Retitle and rewrite section (4.1.5 Determination of IP address allocation size)
> 
> Remove: "Determination of IP address allocation size is the responsibility of ARIN."
> 
> Replace with: (4.1.5 Resource request size) "Determining the validity of the amount of requested IP address resources is the responsibility of ARIN."
> 
> Rationale: Clarify that it is the validity of the request that is more the focus than the amount of resources requested. This does not prevent ARIN from suggesting that a smaller block would be justified where a larger one would not, but also does not suggest that it is ARIN's sole discretion to judge the size of the blocks needed.
> 
> Remove section 4.1.7 RFC2050
> 
> Now that RFC2050 has been replaced with RFC 7020 and ARIN-2013-4 RIR Principles has been adopted, this section is no longer needed.
> 
> Remove section 4.2.4.3 Subscriber Members Less Than One Year and 4.2.4.4. Subscriber Members After One Year
> 
> Replace with: (4.2.4.3 Request size) "ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 or 8.4 transfer. Determination of the appropriate allocation to be issued is based on efficient utilization of space within this time frame, consistent with the principles in 4.2.1."
> 
> Rationale: Since ARIN received its last /8, by IANA implementing section 10.4.2.2, this is now a distinction without a difference.
> 
> Timetable for implementation: Immediate
> _______________________________________________
> 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.


From info at arin.net  Thu May 29 14:23:00 2014
From: info at arin.net (ARIN)
Date: Thu, 29 May 2014 14:23:00 -0400
Subject: [arin-ppml] Board Adopts New Number Policies
Message-ID: <53877B04.8050406@arin.net>

On 16 May 2014 the ARIN Board of Trustees adopted the following policies:

   Recommended Draft Policy ARIN-2014-4: Remove 4.2.5 Web Hosting Policy

   Recommended Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation 
Conservation Update

   Recommended Draft Policy ARIN-2014-10: Remove Sections 4.6 and 4.7

These policies will be implemented no later than 30 June 2014.

Board of Trustees Meeting Minutes are available at:
https://www.arin.net/about_us/bot/index.html

Draft Policy and Policy Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)



From narten at us.ibm.com  Fri May 30 00:53:02 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 30 May 2014 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201405300453.s4U4r266016284@rotala.raleigh.ibm.com>

Total of 9 messages in the last 7 days.
 
script run at: Fri May 30 00:53:02 EDT 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 22.22% |    2 | 21.65% |    18020 | farmer at umn.edu
 11.11% |    1 | 14.47% |    12045 | scottleibrand at gmail.com
 11.11% |    1 | 13.88% |    11556 | owen at delong.com
 11.11% |    1 | 13.29% |    11063 | marla.azinger at ftr.com
 11.11% |    1 | 12.53% |    10427 | andrew.dul at quark.net
 11.11% |    1 |  9.61% |     8001 | mike at iptrading.com
 11.11% |    1 |  8.66% |     7211 | narten at us.ibm.com
 11.11% |    1 |  5.90% |     4912 | info at arin.net
--------+------+--------+----------+------------------------
100.00% |    9 |100.00% |    83235 | Total



From farmer at umn.edu  Sat May 31 17:55:53 2014
From: farmer at umn.edu (David Farmer)
Date: Sat, 31 May 2014 16:55:53 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack
 Policy
In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com>
References: <1140519223408.47993A-100000@Ives.egh.com>	<537B98CA.3030106@umn.edu>
	<E966D949-CBE7-4BB2-AE10-0D42B27752AB@delong.com>
	<18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com>
	<537D069B.5030601@umn.edu>
	<18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com>
Message-ID: <538A4FE9.9010900@umn.edu>

After thinking about this for a while, the justification for a larger 
allocation is clearly intended to be a requirement, and not intended to 
be optional.  So, "must" seems appropriate in the case.  However, I 
can't agree with the comments that "should" and "may" are inappropriate 
in policy all together.  A perfect example is the sentence just before 
the one we are discussing.

     The allocation size should be consistent with the existing ARIN 
minimum
     allocation sizes, unless small allocations are intended to be 
explicitly part
     of the experiment.

Therefore, putting all the suggesting together, here is text for the 
Editorial Change I'm proposing at the PPC next week.

     If an organization requires more resource resources than stipulated 
by the
     applicable minimum allocation sizes size in force at the time of 
their request,
     their experimental documentation should have request must clearly 
described
     describe and justified justify why this a larger allocation is 
required.

Thanks

On 5/21/14, 17:23 , Leif Sawyer wrote:
> I just can't think of a time when
>     "experimental documentation [should] clearly describe and justify"
> "should" ever be  "doesn't"
>
>
> hence my suggestion to use "must".
>
>
>
> -----Original Message-----
> From: David Farmer [mailto:farmer at umn.edu]
> Sent: Wednesday, May 21, 2014 12:04 PM
> To: Leif Sawyer; Owen DeLong
> Cc: David Farmer; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy
>
> I think "should" is sufficiently strong, and gives ARIN Staff a little wiggle room to do what makes sense.  There really have never been that many experimental allocations.
>
> We had a big whoopsie with all 5 RIR's authorizing /12 anchor routes.
> ARIN probably won't do that again anyway, but it's still worth a small fix in policy, just to be clear about it.  The sentence is question is a little rough, so while we are at it a little editorial clean up is probably in order, but please let's not over do it.
>
> I really would like to hear from a few more people about if this editorial change is a good idea or not, even a few +/-1s would be helpful.
>
> Thanks.
>
> On 5/21/14, 13:52 , Leif Sawyer wrote:
>> s/should/must
>>
>>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
>> On Behalf Of Owen DeLong
>> Sent: Wednesday, May 21, 2014 10:34 AM
>> To: David Farmer
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2014-12:
>> Anti-hijack Policy
>>
>>> In looking at the sentence in question; I think the "have" in the
>>> sentence is extraneous, and can deleted.  Then changing "this" to "a
>>> larger allocation" and the tense changes you suggest, results in;
>>>
>>>     If an organization requires more resource than stipulated by the
>>>     minimum allocation sizes in force at the time of their request,
>>>     their experimental documentation should clearly describe and
>>>     justify why a larger allocation is required.
>>>
>> s/resource/resources/
>> s/minimum allocation sizes/applicable minimum allocation size/
>> s/experimental documentation/request/
>>
>> result:
>>
>> If an organization requires more resources than stipulated by the applicable minimum allocation in force at the time of their request, their request should clearly describe and justify why a larger allocation is required.
>>
>> I think this not only parses better, but is more accurate.
>>
>> The first change resolves a grammar error.
>> The second change avoids ambiguity between whether all requests are subject to all minimums in this case vs. the intended meaning that the minimum applicable elsewhere in policy.
>> The third change is because their documentation should be documentation of an experiment, not experimental documentation and what we really care about is the information provided in their ARIN request anyway.
>>
>> I think since this is a minor change which does not alter the meaning of the policy and does improve readability and clarity, that we should probably go ahead and incorporate it as you proposed prior to last call.
>>
>> Owen
>>
-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140531/7cdd0d06/attachment.htm>

From jay at impulse.net  Sat May 31 22:21:19 2014
From: jay at impulse.net (Jay Hennigan)
Date: Sat, 31 May 2014 19:21:19 -0700
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-12: Anti-hijack
 Policy
In-Reply-To: <538A4FE9.9010900@umn.edu>
References: <1140519223408.47993A-100000@Ives.egh.com>	<537B98CA.3030106@umn.edu>	<E966D949-CBE7-4BB2-AE10-0D42B27752AB@delong.com>	<18B2C6E38A3A324986B392B2D18ABC5102C7F8AA3B@fnb1mbx01.gci.com>	<537D069B.5030601@umn.edu>	<18B2C6E38A3A324986B392B2D18ABC5102C7F8AB9D@fnb1mbx01.gci.com>
	<538A4FE9.9010900@umn.edu>
Message-ID: <538A8E1F.4020201@impulse.net>

On 5/31/14, 2:55 PM, David Farmer wrote:

> Therefore, putting all the suggesting together, here is text for the
> Editorial Change I'm proposing at the PPC next week.
>
>      If an organization requires more resource resources than stipulated
> by the
>      applicable minimum allocation sizes size in force at the time of
> their request,
>      their experimental documentation should have request must clearly
> described
>      describe and justified justify why this a larger allocation is
> required.

An organization is a singular entity without gender.  Pronoun should 
match. ("its", not "their").  Also, while the request for  the 
documentation isn't experimental, the allocation is.  Thus:

      If an organization requires more resources than stipulated
      by the applicable minimum allocation size in force at the
      time of its request, the request must clearly describe and
      justify why a larger allocation is required.