<div dir="ltr">It seems to me that this proposal actually simplifies things a lot more than it appears at first glance. Obviously it expands section 8 with a lot more words. But it does so in order to almost completely remove the dependencies on section 4 (leaving just a reference to the minimum allocation size). So once the ARIN free pool is exhausted, that will mean that the policy under which most people get IPv4 space will be dramatically simpler than it is today. It will also open up the way to dramatically simplifying section 4 after free pool exhaustion.<div><br>I haven't yet worked through all the situations I can think of to make sure this is better than current policy in all cases, but on first pass it appears to me to be a significant improvement on the status quo.</div><div><br></div><div>-Scott</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 13, 2014 at 5:34 AM, Mike Burns <span dir="ltr"><<a href="mailto:mike@iptrading.com" target="_blank">mike@iptrading.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div bgcolor="#ffffff">
<div><font face="Arial">Hi Jason,</font></div>
<div><font face="Arial"></font> </div>
<blockquote style="BORDER-LEFT:#000000 2px solid;PADDING-LEFT:5px;PADDING-RIGHT:0px;MARGIN-LEFT:5px;MARGIN-RIGHT:0px" dir="ltr">
<div style="FONT:10pt arial"><br> </div>
<div dir="ltr"><span class="">
<div>However, assuming that 2014-14 is discussed first and does not pass,
would you still oppose 2014-20?</div>
<div> </div>
</span><div><font face="Arial">Possibly. </font></div><span class="">
<div><font face="Arial"></font><br> </div>
<div>Would you agree that 2014-20 a movement in the direction as it is in the
middle ground between current needs based and transfers without need?</div>
<div> </div>
</span><div><font face="Arial">It seems like you are removing the 24month
distinction between transfers and free pool allocations and replacing it with
a more complex, although possibly more expansive mechanism. I would have to
consider more analysis of the various scenarios and balance my support against
my opposition to NRPM bloat and transfer policy complexity.</font></div><span class="">
<div><br></div>
<div>Would you agree that while 2014-20, in your opinion does not go far
enough, it is still better than the status quo?</div>
<div> </div>
</span><div><font face="Arial">Well the status quo has changed, with minimums
reduced to /24, and I have not had time to analyze sufficiently. One of the
real problems I had encountered with transfers was related to the /20 minimum
and I have not had problems with transfers due to explosive growth.
Unfortunately!</font></div><span class="">
<div><font face="Arial"></font> </div>
<div><br></div>
<div>2014-20 does in fact separate the needs test for transfers from the needs
test for ARIN allocations and assignments.</div>
<div>WRT transfers, at any time, an org that can demonstrate 80% utilization
on average across all their IP space, is eligible to completed 1 or more
transfer and up to double their holdings. This is very different from
demonstrating 80% utilization of your most recent block, and efficiently using
all your older IP space, and only getting double what you used in the last 12
months.</div>
<div><br></div>
<div>This however does not help orgs with no resources 2*0=0, nor does it help
orgs that have a history of slow growth with recent rapid growth.</div>
<div><br></div>
<div>To help orgs that have no resources, I wanted to make it fairly easy for
them to get what ever the minimum assignment/allocation is (the only tie back
to ARIN issued IP space) up to a /24 for end-sites and up to a /21 for
ISPs. I wanted at the same time to disqualify orgs that have no actual
plan on having stuff to number. Once they get their initial space that
can use it to 80% and then double, us that to 80%, and double again, and so
on.</div>
<div><br></div>
<div>For orgs with only recent rapid growth, and for new orgs who don't want
to keep doubling, they can choose a look back window between 3 and 12 months,
and calculate a two year supply.</div>
<div><br></div>
<div>So a new org may transfer in a /24, show 80% utilization after 45 days,
transfer in an additional /24, show 80% utilization of both blocks after 90
days, and then qualify to transfer in up to the <span style="LINE-HEIGHT:18px;FONT-FAMILY:arial,helvetica,sans-serif;COLOR:rgb(0,0,0);FONT-SIZE:12px">equivalent</span> of
16 * /24s.</div>
<div><br></div>
<div>__Jason</div>
<div><br></div>
<div> </div>
</span><div><font face="Arial">It sounds better to me than the current system,
but I definitely prefer 2014-14. My concern is that whenever verbiage is added
to the NRPM it opens new doors to misinterpretation which have to be addressed
through more verbiage. In addition, whenever new issues or problems are
discovered when applying this new mechanism to different business-case
scenarios, more verbiage would be necessary to restore "fairness". And
considering the myriad ways that businesses can find themselves in need of
IPv4 space I think we are taking the first steps down a dangerous path with
your proposal. On the other hand 2014-14 addresses the needs of fast and slow
growing companies, and the needs of small companies, with less of this danger
and less risk of out-of-policy transfers which hold their own separate
dangers. </font></div>
<div><font face="Arial"></font> </div>
<div><font face="Arial">Regards,</font></div>
<div><font face="Arial">Mike</font></div>
<div><font face="Arial"></font> </div>
<div><br></div>
<div><br></div>
<div><br></div>
<div> </div>
<div><br></div>
<div> </div>
<div>
<div><br></div>
<div><br></div></div></div><div><div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Sep 12, 2014 at 1:19 PM, Mike Burns <span dir="ltr"><<a href="mailto:mike@iptrading.com" target="_blank">mike@iptrading.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div dir="ltr">
<div dir="ltr">
<div style="FONT-FAMILY:'Calibri';COLOR:#000000;FONT-SIZE:12pt">
<div>Hi Jason,</div>
<div> </div>
<div>I apologize for not commenting on this earlier, I decided to sit back
and see what other input was received.</div>
<div> </div>
<div>I think that you have correctly identified in your problem statement
certain issues we face at the near-exhaust stage and beyond.</div>
<div>ARIN allocation policy was always premised on the free pool, and we
have decided to borrow the same policy and apply it to the wholly new
environment of a trading market.</div>
<div style="FONT-STYLE:normal;DISPLAY:inline;FONT-FAMILY:'Calibri';COLOR:#000000;FONT-SIZE:small;FONT-WEIGHT:normal;TEXT-DECORATION:none">
<div style="FONT:10pt tahoma">
<div><font size="3" face="Calibri">You correctly identify issues like
transactional costs which are imposed on recipients as a result of free-pool
premised policies whose authors did not consider these
implications.</font></div>
<div><font size="3" face="Calibri">You note that ARIN policy does not
efficiently accommodate various recipient growth profiles, especially as any
wiggle-room is squeezed out of every allocation by a team of ARIN
reviewers.</font></div>
<div><font size="3" face="Calibri"></font> </div>
<div><font size="3" face="Calibri">We can expect more such problems as market
forces tend to diverge from ARIN policy prescriptions, and it is my belief
that the weight of these distortions puts a strain on Whois accuracy as more
money flows into this market. When business needs are faced-up against
ARIN policy, at a certain point the business risk of inadequate allocation
overrides the risk of an out-of-policy transfer. And these out-of-policy
transfers can happen by multiple means, including phased-contracts,
permanent leasing, and zombie corporations which ARIN policy can’t
touch. ARIN policy is a market distortion which will likely grow larger over
time.</font></div>
<div><font size="3" face="Calibri"></font> </div>
<div><font size="3" face="Calibri">Rather than try to put our finger in the dyke
through more and more NRPM verbiage, isn’t it time we acknowledged that a
separate allocation paradigm exists in the trading market which requires a
separate (or absent) needs-test for transfers? </font></div>
<div><font size="3" face="Calibri"></font> </div>
<div><font size="3" face="Calibri">I believe that every circumstance elucidated
in your proposal is answered by the much more streamlined 2014-14, which
removes needs testing from transfers smaller than a /16, once per year.
</font></div>
<div><font size="3" face="Calibri"></font> </div>
<div><font size="3" face="Calibri">I am against further un-necessary clutter in
the NRPM, and if we seek to match every unknown and unknowable vagary of the
impending transfer market with new policy, we open the door to a virtual tax
code of text. Here is one of your new sections:</font></div><span>
<div><font size="3" face="Calibri"></font> </div><font face="Arial"><span><font style="FONT-SIZE:6pt">8.3.2.3.2.1 Calculation of
Monthly Average Use Rate</font></span><font style="FONT-SIZE:6pt"><br style="TEXT-TRANSFORM:none;BACKGROUND-COLOR:rgb(255,255,255);TEXT-INDENT:0px;FONT:12px/18px arial,helvetica,sans-serif;WHITE-SPACE:normal;LETTER-SPACING:normal;COLOR:rgb(0,0,0);WORD-SPACING:0px"></font><span><font style="FONT-SIZE:6pt">An organization may choose a look-back window of any
number of months between 3 and 12, inclusive, from the date of the current
request. ARIN will calculate the total amount of new addresses acquired,
during the look-back window, by the organization from non-M&A transfers,
direct allocations or assignments from ARIN, or reallocations or
reassignments from an ISP. That total will be divided by the number of
months in the look-back window to calculate the organization’s monthly
average use rate.</font></span></font>
<div><font size="3" face="Calibri"></font> </div></span>
<div><font size="3" face="Calibri">8.3.2.3.2.1?</font></div>
<div><font size="3" face="Calibri"></font> </div>
<div><font size="3" face="Calibri">While I support the recognition of the
problems Jason identified, I am opposed to 2014-20. </font></div>
<div><font size="3" face="Calibri">(Also I would counsel against regarding
silence as approval.)</font></div>
<div><font size="3" face="Calibri"></font> </div>
<div><font size="3" face="Calibri">Regards</font></div>
<div><font size="3" face="Calibri"></font> </div>
<div><font size="3" face="Calibri">Mike Burns</font></div>
<div><font size="3" face="Calibri"></font> </div>
<div><font size="3" face="Calibri"></font> </div>
<div style="BACKGROUND:#f5f5f5">
<div><b>From:</b> <a title="jschiller@google.com" href="mailto:jschiller@google.com" target="_blank">Jason Schiller</a> </div>
<div><b>Sent:</b> Friday, September 12, 2014 12:13 PM</div>
<div><b>To:</b> <a title="owens@nysernet.org" href="mailto:owens@nysernet.org" target="_blank">owens@nysernet.org</a> ; <a title="kevinb@thewire.ca" href="mailto:kevinb@thewire.ca" target="_blank">Kevin Blumberg</a> ; <a title="farmer@umn.edu" href="mailto:farmer@umn.edu" target="_blank">David
Farmer</a> </div>
<div><b>Cc:</b> <a title="arin-ppml@arin.net" href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a> </div>
<div><b>Subject:</b> Re: [arin-ppml] Draft Policy ARIN-2014-20: Transfer
Policy Slow Start and Simplified Needs Verification</div></div></div>
<div> </div></div>
<div style="FONT-STYLE:normal;DISPLAY:inline;FONT-FAMILY:'Calibri';COLOR:#000000;FONT-SIZE:small;FONT-WEIGHT:normal;TEXT-DECORATION:none">
<div>
<div>
<div dir="ltr">It has been a week, and there has been no discussion on this
thread.
<div> </div>
<div>I take the silence to mean the suggested "option 2" rewrite is
non-controversial and meets all of Bill's concerns.</div>
<div> </div>
<div>I also take the silence to mean that all three options I have suggested
all result in the same implementation, </div>
<div>and since no one believes any of the three options differ in
implementation, there is no preference.</div>
<div> </div>
<div>I humbly submit we should go with option 2, as it is closest to Bill's
suggestion, and keeps 8.2 and 8.3 in line </div>
<div>(setting the ground work for a future unification of 8.2 and
8.3).</div>
<div> </div>
<div>Will there be discussion now? Or should we just silently move
forward?</div>
<div> </div>
<div> </div>
<div>Thanks,</div>
<div> </div>
<div>___Jason</div>
<div> </div>
<div> </div>
<div> </div></div>
<div class="gmail_extra">
<div> </div>
<div class="gmail_quote">On Thu, Sep 4, 2014 at 11:34 AM, Jason Schiller <span dir="ltr"><<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div dir="ltr">Bill,
<div> </div>
<div>Thank you.</div>
<div> </div>
<div>The intent was NOT to remove the <span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">requirement for
in-region recipients of transfers to sign an RSA.</span></div>
<div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px"><br></span></div>
<div><font face="arial, sans-serif">My apologies. </font></div>
<div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px"><br></span></div>
<div><font face="arial, sans-serif">There is a lot or parallel structure
in 8.3 and 8.4 and in my mind 8.4 is identical to 8.3 except 8.4 has a
clause "Except when the </font><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">recipient</span><font face="arial, sans-serif"> is out of region then that region's policy
applies", and " </font><font face="arial, sans-serif">Except when the
</font><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">source</span><font face="arial, sans-serif"> is out of region then that region's policy
applies". I really wanted to completely merge 8.3 and 8.4 to remove
the parallel structure but as an editorial re-write only and not part of
this discussion. </font></div>
<div><font face="arial, sans-serif"><br></font></div>in 8.4 there are a
separate bullets for 24-month supply and sign the RSA:<br>
<div>"> Recipients within the ARIN region will be subject to current
ARIN policies and sign an RSA for the resources being received.<br>>
Recipients within the ARIN region must demonstrate the need for up to a
24-month supply of IPv4 address space."
<div> </div>
<div>I think in my mind I imagined a similar separate bullets in 8.3, one
for 24-month supply and another for sign RSA, and I intended just to
remove the 24 month part. </div>
<div> </div>
<div>I think there are a few ways to fix this.</div>
<div> </div>
<div>
<div>Option 1 - minimun rewrtite</div>
<div>- remove only the "24-month" portion of the 8.3 text. This is the
minimum change, but brings section 8.3 and 8.4 further out of
alignment</div>
<div> </div>
<div>Option 2 - single bullet for "meet ARIN policy" and "sign RSA" (8.3
as the model text)</div>
<div>- replace the whole "24-month" text and "meet ARIN policy" text in
8.3 with a bullet that included "sign the RSA" and "meet ARIN policy"
under one bullet and is parallel to text in 8.4 (minus within the ARIN
region)</div>
<div> </div>
<div>Option 3 - two separate bullets for "meet ARIN policy" and "sign RSA"
(8.2 as the model text) </div>
<div>- replace the whole "24-month" text in 8.3 with a bullet that
included "sign the RSA"</div>
<div>-separate the "sign the RSA" and "meet ARIN policy" in 8.4 into two
bullets and is parallel to text in 8.3 (plus the within ARIN
region)</div></div>
<div> </div>
<div>(If the summary of the options are hard to follow I have a suggestion
for the specific rewrites below)</div>
<div> </div>
<div>I think your suggestion is roughly Option 2 below (the only
difference is with your suggested rewrite, there are now two bullets in
8.3 stating the recipient is subject to current ARIN policies).
Assuming all the options have the same policy implications, I would prefer
option 2 or 3, as these bring greater alignment of the sections.
</div>
<div> </div>
<div>Do these options all meet your concern?</div>
<div> </div>
<div>Does the community and ARIN staff agree that the thee options have
the same policy implications?</div>
<div> </div>
<div> </div>
<div>Kevin, David,</div>
<div> </div>
<div>I think at this point you own the text?</div>
<div>I would be supportive of the friendly amendment to modify the draft
policy as follows:</div>
<div> </div>
<div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px"></span> </div>
<div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">OPTION
1:</span></div><span>
<div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">Replace
the following Section 8.3 text:</span><br style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">
<div style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px"><br>"> The
recipient must demonstrate the need for up to a 24-month supply<br>
of IP address resources under current ARIN policies and sign an<br>
RSA."</div>
<div style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px"> </div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">with:</span></div>
<div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px"><br></span></div></span>
<div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">">
</span>Recipients will sign an RSA for the resources being
received."</div>
<div> </div>
<div> </div>
<div>OPTION 2:</div>
<div> </div>
<div>
<div><span><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">Replace the
following Section 8.3 text:</span><br style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px"></span>
<div><span><br><font face="arial, sans-serif">"> The recipient must
demonstrate the need for up to a 24-month supply</font><br><font face="arial, sans-serif"> of IP address resources under current ARIN
policies and sign an</font><br> RSA.<br></span> > The
resources transferred will be subject to current ARIN policies.<span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">"</span></div>
<div style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px"> </div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">with:</span></div>
<div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px"><br></span></div>
<div>
<div>"> Recipients will be subject to current ARIN policies and sign an
RSA for the resources being received."<br></div></div></div>
<div> </div>
<div>OPTION 3:</div>
<div><span>
<div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">Replace
the following Section 8.3 text:</span><br style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">
<div style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px"><br>"> The
recipient must demonstrate the need for up to a 24-month supply<br>
of IP address resources under current ARIN policies and sign an<br>
RSA."</div>
<div style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px"> </div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">with:</span></div>
<div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px"><br></span></div></span>
<div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">">
</span>Recipients will sign an RSA for the resources being
received."</div></div>
<div> </div>
<div>and replace the following Section 8.4 text:</div>
<div> </div>"> Recipients within the ARIN region will be subject
to current ARIN policies and sign an RSA for the resources being
received.<br> > Recipients within the ARIN region must
demonstrate the need for up to a 24-month supply of IPv4 address
space."</div>
<div> </div>
<div>With:</div>
<div> </div>
<div>
<div>"> Recipients within the ARIN region will sign an RSA for the
resources being received.</div>
<div>> The resources transferred to recipients within the ARIN region
will be subject to current ARIN policies."</div>
<div> </div>
<div>If all the options are indeed the same I would prefer option 2 or
3.</div>
<div>If the options have different policy implications and we can converge
on one standard for both 8.2 and 8.3, then I would prefer that.</div>
<div> </div>
<div> </div>
<div>___Jason</div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div></div></div>
<div class="gmail_extra">
<div>
<div><br><br>
<div class="gmail_quote">On Thu, Sep 4, 2014 at 8:50 AM, Bill Owens <span dir="ltr"><<a href="mailto:owens@nysernet.org" target="_blank">owens@nysernet.org</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div>On Wed, Sep 03, 2014 at 04:55:58PM -0400, ARIN wrote:<br>> On 28
August 2014 the ARIN Advisory Council (AC) accepted<br>>
"ARIN-prop-212 Transfer policy slow start and simplified needs<br>>
verification" as a Draft Policy.<br>><br></div>. . .<br>
<div>><br>> Draft Policy ARIN-2014-20<br>> Transfer Policy Slow
Start and Simplified Needs Verification<br>><br>> Date: 3
September 2014<br>><br></div>. . .<br>
<div>><br>> Policy statement:<br>><br>> Remove the following
section 8.3 text:<br>><br>> “The recipient must demonstrate the
need for up to a 24-month supply<br>> of IP address resources under
current ARIN policies and sign an<br>> RSA.”<br><br></div>Shouldn't
that be something like this, instead?<br><br>Replace the following
Section 8.3 text:<br>
<div><br>"The recipient must demonstrate the need for up to a 24-month
supply<br> of IP address resources under current ARIN policies and
sign an<br> RSA.”<br><br></div>with:<br><br>"The recipient will be
subject to current ARIN policies and sign an<br> RSA for the
resources being received."<br><br>As written it appears to remove the
requirement for recipients of in-region transfers to sign an
RSA.<br><span><font color="#888888"><br>Bill.<br></font></span>
<div>
<div>_______________________________________________<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.</div></div></blockquote></div><br><br clear="all">
<div> </div></div></div><span><font color="#888888">-- <br><font color="#555555" face="'courier new', monospace">
<div><span style="FONT-FAMILY:arial;COLOR:rgb(0,0,0)"><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></font></span></div></blockquote></div><br><br clear="all">
<div> </div>-- <br><font color="#555555" face="'courier new', monospace">
<div><span style="FONT-FAMILY:arial;COLOR:rgb(0,0,0)"><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>
<p></p>
<hr>
<span>_______________________________________________<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.</span>
<p></p></div></div></div></div></blockquote></div><br><br clear="all">
<div><br></div>-- <br><font color="#555555" face="'courier new', monospace">
<div><span style="FONT-FAMILY:arial;COLOR:rgb(0,0,0)"><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></blockquote></div>
<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" 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></blockquote></div><br></div>