From farmer at umn.edu  Thu Nov  1 10:53:54 2012
From: farmer at umn.edu (David Farmer)
Date: Thu, 01 Nov 2012 09:53:54 -0500
Subject: [arin-ppml] ARIN-prop-183 Section 8.4 Transfer enhancement
In-Reply-To: <CAMDXq5NAYm_5hQS5MDYdBweF_h=R_0mgzP6WwmPneDRLqEGAYA@mail.gmail.com>
References: <508EE3D3.1000004@arin.net> <25C771DACB394DC591B9CB4A519DDDB5@MPC>
	<508FEBAE.6010803@umn.edu>
	<CAMDXq5Ob5MzDhpmDFwikw_fX_KiK11PwRA-Tsywb2xM5CSdGRA@mail.gmail.com>
	<50903486.5050809@umn.edu>
	<CAMDXq5NAYm_5hQS5MDYdBweF_h=R_0mgzP6WwmPneDRLqEGAYA@mail.gmail.com>
Message-ID: <50928D02.2060703@umn.edu>

On 10/30/12 15:32 , Martin Hannigan wrote:
> On Tue, Oct 30, 2012 at 4:11 PM, David Farmer <farmer at umn.edu> wrote:
...
>> Section 8.4 is fairly specific that there needs to be a reciprocal policy at
>> the other RIR, if you remember I argued against that, but that is ARIN's
>> policy.
>
> +1
>
>> I'm willing to accept this on to the docket in order to not create a
>> catch-22, and make it clear ARIN is willing to consider this of other RIRs
>> are too.  However, I'm not sure significant effort should be put into it
>> until at least ASN transfers have been proposed at another RIR.
>
> Why bother working on policy if you aren't going to take it seriously?
> That also implies that we don't take registry accuracy seriously FWIW.

I do take this policy seriously and even support it.  But without 
reciprocal policy at another RIR this is actually an irrelevant piece of 
policy.  So unless there is some sign of another RIR taking up the 
issue, I believe the ARIN community has more important and timely issues 
to work on.

As a sign of good faith to the other RIRs I'd be willing to take this on 
the docket, I don't want to send the message we're not interested, like 
I said I support this.   However, without some sign of another RIR 
taking up the issue, I couldn't in good faith prioritizes this over 
other policy issues.  I'm not saying it can't or won't get worked on, 
but that just about everything else should probably take priority over 
it, unless there is activity on the issue in another RIR.



From bjohnson at drtel.com  Thu Nov  1 15:26:50 2012
From: bjohnson at drtel.com (Brian Johnson)
Date: Thu, 1 Nov 2012 19:26:50 +0000
Subject: [arin-ppml] ARIN-prop-183 Section 8.4 Transfer enhancement
In-Reply-To: <50928D02.2060703@umn.edu>
References: <508EE3D3.1000004@arin.net>
	<25C771DACB394DC591B9CB4A519DDDB5@MPC>	<508FEBAE.6010803@umn.edu>
	<CAMDXq5Ob5MzDhpmDFwikw_fX_KiK11PwRA-Tsywb2xM5CSdGRA@mail.gmail.com>
	<50903486.5050809@umn.edu>
	<CAMDXq5NAYm_5hQS5MDYdBweF_h=R_0mgzP6WwmPneDRLqEGAYA@mail.gmail.com>
	<50928D02.2060703@umn.edu>
Message-ID: <F05D77A9631CAE4097F7B69095F1B06FD62A1239@EX02.drtel.lan>

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Farmer
> Sent: Thursday, November 01, 2012 9:54 AM
> To: Martin Hannigan
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN-prop-183 Section 8.4 Transfer enhancement
> 
> On 10/30/12 15:32 , Martin Hannigan wrote:
> > On Tue, Oct 30, 2012 at 4:11 PM, David Farmer <farmer at umn.edu> wrote:
> ...
> >> Section 8.4 is fairly specific that there needs to be a reciprocal policy at
> >> the other RIR, if you remember I argued against that, but that is ARIN's
> >> policy.
> >
> > +1
> >
> >> I'm willing to accept this on to the docket in order to not create a
> >> catch-22, and make it clear ARIN is willing to consider this of other RIRs
> >> are too.  However, I'm not sure significant effort should be put into it
> >> until at least ASN transfers have been proposed at another RIR.
> >
> > Why bother working on policy if you aren't going to take it seriously?
> > That also implies that we don't take registry accuracy seriously FWIW.
> 
> I do take this policy seriously and even support it.  But without
> reciprocal policy at another RIR this is actually an irrelevant piece of
> policy.  So unless there is some sign of another RIR taking up the
> issue, I believe the ARIN community has more important and timely issues
> to work on.

I think we need to curb our desire to be flippant.

I agree with Martin that this is a valid topic and agree with David that this is a lower priority until we have other RIRs in discussion on the issue.

> 
> As a sign of good faith to the other RIRs I'd be willing to take this on
> the docket, I don't want to send the message we're not interested, like
> I said I support this.   However, without some sign of another RIR
> taking up the issue, I couldn't in good faith prioritizes this over
> other policy issues.  I'm not saying it can't or won't get worked on,
> but that just about everything else should probably take priority over
> it, unless there is activity on the issue in another RIR.
> 

+1 for putting this on the docket. It will show other RIRs that it is on our radar and that we will need reciprocal policy to implement it.

- Brian


From narten at us.ibm.com  Fri Nov  2 00:53:03 2012
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 02 Nov 2012 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201211020453.qA24r3JZ018074@rotala.raleigh.ibm.com>

Total of 43 messages in the last 7 days.
 
script run at: Fri Nov  2 00:53:03 EDT 2012
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 11.63% |    5 |  8.92% |    31469 | info at arin.net
  9.30% |    4 |  8.98% |    31699 | farmer at umn.edu
  9.30% |    4 |  7.44% |    26249 | kkargel at polartel.com
  6.98% |    3 |  8.88% |    31327 | patrick at klos.com
  6.98% |    3 |  7.17% |    25290 | hannigan at gmail.com
  6.98% |    3 |  6.89% |    24301 | rgrant at skywaywest.com
  6.98% |    3 |  6.65% |    23451 | cblecker at gmail.com
  6.98% |    3 |  6.35% |    22413 | mike at nationwideinc.com
  4.65% |    2 |  6.61% |    23319 | lee at dilkie.com
  4.65% |    2 |  4.86% |    17146 | jrhett at netconsonance.com
  4.65% |    2 |  4.64% |    16381 | snoble at sonn.com
  2.33% |    1 |  4.26% |    15026 | yi.chu at sprint.com
  2.33% |    1 |  3.70% |    13047 | owen at delong.com
  2.33% |    1 |  3.41% |    12036 | jcurran at arin.net
  2.33% |    1 |  2.11% |     7436 | mysidia at gmail.com
  2.33% |    1 |  2.02% |     7118 | bjohnson at drtel.com
  2.33% |    1 |  1.89% |     6655 | mueller at syr.edu
  2.33% |    1 |  1.82% |     6436 | narten at us.ibm.com
  2.33% |    1 |  1.78% |     6276 | andrew.koch at gawul.net
  2.33% |    1 |  1.63% |     5759 | matthew at matthew.at
--------+------+--------+----------+------------------------
100.00% |   43 |100.00% |   352834 | Total



From jcurran at arin.net  Fri Nov  2 13:29:53 2012
From: jcurran at arin.net (John Curran)
Date: Fri, 2 Nov 2012 17:29:53 +0000
Subject: [arin-ppml] =?windows-1252?q?Avoid_impacting_your_weekend=85__Vot?=
 =?windows-1252?q?e_*today*_in_the_2012_ARIN_Board_and_Advisory_Council_El?=
 =?windows-1252?q?ections!?=
References: <508EE5BC.6030907@arin.net>
Message-ID: <7857874C-4AC3-4C79-AC49-6DED1BFAD112@corp.arin.net>

ARIN Community -

   The 2012 ARIN Board and Advisory Council Elections are open until 5 PM tomorrow,
   but you can avoid waiting till the last minute by registering your vote today (if you have
   not done so already... :-)

   While there may be talk in the daily news of other elections, remember that the 2012
   ARIN Board and Advisory Council elections are the most important ones when it comes
   to setting the direction and leadership for management of number resources in this region!

   Please refer to the information below or feel free to contact us (via info at arin.net<mailto:info at arin.net>) you
   have any questions.

Thanks!
/John

John Curran
President and CEO
ARIN

Begin forwarded message:

From: ARIN <info at arin.net<mailto:info at arin.net>>
Subject: [arin-announce] ARIN Board and Advisory Council Elections - Vote Now
Date: October 29, 2012 4:23:24 PM EDT
To: arin-announce at arin.net<mailto:arin-announce at arin.net>


The polls remain open for the election to fill three seats on the ARIN Board of Trustees and six seats on ARIN Advisory Council. The sixth seat on the ARIN AC is a vacated seat with a term of one year remaining. The candidate with the sixth highest count of votes for the ARIN AC will fill this sixth seat. The polls close at 5:00 PM ET, 3 November.

Brief candidate biographies and a link to submit or view statements of support can be found through ARIN Election Headquarters. A compilation of Candidate questionnaire responses in PDF is available at:

https://www.arin.net/participate/elections/candidate_bios.pdf

You must be the Designated Member Representative (DMR) from a general Member in good standing as of 25 August 2012 to vote. As stated in previous announcements, the deadline for establishing voter eligibility was 10 October 2012. To vote, visit ARIN Election Headquarters and click on the Vote button:

https://www.arin.net/app/election/

Detailed voting instructions are available at:

https://www.arin.net/participate/elections/instructions.html#vote

Designated member representatives must cast and confirm their ballots by 5:00 PM ET, 3 November.

If you have any questions about voting or encounter problems with the system, please immediately contact ARIN Communication and Member Services at info at arin.net<mailto:info at arin.net>.

Regards,

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



_______________________________________________
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List (ARIN-announce at arin.net<mailto:ARIN-announce at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-announce
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/20121102/359ad6b2/attachment.htm>

From info at arin.net  Tue Nov  6 15:11:04 2012
From: info at arin.net (ARIN)
Date: Tue, 06 Nov 2012 15:11:04 -0500
Subject: [arin-ppml] ARIN XXX Meeting Report Now Available
Message-ID: <50996ED8.2040909@arin.net>

The ARIN community took part in lively discussions at ARIN XXX in 
Dallas, Texas from 24-26 October. The report of Public Policy and 
Members Meeting, which includes presentations, summary notes, webcast 
archives and transcripts of the entire meeting, is now available on the 
ARIN website at:
http://www.arin.net/participate/meetings/reports/ARIN_XXX/

We thank everyone in the community who participated in person and 
remotely. Congratulations to Brian Johnson, winner of the ARIN XXX 
Meeting Survey Raffle! Brian?s name was randomly selected from among 
those who completed the ARIN XXX Meeting Survey or the Remote 
Participants? Survey to receive a Samsung Galaxy Note 10.1. Thank you to 
everyone who filled out the surveys. The feedback provided in the 
surveys is valuable to improving future meetings.

Please plan to join us 21?24 April 2013 for ARIN 31 in Bridgetown, 
Barbados to continue to take part in the integral Internet number 
resource Policy Development Process.

Regards,

Communications and Member Services

American Registry for Internet Numbers (ARIN)


From info at arin.net  Thu Nov  8 14:16:58 2012
From: info at arin.net (ARIN)
Date: Thu, 08 Nov 2012 14:16:58 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - October 2012
In-Reply-To: <50919212.8010006@arin.net>
References: <5091686E.8080408@arin.net> <50919212.8010006@arin.net>
Message-ID: <509C052A.40009@arin.net>

> The AC abandoned ARIN-prop-180. Anyone dissatisfied with this decision
> may initiate a petition. The petition to advance a proposal would be
> the "Discussion Petition." The deadline to begin a petition will be
> five business days after the AC's draft meeting minutes are published.

The minutes of the AC's 26 October 2012 meeting have been published
and are available at:
https://www.arin.net/about_us/ac/index.html

The deadline to begin a petition is 15 November 2012.

Regards,

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



On 10/31/12 5:03 PM, ARIN wrote:
> We've corrected a typo in the message below. Prop-180 was abandoned by
> the AC. This action may be petitioned.
>
> In accordance with the ARIN Policy Development Process the ARIN Advisory
> Council (AC) held a meeting on 26 October 2012 and made decisions about
> several draft policies and proposals.
>
> The AC moved the following draft policies to last call (they will be
> posted separately to last call):
>
>   ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers
>   ARIN-2012-7: Reassignments for Third Party Internet Access (TPIA)
> over Cable
>
> The following remains on the AC's docket:
>
>   ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement
>   ARIN-2012-6: Revising Section 4.4 C/I Reserved Pool Size
>   ARIN-2012-8: Aligning 8.2 and 8.3 Transfer Policy
>
> The following proposal was added to the AC's docket for development
> and evaluation:
>
>   ARIN-prop-182 Update Residential Customer Definition to not exclude
> wireless as Residential Service
>
> The AC abandoned the following:
>
>   ARIN-prop-180 ISP Private Reassignment
>
> The AC provided the following statement: "The ARIN Advisory Council
> decided to abandon ARIN-prop-180 based on feedback from the community
> on PPML and at the Public Policy Meeting in Dallas.  The community
> expressed a clear lack of support for the policy idea as presented,
> and while several other ideas were discussed, there was no clear
> consensus on a path forward for this policy proposal.  The AC would
> encourage the originator and any interested members of the community
> to continue discussions on the issue, and would welcome a future
> policy proposal on the topic if any areas of consensus can be found.
> Due to the difficulties of gaining consensus on a policy that is so
> broad, the AC recommends that future work in this area should be
> narrowed to solve a specific problem."
>
> The AC abandoned ARIN-prop-180. Anyone dissatisfied with this decision
> may initiate a petition. The petition to advance a proposal would be
> the "Discussion 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
>
> 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 narten at us.ibm.com  Fri Nov  9 00:53:03 2012
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 09 Nov 2012 00:53:03 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201211090553.qA95r4aq021418@rotala.raleigh.ibm.com>

Total of 4 messages in the last 7 days.
 
script run at: Fri Nov  9 00:53:03 EST 2012
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 50.00% |    2 | 37.83% |    12806 | info at arin.net
 25.00% |    1 | 41.15% |    13930 | jcurran at arin.net
 25.00% |    1 | 21.01% |     7112 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    4 |100.00% |    33848 | Total



From cja at daydream.com  Fri Nov  9 08:09:30 2012
From: cja at daydream.com (CJ Aronson)
Date: Fri, 9 Nov 2012 08:09:30 -0500
Subject: [arin-ppml] 2012-5: Removal of Renumbering Requirement for Small
	Multihomers
Message-ID: <CAMvf=7YSwfgyJqSEHR8998zygGgSYgL6XJmtzM_WwjVxF99xrg@mail.gmail.com>

Hi everyone,

This draft is in last call.  Any further input from this list on this
draft policy?  Thanks a lot!

----Cathy

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

The ARIN Advisory Council (AC) met on 26 October 2012 and decided to
send the following draft policy to last call:

   Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for
Small Multihomers

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. Last call for 2012-5 will
expire on 14 November 2012. 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)


## * ##


Draft Policy ARIN-2012-5
Removal of Renumbering Requirement for Small Multihomers

Date: 25 July 2012

Policy statement:

Remove the entire subsection 4.3.6.2 "Additional Assignments for Small
Multihomers".

Rationale:

The policy has had the unintended effect of freezing small multi homed
end users from being able to return to ARIN for additional assignments.
The requirement to renumber out of space is unique and is applying an
undue burden of renumbering what would be an organization's core
infrastructure.

Timetable for implementation: immediate


From jeffrey.lyon at blacklotus.net  Tue Nov 13 22:36:52 2012
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Tue, 13 Nov 2012 22:36:52 -0500
Subject: [arin-ppml] Utilization policy is not aggregate
Message-ID: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>

All,

I put in a IPv4 request today and received this reply:

-- snip --

Message:Hello Jeffrey,

Thank you for the reply. We don't aggregate your holdings to come up
with a utilization percent. Each individual block must be efficiently
utilized. That's how policy is written, and that's how ARIN's operated
since our inception. 2% of a /21 isn't a lot, you're right, but policy
is policy, and it says 80%, so it's best if we don't make exceptions
and hold everyone to the same rule, dont you agree?

-- snip --

We hold 2 x /21 and it seems that 78% + 92% = 85% aggregate
utilization is not sufficient under current policy.  I do not believe
it is equitable that we're ineligible to request resources because our
space is deaggregated where a network operator with contiguous /20
would be eligible.

Would anyone else be in favor of amending this?

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


From matthew at matthew.at  Tue Nov 13 23:07:27 2012
From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 13 Nov 2012 20:07:27 -0800
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
Message-ID: <557C32FB-50FC-4859-A1E7-A8560636792A@matthew.at>

Agree, this reply is insane. Draft a better policy.

Matthew Kaufman

(Sent from my iPhone)

On Nov 13, 2012, at 7:36 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:

> All,
> 
> I put in a IPv4 request today and received this reply:
> 
> -- snip --
> 
> Message:Hello Jeffrey,
> 
> Thank you for the reply. We don't aggregate your holdings to come up
> with a utilization percent. Each individual block must be efficiently
> utilized. That's how policy is written, and that's how ARIN's operated
> since our inception. 2% of a /21 isn't a lot, you're right, but policy
> is policy, and it says 80%, so it's best if we don't make exceptions
> and hold everyone to the same rule, dont you agree?
> 
> -- snip --
> 
> We hold 2 x /21 and it seems that 78% + 92% = 85% aggregate
> utilization is not sufficient under current policy.  I do not believe
> it is equitable that we're ineligible to request resources because our
> space is deaggregated where a network operator with contiguous /20
> would be eligible.
> 
> Would anyone else be in favor of amending this?
> 
> -- 
> Jeffrey A. Lyon, CISSP
> President, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: 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 Matthew.Wilder at telus.com  Wed Nov 14 00:04:57 2012
From: Matthew.Wilder at telus.com (Matthew Wilder)
Date: Tue, 13 Nov 2012 22:04:57 -0700
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
Message-ID: <DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>

I would absolutely support a change in this policy.  I agree it is currently highly unfavorable to those with multiple allocations.  I know because I have quite a few allocations, and trying to get them all up to 80% utilization is like tacking jello to the wall.  Not a fun exercise.  You have my +1.

Matthew Wilder
TELUS
________________________________________
From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon [jeffrey.lyon at blacklotus.net]
Sent: November 13, 2012 7:36 PM
To: arin-ppml at arin.net List
Subject: [arin-ppml] Utilization policy is not aggregate

All,

I put in a IPv4 request today and received this reply:

-- snip --

Message:Hello Jeffrey,

Thank you for the reply. We don't aggregate your holdings to come up
with a utilization percent. Each individual block must be efficiently
utilized. That's how policy is written, and that's how ARIN's operated
since our inception. 2% of a /21 isn't a lot, you're right, but policy
is policy, and it says 80%, so it's best if we don't make exceptions
and hold everyone to the same rule, dont you agree?

-- snip --

We hold 2 x /21 and it seems that 78% + 92% = 85% aggregate
utilization is not sufficient under current policy.  I do not believe
it is equitable that we're ineligible to request resources because our
space is deaggregated where a network operator with contiguous /20
would be eligible.

Would anyone else be in favor of amending this?

--
Jeffrey A. Lyon, CISSP
President, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: 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 jeffrey.lyon at blacklotus.net  Fri Nov 16 00:44:49 2012
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Fri, 16 Nov 2012 00:44:49 -0500
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
Message-ID: <CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>

