<div dir="ltr">As discussed at the mic by David Huberman, this policy will be used wrt specified transfers. <div><br></div><div>I am personally confused as to the impact of this change, and my understanding of the impact seems to be at odds with a few community members I discussed it with.</div><div> </div><div>I suspect requests fall into two buckets. </div><div><br></div><div>The first bucket is based on past growth.</div><div><br></div><div>The second bucket is based on a future looking 2 year projection for Specified transfers </div><div>(or a one year future looking projection for ARIN IP space / waiting list).</div><div><br></div><div>I suspect the 30 days part does (to some extent) regulate outrageously large claims, as this is a real short term verifiable commitment. Without a possibility of a 30 day check you simply fall back to an officer attestation of a two year projected need claim.</div><div><br></div><div>I am trying to figure out what is the likely impact of only requiring a two year projected need claim. So my questions are regarding to what level of push back ARIN provides against two year projected need in general, and will that be sufficient to prevent outlandishly large claims. </div><div><br></div><div>Maybe another way to get at this is to compare end user transfer stats to ISP transfer stats. </div><div>- what percentage of ISP specified transfers are justified by past growth? by a two year projection?</div><div>- what percentage of end user specified transfers are justified by past growth? by a two year projection?</div><div>- what is the average size of ISP specified transfers that are justified by past growth? by a two year projection?</div><div><div>- what is the average size of end user specified transfers that are justified by past growth? by a two year projection?</div></div><div>- do we see a greater gap between average ISP size between specified transfers that are justified by past growth vs. by a two year projection?</div><div>- do we see a greater percentage of ISP transfers justified by a 2 year projection than end users?</div><div><br></div><div><br></div><div>David, I hear a lot of people such as yourself, supposing that removal of the 30 day need check will not change anything else. But I believe it makes (pre-)approval for transfer solely based on the 2 year need projection, which I am concerned could be wildly optimistic. </div><br>I am not confusing it with 2015-7: Simplified requirements for demonstrated need for IPv4 transfers. I believe 2015-7 would result in two changes, 1. lowering the bar for ISP to match what end users need in 2015-3, and 2. removing any demonstration of current utilization (and by extension demonstration that you can and are properly managing the space you have) for both ISPs and end users.<div><br></div><div>I can see where there could be some confusion as I have the same concern for both proposals, that there needs to be some tangible verifiable claim. </div><div><br></div><div>I think some people are narrowly looking at the 30 day removal as a positive thing, and I agree it is a positive thing, but it is not clear to me that people are looking at what is left in the policy. What is left is the same as 2015-7 minus the lack of demonstration of current utilization. </div><div><br></div><div>To me it seemed that the community was less supportive of 2015-7 than 2015-3. When I probed after the fact (as I did not get a good sense from the conversation at the more or the questions asked) it became clear to me people had concerns about changing the needs measurement to simply a non-verifiable two year need claim in 2015-7, but felt removing the 30 day assessment was good. When I suggested to them that without the 30 day assessment, they only had to meet the non-verifiable two year need claim, they explained to me that only the 30 day assessment was being removed, and did not seem to think justification could be based solely on a 2 year projected need. </div><div><br></div><div>It seems to me if you take current end user policy and remove the 30 day assessment, you have backed yourself into only needing a non-verifiable two year need claim. Am I mistaken about this? If I am not mistaken, then I am concerned that the community may have not considered the impact of these changes. If I am mistaken, then I need a better understanding of this policy proposal.</div><div><br></div><div>__Jason</div><div><br></div><div> <br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 25, 2016 at 10:53 AM, David Farmer <span dir="ltr"><<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm worried that people are confusing policy proposals; ARIN<br>
2015-3:Remove 30 day utilization requirement in end-user IPv4 policy,<br>
simply removes the 25% immediate need (30-day) clause, it shouldn't<br>
really change anything else.<br>
<br>
On Mon, Apr 25, 2016 at 9:40 AM, Jason Schiller <<a href="mailto:jschiller@google.com">jschiller@google.com</a>> wrote:<br>
> After the topic of 2015-3 closed I was discussing the policy with some folks<br>
> and there seems to be some confusion.<br>
><br>
> If 2015-3 was current ARIN policy what would staff accept as an acceptable<br>
> justification.<br>
><br>
> It was my assumption that an ARIN ticket that said "We might have 9 million<br>
> new customers in the next two years. We would like transfer approval for a<br>
> /8. We are currently holding a /21 which we intend to keep." And an<br>
> officer of the company attests to this. Then ARIN would accept this<br>
> justification as sufficient.<br>
><br>
> Others postulated that the amount of documentation required would be<br>
> unchanged from what it previously was. For a two year transfer approval<br>
> that is not based on a doubling of the previous 1 year run rate, a requester<br>
> would still have to submit a business case supporting the two year growth<br>
> need, and the officer would have to attest to that business case. The only<br>
> difference here is that ARIN would not review the business case except that<br>
> the project count of things in two years is more that 50% of what is<br>
> requested plus what is held. This means ARIN would not review the<br>
> supporting documentation of the business case, and leave that up to the<br>
> officer of the requesting company to do. Is that correct?<br>
><br>
><br>
> Additionally, can staff provide some statistics on the following:<br>
><br>
> 1. over the last year how many end user transfer (pre-)approvals were<br>
> justified based on past growth?<br>
><br>
> 2. over the last year how many end user transfer (pre-)approvals were<br>
> justified based on<br>
> a future looking growth projection that was not based an past growth?<br>
><br>
> 3. Of the requests in type 2 above, how many were:<br>
> - Approved with no additional questions asked about the growth projection<br>
> (not including the request for attestation)?<br>
> - How many with one additional question about the growth projection?<br>
> - How many with two or more additional questions about the growth<br>
> projection?<br>
> - How many were closed with no (pre-)approval during additional questions<br>
> about the growth projection?<br>
> - How many were left unresolved for 30 days or more (or abandoned) during<br>
> additional questions about the growth projection<br>
><br>
><br>
> I realize that some or all of the stats questions may take some time to<br>
> answer. Please feel free to answer the first question about what<br>
> documentation is required to be in the ticket and attested to, and any stats<br>
> that are easily found, and follow up with the more time consuming stats<br>
> later.<br>
><br>
> Thanks,<br>
><br>
> __Jason<br>
><br>
><br>
><br>
> On Wed, Feb 17, 2016 at 1:19 PM, Jason Schiller <<a href="mailto:jschiller@google.com">jschiller@google.com</a>><br>
> wrote:<br>
>><br>
>> Just in case it wasn't clear, I oppose as written as it has no teeth and<br>
>> can easily be an end user end-run around justified need.<br>
>><br>
>> I support the change with some teeth so it is not likely to be an end-run<br>
>> around justified need.<br>
>><br>
>> __Jason<br>
>><br>
>><br>
>><br>
>> On Tue, Feb 16, 2016 at 4:52 PM, Brian Jones <<a href="mailto:bjones@vt.edu">bjones@vt.edu</a>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Tue, Feb 16, 2016 at 3:51 PM, Richard J. Letts <<a href="mailto:rjletts@uw.edu">rjletts@uw.edu</a>> wrote:<br>
>>>><br>
>>>> My preference is to apply the policy change as written (with the minor<br>
>>>> editorial change substituting "criterion" for "criteria".)<br>
>>><br>
>>><br>
>>> +1<br>
>>> --<br>
>>> Brian<br>
>>><br>
>>>><br>
>>>><br>
>>>> Thank you<br>
>>>> Richard Letts<br>
>>>><br>
>>>> > -----Original Message-----<br>
>>>> > From: <a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a> [mailto:<a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>]<br>
>>>> > On<br>
>>>> > Behalf Of David Farmer<br>
>>>> > Sent: Monday, February 15, 2016 9:23 PM<br>
>>>> > To: ARIN PPML <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>><br>
>>>> > Subject: Re: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization<br>
>>>> > Requirement in End-User IPv4 Policy<br>
>>>> ><br>
>>>> > As shepherd, I need additional feedback on this, I need a better sense<br>
>>>> > of<br>
>>>> > what the community wants here.<br>
>>>> ><br>
>>>> > Should we move forward more or less as-is, with a minor editorial<br>
>>>> > change,<br>
>>>> > substituting "criterion" for "criteria"?<br>
>>>> ><br>
>>>> > Or, does the community want to work on a way to address the concerns<br>
>>>> > raised but Jason?<br>
>>>> ><br>
>>>> > Your input please.<br>
>>>> ><br>
>>>> > Thanks<br>
>>>> ><br>
>>>> > On 1/29/16 10:00 , Jason Schiller wrote:<br>
>>>> > > McTim,<br>
>>>> > ><br>
>>>> > > WRT some other tangible and verifiable claim to show there was a<br>
>>>> > > real<br>
>>>> > > commitment to use half the address space within one year...<br>
>>>> > ><br>
>>>> > > I think there are 3 choices:<br>
>>>> > ><br>
>>>> > > 1. Very vague<br>
>>>> > ><br>
>>>> > > Something like "there must be some tangible and verifiable claim to<br>
>>>> > > show there was a real commitment to use half the address space<br>
>>>> > > within<br>
>>>> > > one year and not just a future projection or business case"<br>
>>>> > ><br>
>>>> > ><br>
>>>> > > 2. Open ended with some guidance for ARIN staff:<br>
>>>> > ><br>
>>>> > > Something like "there must be some tangible and verifiable claim to<br>
>>>> > > show there was a real commitment to use half the address space<br>
>>>> > > within<br>
>>>> > > one year and not just a future projection or business case. Some<br>
>>>> > > examples include:<br>
>>>> > > - list of equipment in hand to be numbered counting at least 25% of<br>
>>>> > > requested IP size<br>
>>>> > > - invoices showing equipment purchases demonstrating a commitment to<br>
>>>> > > buy equipment to be numbered counting at least 25% of requested IP<br>
>>>> > > size<br>
>>>> > > - invoices showing equipment purchases demonstrating a commitment to<br>
>>>> > > buy equipment to be numbered counting at least 50% of requested IP<br>
>>>> > > size within one year<br>
>>>> > > - lease agreements for real estate supporting equipment that is<br>
>>>> > > appropratly sized to support equipment to be numbered counting at<br>
>>>> > > least 50% of requested IP size<br>
>>>> > ><br>
>>>> > > 3. specific criterion<br>
>>>> > ><br>
>>>> > > ----<br>
>>>> > ><br>
>>>> > > I don't know what it the right answer here, and suspect it has more<br>
>>>> > > to<br>
>>>> > > do with what the community is comfortable with.<br>
>>>> > ><br>
>>>> > > On one end of the spectrum is choice 1. This allows ARIN to do the<br>
>>>> > > right thing. But this also is not clear about what the community<br>
>>>> > > expects, and ARIN may act in a way that is counter to what is<br>
>>>> > > anticipated, and may seem like ARIN is being arbitrary or has too<br>
>>>> > > much<br>
>>>> > > leeway to screw with requestors.<br>
>>>> > ><br>
>>>> > > The opposite end of the spectrum is choice 3. This sets a very<br>
>>>> > > clear<br>
>>>> > > list of what qualifies. Hammering out that list may be very<br>
>>>> > > difficult, and it is unlikely to be complete. This will leave<br>
>>>> > > little<br>
>>>> > > or no room for ARIN to do the right thing and approve a request that<br>
>>>> > > is justified, but not one of the criterion listed.<br>
>>>> > ><br>
>>>> > > Choice 2 is the middle ground. Where we have a not necessarily<br>
>>>> > > complete list of criterion (so somewhat less difficulty in drawing<br>
>>>> > > up<br>
>>>> > > the list) that creates a very clear expectation of what ARIN should<br>
>>>> > > accept (and reduces the possibility that ARIN may act in a way that<br>
>>>> > > is<br>
>>>> > > counter to what is anticipated, and may seem like ARIN is being<br>
>>>> > > arbitrary or has too much leeway to screw with requestors) with<br>
>>>> > > respect to criterion clearly defined, while also allowing ARIN to do<br>
>>>> > > the right thing with similar types of proof that are not explicitly<br>
>>>> > > listed as criterion (this has somewhat higher risk that ARIN may act<br>
>>>> > > in a way that is counter to what is anticipated, and may seem like<br>
>>>> > > ARIN is being arbitrary or has too much leeway to screw with<br>
>>>> > > requestors, but less risk than option 1 as the criterion should<br>
>>>> > > serve<br>
>>>> > > as good guidance)<br>
>>>> > ><br>
>>>> > ><br>
>>>> > > So two open questions to the community?<br>
>>>> > ><br>
>>>> > > 1. Is the community most comfortable with:<br>
>>>> > > A. totally vague and open-ended such as "there must be some<br>
>>>> > > tangible and verifiable claim to show there was a real commitment<br>
>>>> > > to<br>
>>>> > > use half the address space within one year and not just a future<br>
>>>> > > projection or business case"<br>
>>>> > ><br>
>>>> > > B. A vague statement with some guidance as to some acceptable<br>
>>>> > > forms of tangible verifiable proof of a real commitment to use half<br>
>>>> > > the IP address within one year.<br>
>>>> > ><br>
>>>> > > C. A very clear list of what proof is considered acceptable<br>
>>>> > ><br>
>>>> > ><br>
>>>> > > 2. If the community prefers B. guidance or C. a very clear list then<br>
>>>> > > what sort of things would the community like to see on that list?<br>
>>>> > ><br>
>>>> > ><br>
>>>> > > On Fri, Jan 29, 2016 at 8:27 AM, McTim <<a href="mailto:dogwallah@gmail.com">dogwallah@gmail.com</a><br>
>>>> > > <mailto:<a href="mailto:dogwallah@gmail.com">dogwallah@gmail.com</a>>> wrote:<br>
>>>> > ><br>
>>>> > ><br>
>>>> > ><br>
>>>> > > On Thu, Jan 28, 2016 at 4:52 PM, Jason Schiller<br>
>>>> > > <<a href="mailto:jschiller@google.com">jschiller@google.com</a> <mailto:<a href="mailto:jschiller@google.com">jschiller@google.com</a>>> wrote:<br>
>>>> > ><br>
>>>> > > I support the removal of the 30 day utilization as it is<br>
>>>> > > unreasonable for any larger end-site, who may have a real<br>
>>>> > > need<br>
>>>> > > for say a /16, with 65,000 desktops arriving on a loading<br>
>>>> > > doc<br>
>>>> > > next week, but an inability to unbox, configure and deploy<br>
>>>> > > 16,384 to the various office locations in 30 days.<br>
>>>> > ><br>
>>>> > ><br>
>>>> > > agreed.<br>
>>>> > ><br>
>>>> > > However, this is the only provision that has a real,<br>
>>>> > > tangible,<br>
>>>> > > and verifiable claim. Without this check justified need for<br>
>>>> > > end<br>
>>>> > > users simply becomes a 1 year future looking projection, and<br>
>>>> > > with sufficient arm waving an easy end run around justified<br>
>>>> > > need<br>
>>>> > > for any end user with no IP space or if they are efficiently<br>
>>>> > > using what they currently hold.<br>
>>>> > ><br>
>>>> > ><br>
>>>> > > good point!<br>
>>>> > ><br>
>>>> > > I could get on board if the maximum sized block permitted on<br>
>>>> > > a<br>
>>>> > > purely future looking projection was a /24 and you had to<br>
>>>> > > use it<br>
>>>> > > prior to getting more.<br>
>>>> > ><br>
>>>> > ><br>
>>>> > > +1<br>
>>>> > ><br>
>>>> > > I could certainly get on board if there were some other<br>
>>>> > > tangible<br>
>>>> > > and verifiable claim to show there was a real commitment to<br>
>>>> > > use<br>
>>>> > > half the address space within one year.<br>
>>>> > ><br>
>>>> > ><br>
>>>> > > Would this language suffice, or would we need a metric of some<br>
>>>> > > sort?<br>
>>>> > ><br>
>>>> > ><br>
>>>> > > Regards,<br>
>>>> > ><br>
>>>> > > McTim<br>
>>>> > ><br>
>>>> > > __Jason<br>
>>>> > ><br>
>>>> > > On Thu, Jan 28, 2016 at 8:55 AM, Brian Jones <<a href="mailto:bjones@vt.edu">bjones@vt.edu</a><br>
>>>> > > <mailto:<a href="mailto:bjones@vt.edu">bjones@vt.edu</a>>> wrote:<br>
>>>> > ><br>
>>>> > > Looks good to me Dave. I am okay with using criteria or<br>
>>>> > > criterion, however using the strict definition it looks<br>
>>>> > > as<br>
>>>> > > though criterion is the proper singular form.<br>
>>>> > ><br>
>>>> > > --<br>
>>>> > > Brian<br>
>>>> > ><br>
>>>> > > On Wed, Jan 27, 2016 at 5:54 PM, David Farmer<br>
>>>> > > <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a> <mailto:<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>>> wrote:<br>
>>>> > ><br>
>>>> > > The following is the proposed update for<br>
>>>> > > ARIN-2015-3:<br>
>>>> > > Remove 30-Day Utilization Requirement in End-User<br>
>>>> > > IPv4<br>
>>>> > > Policy based on strong support in Montreal.<br>
>>>> > ><br>
>>>> > > Beyond deleting the 25% bullet as the policy says,<br>
>>>> > > their<br>
>>>> > > are editorial changes as follows to the remaining<br>
>>>> > > text;<br>
>>>> > ><br>
>>>> > > - It looks weird to have single item bullet list, so<br>
>>>> > > merge the two remaining sentence fragments into a<br>
>>>> > > single<br>
>>>> > > sentence.<br>
>>>> > > - Change "are" to "is", since there is only one<br>
>>>> > > remaining criteria<br>
>>>> > > - Use of "criteria" as a singular is common usage,<br>
>>>> > > even<br>
>>>> > > though technically it's plural.<br>
>>>> > > - Resulting in "The basic criteria that must be met<br>
>>>> > > is a<br>
>>>> > > 50% utilization rate within one year."<br>
>>>> > ><br>
>>>> > > The remaining and resulting text for 4.3.3 is now<br>
>>>> > > included in the policy text, for editorial clarity.<br>
>>>> > > The<br>
>>>> > > original staff and legal suggested removing the<br>
>>>> > > RFC2050<br>
>>>> > > reference and also pointed out that<br>
>>>> > > 4.2.3.6 also has a 25% immediate use clause and a<br>
>>>> > > RFC2050 reference.<br>
>>>> > ><br>
>>>> > > Feedback in Montreal was that deleting the 25%<br>
>>>> > > immediate<br>
>>>> > > use was a nice bite-sized change, and we shouldn't<br>
>>>> > > try<br>
>>>> > > to do more than that with this change, so those<br>
>>>> > > changes<br>
>>>> > > are not included at this time.<br>
>>>> > ><br>
>>>> > > Any additional feedback or comments are appreciated.<br>
>>>> > ><br>
>>>> > > Thanks<br>
>>>> > ><br>
>>>> > > ---------<br>
>>>> > ><br>
>>>> > > Draft Policy ARIN-2015-3: Remove 30 day utilization<br>
>>>> > > requirement in end-user IPv4 policy<br>
>>>> > ><br>
>>>> > > Date: 27 January 2015<br>
>>>> > ><br>
>>>> > > Problem Statement:<br>
>>>> > ><br>
>>>> > > End-user policy is intended to provide end-users<br>
>>>> > > with a<br>
>>>> > > one year supply of IP addresses. Qualification for a<br>
>>>> > > one-year supply requires the network operator to<br>
>>>> > > utilize<br>
>>>> > > at least 25% of the requested addresses within 30<br>
>>>> > > days.<br>
>>>> > > This text is unrealistic and should be removed.<br>
>>>> > ><br>
>>>> > > First, it often takes longer than 30 days to stage<br>
>>>> > > equipment and start actually using the addresses.<br>
>>>> > ><br>
>>>> > > Second, growth is often not that regimented; the<br>
>>>> > > forecast is to use X addresses over the course of a<br>
>>>> > > year, not to use 25% of X within 30 days.<br>
>>>> > ><br>
>>>> > > Third, this policy text applies to additional<br>
>>>> > > address<br>
>>>> > > space requests. It is incompatible with the<br>
>>>> > > requirements<br>
>>>> > > of other additional address space request<br>
>>>> > > justification<br>
>>>> > > which indicates that 80% utilization of existing<br>
>>>> > > space<br>
>>>> > > is sufficient to justify new space. If a block is at<br>
>>>> > > 80%, then often (almost always?) the remaining 80%<br>
>>>> > > will<br>
>>>> > > be used over the next 30 days and longer. Therefore<br>
>>>> > > the<br>
>>>> > > operator cannot honestly state they will use 25% of<br>
>>>> > > the<br>
>>>> > > ADDITIONAL space within 30 days of receiving it;<br>
>>>> > > they're<br>
>>>> > > still trying to use their older block efficiently.<br>
>>>> > ><br>
>>>> > > Fourth, in the face of ARIN exhaustion, some ISPs<br>
>>>> > > are<br>
>>>> > > starting to not give out /24 (or larger) blocks. So<br>
>>>> > > the<br>
>>>> > > justification for the 25% rule that previously<br>
>>>> > > existed<br>
>>>> > > (and in fact, applied for many years) is no longer<br>
>>>> > > germane.<br>
>>>> > ><br>
>>>> > > Policy statement:<br>
>>>> > ><br>
>>>> > > Remove the 25% utilization criteria bullet point<br>
>>>> > > from<br>
>>>> > > NRPM 4.3.3.<br>
>>>> > ><br>
>>>> > > Resulting text:<br>
>>>> > ><br>
>>>> > > 4.3.3. Utilization rate<br>
>>>> > ><br>
>>>> > > Utilization rate of address space is a key factor in<br>
>>>> > > justifying a new<br>
>>>> > > assignment of IP address space. Requesters must show<br>
>>>> > > exactly how<br>
>>>> > > previous address assignments have been utilized and<br>
>>>> > > must<br>
>>>> > > provide<br>
>>>> > > appropriate details to verify their one-year growth<br>
>>>> > > projection.<br>
>>>> > ><br>
>>>> > > The basic criteria that must be met is a 50%<br>
>>>> > > utilization<br>
>>>> > > rate within one year.<br>
>>>> > ><br>
>>>> > > A greater utilization rate may be required based on<br>
>>>> > > individual network<br>
>>>> > > requirements. Please refer to RFC 2050 for more<br>
>>>> > > information on<br>
>>>> > > utilization guidelines.<br>
>>>> > ><br>
>>>> > > Comments:<br>
>>>> > > a.Timetable for implementation: Immediate<br>
>>>> > > b.Anything else<br>
>>>> > ><br>
>>>> > > --<br>
>>>> > > ================================================<br>
>>>> > > David Farmer Email: <a href="mailto:farmer@umn.edu">farmer@umn.edu</a><br>
>>>> > > <mailto:<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>><br>
>>>> > > Office of Information Technology<br>
>>>> > > University of Minnesota<br>
>>>> > > 2218 University Ave SE Phone: <a href="tel:1-612-626-0815" value="+16126260815">1-612-626-0815</a><br>
>>>> > > <tel:<a href="tel:1-612-626-0815" value="+16126260815">1-612-626-0815</a>><br>
>>>> > > Minneapolis, MN 55414-3029 Cell: <a href="tel:1-612-812-9952" value="+16128129952">1-612-812-9952</a><br>
>>>> > > <tel:<a href="tel:1-612-812-9952" value="+16128129952">1-612-812-9952</a>><br>
>>>> > > ================================================<br>
>>>> > > _______________________________________________<br>
>>>> > > PPML<br>
>>>> > > You are receiving this message because you are<br>
>>>> > > subscribed to<br>
>>>> > > the ARIN Public Policy Mailing List<br>
>>>> > > (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a><br>
>>>> > > <mailto:<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>>).<br>
>>>> > > Unsubscribe or manage your mailing list subscription<br>
>>>> > > at:<br>
>>>> > > <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>>>> > > Please contact <a href="mailto:info@arin.net">info@arin.net</a> <mailto:<a href="mailto:info@arin.net">info@arin.net</a>><br>
>>>> > > if<br>
>>>> > > you experience any issues.<br>
>>>> > ><br>
>>>> > ><br>
>>>> > ><br>
>>>> > > _______________________________________________<br>
>>>> > > PPML<br>
>>>> > > You are receiving this message because you are<br>
>>>> > > subscribed to<br>
>>>> > > the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a><br>
>>>> > > <mailto:<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>>).<br>
>>>> > > Unsubscribe or manage your mailing list subscription at:<br>
>>>> > > <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>>>> > > Please contact <a href="mailto:info@arin.net">info@arin.net</a> <mailto:<a href="mailto:info@arin.net">info@arin.net</a>> if<br>
>>>> > > you<br>
>>>> > > experience any issues.<br>
>>>> > ><br>
>>>> > ><br>
>>>> > ><br>
>>>> > ><br>
>>>> > > --<br>
>>>> > ><br>
>>>> > _______________________________________________________<br>
>>>> > > Jason Schiller|NetOps|<a href="mailto:jschiller@google.com">jschiller@google.com</a><br>
>>>> > > <mailto:<a href="mailto:jschiller@google.com">jschiller@google.com</a>>|<a href="tel:571-266-0006" value="+15712660006">571-266-0006</a><br>
>>>> > > <tel:<a href="tel:571-266-0006" value="+15712660006">571-266-0006</a>><br>
>>>> > ><br>
>>>> > ><br>
>>>> > > _______________________________________________<br>
>>>> > > PPML<br>
>>>> > > You are receiving this message because you are subscribed to<br>
>>>> > > the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a><br>
>>>> > > <mailto:<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>>).<br>
>>>> > > Unsubscribe or manage your mailing list subscription at:<br>
>>>> > > <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>>>> > > Please contact <a href="mailto:info@arin.net">info@arin.net</a> <mailto:<a href="mailto:info@arin.net">info@arin.net</a>> if you<br>
>>>> > > experience any issues.<br>
>>>> > ><br>
>>>> > ><br>
>>>> > ><br>
>>>> > ><br>
>>>> > > --<br>
>>>> > > Cheers,<br>
>>>> > ><br>
>>>> > > McTim<br>
>>>> > > "A name indicates what we seek. An address indicates where it<br>
>>>> > > is. A<br>
>>>> > > route indicates how we get there." Jon Postel<br>
>>>> > ><br>
>>>> > ><br>
>>>> > ><br>
>>>> > ><br>
>>>> > > --<br>
>>>> > > _______________________________________________________<br>
>>>> > > Jason Schiller|NetOps|<a href="mailto:jschiller@google.com">jschiller@google.com</a><br>
>>>> > > <mailto:<a href="mailto:jschiller@google.com">jschiller@google.com</a>>|<a href="tel:571-266-0006" value="+15712660006">571-266-0006</a><br>
>>>> > ><br>
>>>> > ><br>
>>>> > ><br>
>>>> > > _______________________________________________<br>
>>>> > > PPML<br>
>>>> > > You are receiving this message because you are subscribed to the<br>
>>>> > > ARIN<br>
>>>> > > Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
>>>> > > Unsubscribe or manage your mailing list subscription at:<br>
>>>> > > <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>>>> > > Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
>>>> > ><br>
>>>> ><br>
>>>> ><br>
>>>> > --<br>
>>>> > ================================================<br>
>>>> > David Farmer Email: <a href="mailto:farmer@umn.edu">farmer@umn.edu</a><br>
>>>> > Office of Information Technology<br>
>>>> > University of Minnesota<br>
>>>> > 2218 University Ave SE Phone: <a href="tel:1-612-626-0815" value="+16126260815">1-612-626-0815</a><br>
>>>> > Minneapolis, MN 55414-3029 Cell: <a href="tel:1-612-812-9952" value="+16128129952">1-612-812-9952</a><br>
>>>> > ================================================<br>
>>>> > _______________________________________________<br>
>>>> > PPML<br>
>>>> > You are receiving this message because you are subscribed to the ARIN<br>
>>>> > Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
>>>> > Unsubscribe or manage your mailing list subscription at:<br>
>>>> > <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>>>> > Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
>>>> _______________________________________________<br>
>>>> PPML<br>
>>>> You are receiving this message because you are subscribed to<br>
>>>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
>>>> Unsubscribe or manage your mailing list subscription at:<br>
>>>> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>>>> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> PPML<br>
>>> You are receiving this message because you are subscribed to<br>
>>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
>>> Unsubscribe or manage your mailing list subscription at:<br>
>>> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>>> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> _______________________________________________________<br>
>> Jason Schiller|NetOps|<a href="mailto:jschiller@google.com">jschiller@google.com</a>|<a href="tel:571-266-0006" value="+15712660006">571-266-0006</a><br>
>><br>
><br>
><br>
<span class="HOEnZb"><font color="#888888">><br>
> --<br>
> _______________________________________________________<br>
> Jason Schiller|NetOps|<a href="mailto:jschiller@google.com">jschiller@google.com</a>|<a href="tel:571-266-0006" value="+15712660006">571-266-0006</a><br>
><br>
><br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
<br>
<br>
<br>
--<br>
===============================================<br>
David Farmer <a href="mailto:Email%3Afarmer@umn.edu">Email:farmer@umn.edu</a><br>
Networking & Telecommunication Services<br>
Office of Information Technology<br>
University of Minnesota<br>
2218 University Ave SE Phone: <a href="tel:612-626-0815" value="+16126260815">612-626-0815</a><br>
Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>
===============================================<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>