<div dir="ltr">David,<div><br></div><div>I want to apologize for the scenario I proposed. After reading Leslie's comments, and looking back at my text, I realize taking it without the context of your previous email is says something quite different. (And I'm sure it seems like I am trying to intentionally twist your words, which I was not).</div><div><br></div><div>What I was trying to say, in the most boiled down and generic way is as long as ARIN doesn't automatically see a new region that pops up as a news MDN, when the is some applicable growth history of more than 1 year to be applied. </div><div><br></div><div>I think splitting is the easiest case to think about (per staff comments this seems not to be a problem), but I think there may be others.</div><div><br></div><div>Possibly as an example, a company is deploying fiber to residences. They in are 12 markets, each is an MDN for routing reasons, regional Peering, and differences of growth. They entered Washington DC last year, and efficiently used a /16. They are now entering Boston. Boston has nearly the same size (actually slightly smaller) and a similar population (slightly more dense). They have the same commitment to build in Boston as they did in DC, and will pass the same number of residences on the same time line. Can they have a /18? </div><div>Certainly a company that has deployed fiber to residents in 12 markets now declaring an MDN for their cloud offering would not have an applicable growth history to apply and that should be considered a new MDN.</div><div><br></div><div>__Jason</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 11, 2014 at 10:56 AM, David Huberman <span dir="ltr"><<a href="mailto:David.Huberman@microsoft.com" target="_blank">David.Huberman@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
Jason,<br>
<br>
That's not what I said :-) I addressed what I thought you were presenting - a special case where a network takes one discrete site and splits it.<br>
<br>
In the regular case, described in your email just now, the new site is new. Slow start applies, minus any immediate need justification. It should get whatever prefix between a /24 and a /20 meets the three month need. It has no customers (or it does and
immediate need applies) so why should it get more?<br>
<br>
This is how it always worked and it generally worked well. It's so easy to get more space for a new discrete site, after all.<span class=""><br>
<br>
David R Huberman<br>
Microsoft Corporation<br>
Principal, Global IP Addressing<br>
<hr style="display:inline-block;width:98%">
</span><div dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>><br>
<b>Sent:</b> Tuesday, November 11, 2014 7:48:20 AM<div><div class="h5"><br>
<b>To:</b> David Huberman<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] 2014-19 and evidence of deployment</div></div></font>
<div> </div>
</div><div><div class="h5">
<div>
<div dir="ltr">David,
<div><br>
</div>
<div>That would suffice if when an org goes from 4 MDNs to 5 MDNs that ARIN does not treat the newly added region as anew MDN, but my understanding that this is not the case.</div>
<div><br>
</div>
<div>Leslie, can you comment on this practice as well? It was my understanding from the policy experience report that this is not the case.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>__Jason</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Nov 11, 2014 at 8:38 AM, David Huberman <span dir="ltr">
<<a href="mailto:David.Huberman@microsoft.com" target="_blank">David.Huberman@microsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>You split one site into two sites. The existing addresses go wherever you put them. Your network, your rules.<br>
<br>
Once a site is 80% and the other condition (50% overall or no /24 free) is met, you ask for more space for that site. That site is not a new. The customers (ISP) or equipment (EU) already existed and the address space already existed. No rule explicitly says
staff MUST classify the split sites as new, so staff are free to apply reasoable interpretation to fit the unique situation.
<br>
<br>
Staff should apply regular additional alloc rules for any requests from the split sites.<br>
<br>
Please note this is beyond a fringe case. We enjoy a fantastic staff who should be free to apply reasonable rules to such a situation, set the new rule as a procedure, and apply consistently as best they are able.
<br>
<br>
Just my opinion.<span><br>
<br>
David R Huberman<br>
Microsoft Corporation<br>
Principal, Global IP Addressing<br>
<hr style="display:inline-block;width:98%">
</span>
<div dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>><br>
<b>Sent:</b> Tuesday, November 11, 2014 5:18:46 AM<br>
<b>To:</b> David Huberman<br>
<b>Cc:</b> <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>
<div>
<div><br>
<b>Subject:</b> Re: [arin-ppml] 2014-19 and evidence of deployment</div>
</div>
</font>
<div> </div>
</div>
<div>
<div>
<div>
<div dir="ltr">David,
<div><br>
</div>
<div>I would love to hear from Leslie on your question, maybe we are trying to solve a non-problem.</div>
<div><br>
</div>
<div>In the mean time I do have one concern about what you wrote WRT an existing MDN site splitting and being fulfilled under immediate need. </div>
<div><br>
</div>
<div>Imagine you have MDN1 which grew from nothing to a /16 over the last year. You have just crossed 80% utilization, and want to grow into a new /18 which is a 3 month supply. But the region has gotten too big. So you split it into MDN1 and MDN6. Have
the pre-existing customers are in MDN1 and half in MDN6, and half the future looking growth is in MDN1 and half in MDN6. Can you move half your addresses to MDN6, have both MDN1 and MDN6 over 80% utilized, and get a /19 for MDN1 and a /19 for MDN6?</div>
<div><br>
</div>
<div>1. MDN6 does not have immediate need. The customers moved there kept the former MDN1 addressing. So you would have to start fresh with a /21, and ramp up to a /19.</div>
<div><br>
</div>
<div>2. If you were renumbering the customers in MDN6, you would only qualify for as many as you could address in 30 days (this many not be an issue for ISPs because when you re-allocate or assign the addresses they are in use, but for end-users they actually
have to be in service I have personally had an issue qualifying for IPs for an end-user under immediate need when I was asking for as many IPs as I had things to number, but couldn't actually complete numbering them in 30 days). </div>
<div><br>
</div>
<div>So no in two cases I don't think immediate need (which has an intentionally high bar [to be used in exceptional circumstances] )does not work. </div>
<div><br>
</div>
<div>__Jason</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Nov 11, 2014 at 7:59 AM, David Huberman <span dir="ltr">
<<a href="mailto:David.Huberman@microsoft.com" target="_blank">David.Huberman@microsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Something isn't right here. <br>
<br>
MDN (in basically the 2013 form) existed for 12 years without much of a problem. The language was tinkered a bit for subsequent alloc math, but new sites text wasn't. A new site opening was given:<br>
<br>
- a /22 or a /20 - dealer's choice since those were the minimums after 2005. Many were issued /20s except for smaller deployments who were happy to take /22s.<br>
<br>
- more if immediate need justified it.<br>
<br>
Slow start applies to section 4 requests. So under standard slow start math, you took the /22 or /20, and grow the NEW site with it. Just like an initial alloc to a new ISP. If the site wasn't really new, you could use existing customer counts and apply immediate
need. Nothing was broken. A special case like a site split into two is easily handled under the above considerations, isn't it?<br>
<br>
So ... Either the community has misunderstood Leslie's policy experience report, the report is wrong, or I'm wrong.
<br>
<br>
I stand by my suggestion. Section 7 is unnecessary and, to Marty's point, heavy handed.<br>
<br>
Now would be a great time for Leslie to jump in :-) Or if you don't accept my experiences in this as helpful, feel free to move on with the thread. Frankly, other than the heavy handedness of paragraph 7, I see no brokenness beyond fringe cases.
<br>
<span><br>
David R Huberman<br>
Microsoft Corporation<br>
Principal, Global IP Addressing<br>
<hr style="display:inline-block;width:98%">
</span>
<div dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>><br>
<b>Sent:</b> Tuesday, November 11, 2014 4:43:34 AM
<div>
<div><br>
<b>To:</b> David Huberman<br>
<b>Cc:</b> Martin Hannigan; John Santos; <a href="mailto:arin-ppml@arin.net" target="_blank">
arin-ppml@arin.net</a><br>
<b>Subject:</b> Re: [arin-ppml] 2014-19 and evidence of deployment</div>
</div>
</font>
<div> </div>
</div>
<div>
<div>
<div>
<div dir="ltr">David,
<div><br>
</div>
<div>In the <a href="https://www.arin.net/policy/archive/nrpm_20140626.pdf" target="_blank">
06/2014 NRPM </a> we had exactly the current policy minus paragraph 7. </div>
<div><br>
</div>
<div>At that time, we had a <a href="https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf" target="_blank">
policy experience report</a> where ARIN staff explained 4.5 has criteria for getting additional addresses for an existing MDN but no criteria for getting addresses for a new MDN. ARIN staff communicated that they were using only the Immediate Need 4.2.1.6
for allocations to new MDNs</div>
<div><br>
</div>
<div>We needed 2014-18 to encourage ARIN to open up the criteria for NEW MDNs to include the minimum.</div>
<div><br>
</div>
<div>I am suggesting further 2014-19 to extend it to also consider a 3 month supply if there is an applicable supporting 1 year use history.</div>
<div><br>
</div>
<div>I suspect if we struck paragraph 7, ARIN would go back to their previous practice of only applying immediate need, and looking for connectivity agreements, and giving a /21 or enough to meet 30 day need.</div>
<div><br>
</div>
<div>If you want to completely remove the proof of deployment, I think you would still need to keep the second half of paragraph 7...</div>
<div><br>
</div>
<div>
<div style="font-family:arial,sans-serif;font-size:13px"><font face="arial, sans-serif">"7. </font><font color="#000000" face="arial, helvetica, sans-serif"><span style="font-size:12px;line-height:18px">When an organization declares they are adding a new discrete
network site, the new networks shall be allocated:</span></font></div>
<div style="font-family:arial,sans-serif;font-size:13px"><font color="#000000" face="arial, helvetica, sans-serif"><span style="font-size:12px;line-height:18px"><br>
</span></font></div>
<div style="font-family:arial,sans-serif;font-size:13px"><font color="#000000" face="arial, helvetica, sans-serif"><span style="font-size:12px;line-height:18px">- </span></font><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px">the
minimum allocation size under section 4.2.1.5</span><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px"> </span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><font color="#000000" face="arial, helvetica, sans-serif"><span style="font-size:12px;line-height:18px">- </span></font><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px"> more
than the minimum allocation size if </span><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px">the organization can demonstrate additional need using the immediate need criteria (4.2.1.6)</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><font color="#000000" face="arial, helvetica, sans-serif"><span style="font-size:12px;line-height:18px">- a</span></font><span style="font-family:Calibri;color:rgb(38,38,38)"> 3-month supply of address
space may be requested if the new MDN can show an applicable demonstrated one-year utilization history."</span></div>
</div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:Calibri;color:rgb(38,38,38)"><br>
</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:Calibri;color:rgb(38,38,38)">Is that in line with what you are proposing?</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:Calibri;color:rgb(38,38,38)"><br>
</span></div>
<div><font color="#262626" face="Calibri">I assume you would conclude that most organization that declare they have a new MDN are not committing fraud, and will be using the address within 3 months, and if not in 3 months or more, ARIN is free to reclaim (if
they believe the organization is not working in good faith) under section 12.</font></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:Calibri;color:rgb(38,38,38)"><br>
</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:Calibri;color:rgb(38,38,38)">Is that about right?</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:Calibri;color:rgb(38,38,38)"><br>
</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:Calibri;color:rgb(38,38,38)">__Jason</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Nov 11, 2014 at 7:11 AM, David Huberman <span dir="ltr">
<<a href="mailto:David.Huberman@microsoft.com" target="_blank">David.Huberman@microsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>J-<br>
<br>
What if paragraph 7 were struck entirely from existing 4.5 text? Wouldn't that leave the staff able to issue blocks to new MDNs under the same rules as everyone else in section 4, while at the same time removing the documentation requirement?<br>
<br>
Thinking out loud. <br>
<span><br>
David R Huberman<br>
Microsoft Corporation<br>
Principal, Global IP Addressing<br>
</span>
<hr style="display:inline-block;width:98%">
<div dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>><br>
<b>Sent:</b> Tuesday, November 11, 2014 3:46:18 AM<br>
<b>To:</b> David Huberman<br>
<b>Cc:</b> Martin Hannigan; John Santos; <a href="mailto:arin-ppml@arin.net" target="_blank">
arin-ppml@arin.net</a>
<div>
<div><br>
<b>Subject:</b> Re: [arin-ppml] 2014-19 and evidence of deployment</div>
</div>
</font>
<div> </div>
</div>
<div>
<div>
<div>
<div dir="ltr">While I appreciate this discussion, I believe there is a real need to change policy.
<div><br>
</div>
<div>Previously a new MDN could only qualify under and get an initial allocation sized block.</div>
<div><br>
</div>
<div>This was extended to include more than the initial allocation sized block under immediate need.</div>
<div><br>
</div>
<div>I believe there is another case (besides immediate need) where more than the initial allocation sized block is justified. That is when there is a demonstrated past 1 year growth history that supports a future looking 3 month growth of a new MDN. Such
is the case when an existing MDN is split. Hence 2014-19.</div>
<div><br>
</div>
<div>I don't want to get hung up on the proof of deployment text that already exists.</div>
<div><br>
</div>
<div>Those of you that think this should be changed, please provide suitable text, and we can run the two policy proposals in parallel. </div>
<div><br>
</div>
<div>If you think this is unnecessary tinkering, then I would expect we will not rat hole on the pre-existing "proof of deployment" text when discussion 2014-19 as we did in the previous meeting.</div>
<div><br>
</div>
<div>Thank you.</div>
<div><br>
</div>
<div><br>
</div>
<div>__Jason</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Nov 11, 2014 at 12:08 AM, David Huberman <span dir="ltr">
<<a href="mailto:David.Huberman@microsoft.com" target="_blank">David.Huberman@microsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In my world view, policy should never assume the requestor is lying. The same should hold true for ARIN staff.<br>
<br>
No one ever mandated ARIN with stopping the scammers. I believe it was Rob Seastrom who posted here a long time ago and basically said that ARIN staff are entrusted to do the best job they can in running the registry, but the community shouldn't have expectations
that ARIN staff can figure out who's lying and who's not.<br>
<br>
But because ARIN got burned by large-scale hijacking in the early 2000s, it has operated under "trust but verify" ever since. And this fosters the antagonism towards the registry which I think is wholly avoidable. "Trust but verify" is a bad way to run an
RIR, in my experience.<br>
<br>
I hope we can focus on policy language which always assumes a request is bona fide, and let's stop worrying about the 1% of requestors who are lying. That way, network engineers can spend less time dealing with ARIN, and more time running their networks.<br>
<br>
David R Huberman<br>
Microsoft Corporation<br>
Principal, Global IP Addressing<br>
<div>
<div><br>
-----Original Message-----<br>
From: <a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a> [mailto:<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a>] On Behalf Of Martin Hannigan<br>
Sent: Monday, November 10, 2014 8:55 PM<br>
To: John Santos<br>
Cc: <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>
Subject: Re: [arin-ppml] 2014-19 and evidence of deployment<br>
<br>
On Mon, Nov 10, 2014 at 6:17 PM, John Santos <<a href="mailto:JOHN@egh.com" target="_blank">JOHN@egh.com</a>> wrote:<br>
> On Mon, 10 Nov 2014, Martin Hannigan wrote:<br>
><br>
>> ><br>
>> > "7. Upon verification that the organization has shown evidence of<br>
>> > deployment of the new discrete network site, [such as, but not<br>
>> > limited to the<br>
>> > following: a network design showing existing and new discreet<br>
>> > networks and supporting documentation that the proposed design in<br>
>> > in progress such as contracts for new space or power, new equipment<br>
>> > orders, publicly available marketing material describing the<br>
>> > offering in a new location, or some other significant capital<br>
>> > investment in the project,] the new networks shall be<br>
>> > allocated:<br>
>> ><br>
>><br>
>> Let's go back to the original point I made in the last two PPC and<br>
>> ARIN meetings. How can a company contract for real estate, energy or<br>
>> network without knowing if they had IP addresses to operate their<br>
>> business (in this current environment of v4 scarcity and policy<br>
>> wonkery?)?<br>
><br>
> Any company with a business plan is taking risks and has to have a<br>
> fall back plan (even if the plan is "pack it in") for any conceivable<br>
> eventuality. You want ARIN to guarantee that they can get IPv4 before<br>
> they've found a site, bought any equipment, signed any contracts with<br>
> suppliers or customers, or even made any public announcements of their<br>
> plans to establish a new site?<br>
<br>
Let me get this straight. So one should have a business plans that accounts for spending money that may not actually get to generate any revenue? ARIN has been assigning addresses without this requirement for a decade plus. The ability to forward look (guarantee)
has been shrunk and now ARIN is targeting MDN for discriminatory policies and removing any ability to forward look, a normal practice in "business".<br>
The risk of not getting addresses because ARIN is using clueless requirements is very high, not average. This isn't a simple excercise of "win some lose some". There are real dollars at stake (whether you operate a single rack or 1000 racks regardless of how
much "power" you<br>
use) and real risks.<br>
<br>
This proposal is best summed up as 'wasteful tinkering'.<br>
<br>
Best,<br>
<br>
-M<<br>
</div>
</div>
_______________________________________________<br>
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="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://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>
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="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://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>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div><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>|<a href="tel:571-266-0006" value="+15712660006" target="_blank">571-266-0006</a></font></div>
<div><font face="'courier new', monospace"><br>
</font></div>
</span></div>
</font></div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div><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>|<a href="tel:571-266-0006" value="+15712660006" target="_blank">571-266-0006</a></font></div>
<div><font face="'courier new', monospace"><br>
</font></div>
</span></div>
</font></div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div><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>|<a href="tel:571-266-0006" value="+15712660006" target="_blank">571-266-0006</a></font></div>
<div><font face="'courier new', monospace"><br>
</font></div>
</span></div>
</font></div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div><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>|<a href="tel:571-266-0006" value="+15712660006" target="_blank">571-266-0006</a></font></div>
<div><font face="'courier new', monospace"><br>
</font></div>
</span></div>
</font></div>
</div>
</div>
</div></div></div>
</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>