On Wed, Nov 14, 2012 at 12:04 AM, Matthew Wilder
<Matthew.Wilder at telus.com> wrote:
> I would absolutely support a change in this policy.  I agree it is currently highly unfavorable to those with multiple allocations.  I know because I have quite a few allocations, and trying to get them all up to 80% utilization is like tacking jello to the wall.  Not a fun exercise.  You have my +1.
>
> Matthew Wilder
> TELUS
> ________________________________________
> From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon [jeffrey.lyon at blacklotus.net]
> Sent: November 13, 2012 7:36 PM
> To: arin-ppml at arin.net List
> Subject: [arin-ppml] Utilization policy is not aggregate
>
> All,
>
> I put in a IPv4 request today and received this reply:
>
> -- snip --
>
> Message:Hello Jeffrey,
>
> Thank you for the reply. We don't aggregate your holdings to come up
> with a utilization percent. Each individual block must be efficiently
> utilized. That's how policy is written, and that's how ARIN's operated
> since our inception. 2% of a /21 isn't a lot, you're right, but policy
> is policy, and it says 80%, so it's best if we don't make exceptions
> and hold everyone to the same rule, dont you agree?
>
> -- snip --
>
> We hold 2 x /21 and it seems that 78% + 92% = 85% aggregate
> utilization is not sufficient under current policy.  I do not believe
> it is equitable that we're ineligible to request resources because our
> space is deaggregated where a network operator with contiguous /20
> would be eligible.
>
> Would anyone else be in favor of amending this?
>
> --
> Jeffrey A. Lyon, CISSP
> President, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: 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.


Are there any other opinions on this matter? I would like to hear any
opposition that may exist before moving forward with drafting a policy
proposal.

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


From narten at us.ibm.com  Fri Nov 16 00:53:03 2012
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 16 Nov 2012 00:53:03 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201211160553.qAG5r31Z006229@rotala.raleigh.ibm.com>

Total of 5 messages in the last 7 days.
 
script run at: Fri Nov 16 00:53:03 EST 2012
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 20.00% |    1 | 23.22% |     7399 | matthew.wilder at telus.com
 20.00% |    1 | 20.08% |     6399 | cja at daydream.com
 20.00% |    1 | 19.08% |     6081 | narten at us.ibm.com
 20.00% |    1 | 18.88% |     6015 | matthew at matthew.at
 20.00% |    1 | 18.74% |     5972 | jeffrey.lyon at blacklotus.net
--------+------+--------+----------+------------------------
100.00% |    5 |100.00% |    31866 | Total



From scottleibrand at gmail.com  Fri Nov 16 00:53:44 2012
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 15 Nov 2012 22:53:44 -0700
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
Message-ID: <3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>

On Nov 15, 2012, at 10:44 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:

> On Wed, Nov 14, 2012 at 12:04 AM, Matthew Wilder
> <Matthew.Wilder at telus.com> wrote:
>> I would absolutely support a change in this policy.  I agree it is currently highly unfavorable to those with multiple allocations.  I know because I have quite a few allocations, and trying to get them all up to 80% utilization is like tacking jello to the wall.  Not a fun exercise.  You have my +1.
>> 
>> Matthew Wilder
>> TELUS
>> ________________________________________
>> From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon [jeffrey.lyon at blacklotus.net]
>> Sent: November 13, 2012 7:36 PM
>> To: arin-ppml at arin.net List
>> Subject: [arin-ppml] Utilization policy is not aggregate
>> 
>> All,
>> 
>> I put in a IPv4 request today and received this reply:
>> 
>> -- snip --
>> 
>> Message:Hello Jeffrey,
>> 
>> Thank you for the reply. We don't aggregate your holdings to come up
>> with a utilization percent. Each individual block must be efficiently
>> utilized. That's how policy is written, and that's how ARIN's operated
>> since our inception. 2% of a /21 isn't a lot, you're right, but policy
>> is policy, and it says 80%, so it's best if we don't make exceptions
>> and hold everyone to the same rule, dont you agree?
>> 
>> -- snip --
>> 
>> We hold 2 x /21 and it seems that 78% + 92% = 85% aggregate
>> utilization is not sufficient under current policy.  I do not believe
>> it is equitable that we're ineligible to request resources because our
>> space is deaggregated where a network operator with contiguous /20
>> would be eligible.
>> 
>> Would anyone else be in favor of amending this?
>> 
>> 
> 
> 
> Are there any other opinions on this matter? I would like to hear any
> opposition that may exist before moving forward with drafting a policy
> proposal.
> 

Not necessarily opposed, but one reason for the existing language is: if you are at 90% of a /16, and your 3 month need is only for a /20, then you would still be at >80% immediately after getting your /20, without using a bit of it. If you have to use 80% (or even 50%) of all allocations, that eliminates that loophole. 

Scott

From rgrant at skywaywest.com  Fri Nov 16 01:53:12 2012
From: rgrant at skywaywest.com (Ron Grant)
Date: Thu, 15 Nov 2012 22:53:12 -0800
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
Message-ID: <50A5E2D8.80802@skywaywest.com>


We're very near exhaustion so any new policy should be framed with the 
transfer market in mind.

If somebody's willing to sell, and somebody else is willing to buy, but 
they can't justify it because of a math problem - well, I'd be in favour 
of changing it.

So the example is really this:

"if you are at 90% of a /16, and all that's available for purchase is a 
/20, is it really a problem if after purchase you'd be able to buy more?"


