<div dir="ltr">Mike, <div><br></div><div>I appreciate you providing a clear argument. You are saying that the whole concept of limiting access to the waiting list based on total holdings in 2019-16 is unfair. While I'm not sure I agree, I think this is a valid question for the community to discuss.</div><div><br></div><div>However, many others seem to be claiming that there are fairness issues with how 2019-16 implemented, but not with the policy itself, in my mind I don't see how that argument holds water.<br></div><div><br></div><div>Thanks</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 20, 2020 at 10:34 AM Mike Burns <<a href="mailto:mike@iptrading.com" target="_blank">mike@iptrading.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><p class="MsoNormal">Hi David,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">What was not arbitrary was the choice to impose any limit whatsoever on the amount of holdings an organization can  have while retaining access to the free pool via the waiting list.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">That was a shining line crossed, no matter the (acknowledged) arbitrariness of the size selected.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">As a community we should have been able to discuss the radical step away from treating all organizations equally when it comes to free pool access. I can remember discussions in the past which included large companies jealous of their rights in the context of making transfers needs-free below a certain size.  They argued, convincingly I thought, that continuing to impose the needs-test on large blocks while exempting small blocks was an impermissible relegation of our community members into different classes.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Would it be permissible if the community decided that organizations with a market cap over $100 million are not allowed to purchase IPv4 blocks?<u></u><u></u></p><p class="MsoNormal">By the logic employed in the holdings-cap on waiting-list access, I don’t see any reason why it wouldn’t be permissible.<u></u><u></u></p><p class="MsoNormal">We are deciding that small holders should get access and large holders should not get access to the free pool, what is the difference between the free pool and the transfer pool?  Shouldn’t the same reasons we advance small holders obtain?<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Other RIRs decided that new entrants should stand in line before existing organizations, based on the logic that it was the older organizations who are more responsible for creating the scarcity environment, and many received their addresses before they had to pay for them, so in recognition of the comparably greater hardship faced by new entrants, the proper treatment was to prefer new entrants.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Some in this community may feel that way, or they may have other reasons to prefer smaller companies over larger companies.  We should have had a discussion and a vote on this singular issue instead of crossing this line the way it was crossed, in the Advisory Council deliberations.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I do understand that large holders pay more fees, that is not an issue for me, it’s the denial of access to certain pools that bothers me.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">What troubles me is the concept that holders below /18 are “innocent” and those over, by inference, are less so. The cap was implemented in the wake of a particular fraud on the waiting list that was not a function of the size of the fraudster’s holdings but fraud on the justification attestations.  I am not clear on how the cap on holdings was meant to address that particular fraud.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I do support the policy as a step forward but I think there should be no cap on holdings because then access to the free pool is no longer impartial.<u></u><u></u></p><p class="MsoNormal">It’s partial to small holders.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Regards,<br>Mike<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><b>From:</b> ARIN-PPML <<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a>> <b>On Behalf Of </b>David Farmer via ARIN-PPML<br><b>Sent:</b> Monday, July 20, 2020 10:29 AM<br><b>To:</b> Tom Pruitt <<a href="mailto:tpruitt@stratusnet.com" target="_blank">tpruitt@stratusnet.com</a>><br><b>Cc:</b> <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br><b>Subject:</b> Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of OrganizIt reaations Removed from Waitlist by Implementation of ARIN-2019-16<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal" style="margin-bottom:12pt">I have to disagree, the implementation of 2019-16 was fair and impartial. There was a general criterion that was applied, it wasn't overly specific, such that it only targeted a single or small group of specific organizations. Yes, the selection of /20 was mostly arbitrary, but any number picked would have been mostly arbitrary. The /18 that this policy proposes is mostly arbitrary as well. The specific numbers are a judgment call, both in 2019-16 and this policy. Nevertheless, innocent organizations were impacted by the implementation of 2019-16, and that is regrettable, unfortunate, and frankly, it sucks, but that doesn't me it was unfair. <u></u><u></u></p><div><p class="MsoNormal" style="margin-bottom:12pt">Further, the alternative implementation, that you propose would have been unfair because the organizations with a /20 or less of total holdings, but requesting more than a /22, would qualify under the policy in 2019-16 if they simply reduced their request. Therefore, requiring them to be removed from the waiting list and to reapply would have been unnecessarily bureaucratic and petty, with the only effect being that they lost their place on the waiting list. Allowing these entities to reduce their request seems an eminently fair way do deal with that situation.<u></u><u></u></p></div><div><p class="MsoNormal">Personally, I like and support the concept of mitigating at least some of the impact on innocent organizations by allowing those with up to and including a /18 of total holdings back on the list for up to a /22. I'll note that this specific idea didn't come up during the discussions leading up to 2019-16 or immediately following the implementation of it.  However, while I support mitigating the effects of 2019-16 on several innocent organizations, I most strenuously object to referring to the implementation of 2019-16 as unfair. The implementation of 2019-16 was both fair and impartial, even though the impact on some organizations was undesirable, it was nevertheless fair.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thanks.<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Fri, Jul 17, 2020 at 3:34 PM Tom Pruitt <<a href="mailto:tpruitt@stratusnet.com" target="_blank">tpruitt@stratusnet.com</a>> wrote:<u></u><u></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt"><p class="MsoNormal">The organizations this draft policy would affect  had qualified for space before 2019-16 (limiting space to a /20 and limiting a max request to a /22) was implemented.  The implementation of the policy removed the organizations that had over a /20, but allowed organizations with less than that who wanted more than a /22 to adjust their request and remain on the list.  If all organizations who didn't fit the new criteria  with their existing requests were removed then it would have been applied fairly and equal, but that isn't what happened.<br><br>This proposal actually equalizes the implementation of 2019-16.<br><br><br>Yes the problem is the lack of IPv6 deployment, I don't think anyone can argue that.<br><br>Thanks,<br>Tom Pruitt <br>Network Engineer<br>Stratus Networks<br><br>This e-mail, and any files transmitted with it are the property of Stratus Networks, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 309-408-8704 and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited<br><br>-----Original Message-----<br>From: ARIN-PPML <<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a>> On Behalf Of Fernando Frediani<br>Sent: Friday, July 17, 2020 11:01 AM<br>To: <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of Organizations Removed from Waitlist by Implementation of ARIN-2019-16<br><br>What is the justification to give organization who already have some reasonable space to work with, more space in current times ?<br><br>Everybody is suffering from the same problem of IPv4 scarcity and that affects all equally. If we have already a policy that limits on /20 it is for a reason, a fair reason by the way. So why are we going to bend it in this case in the other direction ?<br>I see this type of proposal privileging just a few rather than been equalized to all others.<br><br>Therefore I keep opposed to it.<br><br>Fernando<br><br>On 17/07/2020 12:24, Steven Ryerse via ARIN-PPML wrote:<br>> +1<br>><br>><br>> Steven Ryerse<br>> President<br>><br>> <a href="mailto:sryerse@eclipse-networks.com" target="_blank">sryerse@eclipse-networks.com</a> | C: 770.656.1460<br>> 100 Ashford Center North | Suite 110 | Atlanta, Georgia 30338<br>><br>>        <br>><br>><br>><br>> -----Original Message-----<br>> From: ARIN-PPML <<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a>> On Behalf Of Mike Burns<br>> Sent: Friday, July 17, 2020 10:59 AM<br>> To: <a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a>; <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>> Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of <br>> Organizations Removed from Waitlist by Implementation of ARIN-2019-16<br>><br>> I support the policy as written and I do not believe we should prioritize small holders over large holders.<br>> Large holders pay higher fees but I don't see the rationale behind favoring small  holders on the wait list.<br>> All holders should be on equal footing, we never had a new-entrant reserve at ARIN and I think if that is something we want to do, it should be discussed openly and not inserted through the back door of waitlist policy.<br>><br>> Regards,<br>> Mike<br>><br>><br>><br>> -----Original Message-----<br>> From: ARIN-PPML <<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a>> On Behalf Of <br>> <a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a><br>> Sent: Thursday, July 16, 2020 7:59 AM<br>> To: <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>> Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of <br>> Organizations Removed from Waitlist by Implementation of ARIN-2019-16<br>><br>> I am also against this proposal.<br>><br>> If we allow holders of larger blocks back onto the list, we take away blocks that should go to smaller holders.<br>><br>> The waiting list is NOT a lottery to be "won", and I think the policy should not change.<br>><br>> Albert Erdmann<br>> Network Administrator<br>> Paradise On Line Inc.<br>><br>><br>> On Wed, 15 Jul 2020, Andrew Dul wrote:<br>><br>>> I do not support the reintroduction of organizations onto the <br>>> wait-list who were removed due to having existing address holdings <br>>> larger than a /20.  Being on the wait-list was never a guarantee that <br>>> you would receive space.  The AC had to balance the various elements <br>>> of<br>> block size and organizations who would be eligible to receive space under the updated policy and we were aware that the rules as implemented would prevent some organizations on the wait-list from receiving blocks going forward.<br>>> Speaking only for myself, not the AC<br>>><br>>> Andrew<br>>><br>>> On 6/19/2020 11:25 AM, Alyssa Moore wrote:<br>>>        Hi folks,<br>>><br>>>        There was some great discussion of this policy proposal at ARIN45.<br>> We hear a wide range of views including:<br>>>         1. Don't grandfather organizations. The new waitlist policy <br>>> is<br>> sound.<br>>>         2. Organizations that were on the waitlist before 2019-16 <br>>> should be<br>> eligible for their original request size (even if it exceeds the new <br>> limit<br>>>            of a /22).<br>>>         3. Organizations that were on the waitlist before 2019-16 <br>>> should<br>> remain eligible if their holdings exceed a /20 OR a /18. The draft <br>> policy<br>>>            under discussion specifies a /18 total holdings for<br>> grandfathered orgs, while the current waitlist policy (2019-16) specifies a /20.<br>>>         4. Organizations that were on the waitlist before 2019-16 <br>>> should be<br>> eligible regardless of their total holdings because that was not a<br>>>            restriction of the policy under which they originally <br>>> qualified<br>> for the waitlist.<br>>>         There was general support to continue finessing this draft. <br>>> If you<br>> have views on the above noted parameters, please make them known here.<br>>> For reference:<br>>><br>>> Old waitlist policy<br>>>   1. Requester specifies smallest block they'd be willing to accept, <br>>> equal<br>> to or larger than the applicable minimum size specified elsewhere in <br>> ARIN<br>>>      policy.<br>>>   2. Did not place a limit on the total existing IP address holdings <br>>> of a<br>> party eligible for the waitlist.<br>>>   3. Made resources issued from the waitlist ineligible for transfer <br>>> until after a period of 12 months. New Waitlist Policy  1. Limits the <br>>> size of block ARIN can issue on the waitlist to a /22.<br>>>   2. Places a limit on the total existing IP address holdings of a <br>>> party<br>> eligible for the waitlist at a /20 or less.<br>>>   3. Makes resources issued from the waitlist ineligible for transfer <br>>> until after a period of 60 months.<br>>><br>>> Best,<br>>> Alyssa<br>>><br>>> On Thu, Mar 26, 2020 at 3:35 PM David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:<br>>>        I support this policy and believe the policy development <br>>> process is<br>> the proper place to handle this issue. However, this policy seems to<br>>>        be implementable as a one-time policy directive to ARIN Staff.<br>>> Once<br>> implemented, by putting the effected organizations back on the waiting<br>>>        list, it seems unnecessary to memorialized the text in the <br>>> NRPM, it<br>> would immediately become extraneous and potentially confusing to<br>>>        future readers of the NRPM.<br>>> Therefore, I would like to recommend the Policy Statement not be <br>>> added to the NRPM upon its implementation. I believe this to be <br>>> consistent with<br>> the intent of the policy.  Otherwise, does ARIN Staff have procedural advice on how best to handle what seems like a one-time directive?<br>>> Thanks<br>>><br>>> On Tue, Mar 24, 2020 at 12:21 PM ARIN <<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>> wrote:<br>>><br>>>        Draft Policy ARIN-2020-2: Grandfathering of Organizations <br>>> Removed<br>> from<br>>>        Waitlist by Implementation of ARIN-2019-16<br>>><br>>>        Problem Statement:<br>>><br>>>        The implementation of the ARIN-2019-16 Advisory Council<br>> Recommendation<br>>>        Regarding NRPM 4.1.8: Unmet Requests caused some organizations to be<br>>>        removed from the waiting list that were approved under the old<br>> policy?s<br>>>        eligibility criteria. These organizations should have been<br>> grandfathered<br>>>        when the waitlist was reopened to allow them to receive an<br>> allocation of<br>>>        IPv4 up to the new policy?s maximum size constraint of a /22.<br>>><br>>>        Policy Statement: Update NRPM Section 4.1.8 as follows:<br>>><br>>>        Add section 4.1.8.3 (temporary language in the NRPM to remain <br>>> until<br>> the<br>>>        policy objective is achieved)<br>>><br>>>        Restoring organizations to the waitlist<br>>><br>>>        ARIN will restore organizations that were removed from the <br>>> waitlist<br>> at<br>>>        the adoption of ARIN-2019-16 to their previous position if <br>>> their<br>> total<br>>>        holdings of IPv4 address space amounts to a /18 or less. The maximum<br>>>        size aggregate that a reinstated organization may qualify for <br>>> is a<br>> /22.<br>>>        All restored organizations extend their 2 year approval by <br>>> [number<br>> of<br>>>        months between July 2019 and implementation of new policy]. <br>>> Any<br>> requests<br>>>        met through a transfer will be considered fulfilled and <br>>> removed from<br>> the<br>>>        waiting list.<br>>><br>>>        Comments:<br>>><br>>>        Timetable for implementation: Immediate<br>>><br>>>        Anything Else: While attending ARIN 44 and discussing this <br>>> with<br>> other<br>>>        community members the vast majority indicated that they agreed <br>>> that<br>> some<br>>>        organizations were treated unfairly. This proposal is a remedy.<br>>>        _______________________________________________<br>>>        ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>>>        Unsubscribe or manage your mailing list subscription at:<br>>>        <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&c=E,1,itejYWK1neA4HwQI2654uD6T84LDr-jtyvegBUSRLaqI3i7cGDsXGSLO9kZFAeEqibHLpNp9IQUPINbrQtts-4t2a9DQNRIijWuYbVTpZdvZJI2YmIU7zQMg&typo=1" target="_blank">https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&c=E,1,itejYWK1neA4HwQI2654uD6T84LDr-jtyvegBUSRLaqI3i7cGDsXGSLO9kZFAeEqibHLpNp9IQUPINbrQtts-4t2a9DQNRIijWuYbVTpZdvZJI2YmIU7zQMg&typo=1</a><br>>>        Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>>><br>>><br>>><br>>> --<br>>> ===============================================<br>>> David Farmer               <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a> Networking & <br>>> Telecommunication Services Office of Information Technology <br>>> University of Minnesota<br>>> 2218 University Ave SE        Phone: 612-626-0815 Minneapolis, MN<br>>> 55414-3029   Cell: 612-812-9952<br>>> ===============================================<br>>> _______________________________________________<br>>> ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>>> Unsubscribe or manage your mailing list subscription at:<br>>> <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2f" target="_blank">https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2f</a><br>>> m <br>>> ailman%2flistinfo%2farin-ppml&c=E,1,pr8_yOATR6fbNAoiwPjuIuQtJCW1Nm7ql<br>>> k <br>>> KG7uppvzhqUtK33qz6GCTJCwHGGeKePdcEaJZZdUUw-RTujqMB1FJ2DG6HTd2r6GM5s4H<br>>> y<br>>> nLV4b0vI3AnQPQ,,&typo=1 Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you <br>>> experience any issues.<br>>><br>>><br>>> _______________________________________________<br>>> ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>>> Unsubscribe or manage your mailing list subscription at:<br>>> <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2f" target="_blank">https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2f</a><br>>> m <br>>> ailman%2flistinfo%2farin-ppml&c=E,1,RsBXYYW2wGypb0Y4GbeHTbKFC2827Z3js<br>>> p <br>>> at1aezQl0yTqcY6d2pTdFdOAraqUCnPZ-okcO1-ObFc2thTsKxGhJ1eTCN_Cv8UpPoW80<br>>> d<br>>> 6gOeCMy96nbc8z4g0yY0&typo=1 Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you <br>>> experience any issues.<br>>><br>>><br>>><br>> _______________________________________________<br>> ARIN-PPML<br>> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>> Unsubscribe or manage your mailing list subscription at:<br>> <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fm" target="_blank">https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fm</a><br>> ailman%2flistinfo%2farin-ppml&c=E,1,PZT3k6xZlfRBghEBxxufd4mu2Ve_KsVjNF<br>> Fbz6LOCh9lpSIRtyNyDCvryXvevPimoqYvm4gDqykjaXQTjrj8V6QM-AY3-lYKC-1oXXBA<br>> -awSsCEN&typo=1 Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any <br>> issues.<br>> _______________________________________________<br>> ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>> Unsubscribe or manage your mailing list subscription at:<br>> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>_______________________________________________<br>ARIN-PPML<br>You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>Unsubscribe or manage your mailing list subscription at:<br><a href="https://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>_______________________________________________<br>ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>Unsubscribe or manage your mailing list subscription at:<br><a href="https://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<u></u><u></u></p></blockquote></div><p class="MsoNormal"><br clear="all"><u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">-- <u></u><u></u></p><div><p class="MsoNormal">===============================================<br>David Farmer               <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota   <br>2218 University Ave SE        Phone: 612-626-0815<br>Minneapolis, MN 55414-3029   Cell: 612-812-9952<br>=============================================== <u></u><u></u></p></div></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">===============================================<br>David Farmer               <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota   <br>2218 University Ave SE        Phone: 612-626-0815<br>Minneapolis, MN 55414-3029   Cell: 612-812-9952<br>=============================================== </div>