On 12-11-15 9:53 PM, Scott Leibrand wrote:
> On Nov 15, 2012, at 10:44 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
>
>> On Wed, Nov 14, 2012 at 12:04 AM, Matthew Wilder
>> <Matthew.Wilder at telus.com> wrote:
>>> <snip>
>>>
>>>
>>
>> Are there any other opinions on this matter? I would like to hear any
>> opposition that may exist before moving forward with drafting a policy
>> proposal.
>>
> Not necessarily opposed, but one reason for the existing language is: if you are at 90% of a /16, and your 3 month need is only for a /20, then you would still be at >80% immediately after getting your /20, without using a bit of it. If you have to use 80% (or even 50%) of all allocations, that eliminates that loophole.
>
> Scott
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (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.

Forgot to CC: List. Sorry for the duplicate, Scott.



-- 
Ron Grant                                Managed DSL/T1/Wireless/Fibre
Skyway West Business Internet          Internet and Private Networking
rgrant at skywaywest.com                  Bonding and Fail Over Solutions
ph:  604 737 2113               Virtual Data Centre and Private Clouds
fax: 604 482 1299                            http://www.skywaywest.com

Sales, Support and Billing    http://www.skywaywest.com/contact-us.htm



From Matthew.Wilder at telus.com  Fri Nov 16 04:52:19 2012
From: Matthew.Wilder at telus.com (Matthew Wilder)
Date: Fri, 16 Nov 2012 02:52:19 -0700
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <50A5E2D8.80802@skywaywest.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>,
	<50A5E2D8.80802@skywaywest.com>
Message-ID: <DE229826F48ABD4CBF754E5AA6CFC14B211EF2BD20@WP40044.corp.ads>

Respectfully, I have to agree with Ron.  The policy should be biased toward allowing entities access to the resources they need, rather than biased toward the attempt to ensure each resource is immediately utilized.  In the network world, we all know that things take time.  Migrations occur.  Subscribers come and go.  Utilization on any given resource goes up and down.  In general I would love to see the policy focus more on aggregate utilization and justification.

I agree that in Ron's example an entity that can justify 4 x /20 for their 2 year need should be allowed to acquire up to those 4 x /20 at any point in the 2 years beginning with their first transfer in which they acquire the /20, regardless of utilization of the individual /20 ranges, BUT holding the overall 80% utilization requirement as a necessary condition for subsequent allocations / transfers.  This approach could lead to a balanced policy in my mind and one which accomplishes what RIR policy should do; namely to get number resources to those who need them.

mw
________________________________________
From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Ron Grant [rgrant at skywaywest.com]
Sent: November 15, 2012 10:53 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Utilization policy is not aggregate

We're very near exhaustion so any new policy should be framed with the
transfer market in mind.

If somebody's willing to sell, and somebody else is willing to buy, but
they can't justify it because of a math problem - well, I'd be in favour
of changing it.

So the example is really this:

"if you are at 90% of a /16, and all that's available for purchase is a
/20, is it really a problem if after purchase you'd be able to buy more?"


On 12-11-15 9:53 PM, Scott Leibrand wrote:
> On Nov 15, 2012, at 10:44 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
>
>> On Wed, Nov 14, 2012 at 12:04 AM, Matthew Wilder
>> <Matthew.Wilder at telus.com> wrote:
>>> <snip>
>>>
>>>
>>
>> Are there any other opinions on this matter? I would like to hear any
>> opposition that may exist before moving forward with drafting a policy
>> proposal.
>>
> Not necessarily opposed, but one reason for the existing language is: if you are at 90% of a /16, and your 3 month need is only for a /20, then you would still be at >80% immediately after getting your /20, without using a bit of it. If you have to use 80% (or even 50%) of all allocations, that eliminates that loophole.
>
> Scott
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (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.

Forgot to CC: List. Sorry for the duplicate, Scott.



--
Ron Grant                                Managed DSL/T1/Wireless/Fibre
Skyway West Business Internet          Internet and Private Networking
rgrant at skywaywest.com                  Bonding and Fail Over Solutions
ph:  604 737 2113               Virtual Data Centre and Private Clouds
fax: 604 482 1299                            http://www.skywaywest.com

Sales, Support and Billing    http://www.skywaywest.com/contact-us.htm

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (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 bill at herrin.us  Fri Nov 16 09:01:19 2012
From: bill at herrin.us (William Herrin)
Date: Fri, 16 Nov 2012 09:01:19 -0500
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
Message-ID: <CAP-guGXUeT-rebsns0dntCYL75yMfY2sSc4revDQ1WYxaLNKBw@mail.gmail.com>

On Fri, Nov 16, 2012 at 12:53 AM, Scott Leibrand
<scottleibrand at gmail.com> wrote:
> Not necessarily opposed, but one reason for the existing
> language is: if you are at 90% of a /16, and your 3 month
> need is only for a /20, then you would still be at >80%
> immediately after getting your /20, without using a bit of it.
> If you have to use 80% (or even 50%) of all allocations,
> that eliminates that loophole.

Do you have to use 80% on all allocations? Or just the most recent one?

-Bill

-- 
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 scottleibrand at gmail.com  Fri Nov 16 09:06:59 2012
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 16 Nov 2012 07:06:59 -0700
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <DE229826F48ABD4CBF754E5AA6CFC14B211EF2BD20@WP40044.corp.ads>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
	<50A5E2D8.80802@skywaywest.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B211EF2BD20@WP40044.corp.ads>
Message-ID: <B0C849A0-D125-4277-B4B2-A0E419207523@gmail.com>

Matthew and Ron,

Excellent points, and agreed. I think you just wrote a good rationale for the policy. 

So what remains IMO is to ensure that this doesn't introduce a loophole for draining the free pool when all that's left are small blocks. Re-reading 4.1.8, I think the "one block every three months" restriction would be sufficient there. 

I look forward to seeing policy text, and will be happy to help in any way I can. 

Scott

On Nov 16, 2012, at 2:52 AM, Matthew Wilder <Matthew.Wilder at telus.com> wrote:

> Respectfully, I have to agree with Ron.  The policy should be biased toward allowing entities access to the resources they need, rather than biased toward the attempt to ensure each resource is immediately utilized.  In the network world, we all know that things take time.  Migrations occur.  Subscribers come and go.  Utilization on any given resource goes up and down.  In general I would love to see the policy focus more on aggregate utilization and justification.
> 
> I agree that in Ron's example an entity that can justify 4 x /20 for their 2 year need should be allowed to acquire up to those 4 x /20 at any point in the 2 years beginning with their first transfer in which they acquire the /20, regardless of utilization of the individual /20 ranges, BUT holding the overall 80% utilization requirement as a necessary condition for subsequent allocations / transfers.  This approach could lead to a balanced policy in my mind and one which accomplishes what RIR policy should do; namely to get number resources to those who need them.
> 
> mw
> ________________________________________
> From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Ron Grant [rgrant at skywaywest.com]
> Sent: November 15, 2012 10:53 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Utilization policy is not aggregate
> 
> We're very near exhaustion so any new policy should be framed with the
> transfer market in mind.
> 
> If somebody's willing to sell, and somebody else is willing to buy, but
> they can't justify it because of a math problem - well, I'd be in favour
> of changing it.
> 
> So the example is really this:
> 
> "if you are at 90% of a /16, and all that's available for purchase is a
> /20, is it really a problem if after purchase you'd be able to buy more?"
> 
> 
> On 12-11-15 9:53 PM, Scott Leibrand wrote:
>> On Nov 15, 2012, at 10:44 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
>> 
>>> On Wed, Nov 14, 2012 at 12:04 AM, Matthew Wilder
>>> <Matthew.Wilder at telus.com> wrote:
>>>> <snip>
>>>> 
>>>> 
>>> 
>>> Are there any other opinions on this matter? I would like to hear any
>>> opposition that may exist before moving forward with drafting a policy
>>> proposal.
>>> 
>> Not necessarily opposed, but one reason for the existing language is: if you are at 90% of a /16, and your 3 month need is only for a /20, then you would still be at >80% immediately after getting your /20, without using a bit of it. If you have to use 80% (or even 50%) of all allocations, that eliminates that loophole.
>> 
>> Scott
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (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.
> 
> Forgot to CC: List. Sorry for the duplicate, Scott.
> 
> 
> 
> --
> Ron Grant                                Managed DSL/T1/Wireless/Fibre
> Skyway West Business Internet          Internet and Private Networking
> rgrant at skywaywest.com                  Bonding and Fail Over Solutions
> ph:  604 737 2113               Virtual Data Centre and Private Clouds
> fax: 604 482 1299                            http://www.skywaywest.com
> 
> Sales, Support and Billing    http://www.skywaywest.com/contact-us.htm
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (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  Fri Nov 16 09:44:35 2012
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 16 Nov 2012 06:44:35 -0800
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <CAP-guGXUeT-rebsns0dntCYL75yMfY2sSc4revDQ1WYxaLNKBw@mail.gmail.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
	<CAP-guGXUeT-rebsns0dntCYL75yMfY2sSc4revDQ1WYxaLNKBw@mail.gmail.com>
Message-ID: <CAGkMwz5pOab+LHXxq9h4HzzFNC26e+yWUcMYJvcLUa63JVjsCw@mail.gmail.com>

On Fri, Nov 16, 2012 at 6:01 AM, William Herrin <bill at herrin.us> wrote:

> On Fri, Nov 16, 2012 at 12:53 AM, Scott Leibrand
> <scottleibrand at gmail.com> wrote:
> > Not necessarily opposed, but one reason for the existing
> > language is: if you are at 90% of a /16, and your 3 month
> > need is only for a /20, then you would still be at >80%
> > immediately after getting your /20, without using a bit of it.
> > If you have to use 80% (or even 50%) of all allocations,
> > that eliminates that loophole.
>
> Do you have to use 80% on all allocations? Or just the most recent one?
>

That's not very clear in the ISP additional allocation policy.
https://www.arin.net/policy/nrpm.html#four24 for ISPs says:

4.2.4.1. Utilization percentage (80%)

ISPs must have efficiently utilized all previous allocations and at least
80% of their most recent allocation in order to receive additional space.
This includes all space reassigned to their customers. Please note that
until your prior utilization is verified to meet the 80% requirement, ARIN
can neither process nor approve a request for additional addresses.

https://www.arin.net/policy/nrpm.html#four361 for end users is more clear:

4.3.6.1 Utilization Requirements for Additional Assignment

In order to justify an additional assignment, end-users must have
efficiently utilized at least 80% of all previous assignments, and must
provide ARIN with utilization details.

On the other hand, the Multiple Discrete Networks policy at
https://www.arin.net/policy/nrpm.html#four5 only requires 50% overall (but
80% of each site at the time it was assigned).

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

From mueller at syr.edu  Fri Nov 16 09:17:48 2012
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 16 Nov 2012 14:17:48 +0000
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <50A5E2D8.80802@skywaywest.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
	<50A5E2D8.80802@skywaywest.com>
Message-ID: <855077AC3D7A7147A7570370CA01ECD2280B80@SUEX10-mbx-10.ad.syr.edu>

I agree with this framing of the problem and as a new AC member will be willing to work on getting a new, well-thought-out policy through.

--MM

> -----Original Message-----
> 
> We're very near exhaustion so any new policy should be framed with the
> transfer market in mind.
> 
> If somebody's willing to sell, and somebody else is willing to buy, but
> they can't justify it because of a math problem - well, I'd be in favour
> of changing it.
> 
> So the example is really this:
> 
> "if you are at 90% of a /16, and all that's available for purchase is a
> /20, is it really a problem if after purchase you'd be able to buy more?"
> 
issues.


From SRyerse at eclipse-networks.com  Fri Nov 16 10:50:46 2012
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Fri, 16 Nov 2012 15:50:46 +0000
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>,
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
Message-ID: <0DFF19C7-926C-40D5-B804-A41857BAF162@eclipse-networks.com>

I agree with the change. Fairness needs to prevail. 

Sent from my iPhone

On Nov 16, 2012, at 12:45 AM, "Jeffrey Lyon" <jeffrey.lyon at blacklotus.net> wrote:

> On Wed, Nov 14, 2012 at 12:04 AM, Matthew Wilder
> <Matthew.Wilder at telus.com> wrote:
>> I would absolutely support a change in this policy.  I agree it is currently highly unfavorable to those with multiple allocations.  I know because I have quite a few allocations, and trying to get them all up to 80% utilization is like tacking jello to the wall.  Not a fun exercise.  You have my +1.
>> 
>> Matthew Wilder
>> TELUS
>> ________________________________________
>> From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon [jeffrey.lyon at blacklotus.net]
>> Sent: November 13, 2012 7:36 PM
>> To: arin-ppml at arin.net List
>> Subject: [arin-ppml] Utilization policy is not aggregate
>> 
>> All,
>> 
>> I put in a IPv4 request today and received this reply:
>> 
>> -- snip --
>> 
>> Message:Hello Jeffrey,
>> 
>> Thank you for the reply. We don't aggregate your holdings to come up
>> with a utilization percent. Each individual block must be efficiently
>> utilized. That's how policy is written, and that's how ARIN's operated
>> since our inception. 2% of a /21 isn't a lot, you're right, but policy
>> is policy, and it says 80%, so it's best if we don't make exceptions
>> and hold everyone to the same rule, dont you agree?
>> 
>> -- snip --
>> 
>> We hold 2 x /21 and it seems that 78% + 92% = 85% aggregate
>> utilization is not sufficient under current policy.  I do not believe
>> it is equitable that we're ineligible to request resources because our
>> space is deaggregated where a network operator with contiguous /20
>> would be eligible.
>> 
>> Would anyone else be in favor of amending this?
>> 
>> --
>> Jeffrey A. Lyon, CISSP
>> President, Black Lotus Communications
>> mobile: (757) 304-0668 | gtalk: 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.
> 
> 
> Are there any other opinions on this matter? I would like to hear any
> opposition that may exist before moving forward with drafting a policy
> proposal.
> 
> Thanks,
> -- 
> Jeffrey A. Lyon, CISSP
> President, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: 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 cb.list6 at gmail.com  Fri Nov 16 16:38:57 2012
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Fri, 16 Nov 2012 13:38:57 -0800
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <0DFF19C7-926C-40D5-B804-A41857BAF162@eclipse-networks.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<0DFF19C7-926C-40D5-B804-A41857BAF162@eclipse-networks.com>
Message-ID: <CAD6AjGSQWrJvw5jOcv=_rCfRyb1uJ84+QkMRvMUEpTqu1wWVdQ@mail.gmail.com>

On Nov 16, 2012 7:56 AM, "Steven Ryerse" <SRyerse at eclipse-networks.com>
wrote:
>
> I agree with the change. Fairness needs to prevail.
>

+1

CB

Sent from ipv6-only android

> Sent from my iPhone
>
> On Nov 16, 2012, at 12:45 AM, "Jeffrey Lyon" <jeffrey.lyon at blacklotus.net>
wrote:
>
> > On Wed, Nov 14, 2012 at 12:04 AM, Matthew Wilder
> > <Matthew.Wilder at telus.com> wrote:
> >> I would absolutely support a change in this policy.  I agree it is
currently highly unfavorable to those with multiple allocations.  I know
because I have quite a few allocations, and trying to get them all up to
80% utilization is like tacking jello to the wall.  Not a fun exercise.
 You have my +1.
> >>
> >> Matthew Wilder
> >> TELUS
> >> ________________________________________
> >> From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On
Behalf Of Jeffrey Lyon [jeffrey.lyon at blacklotus.net]
> >> Sent: November 13, 2012 7:36 PM
> >> To: arin-ppml at arin.net List
> >> Subject: [arin-ppml] Utilization policy is not aggregate
> >>
> >> All,
> >>
> >> I put in a IPv4 request today and received this reply:
> >>
> >> -- snip --
> >>
> >> Message:Hello Jeffrey,
> >>
> >> Thank you for the reply. We don't aggregate your holdings to come up
> >> with a utilization percent. Each individual block must be efficiently
> >> utilized. That's how policy is written, and that's how ARIN's operated
> >> since our inception. 2% of a /21 isn't a lot, you're right, but policy
> >> is policy, and it says 80%, so it's best if we don't make exceptions
> >> and hold everyone to the same rule, dont you agree?
> >>
> >> -- snip --
> >>
> >> We hold 2 x /21 and it seems that 78% + 92% = 85% aggregate
> >> utilization is not sufficient under current policy.  I do not believe
> >> it is equitable that we're ineligible to request resources because our
> >> space is deaggregated where a network operator with contiguous /20
> >> would be eligible.
> >>
> >> Would anyone else be in favor of amending this?
> >>
> >> --
> >> Jeffrey A. Lyon, CISSP
> >> President, Black Lotus Communications
> >> mobile: (757) 304-0668 | gtalk: 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.
> >
> >
> > Are there any other opinions on this matter? I would like to hear any
> > opposition that may exist before moving forward with drafting a policy
> > proposal.
> >
> > Thanks,
> > --
> > Jeffrey A. Lyon, CISSP
> > President, Black Lotus Communications
> > mobile: (757) 304-0668 | gtalk: 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20121116/734e01fb/attachment.htm>

From george.herbert at gmail.com  Fri Nov 16 16:53:09 2012
From: george.herbert at gmail.com (George Herbert)
Date: Fri, 16 Nov 2012 13:53:09 -0800
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <CAD6AjGSQWrJvw5jOcv=_rCfRyb1uJ84+QkMRvMUEpTqu1wWVdQ@mail.gmail.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<0DFF19C7-926C-40D5-B804-A41857BAF162@eclipse-networks.com>
	<CAD6AjGSQWrJvw5jOcv=_rCfRyb1uJ84+QkMRvMUEpTqu1wWVdQ@mail.gmail.com>
Message-ID: <CAK__KzsG=YKigmNH2-+6gcnH_nSmvvSiPtnUV_sv_7N_mJcH4A@mail.gmail.com>

On Fri, Nov 16, 2012 at 1:38 PM, Cameron Byrne <cb.list6 at gmail.com> wrote:
>
> On Nov 16, 2012 7:56 AM, "Steven Ryerse" <SRyerse at eclipse-networks.com>
> wrote:
>>
>> I agree with the change. Fairness needs to prevail.
>>
>
> +1
>
> CB

Also agree.

I do not want to introduce new methods to game the system, but this
seems to me to be Jeffrey Lyon has quite legitimately found an
inadvertent goof in the way the prior policy was written, and the
request and suggestions for how to change the policy seem reasonable
and responsible, of general interest and not just an attempt to game
the system for his own benefit.  I can easily see this affecting many
others.

Scott Leibrand's 4.1.8 / 1 block every 3 months approach also seems
reasonable and responsible.

Perhaps there's a hidden gotcha, but I am not seeing it so far.


-- 
-george william herbert
george.herbert at gmail.com


From scottleibrand at gmail.com  Fri Nov 16 16:55:10 2012
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 16 Nov 2012 13:55:10 -0800
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <CAK__KzsG=YKigmNH2-+6gcnH_nSmvvSiPtnUV_sv_7N_mJcH4A@mail.gmail.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<0DFF19C7-926C-40D5-B804-A41857BAF162@eclipse-networks.com>
	<CAD6AjGSQWrJvw5jOcv=_rCfRyb1uJ84+QkMRvMUEpTqu1wWVdQ@mail.gmail.com>
	<CAK__KzsG=YKigmNH2-+6gcnH_nSmvvSiPtnUV_sv_7N_mJcH4A@mail.gmail.com>
Message-ID: <CAGkMwz5OiWO6Ak_G7dOi=Uzsrdwe3vRcB8tu+n7QmbEHpkXv5w@mail.gmail.com>

On Fri, Nov 16, 2012 at 1:53 PM, George Herbert <george.herbert at gmail.com>wrote:

> On Fri, Nov 16, 2012 at 1:38 PM, Cameron Byrne <cb.list6 at gmail.com> wrote:
> >
> > On Nov 16, 2012 7:56 AM, "Steven Ryerse" <SRyerse at eclipse-networks.com>
> > wrote:
> >>
> >> I agree with the change. Fairness needs to prevail.
> >>
> >
> > +1
> >
> > CB
>
> Also agree.
>
> I do not want to introduce new methods to game the system, but this
> seems to me to be Jeffrey Lyon has quite legitimately found an
> inadvertent goof in the way the prior policy was written, and the
> request and suggestions for how to change the policy seem reasonable
> and responsible, of general interest and not just an attempt to game
> the system for his own benefit.  I can easily see this affecting many
> others.
>
> Scott Leibrand's 4.1.8 / 1 block every 3 months approach also seems
> reasonable and responsible.
>

To be clear, that's already in existing policy, so no change is required
there.

-Scott


>
> Perhaps there's a hidden gotcha, but I am not seeing it so far.
>
>
> --
> -george william herbert
> george.herbert at gmail.com
> _______________________________________________
> 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/20121116/d608f1d3/attachment.htm>

From mysidia at gmail.com  Fri Nov 16 19:22:53 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 16 Nov 2012 18:22:53 -0600
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
Message-ID: <CAAAwwbWfaVxtQjWhP2RSU0OJpDj_zN+7U4djO6EYvO9Z90hJcQ@mail.gmail.com>

On 11/15/12, Scott Leibrand <scottleibrand at gmail.com> wrote:
> Not necessarily opposed, but one reason for the existing language is: if you
> are at 90% of a /16, and your 3 month need is only for a /20, then you would
> still be at >80% immediately after getting your /20, without using a bit of

exactly....  and It would not be favorable to have a measure of
utilization that allowed an organization to fail to efficiently
utilize  each of the allocations they obtain, before requesting
another.

It's essentially like saying  "You used your previous allocation _SO_
efficiently, that we will give you a bonus,  and  let you not use the
next allocation so efficiently, and still obtain more resources."

Instead it should just be  "lesson learned"  for the applicant;  if
you ever actually exceed 80% utilization, stop allocating from that
block, start allocating from the new one, and there is no need to
change policy.

(Except to increase the utilization requirement to a higher value);
E.g.  80%  utilization on the preceding allocation,  and 99%
utilization on  allocations that preceded it..


The applicant who got the larger allocation and achieved the same
overall percentage of utilization,  had to meet a larger need
requirement to obtain that allocation.    And they also had to
allocate more number resources after actually obtaining the
allocation, to be allocated the next one.

> Scott
--
-JH


From jeffrey.lyon at blacklotus.net  Fri Nov 16 19:27:16 2012
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Fri, 16 Nov 2012 19:27:16 -0500
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <CAAAwwbWfaVxtQjWhP2RSU0OJpDj_zN+7U4djO6EYvO9Z90hJcQ@mail.gmail.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
	<CAAAwwbWfaVxtQjWhP2RSU0OJpDj_zN+7U4djO6EYvO9Z90hJcQ@mail.gmail.com>
Message-ID: <CACrmG8fPQRm8ddDuOQ1HEk8=rnW=svgX6G9V4oHyZsjjb5L5pQ@mail.gmail.com>

On Fri, Nov 16, 2012 at 7:22 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> On 11/15/12, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> Not necessarily opposed, but one reason for the existing language is: if you
>> are at 90% of a /16, and your 3 month need is only for a /20, then you would
>> still be at >80% immediately after getting your /20, without using a bit of
>
> exactly....  and It would not be favorable to have a measure of
> utilization that allowed an organization to fail to efficiently
> utilize  each of the allocations they obtain, before requesting
> another.
>
> It's essentially like saying  "You used your previous allocation _SO_
> efficiently, that we will give you a bonus,  and  let you not use the
> next allocation so efficiently, and still obtain more resources."
>
> Instead it should just be  "lesson learned"  for the applicant;  if
> you ever actually exceed 80% utilization, stop allocating from that
> block, start allocating from the new one, and there is no need to
> change policy.
>
> (Except to increase the utilization requirement to a higher value);
> E.g.  80%  utilization on the preceding allocation,  and 99%
> utilization on  allocations that preceded it..
>
>
> The applicant who got the larger allocation and achieved the same
> overall percentage of utilization,  had to meet a larger need
> requirement to obtain that allocation.    And they also had to
> allocate more number resources after actually obtaining the
> allocation, to be allocated the next one.
>
>> Scott
> --
> -JH

Jimmy,

At the risk of getting off on a tangent, the only reason we ended up
with 2 x /21 vs. 1 x /20 is that we have been extremely stingy with IP
space where our competitors have been handing them out like candy. At
one point we were charging $30/mo, per IP in order to conserve space.
We were able to survive on a single /21 for 4 years as a result. One
of our competitors who does not follow the same best practices has an
aggregate /16 or so.

The lesson i've learned is that wasteful companies receive
preferential treatment under current policies.

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


From lar at mwtcorp.net  Fri Nov 16 20:05:48 2012
From: lar at mwtcorp.net (Larry Ash)
Date: Fri, 16 Nov 2012 18:05:48 -0700
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <CAAAwwbWfaVxtQjWhP2RSU0OJpDj_zN+7U4djO6EYvO9Z90hJcQ@mail.gmail.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
	<CAAAwwbWfaVxtQjWhP2RSU0OJpDj_zN+7U4djO6EYvO9Z90hJcQ@mail.gmail.com>
Message-ID: <web-3261713@be1.mail.trib.com>

On Fri, 16 Nov 2012 18:22:53 -0600
  Jimmy Hess <mysidia at gmail.com> wrote:
> On 11/15/12, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> Not necessarily opposed, but one reason for the existing language is: if you
>> are at 90% of a /16, and your 3 month need is only for a /20, then you would
>> still be at >80% immediately after getting your /20, without using a bit of
> 
> exactly....  and It would not be favorable to have a measure of
> utilization that allowed an organization to fail to efficiently
> utilize  each of the allocations they obtain, before requesting
> another.
> 
> It's essentially like saying  "You used your previous allocation _SO_
> efficiently, that we will give you a bonus,  and  let you not use the
> next allocation so efficiently, and still obtain more resources."
> 
> Instead it should just be  "lesson learned"  for the applicant;  if
> you ever actually exceed 80% utilization, stop allocating from that
> block, start allocating from the new one, and there is no need to
> change policy.

Reaching 80% on a smaller allocation is a lot
harder than a /18. Over time holes develop in the utilization.
You will reuse them but at any given time it's difficult if not
impossible.

How about 80% overall with no single allocation under 70% (whatever).

The 80% policy has always greatly favored the big guys. It's much
easier to reach 80% on a /18 than a /20. Natural holes that occur
always seem to amount to almost 10-25% in a /20 unless much of it
has been delegated as /23's or /24's.

I have turned away customers on a number of occasions over the years
because they needed /24's or larger and I didn't have any open and no
hope of getting more. For several years my utilization was only in the
lower 70's but the largest contiguous blocks were frequently /26's.

We constantly worked at closing the gaps but you can only ask customers
to do so much.

> 
> (Except to increase the utilization requirement to a higher value);
> E.g.  80%  utilization on the preceding allocation,  and 99%
> utilization on  allocations that preceded it..
> 
> 
> The applicant who got the larger allocation and achieved the same
> overall percentage of utilization,  had to meet a larger need
> requirement to obtain that allocation.    And they also had to
> allocate more number resources after actually obtaining the
> allocation, to be allocated the next one.
> 
>> Scott
> --
> -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.

Larry Ash


From jeffrey.lyon at blacklotus.net  Fri Nov 16 20:40:08 2012
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Fri, 16 Nov 2012 20:40:08 -0500
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <web-3261713@be1.mail.trib.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
	<CAAAwwbWfaVxtQjWhP2RSU0OJpDj_zN+7U4djO6EYvO9Z90hJcQ@mail.gmail.com>
	<web-3261713@be1.mail.trib.com>
Message-ID: <CACrmG8dcZ4ykCFcjarq0nLp3g=wop=ZjKKEEaG8ABmga=4vtyg@mail.gmail.com>

On Fri, Nov 16, 2012 at 8:05 PM, Larry Ash <lar at mwtcorp.net> wrote:
> On Fri, 16 Nov 2012 18:22:53 -0600
>  Jimmy Hess <mysidia at gmail.com> wrote:
>>
>> On 11/15/12, Scott Leibrand <scottleibrand at gmail.com> wrote:
>>>
>>> Not necessarily opposed, but one reason for the existing language is: if
>>> you
>>> are at 90% of a /16, and your 3 month need is only for a /20, then you
>>> would
>>> still be at >80% immediately after getting your /20, without using a bit
>>> of
>>
>>
>> exactly....  and It would not be favorable to have a measure of
>> utilization that allowed an organization to fail to efficiently
>> utilize  each of the allocations they obtain, before requesting
>> another.
>>
>> It's essentially like saying  "You used your previous allocation _SO_
>> efficiently, that we will give you a bonus,  and  let you not use the
>> next allocation so efficiently, and still obtain more resources."
>>
>> Instead it should just be  "lesson learned"  for the applicant;  if
>> you ever actually exceed 80% utilization, stop allocating from that
>> block, start allocating from the new one, and there is no need to
>> change policy.
>
>
> Reaching 80% on a smaller allocation is a lot
> harder than a /18. Over time holes develop in the utilization.
> You will reuse them but at any given time it's difficult if not
> impossible.
>
> How about 80% overall with no single allocation under 70% (whatever).
>
> The 80% policy has always greatly favored the big guys. It's much
> easier to reach 80% on a /18 than a /20. Natural holes that occur
> always seem to amount to almost 10-25% in a /20 unless much of it
> has been delegated as /23's or /24's.
>
> I have turned away customers on a number of occasions over the years
> because they needed /24's or larger and I didn't have any open and no
> hope of getting more. For several years my utilization was only in the
> lower 70's but the largest contiguous blocks were frequently /26's.
>
> We constantly worked at closing the gaps but you can only ask customers
> to do so much.
>
>>
>> (Except to increase the utilization requirement to a higher value);
>> E.g.  80%  utilization on the preceding allocation,  and 99%
>> utilization on  allocations that preceded it..
>>
>>
>> The applicant who got the larger allocation and achieved the same
>> overall percentage of utilization,  had to meet a larger need
>> requirement to obtain that allocation.    And they also had to
>> allocate more number resources after actually obtaining the
>> allocation, to be allocated the next one.
>>
>>> Scott
>>
>> --
>> -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.
>
>
> Larry Ash

Larry,

Ditto. My largest contiguous is probably a /28 right now, but I still
did not (until yesterday) qualify for more space with ARIN.

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


From rbf+arin-ppml at panix.com  Sat Nov 17 11:15:01 2012
From: rbf+arin-ppml at panix.com (Brett Frankenberger)
Date: Sat, 17 Nov 2012 10:15:01 -0600
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <CAAAwwbWfaVxtQjWhP2RSU0OJpDj_zN+7U4djO6EYvO9Z90hJcQ@mail.gmail.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
	<CAAAwwbWfaVxtQjWhP2RSU0OJpDj_zN+7U4djO6EYvO9Z90hJcQ@mail.gmail.com>
Message-ID: <20121117161500.GA18710@panix.com>

On Fri, Nov 16, 2012 at 06:22:53PM -0600, Jimmy Hess wrote:
> 
> It's essentially like saying  "You used your previous allocation _SO_
> efficiently, that we will give you a bonus,  and  let you not use the
> next allocation so efficiently, and still obtain more resources."

Or it's like saying "because we value form over function, you can't
have any more addresses now, unless you waste time reassigning some of
your customers from your previous allocation to your next allocation".

> Instead it should just be  "lesson learned"  for the applicant;  if
> you ever actually exceed 80% utilization, stop allocating from that
> block, start allocating from the new one, and there is no need to
> change policy.

So you believe that we should encode in policy a preference for making
assignments from newer allocations over older allocations, and reward
providers who do that?

An applicant who has used 95% of his first /16 and 75% of his second
/16 has more efficiently utilized his space than an applicate who has
used 81% of his first /16 and 81% of his second /16.  Yet we are
willing to give more addresses to the second, less efficient,
application, but we will not give more addresses to the first
applicant.

Moreover, the first applicant *can* get more space without any
increase in utilization, simply by renumbering customers equivalent to
5% of a /16 from the his first /16 to his second /16.  Should policy
really be motivating/rewarding this sort of behavior?

A counterargument is the repetitive assignment possibility. Someone who
is at 95% of a /16 justifies and receives a /20.  Without any
utilization of it whatsoever, they are at 89% and can essentially
submit the same paperwork and get another /20 the next day.  However:
(a) even under current policy, they can do that, as long as they move
80% of a /20 of customers from their original /16 to their new
/20, and (b) in the situation I describe, the real cause of the
potential for repetitive assignment is the applicant's voluntary delay of
their request: they could have requested when they got to 80% of their
first /16, and then their /20 would have placed them below 80% in
aggregate.

The goal is efficient utilization of a limited resource. But current
policy treats entites who are equally situated in terms of existing
space, utilization of existing space, and projected need going forward,
differently, based on *which* of their existing addresses they have
used.

If the government started taxing purchases paid for with a $20 bill
differently from purchases paid for with two $10 bills, we'd all think
that's silly.  But we are treating providers who made allocations from
their older assignment differently from providers who make those same
allocations from their newer assignments.

     -- Brett


From gcampbelljm at yahoo.com  Sat Nov 17 11:25:57 2012
From: gcampbelljm at yahoo.com (gcampbelljm at yahoo.com)
Date: Sat, 17 Nov 2012 16:25:57 +0000
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <855077AC3D7A7147A7570370CA01ECD2280B80@SUEX10-mbx-10.ad.syr.edu>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
	<50A5E2D8.80802@skywaywest.com>
	<855077AC3D7A7147A7570370CA01ECD2280B80@SUEX10-mbx-10.ad.syr.edu>
Message-ID: <864088986-1353169540-cardhu_decombobulator_blackberry.rim.net-524803274-@b15.c9.bise6.blackberry>

I concur with you Milton. 
Sent from my BlackBerry? device from Digicel

-----Original Message-----
From: Milton L Mueller <mueller at syr.edu>
Sender: arin-ppml-bounces at arin.net
Date: Fri, 16 Nov 2012 14:17:48 
To: 'Ron Grant'<rgrant at skywaywest.com>; arin-ppml at arin.net<arin-ppml at arin.net>
Subject: Re: [arin-ppml] Utilization policy is not aggregate

I agree with this framing of the problem and as a new AC member will be willing to work on getting a new, well-thought-out policy through.

--MM

> -----Original Message-----
> 
> We're very near exhaustion so any new policy should be framed with the
> transfer market in mind.
> 
> If somebody's willing to sell, and somebody else is willing to buy, but
> they can't justify it because of a math problem - well, I'd be in favour
> of changing it.
> 
> So the example is really this:
> 
> "if you are at 90% of a /16, and all that's available for purchase is a
> /20, is it really a problem if after purchase you'd be able to buy more?"
> 
issues.
_______________________________________________
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 mysidia at gmail.com  Sat Nov 17 12:07:56 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 17 Nov 2012 11:07:56 -0600
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <web-3261713@be1.mail.trib.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B2113B44378@WP40044.corp.ads>
	<CACrmG8f+tFOyzk1=0+XQwrATfdXvbxOr6A+SAQuH7nPfqkqaYw@mail.gmail.com>
	<3AED37E2-BBFC-4534-82B9-B55A20E320C5@gmail.com>
	<CAAAwwbWfaVxtQjWhP2RSU0OJpDj_zN+7U4djO6EYvO9Z90hJcQ@mail.gmail.com>
	<web-3261713@be1.mail.trib.com>
Message-ID: <CAAAwwbWGty56itU=1gBppr-CwtA8i-Jw4ZdyZqZdq1gZBTTOqA@mail.gmail.com>

On 11/16/12, Larry Ash <lar at mwtcorp.net> wrote:
> Reaching 80% on a smaller allocation is a lot
> harder than a /18. Over time holes develop in the utilization.
> You will reuse them but at any given time it's difficult if not
> impossible.
> How about 80% overall with no single allocation under 70% (whatever).
OK....  that solves that particular problem.

Although, still... the  20%  criterion  is really there to give
applicants time to request new IPs before their existing resources are
exhausted;   I would say that  "allowing holes"  would be an
unintended side effect of the policy.

How exactly do we come up with the 80% rule in the first place, and
how exactly do we prove that 80% is the right number, and not  90% or
75%?

Instead of looking at the size of the allocation, and the number of
IPs used, perhaps policy for ISPs should look at the size of the
allocation,  and the _average size of a suballocation_  of each size
from  /32  down to the length of the block assigned.

e.g.
                       Total average number allocated  per 12 month period
/32                   0
/31                   0
/30                   0
/29                   10
/28                   5
/27                   3
/26                   2
/25                   4
/24                   1

And state,  that  new resources may be assigned when any of these
conditions are true:

 (i)    Of all IPv4 resources previously received,  99% have been suballocated.

 (ii)    The number   of   unallocated IP addresses   sums to a number less than
         or equal to the  number of IP addresses allocated over the
previous 6 month period.

 (iii)  The ISP organization can show,   that when the ISP makes
allocations  for the next 3
       months,   it is not possible to map their existing unallocated
address space, onto
       each of those allocations,  without  renumbering customers,

       Or reducing  the available aggregate IP addresses that can be
allocated below
       the size of that ISP's average allocation,  times the average 3
months' number of allocations of that size.






> The 80% policy has always greatly favored the big guys. It's much
> easier to reach 80% on a /18 than a /20. Natural holes that occur
> always seem to amount to almost 10-25% in a /20 unless much of it
> has been delegated as /23's or /24's.

--
-JH


From cgrundemann at gmail.com  Mon Nov 19 10:55:04 2012
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 19 Nov 2012 08:55:04 -0700
Subject: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and 8.3
	Transfer Policy
Message-ID: <CAC1-dtn0cFCLUzTxRB3BcX1oLsDwwjBgeRfoJ-LzzDiseuHJ6Q@mail.gmail.com>

Hail PPML,

Following discussion at the 30th ARIN PPM, ARIN-2012-8 has been
revised. A change-log has been added to the rationale. Please send
feedback at your earliest convenience.

----8<----8<----8<----
Draft Policy ARIN-2012-8 Aligning 8.2 and 8.3 Transfer Policy

Date: 19 November 2012

Policy statement:

Replace the first paragraph of section 8.2 with the following (second
paragraph remains unchanged):

ARIN will consider requests for the transfer of number resources in
the case of mergers and acquisitions under the following conditions:

 * The new entity must provide evidence that they have acquired assets
that used the resources transferred from the current registrant. ARIN
will maintain an up-to-date list of acceptable types of documentation.
 * The current registrant must not be involved in any dispute as to
the status of the transferred resources.
 * The new entity must sign an RSA covering all transferred resources.
 * The transferred resources will be subject to current ARIN policies.
 * The minimum IPv4 transfer size is a /24, or the original assignment
size, whichever is smaller.
 * The minimum IPv6 transfer size is a /48.

Rationale:

The base intent here is to lower confusion, raise clarity, and level
the bar between 8.2 and 8.3 transfers. M&A transfers are distinct from
specified transfers and not all of the same rules can apply - but many
can and should. Therefor this policy change explicitly adds
requirements which do not exist in 8.2 policy text today: Source must
be the undisputed current registered holder, recipient must sign an
RSA (and is subject to policy), and /24 minimum for IPv4, /48 for
IPv6.

Changes following discussion at the ARIN XXX public policy meeting:
1) Changed the first bullet. This was an area for objections because
it did not allow chain of custody transfers, so now instead of saying
that the purchased company must be the current registrant holder it
simply says that there can not be any dispute as to who the registered
holder is.
2) Removed the " such that their continued need is justified" text
from the second bullet, this was another area of debate at the meeting
and justification is already covered in paragraph 2 of 8.2 (which
remains unchanged).
3) Swapped the first two bullets.
4) Added "covering all transferred resources" to the RSA bullet, for clarity.
5) Swapped the third and fourth bullets.
6) Altered the IPv4 minimum allocation to bring it in line with 4.10
resources and any future exceptions.

Timetable for implementation: immediate
----8<----8<----8<----

Cheers,
~Chris


--
@ChrisGrundemann
http://chrisgrundemann.com


From info at arin.net  Mon Nov 19 11:34:46 2012
From: info at arin.net (ARIN)
Date: Mon, 19 Nov 2012 11:34:46 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - November 2012
Message-ID: <50AA5FA6.9040102@arin.net>

In accordance with the ARIN Policy Development Process, the ARIN 
Advisory Council (AC) held a meeting on 15 November 2012 and made 
decisions about draft policies and proposals.

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

   ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers
   ARIN-2012-7: Reassignments for Third Party Internet Access (TPIA) 
over Cable

The following proposal was added to the AC's docket for development and 
evaluation:

   ARIN-prop-183 Section 8.4 Transfer enhancement

The AC is continuing to work on the following:

   ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement
   ARIN-2012-6: Revising Section 4.4 C/I Reserved Pool Size
   ARIN-2012-8: Aligning 8.2 and 8.3 Transfer Policy
   ARIN-prop-182 Update Residential Customer Definition to not exclude 
wireless as Residential Service

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 owen at delong.com  Mon Nov 19 14:26:36 2012
From: owen at delong.com (Owen DeLong)
Date: Mon, 19 Nov 2012 13:26:36 -0600
Subject: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and
	8.3 Transfer Policy
In-Reply-To: <CAC1-dtn0cFCLUzTxRB3BcX1oLsDwwjBgeRfoJ-LzzDiseuHJ6Q@mail.gmail.com>
References: <CAC1-dtn0cFCLUzTxRB3BcX1oLsDwwjBgeRfoJ-LzzDiseuHJ6Q@mail.gmail.com>
Message-ID: <83144B50-5EC8-4A35-81EC-A33DEB298197@delong.com>

1. first bullet, s/used/use/ in that the acquired assets should still be using the resources in order to justify an M&A transfer.
2. Third bullet should read "current and future ARIN policies".
3. Suggest updating the minimum transfer size specification to reflect "Current ARIN minimum allocation or assignment policy as defined in section 4 or section 6 or the original assignment size, whichever is smaller." since over time we have seen changes in these minimums and I would prefer that the transfer policy automatically track other policy changes.

Owen


Sent from my iPad

On Nov 19, 2012, at 9:55 AM, Chris Grundemann <cgrundemann at gmail.com> wrote:

> Hail PPML,
> 
> Following discussion at the 30th ARIN PPM, ARIN-2012-8 has been
> revised. A change-log has been added to the rationale. Please send
> feedback at your earliest convenience.
> 
> ----8<----8<----8<----
> Draft Policy ARIN-2012-8 Aligning 8.2 and 8.3 Transfer Policy
> 
> Date: 19 November 2012
> 
> Policy statement:
> 
> Replace the first paragraph of section 8.2 with the following (second
> paragraph remains unchanged):
> 
> ARIN will consider requests for the transfer of number resources in
> the case of mergers and acquisitions under the following conditions:
> 
> * The new entity must provide evidence that they have acquired assets
> that used the resources transferred from the current registrant. ARIN
> will maintain an up-to-date list of acceptable types of documentation.
> * The current registrant must not be involved in any dispute as to
> the status of the transferred resources.
> * The new entity must sign an RSA covering all transferred resources.
> * The transferred resources will be subject to current ARIN policies.
> * The minimum IPv4 transfer size is a /24, or the original assignment
> size, whichever is smaller.
> * The minimum IPv6 transfer size is a /48.
> 
> Rationale:
> 
> The base intent here is to lower confusion, raise clarity, and level
> the bar between 8.2 and 8.3 transfers. M&A transfers are distinct from
> specified transfers and not all of the same rules can apply - but many
> can and should. Therefor this policy change explicitly adds
> requirements which do not exist in 8.2 policy text today: Source must
> be the undisputed current registered holder, recipient must sign an
> RSA (and is subject to policy), and /24 minimum for IPv4, /48 for
> IPv6.
> 
> Changes following discussion at the ARIN XXX public policy meeting:
> 1) Changed the first bullet. This was an area for objections because
> it did not allow chain of custody transfers, so now instead of saying
> that the purchased company must be the current registrant holder it
> simply says that there can not be any dispute as to who the registered
> holder is.
> 2) Removed the " such that their continued need is justified" text
> from the second bullet, this was another area of debate at the meeting
> and justification is already covered in paragraph 2 of 8.2 (which
> remains unchanged).
> 3) Swapped the first two bullets.
> 4) Added "covering all transferred resources" to the RSA bullet, for clarity.
> 5) Swapped the third and fourth bullets.
> 6) Altered the IPv4 minimum allocation to bring it in line with 4.10
> resources and any future exceptions.
> 
> Timetable for implementation: immediate
> ----8<----8<----8<----
> 
> Cheers,
> ~Chris
> 
> 
> --
> @ChrisGrundemann
> http://chrisgrundemann.com
> _______________________________________________
> 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 cgrundemann at gmail.com  Mon Nov 19 14:48:06 2012
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 19 Nov 2012 12:48:06 -0700
Subject: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and
 8.3 Transfer Policy
In-Reply-To: <83144B50-5EC8-4A35-81EC-A33DEB298197@delong.com>
References: <CAC1-dtn0cFCLUzTxRB3BcX1oLsDwwjBgeRfoJ-LzzDiseuHJ6Q@mail.gmail.com>
	<83144B50-5EC8-4A35-81EC-A33DEB298197@delong.com>
Message-ID: <CAC1-dtnjONLHGLRj1Eg5ZubRDo00Yh6jGuHUm-VRWQnoO6SZ-g@mail.gmail.com>

Thanks for the feedback Owen.

On Mon, Nov 19, 2012 at 12:26 PM, Owen DeLong <owen at delong.com> wrote:
> 1. first bullet, s/used/use/ in that the acquired assets should still be using the resources in order to justify an M&A transfer.

That would constitute a change from the existing text, which several
folks spoke against at the PPM. I'd like to get more feedback before
changing it back again. Comments from others in the community would be
very much appreciated.

> 2. Third bullet should read "current and future ARIN policies".

Good catch, thanks.

> 3. Suggest updating the minimum transfer size specification to reflect "Current ARIN minimum allocation or assignment policy as defined in section 4 or section 6 or the original assignment size, whichever is smaller." since over time we have seen changes in these minimums and I would prefer that the transfer policy automatically track other policy changes.

I believe that would effectively allow everyone to transfer v4/28s
today based on 4.10 - is this something the community wants to allow?
More feedback in this area would also be helpful.

Cheers,
~Chris

>
> Owen
>
>
> Sent from my iPad
>
> On Nov 19, 2012, at 9:55 AM, Chris Grundemann <cgrundemann at gmail.com> wrote:
>
>> Hail PPML,
>>
>> Following discussion at the 30th ARIN PPM, ARIN-2012-8 has been
>> revised. A change-log has been added to the rationale. Please send
>> feedback at your earliest convenience.
>>
>> ----8<----8<----8<----
>> Draft Policy ARIN-2012-8 Aligning 8.2 and 8.3 Transfer Policy
>>
>> Date: 19 November 2012
>>
>> Policy statement:
>>
>> Replace the first paragraph of section 8.2 with the following (second
>> paragraph remains unchanged):
>>
>> ARIN will consider requests for the transfer of number resources in
>> the case of mergers and acquisitions under the following conditions:
>>
>> * The new entity must provide evidence that they have acquired assets
>> that used the resources transferred from the current registrant. ARIN
>> will maintain an up-to-date list of acceptable types of documentation.
>> * The current registrant must not be involved in any dispute as to
>> the status of the transferred resources.
>> * The new entity must sign an RSA covering all transferred resources.
>> * The transferred resources will be subject to current ARIN policies.
>> * The minimum IPv4 transfer size is a /24, or the original assignment
>> size, whichever is smaller.
>> * The minimum IPv6 transfer size is a /48.
>>
>> Rationale:
>>
>> The base intent here is to lower confusion, raise clarity, and level
>> the bar between 8.2 and 8.3 transfers. M&A transfers are distinct from
>> specified transfers and not all of the same rules can apply - but many
>> can and should. Therefor this policy change explicitly adds
>> requirements which do not exist in 8.2 policy text today: Source must
>> be the undisputed current registered holder, recipient must sign an
>> RSA (and is subject to policy), and /24 minimum for IPv4, /48 for
>> IPv6.
>>
>> Changes following discussion at the ARIN XXX public policy meeting:
>> 1) Changed the first bullet. This was an area for objections because
>> it did not allow chain of custody transfers, so now instead of saying
>> that the purchased company must be the current registrant holder it
>> simply says that there can not be any dispute as to who the registered
>> holder is.
>> 2) Removed the " such that their continued need is justified" text
>> from the second bullet, this was another area of debate at the meeting
>> and justification is already covered in paragraph 2 of 8.2 (which
>> remains unchanged).
>> 3) Swapped the first two bullets.
>> 4) Added "covering all transferred resources" to the RSA bullet, for clarity.
>> 5) Swapped the third and fourth bullets.
>> 6) Altered the IPv4 minimum allocation to bring it in line with 4.10
>> resources and any future exceptions.
>>
>> Timetable for implementation: immediate
>> ----8<----8<----8<----
>>
>> Cheers,
>> ~Chris
>>
>>
>> --
>> @ChrisGrundemann
>> http://chrisgrundemann.com
>> _______________________________________________
>> 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.



--
@ChrisGrundemann
http://chrisgrundemann.com


From mike at nationwideinc.com  Mon Nov 19 14:55:37 2012
From: mike at nationwideinc.com (Mike Burns)
Date: Mon, 19 Nov 2012 14:55:37 -0500
Subject: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2
	and8.3 Transfer Policy
In-Reply-To: <CAC1-dtnjONLHGLRj1Eg5ZubRDo00Yh6jGuHUm-VRWQnoO6SZ-g@mail.gmail.com>
References: <CAC1-dtn0cFCLUzTxRB3BcX1oLsDwwjBgeRfoJ-LzzDiseuHJ6Q@mail.gmail.com><83144B50-5EC8-4A35-81EC-A33DEB298197@delong.com>
	<CAC1-dtnjONLHGLRj1Eg5ZubRDo00Yh6jGuHUm-VRWQnoO6SZ-g@mail.gmail.com>
Message-ID: <15DEDDB2E4DB401D93F39AFB9790CD5A@MPC>

Hi Chris,

I support Owen's third point.
I reject Owen's first point.

Regards,
Mike Burns


-----Original Message----- 
From: Chris Grundemann
Sent: Monday, November 19, 2012 2:48 PM
To: Owen DeLong
Cc: ARIN PPML ; arin-ppml at arin.net
Subject: Re: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 
and8.3 Transfer Policy

Thanks for the feedback Owen.

On Mon, Nov 19, 2012 at 12:26 PM, Owen DeLong <owen at delong.com> wrote:
> 1. first bullet, s/used/use/ in that the acquired assets should still be 
> using the resources in order to justify an M&A transfer.

That would constitute a change from the existing text, which several
folks spoke against at the PPM. I'd like to get more feedback before
changing it back again. Comments from others in the community would be
very much appreciated.

> 2. Third bullet should read "current and future ARIN policies".

Good catch, thanks.

> 3. Suggest updating the minimum transfer size specification to reflect 
> "Current ARIN minimum allocation or assignment policy as defined in 
> section 4 or section 6 or the original assignment size, whichever is 
> smaller." since over time we have seen changes in these minimums and I 
> would prefer that the transfer policy automatically track other policy 
> changes.

I believe that would effectively allow everyone to transfer v4/28s
today based on 4.10 - is this something the community wants to allow?
More feedback in this area would also be helpful.

Cheers,
~Chris

>
> Owen
>
>
> Sent from my iPad
>
> On Nov 19, 2012, at 9:55 AM, Chris Grundemann <cgrundemann at gmail.com> 
> wrote:
>
>> Hail PPML,
>>
>> Following discussion at the 30th ARIN PPM, ARIN-2012-8 has been
>> revised. A change-log has been added to the rationale. Please send
>> feedback at your earliest convenience.
>>
>> ----8<----8<----8<----
>> Draft Policy ARIN-2012-8 Aligning 8.2 and 8.3 Transfer Policy
>>
>> Date: 19 November 2012
>>
>> Policy statement:
>>
>> Replace the first paragraph of section 8.2 with the following (second
>> paragraph remains unchanged):
>>
>> ARIN will consider requests for the transfer of number resources in
>> the case of mergers and acquisitions under the following conditions:
>>
>> * The new entity must provide evidence that they have acquired assets
>> that used the resources transferred from the current registrant. ARIN
>> will maintain an up-to-date list of acceptable types of documentation.
>> * The current registrant must not be involved in any dispute as to
>> the status of the transferred resources.
>> * The new entity must sign an RSA covering all transferred resources.
>> * The transferred resources will be subject to current ARIN policies.
>> * The minimum IPv4 transfer size is a /24, or the original assignment
>> size, whichever is smaller.
>> * The minimum IPv6 transfer size is a /48.
>>
>> Rationale:
>>
>> The base intent here is to lower confusion, raise clarity, and level
>> the bar between 8.2 and 8.3 transfers. M&A transfers are distinct from
>> specified transfers and not all of the same rules can apply - but many
>> can and should. Therefor this policy change explicitly adds
>> requirements which do not exist in 8.2 policy text today: Source must
>> be the undisputed current registered holder, recipient must sign an
>> RSA (and is subject to policy), and /24 minimum for IPv4, /48 for
>> IPv6.
>>
>> Changes following discussion at the ARIN XXX public policy meeting:
>> 1) Changed the first bullet. This was an area for objections because
>> it did not allow chain of custody transfers, so now instead of saying
>> that the purchased company must be the current registrant holder it
>> simply says that there can not be any dispute as to who the registered
>> holder is.
>> 2) Removed the " such that their continued need is justified" text
>> from the second bullet, this was another area of debate at the meeting
>> and justification is already covered in paragraph 2 of 8.2 (which
>> remains unchanged).
>> 3) Swapped the first two bullets.
>> 4) Added "covering all transferred resources" to the RSA bullet, for 
>> clarity.
>> 5) Swapped the third and fourth bullets.
>> 6) Altered the IPv4 minimum allocation to bring it in line with 4.10
>> resources and any future exceptions.
>>
>> Timetable for implementation: immediate
>> ----8<----8<----8<----
>>
>> Cheers,
>> ~Chris
>>
>>
>> --
>> @ChrisGrundemann
>> http://chrisgrundemann.com
>> _______________________________________________
>> 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.



--
@ChrisGrundemann
http://chrisgrundemann.com
_______________________________________________
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  Mon Nov 19 14:55:37 2012
From: mike at nationwideinc.com (Mike Burns)
Date: Mon, 19 Nov 2012 14:55:37 -0500
Subject: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2
	and8.3 Transfer Policy
In-Reply-To: <CAC1-dtnjONLHGLRj1Eg5ZubRDo00Yh6jGuHUm-VRWQnoO6SZ-g@mail.gmail.com>
References: <CAC1-dtn0cFCLUzTxRB3BcX1oLsDwwjBgeRfoJ-LzzDiseuHJ6Q@mail.gmail.com><83144B50-5EC8-4A35-81EC-A33DEB298197@delong.com>
	<CAC1-dtnjONLHGLRj1Eg5ZubRDo00Yh6jGuHUm-VRWQnoO6SZ-g@mail.gmail.com>
Message-ID: <15DEDDB2E4DB401D93F39AFB9790CD5A@MPC>

Hi Chris,

I support Owen's third point.
I reject Owen's first point.

Regards,
Mike Burns


-----Original Message----- 
From: Chris Grundemann
Sent: Monday, November 19, 2012 2:48 PM
To: Owen DeLong
Cc: ARIN PPML ; arin-ppml at arin.net
Subject: Re: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 
and8.3 Transfer Policy

Thanks for the feedback Owen.

On Mon, Nov 19, 2012 at 12:26 PM, Owen DeLong <owen at delong.com> wrote:
> 1. first bullet, s/used/use/ in that the acquired assets should still be 
> using the resources in order to justify an M&A transfer.

That would constitute a change from the existing text, which several
folks spoke against at the PPM. I'd like to get more feedback before
changing it back again. Comments from others in the community would be
very much appreciated.

> 2. Third bullet should read "current and future ARIN policies".

Good catch, thanks.

> 3. Suggest updating the minimum transfer size specification to reflect 
> "Current ARIN minimum allocation or assignment policy as defined in 
> section 4 or section 6 or the original assignment size, whichever is 
> smaller." since over time we have seen changes in these minimums and I 
> would prefer that the transfer policy automatically track other policy 
> changes.

I believe that would effectively allow everyone to transfer v4/28s
today based on 4.10 - is this something the community wants to allow?
More feedback in this area would also be helpful.

Cheers,
~Chris

>
> Owen
>
>
> Sent from my iPad
>
> On Nov 19, 2012, at 9:55 AM, Chris Grundemann <cgrundemann at gmail.com> 
> wrote:
>
>> Hail PPML,
>>
>> Following discussion at the 30th ARIN PPM, ARIN-2012-8 has been
>> revised. A change-log has been added to the rationale. Please send
>> feedback at your earliest convenience.
>>
>> ----8<----8<----8<----
>> Draft Policy ARIN-2012-8 Aligning 8.2 and 8.3 Transfer Policy
>>
>> Date: 19 November 2012
>>
>> Policy statement:
>>
>> Replace the first paragraph of section 8.2 with the following (second
>> paragraph remains unchanged):
>>
>> ARIN will consider requests for the transfer of number resources in
>> the case of mergers and acquisitions under the following conditions:
>>
>> * The new entity must provide evidence that they have acquired assets
>> that used the resources transferred from the current registrant. ARIN
>> will maintain an up-to-date list of acceptable types of documentation.
>> * The current registrant must not be involved in any dispute as to
>> the status of the transferred resources.
>> * The new entity must sign an RSA covering all transferred resources.
>> * The transferred resources will be subject to current ARIN policies.
>> * The minimum IPv4 transfer size is a /24, or the original assignment
>> size, whichever is smaller.
>> * The minimum IPv6 transfer size is a /48.
>>
>> Rationale:
>>
>> The base intent here is to lower confusion, raise clarity, and level
>> the bar between 8.2 and 8.3 transfers. M&A transfers are distinct from
>> specified transfers and not all of the same rules can apply - but many
>> can and should. Therefor this policy change explicitly adds
>> requirements which do not exist in 8.2 policy text today: Source must
>> be the undisputed current registered holder, recipient must sign an
>> RSA (and is subject to policy), and /24 minimum for IPv4, /48 for
>> IPv6.
>>
>> Changes following discussion at the ARIN XXX public policy meeting:
>> 1) Changed the first bullet. This was an area for objections because
>> it did not allow chain of custody transfers, so now instead of saying
>> that the purchased company must be the current registrant holder it
>> simply says that there can not be any dispute as to who the registered
>> holder is.
>> 2) Removed the " such that their continued need is justified" text
>> from the second bullet, this was another area of debate at the meeting
>> and justification is already covered in paragraph 2 of 8.2 (which
>> remains unchanged).
>> 3) Swapped the first two bullets.
>> 4) Added "covering all transferred resources" to the RSA bullet, for 
>> clarity.
>> 5) Swapped the third and fourth bullets.
>> 6) Altered the IPv4 minimum allocation to bring it in line with 4.10
>> resources and any future exceptions.
>>
>> Timetable for implementation: immediate
>> ----8<----8<----8<----
>>
>> Cheers,
>> ~Chris
>>
>>
>> --
>> @ChrisGrundemann
>> http://chrisgrundemann.com
>> _______________________________________________
>> 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.



--
@ChrisGrundemann
http://chrisgrundemann.com
_______________________________________________
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 Nov 19 15:38:41 2012
From: farmer at umn.edu (David Farmer)
Date: Mon, 19 Nov 2012 14:38:41 -0600
Subject: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and
 8.3 Transfer Policy
In-Reply-To: <CAC1-dtnjONLHGLRj1Eg5ZubRDo00Yh6jGuHUm-VRWQnoO6SZ-g@mail.gmail.com>
References: <CAC1-dtn0cFCLUzTxRB3BcX1oLsDwwjBgeRfoJ-LzzDiseuHJ6Q@mail.gmail.com>
	<83144B50-5EC8-4A35-81EC-A33DEB298197@delong.com>
	<CAC1-dtnjONLHGLRj1Eg5ZubRDo00Yh6jGuHUm-VRWQnoO6SZ-g@mail.gmail.com>
Message-ID: <50AA98D1.90303@umn.edu>

On 11/19/12 13:48 , Chris Grundemann wrote:
> On Mon, Nov 19, 2012 at 12:26 PM, Owen DeLong <owen at delong.com> wrote:
...
>> 3. Suggest updating the minimum transfer size specification to reflect "Current ARIN minimum allocation or assignment policy as defined in section 4 or section 6 or the original assignment size, whichever is smaller." since over time we have seen changes in these minimums and I would prefer that the transfer policy automatically track other policy changes.
>
> I believe that would effectively allow everyone to transfer v4/28s
> today based on 4.10 - is this something the community wants to allow?
> More feedback in this area would also be helpful.

No, I think Owen is mostly right, but I would change the order and 
simplify for additional clarity to;

"* The minimum transfer size is, the original allocation size or the 
current applicable minimum allocation size in current policy, whichever 
is smaller."

I believe that means you can transfer the original allocation size what 
ever it is and if you want to transfer something else it must conform to 
current policy, that means /28 within the range reserved in 4.10 and /24 
for a small multihomed end user, or a /22 for a multihomed ISP, etc...

Put another way, if you are doing only a partial transfer then you can't 
break things up smaller than current policy allows, and if the current 
block is already smaller, than you can only transfer the whole block.

-- 
================================================
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 farmer at umn.edu  Mon Nov 19 15:38:41 2012
From: farmer at umn.edu (David Farmer)
Date: Mon, 19 Nov 2012 14:38:41 -0600
Subject: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and
 8.3 Transfer Policy
In-Reply-To: <CAC1-dtnjONLHGLRj1Eg5ZubRDo00Yh6jGuHUm-VRWQnoO6SZ-g@mail.gmail.com>
References: <CAC1-dtn0cFCLUzTxRB3BcX1oLsDwwjBgeRfoJ-LzzDiseuHJ6Q@mail.gmail.com>
	<83144B50-5EC8-4A35-81EC-A33DEB298197@delong.com>
	<CAC1-dtnjONLHGLRj1Eg5ZubRDo00Yh6jGuHUm-VRWQnoO6SZ-g@mail.gmail.com>
Message-ID: <50AA98D1.90303@umn.edu>

On 11/19/12 13:48 , Chris Grundemann wrote:
> On Mon, Nov 19, 2012 at 12:26 PM, Owen DeLong <owen at delong.com> wrote:
...
>> 3. Suggest updating the minimum transfer size specification to reflect "Current ARIN minimum allocation or assignment policy as defined in section 4 or section 6 or the original assignment size, whichever is smaller." since over time we have seen changes in these minimums and I would prefer that the transfer policy automatically track other policy changes.
>
> I believe that would effectively allow everyone to transfer v4/28s
> today based on 4.10 - is this something the community wants to allow?
> More feedback in this area would also be helpful.

No, I think Owen is mostly right, but I would change the order and 
simplify for additional clarity to;

"* The minimum transfer size is, the original allocation size or the 
current applicable minimum allocation size in current policy, whichever 
is smaller."

I believe that means you can transfer the original allocation size what 
ever it is and if you want to transfer something else it must conform to 
current policy, that means /28 within the range reserved in 4.10 and /24 
for a small multihomed end user, or a /22 for a multihomed ISP, etc...

Put another way, if you are doing only a partial transfer then you can't 
break things up smaller than current policy allows, and if the current 
block is already smaller, than you can only transfer the whole block.

-- 
================================================
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 JOHN at egh.com  Mon Nov 19 15:13:33 2012
From: JOHN at egh.com (John Santos)
Date: Mon, 19 Nov 2012 15:13:33 -0500
Subject: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and
	8.3 Transfer Policy
In-Reply-To: <CAC1-dtnjONLHGLRj1Eg5ZubRDo00Yh6jGuHUm-VRWQnoO6SZ-g@mail.gmail.com>
Message-ID: <1121119150643.26144B-100000@Ives.egh.com>

On Mon, 19 Nov 2012, Chris Grundemann wrote:

> Thanks for the feedback Owen.
> 
> On Mon, Nov 19, 2012 at 12:26 PM, Owen DeLong <owen at delong.com> wrote:
> > 1. first bullet, s/used/use/ in that the acquired assets should still be using the resources in order to justify an M&A transfer.
> 
> That would constitute a change from the existing text, which several
> folks spoke against at the PPM. I'd like to get more feedback before
> changing it back again. Comments from others in the community would be
> very much appreciated.
> 

Would this effect the case where an organization in financial difficulty
has ceased operations (and so isn't currently using any of the assets),
but the acquiring org is planning to resume operations?  Seems to me we
should want to encourage that, rather than encouraging fire sales in
this kind of situation.  Maybe adding " and intends to continue or resume 
such use" to the first sentence.  Or would that constrain the recipient
too much?


> > 2. Third bullet should read "current and future ARIN policies".
> 
> Good catch, thanks.
> 
> > 3. Suggest updating the minimum transfer size specification to reflect "Current ARIN minimum allocation or assignment policy as defined in section 4 or section 6 or the original assignment size, whichever is smaller." since over time we have seen change
> s in these minimums and I would prefer that the transfer policy automatically track other policy changes.
> 
> I believe that would effectively allow everyone to transfer v4/28s
> today based on 4.10 - is this something the community wants to allow?
> More feedback in this area would also be helpful.
> 
> Cheers,
> ~Chris
> 
> >
> > Owen
> >
> >
> > Sent from my iPad
> >
> > On Nov 19, 2012, at 9:55 AM, Chris Grundemann <cgrundemann at gmail.com> wrote:
> >
> >> Hail PPML,
> >>
> >> Following discussion at the 30th ARIN PPM, ARIN-2012-8 has been
> >> revised. A change-log has been added to the rationale. Please send
> >> feedback at your earliest convenience.
> >>
> >> ----8<----8<----8<----
> >> Draft Policy ARIN-2012-8 Aligning 8.2 and 8.3 Transfer Policy
> >>
> >> Date: 19 November 2012
> >>
> >> Policy statement:
> >>
> >> Replace the first paragraph of section 8.2 with the following (second
> >> paragraph remains unchanged):
> >>
> >> ARIN will consider requests for the transfer of number resources in
> >> the case of mergers and acquisitions under the following conditions:
> >>
> >> * The new entity must provide evidence that they have acquired assets
> >> that used the resources transferred from the current registrant. ARIN
> >> will maintain an up-to-date list of acceptable types of documentation.
> >> * The current registrant must not be involved in any dispute as to
> >> the status of the transferred resources.
> >> * The new entity must sign an RSA covering all transferred resources.
> >> * The transferred resources will be subject to current ARIN policies.
> >> * The minimum IPv4 transfer size is a /24, or the original assignment
> >> size, whichever is smaller.
> >> * The minimum IPv6 transfer size is a /48.
> >>
> >> Rationale:
> >>
> >> The base intent here is to lower confusion, raise clarity, and level
> >> the bar between 8.2 and 8.3 transfers. M&A transfers are distinct from
> >> specified transfers and not all of the same rules can apply - but many
> >> can and should. Therefor this policy change explicitly adds
> >> requirements which do not exist in 8.2 policy text today: Source must
> >> be the undisputed current registered holder, recipient must sign an
> >> RSA (and is subject to policy), and /24 minimum for IPv4, /48 for
> >> IPv6.
> >>
> >> Changes following discussion at the ARIN XXX public policy meeting:
> >> 1) Changed the first bullet. This was an area for objections because
> >> it did not allow chain of custody transfers, so now instead of saying
> >> that the purchased company must be the current registrant holder it
> >> simply says that there can not be any dispute as to who the registered
> >> holder is.
> >> 2) Removed the " such that their continued need is justified" text
> >> from the second bullet, this was another area of debate at the meeting
> >> and justification is already covered in paragraph 2 of 8.2 (which
> >> remains unchanged).
> >> 3) Swapped the first two bullets.
> >> 4) Added "covering all transferred resources" to the RSA bullet, for clarity.
> >> 5) Swapped the third and fourth bullets.
> >> 6) Altered the IPv4 minimum allocation to bring it in line with 4.10
> >> resources and any future exceptions.
> >>
> >> Timetable for implementation: immediate
> >> ----8<----8<----8<----
> >>
> >> Cheers,
> >> ~Chris
> >>
> >>
> >> --
> >> @ChrisGrundemann
> >> http://chrisgrundemann.com
> >> _______________________________________________
> >> 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.
> 
> 
> 
> --
> @ChrisGrundemann
> http://chrisgrundemann.com
> _______________________________________________
> 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.
> 
> 

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



From owen at delong.com  Mon Nov 19 20:18:54 2012
From: owen at delong.com (Owen DeLong)
Date: Mon, 19 Nov 2012 17:18:54 -0800
Subject: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and
	8.3 Transfer Policy
In-Reply-To: <CAC1-dtnjONLHGLRj1Eg5ZubRDo00Yh6jGuHUm-VRWQnoO6SZ-g@mail.gmail.com>
References: <CAC1-dtn0cFCLUzTxRB3BcX1oLsDwwjBgeRfoJ-LzzDiseuHJ6Q@mail.gmail.com>
	<83144B50-5EC8-4A35-81EC-A33DEB298197@delong.com>
	<CAC1-dtnjONLHGLRj1Eg5ZubRDo00Yh6jGuHUm-VRWQnoO6SZ-g@mail.gmail.com>
Message-ID: <B85FEF3E-30B0-4174-89E6-7510CC7CC8AE@delong.com>


On Nov 19, 2012, at 11:48 AM, Chris Grundemann <cgrundemann at gmail.com> wrote:

> Thanks for the feedback Owen.
> 
> On Mon, Nov 19, 2012 at 12:26 PM, Owen DeLong <owen at delong.com> wrote:
>> 1. first bullet, s/used/use/ in that the acquired assets should still be using the resources in order to justify an M&A transfer.
> 
> That would constitute a change from the existing text, which several
> folks spoke against at the PPM. I'd like to get more feedback before
> changing it back again. Comments from others in the community would be
> very much appreciated.
> 
>> 2. Third bullet should read "current and future ARIN policies".
> 
> Good catch, thanks.
> 
>> 3. Suggest updating the minimum transfer size specification to reflect "Current ARIN minimum allocation or assignment policy as defined in section 4 or section 6 or the original assignment size, whichever is smaller." since over time we have seen changes in these minimums and I would prefer that the transfer policy automatically track other policy changes.
> 
> I believe that would effectively allow everyone to transfer v4/28s
> today based on 4.10 - is this something the community wants to allow?
> More feedback in this area would also be helpful.
> 

It would only allow them to transfer /28s if their target use was a valid qualified use under 4.10. As such, I think I'm OK with that.

If people object to that, then I would suggest the following:

"Notwithstanding section 4.10, Current ARIN minimum allocation or assignment policy as defined in section 4 or section 6?"

Owen



From owen at delong.com  Mon Nov 19 20:22:39 2012
From: owen at delong.com (Owen DeLong)
Date: Mon, 19 Nov 2012 17:22:39 -0800
Subject: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and
	8.3 Transfer Policy
In-Reply-To: <50AA98D1.90303@umn.edu>
References: <CAC1-dtn0cFCLUzTxRB3BcX1oLsDwwjBgeRfoJ-LzzDiseuHJ6Q@mail.gmail.com>
	<83144B50-5EC8-4A35-81EC-A33DEB298197@delong.com>
	<CAC1-dtnjONLHGLRj1Eg5ZubRDo00Yh6jGuHUm-VRWQnoO6SZ-g@mail.gmail.com>
	<50AA98D1.90303@umn.edu>
Message-ID: <520B7AC6-6A7B-4B06-BFDE-D29478D4A05A@delong.com>

+1 -- I support Dave's suggested rewording.

Owen

On Nov 19, 2012, at 12:38 PM, David Farmer <farmer at umn.edu> wrote:

> On 11/19/12 13:48 , Chris Grundemann wrote:
>> On Mon, Nov 19, 2012 at 12:26 PM, Owen DeLong <owen at delong.com> wrote:
> ...
>>> 3. Suggest updating the minimum transfer size specification to reflect "Current ARIN minimum allocation or assignment policy as defined in section 4 or section 6 or the original assignment size, whichever is smaller." since over time we have seen changes in these minimums and I would prefer that the transfer policy automatically track other policy changes.
>> 
>> I believe that would effectively allow everyone to transfer v4/28s
>> today based on 4.10 - is this something the community wants to allow?
>> More feedback in this area would also be helpful.
> 
> No, I think Owen is mostly right, but I would change the order and simplify for additional clarity to;
> 
> "* The minimum transfer size is, the original allocation size or the current applicable minimum allocation size in current policy, whichever is smaller."
> 
> I believe that means you can transfer the original allocation size what ever it is and if you want to transfer something else it must conform to current policy, that means /28 within the range reserved in 4.10 and /24 for a small multihomed end user, or a /22 for a multihomed ISP, etc...
> 
> Put another way, if you are doing only a partial transfer then you can't break things up smaller than current policy allows, and if the current block is already smaller, than you can only transfer the whole block.
> 
> -- 
> ================================================
> 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  Mon Nov 19 20:21:34 2012
From: owen at delong.com (Owen DeLong)
Date: Mon, 19 Nov 2012 17:21:34 -0800
Subject: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and
	8.3 Transfer Policy
In-Reply-To: <1121119150643.26144B-100000@Ives.egh.com>
References: <1121119150643.26144B-100000@Ives.egh.com>
Message-ID: <0D832823-F81B-4590-BEAF-6D17CAABA0DF@delong.com>

My point in proposing this is not to exclude resuming operations (which I would consider within the spirit of the language I proposed), but to exclude acquiring assets that used to use resources as an adjunct to acquiring the resources with no intent of continuing said operations using the resources.

IOW, I want to avoid extending the more lenient 8.2 provisions to a sale where someone buys $100,000 worth of IP addresses and $20,000 worth of hardware and then sells the hardware to $SCRAP_DEALER just to keep the addresses.

Those kinds of purchases belong under the scrutiny of 8.3.

Owen

On Nov 19, 2012, at 12:13 PM, John Santos <JOHN at egh.com> wrote:

> On Mon, 19 Nov 2012, Chris Grundemann wrote:
> 
>> Thanks for the feedback Owen.
>> 
>> On Mon, Nov 19, 2012 at 12:26 PM, Owen DeLong <owen at delong.com> wrote:
>>> 1. first bullet, s/used/use/ in that the acquired assets should still be using the resources in order to justify an M&A transfer.
>> 
>> That would constitute a change from the existing text, which several
>> folks spoke against at the PPM. I'd like to get more feedback before
>> changing it back again. Comments from others in the community would be
>> very much appreciated.
>> 
> 
> Would this effect the case where an organization in financial difficulty
> has ceased operations (and so isn't currently using any of the assets),
> but the acquiring org is planning to resume operations?  Seems to me we
> should want to encourage that, rather than encouraging fire sales in
> this kind of situation.  Maybe adding " and intends to continue or resume 
> such use" to the first sentence.  Or would that constrain the recipient
> too much?
> 
> 
>>> 2. Third bullet should read "current and future ARIN policies".
>> 
>> Good catch, thanks.
>> 
>>> 3. Suggest updating the minimum transfer size specification to reflect "Current ARIN minimum allocation or assignment policy as defined in section 4 or section 6 or the original assignment size, whichever is smaller." since over time we have seen change
>> s in these minimums and I would prefer that the transfer policy automatically track other policy changes.
>> 
>> I believe that would effectively allow everyone to transfer v4/28s
>> today based on 4.10 - is this something the community wants to allow?
>> More feedback in this area would also be helpful.
>> 
>> Cheers,
>> ~Chris
>> 
>>> 
>>> Owen
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>> On Nov 19, 2012, at 9:55 AM, Chris Grundemann <cgrundemann at gmail.com> wrote:
>>> 
>>>> Hail PPML,
>>>> 
>>>> Following discussion at the 30th ARIN PPM, ARIN-2012-8 has been
>>>> revised. A change-log has been added to the rationale. Please send
>>>> feedback at your earliest convenience.
>>>> 
>>>> ----8<----8<----8<----
>>>> Draft Policy ARIN-2012-8 Aligning 8.2 and 8.3 Transfer Policy
>>>> 
>>>> Date: 19 November 2012
>>>> 
>>>> Policy statement:
>>>> 
>>>> Replace the first paragraph of section 8.2 with the following (second
>>>> paragraph remains unchanged):
>>>> 
>>>> ARIN will consider requests for the transfer of number resources in
>>>> the case of mergers and acquisitions under the following conditions:
>>>> 
>>>> * The new entity must provide evidence that they have acquired assets
>>>> that used the resources transferred from the current registrant. ARIN
>>>> will maintain an up-to-date list of acceptable types of documentation.
>>>> * The current registrant must not be involved in any dispute as to
>>>> the status of the transferred resources.
>>>> * The new entity must sign an RSA covering all transferred resources.
>>>> * The transferred resources will be subject to current ARIN policies.
>>>> * The minimum IPv4 transfer size is a /24, or the original assignment
>>>> size, whichever is smaller.
>>>> * The minimum IPv6 transfer size is a /48.
>>>> 
>>>> Rationale:
>>>> 
>>>> The base intent here is to lower confusion, raise clarity, and level
>>>> the bar between 8.2 and 8.3 transfers. M&A transfers are distinct from
>>>> specified transfers and not all of the same rules can apply - but many
>>>> can and should. Therefor this policy change explicitly adds
>>>> requirements which do not exist in 8.2 policy text today: Source must
>>>> be the undisputed current registered holder, recipient must sign an
>>>> RSA (and is subject to policy), and /24 minimum for IPv4, /48 for
>>>> IPv6.
>>>> 
>>>> Changes following discussion at the ARIN XXX public policy meeting:
>>>> 1) Changed the first bullet. This was an area for objections because
>>>> it did not allow chain of custody transfers, so now instead of saying
>>>> that the purchased company must be the current registrant holder it
>>>> simply says that there can not be any dispute as to who the registered
>>>> holder is.
>>>> 2) Removed the " such that their continued need is justified" text
>>>> from the second bullet, this was another area of debate at the meeting
>>>> and justification is already covered in paragraph 2 of 8.2 (which
>>>> remains unchanged).
>>>> 3) Swapped the first two bullets.
>>>> 4) Added "covering all transferred resources" to the RSA bullet, for clarity.
>>>> 5) Swapped the third and fourth bullets.
>>>> 6) Altered the IPv4 minimum allocation to bring it in line with 4.10
>>>> resources and any future exceptions.
>>>> 
>>>> Timetable for implementation: immediate
>>>> ----8<----8<----8<----
>>>> 
>>>> Cheers,
>>>> ~Chris
>>>> 
>>>> 
>>>> --
>>>> @ChrisGrundemann
>>>> http://chrisgrundemann.com
>>>> _______________________________________________
>>>> 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.
>> 
>> 
>> 
>> --
>> @ChrisGrundemann
>> http://chrisgrundemann.com
>> _______________________________________________
>> 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.
>> 
>> 
> 
> -- 
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539



From mysidia at gmail.com  Mon Nov 19 22:56:06 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 19 Nov 2012 21:56:06 -0600
Subject: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and
 8.3 Transfer Policy
In-Reply-To: <0D832823-F81B-4590-BEAF-6D17CAABA0DF@delong.com>
References: <1121119150643.26144B-100000@Ives.egh.com>
	<0D832823-F81B-4590-BEAF-6D17CAABA0DF@delong.com>
Message-ID: <CAAAwwbURe0qg-sZDu1+Q_fveZzXXCbZe+Q7bAghLF7QTj1YhQQ@mail.gmail.com>

On 11/19/12, Owen DeLong <owen at delong.com> wrote:

> IOW, I want to avoid extending the more lenient 8.2 provisions to a sale
> where someone buys $100,000 worth of IP addresses and $20,000 worth of
> hardware and then sells the hardware to $SCRAP_DEALER just to keep the
> addresses.

IP addresses don't belong to hardware;  IP addresses belong to IP
interfaces, attached to hardware, in order to provide connectivity to
a network node for communicating or offering a service.     A change
of hardware does not imply that the need for the logical IP interface
goes away.     If you send a router to a scrap dealer, that doesn't
mean all the networks it routed necessarily go away.

What about cases, where the acquiring organization finds the hardware
_belongs_ with  $TRASH_COLLECTION or $SCRAP_DEALER    due to the
obsolescence of said decrepit hardware,   and after acquiring,  they
will make a non-disruptive reallocation of the hardware used to
provide IT services?      Probably by re-consolidating on new
hardware.

That kind of restructuring does not make renumbering reasonable
and doesn't belong under 8.3.


> Those kinds of purchases belong under the scrutiny of 8.3.
> Owen
[snip]
--
-JH


From owen at delong.com  Mon Nov 19 23:39:05 2012
From: owen at delong.com (Owen DeLong)
Date: Mon, 19 Nov 2012 20:39:05 -0800
Subject: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and
	8.3 Transfer Policy
In-Reply-To: <CAAAwwbURe0qg-sZDu1+Q_fveZzXXCbZe+Q7bAghLF7QTj1YhQQ@mail.gmail.com>
References: <1121119150643.26144B-100000@Ives.egh.com>
	<0D832823-F81B-4590-BEAF-6D17CAABA0DF@delong.com>
	<CAAAwwbURe0qg-sZDu1+Q_fveZzXXCbZe+Q7bAghLF7QTj1YhQQ@mail.gmail.com>
Message-ID: <D92FC7C5-53A5-4B4A-B294-FF53FE290AAD@delong.com>


On Nov 19, 2012, at 7:56 PM, Jimmy Hess <mysidia at gmail.com> wrote:

> On 11/19/12, Owen DeLong <owen at delong.com> wrote:
> 
>> IOW, I want to avoid extending the more lenient 8.2 provisions to a sale
>> where someone buys $100,000 worth of IP addresses and $20,000 worth of
>> hardware and then sells the hardware to $SCRAP_DEALER just to keep the
>> addresses.
> 
> IP addresses don't belong to hardware;  IP addresses belong to IP
> interfaces, attached to hardware, in order to provide connectivity to
> a network node for communicating or offering a service.     A change
> of hardware does not imply that the need for the logical IP interface
> goes away.     If you send a router to a scrap dealer, that doesn't
> mean all the networks it routed necessarily go away.
> 

The above statement was short-hand to explain my intent, not an absolute
statement implying that addresses were attached directly to hardware.
Put it back in context with what I was responding to.

> What about cases, where the acquiring organization finds the hardware
> _belongs_ with  $TRASH_COLLECTION or $SCRAP_DEALER    due to the
> obsolescence of said decrepit hardware,   and after acquiring,  they
> will make a non-disruptive reallocation of the hardware used to
> provide IT services?      Probably by re-consolidating on new
> hardware.
> 

The policy language I proposed would not preclude this.

> That kind of restructuring does not make renumbering reasonable
> and doesn't belong under 8.3.

Agreed. However, I want to make sure that 8.2 does not get abused to
back-door 8.3 style transfers by adding hardware to the mix and pretending
it is an acquisition of a working network.

Owen



From bill at telnetcommunications.com  Wed Nov 21 14:21:56 2012
From: bill at telnetcommunications.com (Bill Sandiford)
Date: Wed, 21 Nov 2012 14:21:56 -0500
Subject: [arin-ppml] Updates to 2012-6
Message-ID: <FE7D4327AABC0448A6281C0AC4445C7CE29CF500BE@Exchange2007.HostedMail.local>

All,

Since the conclusion of the Dallas PPM the AC has spent considerable time working on Draft Policy 2012-6.  As a result, we have come up with modified text as below.  You will note that the new policy text makes minimal changes to the existing policy in the NRPM, but still obtains the goals as intended by the author and expressed by the community in Dallas.

Please provide comments.

Regards,
Bill


------



Policy text:



4.4. Micro-allocation

ARIN will make IPv4 micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) as well as the RIRs and IANA. These allocations will be no smaller than a /24. Multiple allocations may be granted in certain situations.



Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. All other micro-allocations WILL be allocated out of other blocks reserved for micro-allocation purposes.

ARIN will make a list of these blocks publicly available.



Exchange point operators must provide justification for the allocation,

including: connection policy, location, other participants (minimum of two total), ASN, and contact information. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy does not preclude exchange point operators from requesting address space under other policies.



ARIN will place an equivalent of a /16 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4. If at the end of the policy term there is unused address space remaining in this pool, ARIN staff is authorized to utilize this space in a manner consistent with community expectations.



ICANN-sanctioned gTLD operators may justify up to the equivalent of an

IPv4 /23 block for each authorized new gTLD, allocated from the free pool or received via transfer, but not from the above reservation. This limit of a /23 equivalent per gTLD does not apply to gTLD allocations made under previous policy.



Rationale:



Additional ICANN-sanctioned DNS infrastructure is being added to the Internet and in quantities greater than anticipated when the micro allocation proposal was written and adopted.



The original CI pool was created to serve new IXP and new CI requirements. The pending need is estimated to be over 1000 new gTLD range, which may exhaust the current /16 reservation before the ARIN free pool is exhausted. Once the current /16 reservation is exhausted, CI providers would no longer be eligible to receive address space, either via the general free pool or via transfer.



The original proposal dealt with this by expanding the reservation to a

/15 and allowing CI to draw from the free pool instead of the reservation until it gets down to a /8.  The consensus coming out of the Dallas meeting seems to be that this is an inadequate solution. As the new expanded gTLD demand will obliterate any reasonable reservation, leaving no resources for the other IXP and CI demands that the original reservation was intended to serve. It is therefore, not possible to services them both out of a common reservation.



In order to ensure continued access to IPv4 number resources by new IXP and DNS operators alike, the AC is modifying the proposal going into last call to allow gTLD operators to continue to qualify for micro allocations from the general free pool or via transfer only, and leaving one /16 reserved for IXP, root, and ccTLD DNS operators.



As a result of the close examination of the CI policy brought about by this proposal, the AC has identified a number of issues in the original policy text that should be addressed. However, the AC is intentionally minimizing the overall changes to this proposal as much as possible for last call in keeping with the spirit of the PDP. The AC intends to make future proposals to deal with these other concerns. The current proposal addresses issues of some urgency and we did not want to delay it to another policy cycle as a result.

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

From bill at telnetcommunications.com  Wed Nov 21 17:05:31 2012
From: bill at telnetcommunications.com (Bill Sandiford)
Date: Wed, 21 Nov 2012 17:05:31 -0500
Subject: [arin-ppml] Updates to 2012-6
In-Reply-To: <3F3CE74D-E570-43F2-808B-542B7C50EF4D@centergate.com>
References: <FE7D4327AABC0448A6281C0AC4445C7CE29CF500BE@Exchange2007.HostedMail.local>
	<3F3CE74D-E570-43F2-808B-542B7C50EF4D@centergate.com>
Message-ID: <FE7D4327AABC0448A6281C0AC4445C7CE29CF500C7@Exchange2007.HostedMail.local>

Hi Rodney,

Please note that terminology is not new.  It is the terminology that is currently in the NRPM today.

https://www.arin.net/policy/nrpm.html#four4

Any suggested edits to the text are welcomed.

Bill

-----Original Message-----
From: Rodney Joffe [mailto:rjoffe at centergate.com] 
Sent: November 21, 2012 2:56 PM
To: Bill Sandiford
Subject: Re: [arin-ppml] Updates to 2012-6

Bill,

Sorry to be the potential bearer of bad tidings regarding the wording of this policy, but...

I think the terminology needs to be cleaned up.

Core DNS operators - Thats someone like me (UltraDNS/Neustar).
core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) - I guess thats confusing.

We are a core DNS service provider. However we will be providing the services to over 300 of the new TLD registries. If you allocate the /23s to us, the registry is screwed if they move at some stage to another provider, or do it themselves. So you should be allocating to the TLD Registry itself, who can then temporarily assign the /23 to us, but can then move it when needed.

No?

Regards
Rodney

On Nov 21, 2012, at 12:21 PM, Bill Sandiford <bill at telnetcommunications.com> wrote:

> All,
>  
> Since the conclusion of the Dallas PPM the AC has spent considerable time working on Draft Policy 2012-6.  As a result, we have come up with modified text as below.  You will note that the new policy text makes minimal changes to the existing policy in the NRPM, but still obtains the goals as intended by the author and expressed by the community in Dallas.
>  
> Please provide comments.
>  
> Regards,
> Bill
>  
> ------
>  
> Policy text:
>  
> 4.4. Micro-allocation
> ARIN will make IPv4 micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) as well as the RIRs and IANA. These allocations will be no smaller than a /24. Multiple allocations may be granted in certain situations.
>  
> Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. All other micro-allocations WILL be allocated out of other blocks reserved for micro-allocation purposes.
> ARIN will make a list of these blocks publicly available.
>  
> Exchange point operators must provide justification for the 
> allocation,
> including: connection policy, location, other participants (minimum of two total), ASN, and contact information. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy does not preclude exchange point operators from requesting address space under other policies.
>  
> ARIN will place an equivalent of a /16 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4. If at the end of the policy term there is unused address space remaining in this pool, ARIN staff is authorized to utilize this space in a manner consistent with community expectations.
>  
> ICANN-sanctioned gTLD operators may justify up to the equivalent of an
> IPv4 /23 block for each authorized new gTLD, allocated from the free pool or received via transfer, but not from the above reservation. This limit of a /23 equivalent per gTLD does not apply to gTLD allocations made under previous policy.
>  
> Rationale:
>  
> Additional ICANN-sanctioned DNS infrastructure is being added to the Internet and in quantities greater than anticipated when the micro allocation proposal was written and adopted.
>  
> The original CI pool was created to serve new IXP and new CI requirements. The pending need is estimated to be over 1000 new gTLD range, which may exhaust the current /16 reservation before the ARIN free pool is exhausted. Once the current /16 reservation is exhausted, CI providers would no longer be eligible to receive address space, either via the general free pool or via transfer.
>  
> The original proposal dealt with this by expanding the reservation to 
> a
> /15 and allowing CI to draw from the free pool instead of the reservation until it gets down to a /8.  The consensus coming out of the Dallas meeting seems to be that this is an inadequate solution. As the new expanded gTLD demand will obliterate any reasonable reservation, leaving no resources for the other IXP and CI demands that the original reservation was intended to serve. It is therefore, not possible to services them both out of a common reservation.
>  
> In order to ensure continued access to IPv4 number resources by new IXP and DNS operators alike, the AC is modifying the proposal going into last call to allow gTLD operators to continue to qualify for micro allocations from the general free pool or via transfer only, and leaving one /16 reserved for IXP, root, and ccTLD DNS operators.
>  
> As a result of the close examination of the CI policy brought about by this proposal, the AC has identified a number of issues in the original policy text that should be addressed. However, the AC is intentionally minimizing the overall changes to this proposal as much as possible for last call in keeping with the spirit of the PDP. The AC intends to make future proposals to deal with these other concerns. The current proposal addresses issues of some urgency and we did not want to delay it to another policy cycle as a result.
>  
> _______________________________________________
> 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  Wed Nov 21 21:35:24 2012
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 21 Nov 2012 21:35:24 -0500
Subject: [arin-ppml] Updates to 2012-6
In-Reply-To: <FE7D4327AABC0448A6281C0AC4445C7CE29CF500C7@Exchange2007.HostedMail.local>
References: <FE7D4327AABC0448A6281C0AC4445C7CE29CF500BE@Exchange2007.HostedMail.local>
	<3F3CE74D-E570-43F2-808B-542B7C50EF4D@centergate.com>
	<FE7D4327AABC0448A6281C0AC4445C7CE29CF500C7@Exchange2007.HostedMail.local>
Message-ID: <CAMDXq5NMmnoeqmtt5F-xeMTn+p=F3bgHrmt92vXKKd4G49AMDw@mail.gmail.com>

I think Rodney's comments are solid. Moves may also be involuntary and
forcing transactions through the transfer process seems like
unnecessary overhead that simply slows things down and could cause
real damage.

The terminology "ICANN sanctioned" is in error as well. ICANN doesn't
sanction TLD's, they enter into agreements and become "contracted
parties". It is consistent with ICANN terminology which I think that
in this case it makes sense to align as much as possible and feasible.

Best,

-M<



On Wed, Nov 21, 2012 at 5:05 PM, Bill Sandiford
<bill at telnetcommunications.com> wrote:
> Hi Rodney,
>
> Please note that terminology is not new.  It is the terminology that is currently in the NRPM today.
>
> https://www.arin.net/policy/nrpm.html#four4
>
> Any suggested edits to the text are welcomed.
>
> Bill
>
> -----Original Message-----
> From: Rodney Joffe [mailto:rjoffe at centergate.com]
> Sent: November 21, 2012 2:56 PM
> To: Bill Sandiford
> Subject: Re: [arin-ppml] Updates to 2012-6
>
> Bill,
>
> Sorry to be the potential bearer of bad tidings regarding the wording of this policy, but...
>
> I think the terminology needs to be cleaned up.
>
> Core DNS operators - Thats someone like me (UltraDNS/Neustar).
> core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) - I guess thats confusing.
>
> We are a core DNS service provider. However we will be providing the services to over 300 of the new TLD registries. If you allocate the /23s to us, the registry is screwed if they move at some stage to another provider, or do it themselves. So you should be allocating to the TLD Registry itself, who can then temporarily assign the /23 to us, but can then move it when needed.
>
> No?
>
> Regards
> Rodney
>
> On Nov 21, 2012, at 12:21 PM, Bill Sandiford <bill at telnetcommunications.com> wrote:
>
>> All,
>>
>> Since the conclusion of the Dallas PPM the AC has spent considerable time working on Draft Policy 2012-6.  As a result, we have come up with modified text as below.  You will note that the new policy text makes minimal changes to the existing policy in the NRPM, but still obtains the goals as intended by the author and expressed by the community in Dallas.
>>
>> Please provide comments.
>>
>> Regards,
>> Bill
>>
>> ------
>>
>> Policy text:
>>
>> 4.4. Micro-allocation
>> ARIN will make IPv4 micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) as well as the RIRs and IANA. These allocations will be no smaller than a /24. Multiple allocations may be granted in certain situations.
>>
>> Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. All other micro-allocations WILL be allocated out of other blocks reserved for micro-allocation purposes.
>> ARIN will make a list of these blocks publicly available.
>>
>> Exchange point operators must provide justification for the
>> allocation,
>> including: connection policy, location, other participants (minimum of two total), ASN, and contact information. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy does not preclude exchange point operators from requesting address space under other policies.
>>
>> ARIN will place an equivalent of a /16 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4. If at the end of the policy term there is unused address space remaining in this pool, ARIN staff is authorized to utilize this space in a manner consistent with community expectations.
>>
>> ICANN-sanctioned gTLD operators may justify up to the equivalent of an
>> IPv4 /23 block for each authorized new gTLD, allocated from the free pool or received via transfer, but not from the above reservation. This limit of a /23 equivalent per gTLD does not apply to gTLD allocations made under previous policy.
>>
>> Rationale:
>>
>> Additional ICANN-sanctioned DNS infrastructure is being added to the Internet and in quantities greater than anticipated when the micro allocation proposal was written and adopted.
>>
>> The original CI pool was created to serve new IXP and new CI requirements. The pending need is estimated to be over 1000 new gTLD range, which may exhaust the current /16 reservation before the ARIN free pool is exhausted. Once the current /16 reservation is exhausted, CI providers would no longer be eligible to receive address space, either via the general free pool or via transfer.
>>
>> The original proposal dealt with this by expanding the reservation to
>> a
>> /15 and allowing CI to draw from the free pool instead of the reservation until it gets down to a /8.  The consensus coming out of the Dallas meeting seems to be that this is an inadequate solution. As the new expanded gTLD demand will obliterate any reasonable reservation, leaving no resources for the other IXP and CI demands that the original reservation was intended to serve. It is therefore, not possible to services them both out of a common reservation.
>>
>> In order to ensure continued access to IPv4 number resources by new IXP and DNS operators alike, the AC is modifying the proposal going into last call to allow gTLD operators to continue to qualify for micro allocations from the general free pool or via transfer only, and leaving one /16 reserved for IXP, root, and ccTLD DNS operators.
>>
>> As a result of the close examination of the CI policy brought about by this proposal, the AC has identified a number of issues in the original policy text that should be addressed. However, the AC is intentionally minimizing the overall changes to this proposal as much as possible for last call in keeping with the spirit of the PDP. The AC intends to make future proposals to deal with these other concerns. The current proposal addresses issues of some urgency and we did not want to delay it to another policy cycle as a result.
>>
>> _______________________________________________
>> 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 sethm at rollernet.us  Thu Nov 22 00:47:37 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 21 Nov 2012 21:47:37 -0800
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
Message-ID: <50ADBC79.9010609@rollernet.us>

What about taking a /24 out to use for something like BGP anycasting?
The whole thing is immediately "used" for that purpose, and the last
time I asked, policy doesn't account for that.

~Seth


From mysidia at gmail.com  Thu Nov 22 03:03:57 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 22 Nov 2012 02:03:57 -0600
Subject: [arin-ppml] Utilization policy is not aggregate
In-Reply-To: <50ADBC79.9010609@rollernet.us>
References: <CACrmG8feK_9+oRpUs6xHjSAsiVFquZ4F2uhiT6JTHqfr4jBosA@mail.gmail.com>
	<50ADBC79.9010609@rollernet.us>
Message-ID: <CAAAwwbWML7GPB1qA=Hq6W89a5hZwEh40BX1BrVHQoRtNAytttg@mail.gmail.com>

On 11/21/12, Seth Mattinen <sethm at rollernet.us> wrote:

It seems like just a weakness in the policy's concept of what utilization is.
In the case of BGP anycasting, you have a /24,  part of which becomes
"unutilizable",
for purposes other than anycasting, for technical reasons;    as long
as you don't allocate multiple /24s in this way,  and still  have very
few anycasted  services,  then a complete model of utilization  should
count it utilized.


The policy could be revised to state  something to the effect that,
when an ISP or end user is allocated a minimum of 1000 or more
addresses, up to a maximum of a single /24 equivalent per  AS  number;
no more than 1 /24 per  2048 IP addresses allocated,  with an adequate
showing of technical justification and contracts requiring this,  can
be counted as  utilized with a justification of  "Service provisioning
agreement requiring unique, separate routing  (Anycast BGP)",  and
therefore unused addresses from the range  are to be considered
utilized space,    for the purpose of justifying additional
allocations for  non-Anycast use.


> What about taking a /24 out to use for something like BGP anycasting?
> The whole thing is immediately "used" for that purpose, and the last
> time I asked, policy doesn't account for that.


> ~Seth
--
-JH


From narten at us.ibm.com  Fri Nov 23 00:53:07 2012
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 23 Nov 2012 00:53:07 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201211230553.qAN5r8Oa003210@rotala.raleigh.ibm.com>

Total of 39 messages in the last 7 days.
 
script run at: Fri Nov 23 00:53:07 EST 2012
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 12.82% |    5 | 12.50% |    41367 | owen at delong.com
 10.26% |    4 | 11.43% |    37828 | scottleibrand at gmail.com
 10.26% |    4 |  8.17% |    27053 | mysidia at gmail.com
  7.69% |    3 |  7.29% |    24138 | jeffrey.lyon at blacklotus.net
  5.13% |    2 |  8.46% |    27994 | bill at telnetcommunications.com
  5.13% |    2 |  6.11% |    20207 | mike at nationwideinc.com
  5.13% |    2 |  5.16% |    17088 | cgrundemann at gmail.com
  5.13% |    2 |  4.76% |    15739 | farmer at umn.edu
  2.56% |    1 |  4.61% |    15243 | cb.list6 at gmail.com
  2.56% |    1 |  3.63% |    12018 | hannigan at gmail.com
  2.56% |    1 |  2.98% |     9859 | john at egh.com
  2.56% |    1 |  2.79% |     9234 | matthew.wilder at telus.com
  2.56% |    1 |  2.44% |     8069 | lar at mwtcorp.net
  2.56% |    1 |  2.42% |     7995 | gcampbelljm at yahoo.com
  2.56% |    1 |  2.35% |     7776 | sryerse at eclipse-networks.com
  2.56% |    1 |  2.28% |     7535 | rbf+arin-ppml at panix.com
  2.56% |    1 |  2.16% |     7133 | rgrant at skywaywest.com
  2.56% |    1 |  1.90% |     6299 | narten at us.ibm.com
  2.56% |    1 |  1.88% |     6218 | george.herbert at gmail.com
  2.56% |    1 |  1.81% |     5998 | bill at herrin.us
  2.56% |    1 |  1.79% |     5924 | mueller at syr.edu
  2.56% |    1 |  1.58% |     5227 | info at arin.net
  2.56% |    1 |  1.52% |     5036 | sethm at rollernet.us
--------+------+--------+----------+------------------------
100.00% |   39 |100.00% |   330978 | Total



From ppml at rs.seastrom.com  Fri Nov 23 06:59:56 2012
From: ppml at rs.seastrom.com (Robert E. Seastrom)
Date: Fri, 23 Nov 2012 06:59:56 -0500
Subject: [arin-ppml] Updates to 2012-6
In-Reply-To: <CAMDXq5NMmnoeqmtt5F-xeMTn+p=F3bgHrmt92vXKKd4G49AMDw@mail.gmail.com>
	(Martin Hannigan's message of "Wed, 21 Nov 2012 21:35:24 -0500")
References: <FE7D4327AABC0448A6281C0AC4445C7CE29CF500BE@Exchange2007.HostedMail.local>
	<3F3CE74D-E570-43F2-808B-542B7C50EF4D@centergate.com>
	<FE7D4327AABC0448A6281C0AC4445C7CE29CF500C7@Exchange2007.HostedMail.local>
	<CAMDXq5NMmnoeqmtt5F-xeMTn+p=F3bgHrmt92vXKKd4G49AMDw@mail.gmail.com>
Message-ID: <867gpc7cn7.fsf@seastrom.com>


Martin Hannigan <hannigan at gmail.com> writes:

> I think Rodney's comments are solid. Moves may also be involuntary and
> forcing transactions through the transfer process seems like
> unnecessary overhead that simply slows things down and could cause
> real damage.
>
> The terminology "ICANN sanctioned" is in error as well. ICANN doesn't
> sanction TLD's, they enter into agreements and become "contracted
> parties". It is consistent with ICANN terminology which I think that
> in this case it makes sense to align as much as possible and feasible.

There are two possible goals here and I think you may be conflating
them and falling into the "better is the enemy of good enough" trap.

The first goal is to patch existing policy such that a flood of new
vgTLDs (vanity gTLDs) does not suck what little life remains out of
the free pool.  Exigent circumstance, change as little as possible.

The second goal, if there's community support, is to clean up 4.4.  I
support doing this.

2012-6 supports the first goal, but doesn't really address the second.

I encourage you to suggest text, preferably on a policy template, so
we can move it forward in Barbados.  But please don't oppose 2012-6
simply because it doesn't fully address the deficiencies that you and
Rodney have identified in existing 4.4.  Those are problems that it
was not intended to fix.

I support 2012-6 as written, but our work is not done here.

-r




From ebw at abenaki.wabanaki.net  Fri Nov 23 16:46:00 2012
From: ebw at abenaki.wabanaki.net (ebw at abenaki.wabanaki.net)
Date: Fri, 23 Nov 2012 16:46:00 -0500
Subject: [arin-ppml] Updates to 2012-6
Message-ID: <201211232146.qANLk1qm059951@nic-naa.net>

Rodney suggests that allocations be made to TLD registry contract holders,
observing, reasonably, as a registry backend service provider employee[1],
that allocations made to registry backend service providers complicate the
possible future selection of providers by the TLD registry contract holder.

This revisits the well-known non-portability of provider-aggregatable address
space.

However, before attempting to reason about delegations and the set of assets
minimally advisable to delegees who may, from time to time, be operators of
one or more delegations, we should consider the properties of the proposed
allocation.

There are economic constraints on the number of allocations that may be made
to IX points -- there are sub-four-figures of IX points globally and nothing
suggests a change of scale.

There are economic constraints on the number of allocations that may be made
to other types of "Critical Infrastructure" such as ISPs and data centers.
The same sacling observation applies.

We are confronted by a label allocation policy that may be simplified without
loss of meaning to "three per day" or "one thousand per year". The rate of
label allocation is, according to the label allocator (ICANN), its contracting
rate. In its 2000 and 2004 allocations its contracting rate was on the order
of one per month, or two orders of magnitude less than its current rate of
allocation. To round to the nearest power of two, it is 1024 /xx per year.

It is speculation to assume this is bursty behavior, and the long-term average
rate of allocation substantially different. It is also speculation to assume
that ICANN will not increase the  rate of its contracting process, which
now preferences a single uniform contract.

I suggest first that the proposed rate of allocation is a concern where the
allocated resource is known to be finite. For simplicity, I offer that the
addition of distinct resources to existing iso3166-1 code points delegees to
present only linear scaling, bounded above by a low integer multiple of the
current allocation, perhaps as small as two, and that the addition of
distinct resources to allow iso639 code points, jointly and severally with
iso3166 code point allocations, is similarly limited, and that the addition
of distinct resources to allow iso3166-2 code points and urban areas[2] is
similarly limited. Roughly, these possible allocations in their aggregate
amount to a very low multiple of the current label allocation when fully
exhausted, however, the allocation regime characterized as 1024-per-year is
unbounded over time. 

Second, I want to point out that .museum began on a very, very, limited 
set of address assets, and that while a significant amount of resources
have been expended creating functional and service level requirements not
in ICANN's current contracts, and so not applicable to the operator of 
the .com, .net, .name, and other registries, as well as all other TLD
registry operators, which may have the effect of raising the entry cost
of registry operations, that no rational for this increase in entry cost
arises from address space or ASN allocation. Uniform allocations such as
a /24 to all registries, whether to the contract holders or to platform
operators (see "provider aggreable", supra), overlooks the year to year
projected operational requirements of the candidate allocatees, and in
many cases (see iso3166-1 "IDN", iso639, and iso3166-2 plus other, supra)
may be satisfied by allocations as small as /27, even /28 in their first
five years of operation.

Third, I want to point out that not all infrastructure is equally critical.
In 2010 it was possible to show that the registrations in .cat were not
secondary to registrations in .com, nor in .es, and therefore that .cat
did not subset the locaii of registrant, registrar, and resolution of the
.com or .es zones. It is currently possible to show that registrations in
.xxx are secondary to registrations in .com, and therefore that .xxx is a
subset of the locii of registrant, registrar, and resolution of the .com
zone. Should .xxx fail, for any reason, the "criticality" of it as core
infrastructure is limited to its operator. While this may not be generally
known, some business plans of the 2004 round gTLD label allocatees, and
for many of the 2012 round gTLD label applicants, are predicated on the
replication of the locii of registrant, registrar, and resolution already
present in the .com zone.

Examples of this are the applications for transliterations of "com" in a
dozen non-Latin scripts. Each such transliterated-into-X registry has the
potential to have significant shared locii of registrant, registrar, and
resolution of the .com zone, a potential preferenced by the existing IPR
policies of ICANN, WIPO, and the registration policy of the applicant.

While one could claim that "com" in any script other than Latin is, by its
non-Latin-ness, "critical" [3], no such claim can be offered for business
plans that simply seek to replicate the locii of registrant, registrar, and 
resolution of the .com zone, whether for the purpose of defensive registration
revenue, or for pay-per-click monitization registration revenue capture, or
both. For simplicity I refer to this as ".copy".

I suggest that means testing, both for necessity (see the .museum observation,
supra) and utility (see .copy, supra) is preferable over uniform allocation,
independent of whether the allocation is to the contract holder, independently,
or to the platform operator, aggregable. We proform means testing for ISP
allocations, so this isn't new territory.

In support of the probable absence of necessity, or utility, of allocations
larger than /28 to some applications of the DNS, many applications ICANN has
solicited propose to provide no significant public function beyond resolution
of zero or some small number of resources other than the base label. However,
if permitted [4], the existing set of credible applicants is several orders
of magnitude greater than the current label-associated set of "critical
infrastructure" resources, and unbounded over time as new brands are created
and the cost to "taste" the DNS for top-level value is only the ICANN fee and
modest operational cost using no-cost-to-applicant address space assets.

So finally to Rodney's point, allocate (according to necessity and utility,
if any) to the ICANN contractor, or to the registry services provider.

When I first asked for v4 assets to be held in reserve for new TLDs about
two years ago the common assumption was that there would only be a quarter
of the number of applications to ICANN there in fact are, and that the
corresponding ratio of "facilities-based" to "virtual" registry operators
would be far higher. The facts at hand are that almost all of this class
of would-be "critical infrastructure" is located in the ARIN region, and
that of these, most applicants are made by, or through, a small number of
registry backend service providers.

I suggest that a way, one I'm now convinced has the least waste, from the
point of view of a scarce, and persistent address allocator, and reasonable
given the external circumstances, is to only allocate to facilities-based
registry operators, and only along the ISP usage guideline, attempting to
rationally forecast use and allocation (and de-allocation). If the external
circumstances were facilities-based applications, not sharing the locii of
registrant, registrar, and resolution fates of the .com registry, I would
hold my original view, one which Rodny has articulated.

Eric

[1] In 2001 and 2002 I was employed by NeuStar, a registry backend service
provider, and from 2008 to 2010 I consulted to CORE, also a registry backend
service provider.

[2] No normative standard, but see Table 8, "Population of Capital Cities and
Cities of 100 000 or More Inhabitants", published in the United Nations
Demographic Yearbook7, or Thomas Brinkhoff's list of the 493 agglomerations
of the world with a population of 1 million inhabitants, published at
http://www.citypopulation.de/, as two reasonable informational choices.

[3] See the recent declaration of incomming ICANN CEO Fadi Chehadi that
Verisign's applications for "com" in scripts other than Latin will be
approved before almost all other applications.

[4] No ICANN Policy Development Process record exists to support ".brand"
types of registries with significant contractual variation from "open", 
"sponsored" or "community-based" registrations.


From ebw at abenaki.wabanaki.net  Fri Nov 23 16:39:41 2012
From: ebw at abenaki.wabanaki.net (ebw at abenaki.wabanaki.net)
Date: Fri, 23 Nov 2012 16:39:41 -0500
Subject: [arin-ppml] Updates to 2012-6
Message-ID: <201211232139.qANLdfSV059921@nic-naa.net>

The example offered reads "ICANN-sanctioned root and ccTLD operators". This
confuses me.

There are at least two root zone editors -- one in Marina del Rey and Reston,
and one or more in Beijing and elsewhere(s).

Publication of the MdR/R editor's data is made by one constellation of servers
authoritative for that root zone.

Publication of the Beijing editor's data is made by another constellation of
servers authoritative for that root zone.

The data originatived by two root zone editors differ. The difference is at
present a small number of labels and associated NS records present only in
the data originating from the Beijing editor.

I suggest first that it is unnecessary to take note only of one editor, and
may have adverse outcomes.

Next, to be slightly pendantic, the editorial function carried out in MdR/R
arises from the IANA Functions Contract, not the current incumbent contractor.
This may not appear to matter but the current IANA Function Contract award
was made through open, competitive bidding, and subsequent awards may be to
parties other than the current incumbent contractor. If this text is not to
have only momentary validity the reference could be to the contract, not to
the contractor.

I appreciate that the example language is in the current NPRM -- this is
not the only place where uniqueness and authority appears as fact, when the
converse are facts in evidence.

In the next note I'll comment on the allocation policy comment Rodney made.

Eric


From owen at delong.com  Fri Nov 23 17:16:37 2012
From: owen at delong.com (Owen DeLong)
Date: Fri, 23 Nov 2012 14:16:37 -0800
Subject: [arin-ppml] Updates to 2012-6
In-Reply-To: <201211232139.qANLdfSV059921@nic-naa.net>
References: <201211232139.qANLdfSV059921@nic-naa.net>
Message-ID: <9F89E5AE-1F14-4CC6-8EEA-3A644845FEE6@delong.com>

While I don't support recognizing alternate root operators in the policy, I would
support s/ICANN/ICANN or the properly appointed successor to IANA Functions/.

Owen

On Nov 23, 2012, at 13:39 , ebw at abenaki.wabanaki.net wrote:

> The example offered reads "ICANN-sanctioned root and ccTLD operators". This
> confuses me.
> 
> There are at least two root zone editors -- one in Marina del Rey and Reston,
> and one or more in Beijing and elsewhere(s).
> 
> Publication of the MdR/R editor's data is made by one constellation of servers
> authoritative for that root zone.
> 
> Publication of the Beijing editor's data is made by another constellation of
> servers authoritative for that root zone.
> 
> The data originatived by two root zone editors differ. The difference is at
> present a small number of labels and associated NS records present only in
> the data originating from the Beijing editor.
> 
> I suggest first that it is unnecessary to take note only of one editor, and
> may have adverse outcomes.
> 
> Next, to be slightly pendantic, the editorial function carried out in MdR/R
> arises from the IANA Functions Contract, not the current incumbent contractor.
> This may not appear to matter but the current IANA Function Contract award
> was made through open, competitive bidding, and subsequent awards may be to
> parties other than the current incumbent contractor. If this text is not to
> have only momentary validity the reference could be to the contract, not to
> the contractor.
> 
> I appreciate that the example language is in the current NPRM -- this is
> not the only place where uniqueness and authority appears as fact, when the
> converse are facts in evidence.
> 
> In the next note I'll comment on the allocation policy comment Rodney made.
> 
> Eric
> _______________________________________________
> 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 brent at brescosolutions.com  Sat Nov 24 14:39:53 2012
From: brent at brescosolutions.com (Alejandra Major)
Date: Sat, 24 Nov 2012 11:39:53 -0800
Subject: [arin-ppml] Gold Watches
Message-ID: <699159663.08184665033108@brescosolutions.com>

                                                 
Hello Ppml
                                                                                          
Status accessories and attributes are very important for successful and popular people. Now you don't have to spend ridiculous money to impress partners with expensive watch. Purchase  watches of high quality that look identical to the ones you will find at the jewelry store.
At the present even in diplomatic circles you will feel like you belong there.
                                                                             
**********************
I just received my PN-20 (Panerai Luminor GMT Automatic), and I have to say I'm really impressed. I have ordered from quite a few replica sites in the past, and I always ended up sending the watch back disappointed. I hope this makes it into your customer comments section. I would recommend this site to anyone. Very prompt delivery, great prices and wonderful quality.
Say thank you
                     Alejandra Major
**********************

Click here ---> http://lefed.ru

                                                                                                    


From dave at temk.in  Sun Nov 25 10:10:41 2012
From: dave at temk.in (David Temkin)
Date: Sun, 25 Nov 2012 10:10:41 -0500
Subject: [arin-ppml] Call for Presentations:  NANOG 57 in Orlando, FL
In-Reply-To: <EA2A7574-EE02-4A45-A02D-DBD4C37169A4@temk.in>
References: <EA2A7574-EE02-4A45-A02D-DBD4C37169A4@temk.in>
Message-ID: <F9E84013-2906-485C-8B28-4870AEF7B74F@temk.in>

Just a friendly reminder that the RFP for NANOG 57 is approaching in just over two weeks.

Best Regards,
-Dave Temkin

On Nov 8, 2012, at 11:48 AM, David Temkin <dave at temk.in> wrote:

> NANOG Community,
> 
> I know that we all just left Dallas after NANOG 56, but the NANOG Program Committee is already hard at work preparing for NANOG 57 in Orlando!  
> 
> The North American Network Operators' Group (NANOG) will hold their 57th meeting in Orlando, FL on February 4th through the 6th.  Of special note, this is the first meeting that will have a fully Monday through Wednesday agenda.  Our host, CyrusOne is eagerly awaiting welcoming you to the Renaissance Orlando at SeaWorld.
> 
> The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG 57 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet. Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability. NANOG 57 submissions are welcome at  http://pc.nanog.org  
> 
> For further information on what the Program Committee is seeking, please see http://www.nanog.org/meetings/nanog57/callforpresentations.html
> 
> This will also be our first meeting after the 2012 WCIT in early December, and we expect topical and timely presentations regarding the results
> 
>     When considering submitting a presentation,  keep these important dates in mind: 
> 
>     Presentation Abstracts and Draft Slides Due:  10-December-2012
>     Final Slides Due:                                                     7-January-2013
>     Draft Program Published:                                    14-January-2013 
>     Final Agenda Published:                                     18-January-2013 
> 
>     Please submit your materials to http://pc.nanog.org 
> 
> Looking forward to seeing everyone in Orlando! 
> 
> -Dave Temkin

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

From cgrundemann at gmail.com  Mon Nov 26 16:25:54 2012
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 26 Nov 2012 14:25:54 -0700
Subject: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and
 8.3 Transfer Policy
In-Reply-To: <D92FC7C5-53A5-4B4A-B294-FF53FE290AAD@delong.com>
References: <1121119150643.26144B-100000@Ives.egh.com>
	<0D832823-F81B-4590-BEAF-6D17CAABA0DF@delong.com>
	<CAAAwwbURe0qg-sZDu1+Q_fveZzXXCbZe+Q7bAghLF7QTj1YhQQ@mail.gmail.com>
	<D92FC7C5-53A5-4B4A-B294-FF53FE290AAD@delong.com>
Message-ID: <CAC1-dt=_ChP42HJQzqZ4czvZkq4i12d0LBAdJXWRsyAqCi2QJA@mail.gmail.com>

I made some updates based on feedback received here, the new text is as follows:

----8<----8<----
Replace the first paragraph of section 8.2 with the following (second
paragraph remains unchanged):

ARIN will consider requests for the transfer of number resources in
the case of mergers and acquisitions under the following conditions:

* The new entity must provide evidence that they have acquired assets
that use the resources transferred from the current registrant. ARIN
will maintain an up-to-date list of acceptable types of documentation.
* The current registrant must not be involved in any dispute as to the
status of the transferred resources.
* The new entity must sign an RSA covering all transferred resources.
* The transferred resources will be subject to ARIN policies.
* The minimum transfer size is the smaller of the original allocation
size or the applicable minimum allocation size in current policy.
----8<----8<----

Cheers,
~Chris


On Mon, Nov 19, 2012 at 9:39 PM, Owen DeLong <owen at delong.com> wrote:
>
> On Nov 19, 2012, at 7:56 PM, Jimmy Hess <mysidia at gmail.com> wrote:
>
>> On 11/19/12, Owen DeLong <owen at delong.com> wrote:
>>
>>> IOW, I want to avoid extending the more lenient 8.2 provisions to a sale
>>> where someone buys $100,000 worth of IP addresses and $20,000 worth of
>>> hardware and then sells the hardware to $SCRAP_DEALER just to keep the
>>> addresses.
>>
>> IP addresses don't belong to hardware;  IP addresses belong to IP
>> interfaces, attached to hardware, in order to provide connectivity to
>> a network node for communicating or offering a service.     A change
>> of hardware does not imply that the need for the logical IP interface
>> goes away.     If you send a router to a scrap dealer, that doesn't
>> mean all the networks it routed necessarily go away.
>>
>
> The above statement was short-hand to explain my intent, not an absolute
> statement implying that addresses were attached directly to hardware.
> Put it back in context with what I was responding to.
>
>> What about cases, where the acquiring organization finds the hardware
>> _belongs_ with  $TRASH_COLLECTION or $SCRAP_DEALER    due to the
>> obsolescence of said decrepit hardware,   and after acquiring,  they
>> will make a non-disruptive reallocation of the hardware used to
>> provide IT services?      Probably by re-consolidating on new
>> hardware.
>>
>
> The policy language I proposed would not preclude this.
>
>> That kind of restructuring does not make renumbering reasonable
>> and doesn't belong under 8.3.
>
> Agreed. However, I want to make sure that 8.2 does not get abused to
> back-door 8.3 style transfers by adding hardware to the mix and pretending
> it is an acquisition of a working network.
>
> 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.



-- 
@ChrisGrundemann
http://chrisgrundemann.com


From farmer at umn.edu  Wed Nov 28 10:06:06 2012
From: farmer at umn.edu (David Farmer)
Date: Wed, 28 Nov 2012 09:06:06 -0600
Subject: [arin-ppml] Updates to 2012-6
In-Reply-To: <FE7D4327AABC0448A6281C0AC4445C7CE29CF500BE@Exchange2007.HostedMail.local>
References: <FE7D4327AABC0448A6281C0AC4445C7CE29CF500BE@Exchange2007.HostedMail.local>
Message-ID: <50B6285E.5040908@umn.edu>

While I support this policy as written.  I think it is important for the 
community to at least consider alternative approaches to this issue.

ICANN's New gTLD Program represents a significant departure from the 
original scope of gTLDs contemplated when the current critical 
infrastructure policy was originally considered and the ARIN community 
decided to include all TLDs (both gTLDs and ccTLDs) as critical 
infrastructure based solely on their location in the DNS hierarchy.

One such alternate approach could be to redefine critical infrastructure 
such that it is base on a objective standard of dependency by other 
systems and processes and not simply based on the fact that some word or 
string has been designated a TLD.  In other-words a TLD should only be 
considered critical infrastructure if it meets some threshold of 
dependency by other systems and processes, and not merely based on its 
location in the DNS hierarchy.

If a properly objective measure of dependency by other systems and 
processes could be found, it may also be reasonable to allow other parts 
of the DNS hierarchy, meeting this objective measure, to qualify as 
critical infrastructure as well.  Today, there are many large scale 
domain providers or even sufficiently critical individual domain names 
that are arguably as critical, or more, to the global Internet as many 
of the more obscure ccTLDs.  However, with the current definition being 
based solely on location in the DNS hierarchy, these other parts of the 
DNS hierarchy do not qualify as critical infrastructure in ARIN policy.

I have no doubt that some of the new gTLDs may eventually rise to an 
objective level of criticality that truly justifies the term critical 
infrastructure.  However, it seems fairly obvious that the vast majority 
of the several thousand gTLDs being considered will never meet such a 
standard and should not be considered any more critical than most other 
parts of the DNS hierarchy.

If the community supports this approach, I would suggest;

1. We ask the Board to suspend gTLDs as a justification for critical 
infrastructure, both for IPv4 and IPv6, until the ARIN policy community 
has time to reconsider the definition of critical infrastructure and 
recommend new policy.

1.A. Or, alternatively suspend everything other than Exchange Points as 
critical infrastructure for both both for IPv4 and IPv6.

2. Then focus our policy efforts on finding an "objective measure of 
dependency by other systems and processes" that all TLDs, and possibly 
other parts of the DNS hierarchy need to meet in order to justify being 
considered critical infrastructure and receiving preferential access to 
Internet Number Resources.

Is this a preferable approach to the proposed policy below?  Also, I'd 
be interested in other alternate approaches members of community would 
like to suggest.

However, without some kind of suspension of the current policy, I 
support the policy as written below to go to Last Call and be 
implemented ASAP.  The policy below is preferable to having the proposed 
new gTLDs potentially consume large amounts of IPv4 address space, 
exhausting the reservation and essentially preventing LXPs and other 
current critical infrastructure from have access to IPv4 resources as 
intended by the reservation created in ARIN-2011-4.

Thanks.

On 11/21/12 13:21 , Bill Sandiford wrote:
> All,
>
> Since the conclusion of the Dallas PPM the AC has spent considerable
> time working on Draft Policy 2012-6.  As a result, we have come up with
> modified text as below.  You will note that the new policy text makes
> minimal changes to the existing policy in the NRPM, but still obtains
> the goals as intended by the author and expressed by the community in
> Dallas.
>
> Please provide comments.
>
> Regards,
>
> Bill
>
> ------
>
> Policy text:
>
> 4.4. Micro-allocation
>
> ARIN will make IPv4 micro-allocations to critical infrastructure
> providers of the Internet, including public exchange points, core DNS
> service providers (e.g. ICANN-sanctioned root and ccTLD operators) as
> well as the RIRs and IANA. These allocations will be no smaller than a
> /24. Multiple allocations may be granted in certain situations.
>
> Exchange point allocations MUST be allocated from specific blocks
> reserved only for this purpose. All other micro-allocations WILL be
> allocated out of other blocks reserved for micro-allocation purposes.
>
> ARIN will make a list of these blocks publicly available.
>
> Exchange point operators must provide justification for the allocation,
>
> including: connection policy, location, other participants (minimum of
> two total), ASN, and contact information. ISPs and other organizations
> receiving these micro-allocations will be charged under the ISP fee
> schedule, while end-users will be charged under the fee schedule for
> end-users. This policy does not preclude exchange point operators from
> requesting address space under other policies.
>
> ARIN will place an equivalent of a /16 of IPv4 address space in a
> reserve for Critical Infrastructure, as defined in section 4.4. If at
> the end of the policy term there is unused address space remaining in
> this pool, ARIN staff is authorized to utilize this space in a manner
> consistent with community expectations.
>
> ICANN-sanctioned gTLD operators may justify up to the equivalent of an
>
> IPv4 /23 block for each authorized new gTLD, allocated from the free
> pool or received via transfer, but not from the above reservation. This
> limit of a /23 equivalent per gTLD does not apply to gTLD allocations
> made under previous policy.
>
> Rationale:
>
> Additional ICANN-sanctioned DNS infrastructure is being added to the
> Internet and in quantities greater than anticipated when the micro
> allocation proposal was written and adopted.
>
> The original CI pool was created to serve new IXP and new CI
> requirements. The pending need is estimated to be over 1000 new gTLD
> range, which may exhaust the current /16 reservation before the ARIN
> free pool is exhausted. Once the current /16 reservation is exhausted,
> CI providers would no longer be eligible to receive address space,
> either via the general free pool or via transfer.
>
> The original proposal dealt with this by expanding the reservation to a
>
> /15 and allowing CI to draw from the free pool instead of the
> reservation until it gets down to a /8.  The consensus coming out of the
> Dallas meeting seems to be that this is an inadequate solution. As the
> new expanded gTLD demand will obliterate any reasonable reservation,
> leaving no resources for the other IXP and CI demands that the original
> reservation was intended to serve. It is therefore, not possible to
> services them both out of a common reservation.
>
> In order to ensure continued access to IPv4 number resources by new IXP
> and DNS operators alike, the AC is modifying the proposal going into
> last call to allow gTLD operators to continue to qualify for micro
> allocations from the general free pool or via transfer only, and leaving
> one /16 reserved for IXP, root, and ccTLD DNS operators.
>
> As a result of the close examination of the CI policy brought about by
> this proposal, the AC has identified a number of issues in the original
> policy text that should be addressed. However, the AC is intentionally
> minimizing the overall changes to this proposal as much as possible for
> last call in keeping with the spirit of the PDP. The AC intends to make
> future proposals to deal with these other concerns. The current proposal
> addresses issues of some urgency and we did not want to delay it to
> another policy cycle as a result.

-- 
================================================
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 Nov 28 13:52:48 2012
From: owen at delong.com (Owen DeLong)
Date: Wed, 28 Nov 2012 10:52:48 -0800
Subject: [arin-ppml] Updates to 2012-6
In-Reply-To: <50B6285E.5040908@umn.edu>
References: <FE7D4327AABC0448A6281C0AC4445C7CE29CF500BE@Exchange2007.HostedMail.local>
	<50B6285E.5040908@umn.edu>
Message-ID: <A7115009-8D8A-477D-8E34-200A84C3B214@delong.com>

I would suggest that if any of the alternative approaches you suggest is desired, then the best course of action is to adopt this policy as is and submit a new policy proposal as you suggest for the next policy cycle.


Owen


On Nov 28, 2012, at 7:06 AM, David Farmer <farmer at umn.edu> wrote:

> While I support this policy as written.  I think it is important for the community to at least consider alternative approaches to this issue.
> 
> ICANN's New gTLD Program represents a significant departure from the original scope of gTLDs contemplated when the current critical infrastructure policy was originally considered and the ARIN community decided to include all TLDs (both gTLDs and ccTLDs) as critical infrastructure based solely on their location in the DNS hierarchy.
> 
> One such alternate approach could be to redefine critical infrastructure such that it is base on a objective standard of dependency by other systems and processes and not simply based on the fact that some word or string has been designated a TLD.  In other-words a TLD should only be considered critical infrastructure if it meets some threshold of dependency by other systems and processes, and not merely based on its location in the DNS hierarchy.
> 
> If a properly objective measure of dependency by other systems and processes could be found, it may also be reasonable to allow other parts of the DNS hierarchy, meeting this objective measure, to qualify as critical infrastructure as well.  Today, there are many large scale domain providers or even sufficiently critical individual domain names that are arguably as critical, or more, to the global Internet as many of the more obscure ccTLDs.  However, with the current definition being based solely on location in the DNS hierarchy, these other parts of the DNS hierarchy do not qualify as critical infrastructure in ARIN policy.
> 
> I have no doubt that some of the new gTLDs may eventually rise to an objective level of criticality that truly justifies the term critical infrastructure.  However, it seems fairly obvious that the vast majority of the several thousand gTLDs being considered will never meet such a standard and should not be considered any more critical than most other parts of the DNS hierarchy.
> 
> If the community supports this approach, I would suggest;
> 
> 1. We ask the Board to suspend gTLDs as a justification for critical infrastructure, both for IPv4 and IPv6, until the ARIN policy community has time to reconsider the definition of critical infrastructure and recommend new policy.
> 
> 1.A. Or, alternatively suspend everything other than Exchange Points as critical infrastructure for both both for IPv4 and IPv6.
> 
> 2. Then focus our policy efforts on finding an "objective measure of dependency by other systems and processes" that all TLDs, and possibly other parts of the DNS hierarchy need to meet in order to justify being considered critical infrastructure and receiving preferential access to Internet Number Resources.
> 
> Is this a preferable approach to the proposed policy below?  Also, I'd be interested in other alternate approaches members of community would like to suggest.
> 
> However, without some kind of suspension of the current policy, I support the policy as written below to go to Last Call and be implemented ASAP.  The policy below is preferable to having the proposed new gTLDs potentially consume large amounts of IPv4 address space, exhausting the reservation and essentially preventing LXPs and other current critical infrastructure from have access to IPv4 resources as intended by the reservation created in ARIN-2011-4.
> 
> Thanks.
> 
> On 11/21/12 13:21 , Bill Sandiford wrote:
>> All,
>> 
>> Since the conclusion of the Dallas PPM the AC has spent considerable
>> time working on Draft Policy 2012-6.  As a result, we have come up with
>> modified text as below.  You will note that the new policy text makes
>> minimal changes to the existing policy in the NRPM, but still obtains
>> the goals as intended by the author and expressed by the community in
>> Dallas.
>> 
>> Please provide comments.
>> 
>> Regards,
>> 
>> Bill
>> 
>> ------
>> 
>> Policy text:
>> 
>> 4.4. Micro-allocation
>> 
>> ARIN will make IPv4 micro-allocations to critical infrastructure
>> providers of the Internet, including public exchange points, core DNS
>> service providers (e.g. ICANN-sanctioned root and ccTLD operators) as
>> well as the RIRs and IANA. These allocations will be no smaller than a
>> /24. Multiple allocations may be granted in certain situations.
>> 
>> Exchange point allocations MUST be allocated from specific blocks
>> reserved only for this purpose. All other micro-allocations WILL be
>> allocated out of other blocks reserved for micro-allocation purposes.
>> 
>> ARIN will make a list of these blocks publicly available.
>> 
>> Exchange point operators must provide justification for the allocation,
>> 
>> including: connection policy, location, other participants (minimum of
>> two total), ASN, and contact information. ISPs and other organizations
>> receiving these micro-allocations will be charged under the ISP fee
>> schedule, while end-users will be charged under the fee schedule for
>> end-users. This policy does not preclude exchange point operators from
>> requesting address space under other policies.
>> 
>> ARIN will place an equivalent of a /16 of IPv4 address space in a
>> reserve for Critical Infrastructure, as defined in section 4.4. If at
>> the end of the policy term there is unused address space remaining in
>> this pool, ARIN staff is authorized to utilize this space in a manner
>> consistent with community expectations.
>> 
>> ICANN-sanctioned gTLD operators may justify up to the equivalent of an
>> 
>> IPv4 /23 block for each authorized new gTLD, allocated from the free
>> pool or received via transfer, but not from the above reservation. This
>> limit of a /23 equivalent per gTLD does not apply to gTLD allocations
>> made under previous policy.
>> 
>> Rationale:
>> 
>> Additional ICANN-sanctioned DNS infrastructure is being added to the
>> Internet and in quantities greater than anticipated when the micro
>> allocation proposal was written and adopted.
>> 
>> The original CI pool was created to serve new IXP and new CI
>> requirements. The pending need is estimated to be over 1000 new gTLD
>> range, which may exhaust the current /16 reservation before the ARIN
>> free pool is exhausted. Once the current /16 reservation is exhausted,
>> CI providers would no longer be eligible to receive address space,
>> either via the general free pool or via transfer.
>> 
>> The original proposal dealt with this by expanding the reservation to a
>> 
>> /15 and allowing CI to draw from the free pool instead of the
>> reservation until it gets down to a /8.  The consensus coming out of the
>> Dallas meeting seems to be that this is an inadequate solution. As the
>> new expanded gTLD demand will obliterate any reasonable reservation,
>> leaving no resources for the other IXP and CI demands that the original
>> reservation was intended to serve. It is therefore, not possible to
>> services them both out of a common reservation.
>> 
>> In order to ensure continued access to IPv4 number resources by new IXP
>> and DNS operators alike, the AC is modifying the proposal going into
>> last call to allow gTLD operators to continue to qualify for micro
>> allocations from the general free pool or via transfer only, and leaving
>> one /16 reserved for IXP, root, and ccTLD DNS operators.
>> 
>> As a result of the close examination of the CI policy brought about by
>> this proposal, the AC has identified a number of issues in the original
>> policy text that should be addressed. However, the AC is intentionally
>> minimizing the overall changes to this proposal as much as possible for
>> last call in keeping with the spirit of the PDP. The AC intends to make
>> future proposals to deal with these other concerns. The current proposal
>> addresses issues of some urgency and we did not want to delay it to
>> another policy cycle as a result.
> 
> -- 
> ================================================
> 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 narten at us.ibm.com  Fri Nov 30 00:53:03 2012
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 30 Nov 2012 00:53:03 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201211300553.qAU5r3gJ012695@rotala.raleigh.ibm.com>

Total of 9 messages in the last 7 days.
 
script run at: Fri Nov 30 00:53:03 EST 2012
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 22.22% |    2 | 23.88% |    21074 | owen at delong.com
 22.22% |    2 | 20.64% |    18212 | ebw at abenaki.wabanaki.net
 11.11% |    1 | 15.76% |    13912 | farmer at umn.edu
 11.11% |    1 | 15.09% |    13318 | dave at temk.in
 11.11% |    1 |  9.54% |     8419 | cgrundemann at gmail.com
 11.11% |    1 |  8.24% |     7273 | narten at us.ibm.com
 11.11% |    1 |  6.85% |     6048 | ppml at rs.seastrom.com
--------+------+--------+----------+------------------------
100.00% |    9 |100.00% |    88256 | Total