<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 29, 2017, at 8:58 AM, Jason Schiller <<a href="mailto:jschiller@google.com" class="">jschiller@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">David, Kevin, Alison<div class=""><br class=""></div><div class="">I am actually comfortable with an implementation that is short of revocation, </div><div class="">but I am still not comfortable with "should". </div><div class=""><br class=""></div><div class="">Should makes it optional. Officially not being out of compliance with</div><div class="">ARIN policy makes it optional. </div><div class=""><br class=""></div><div class="">I suggest that an ISP refusing to register a downstream customer</div><div class="">is out of compliance with ARIN policy, and not just choosing to ignore </div><div class="">an optional recommendation.</div><div class=""><br class=""></div><div class="">If it is only "should" then an ISP can still hold the moral high ground</div><div class="">while refusing to support SWIP on the grounds that they will not</div><div class="">implement tooling and commit resources when it is only optional.</div><div class=""><br class=""></div><div class="">It is a question of if you can hold someone accountable for not</div><div class="">complying or if they are free to ignore something that is optional.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Owen, Chris, Kevin,</div><div class=""><br class=""></div><div class="">Certainly if there is enough support to move this forward, we shouldn't</div><div class="">wait another cycle. (I recognize this weakens the "shall" position)</div></div></div></blockquote><div><br class=""></div>Other than AC sophistry or community confusion, there’s absolutely no reason, IMHO,</div><div>that we can’t get community support and consensus around shall as a minor change</div><div>prior to last call, so I don’t think it actually weakens the argument.</div><div><br class=""></div><div>I agree that if we have enough of either of the above that it won’t move forward</div><div>with shall until another cycle, it’s not worth waiting another cycle and we should</div><div>push through an additional separate policy for this single-word correction, so I</div><div>suppose to that extent, it could be seen as weakening the argument for doing it now.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">My hope is if we can close out the discussion of this topic at the meeting </div><div class="">with a clear understanding of if there is community support to move forward</div><div class="">the policy with "shall" and also if there is clear support to move the policy forward</div><div class="">with "should" in this cycle. This will give the AC a maximum of leverage to do </div><div class=""><span style="font-size: 12.48px;" class="">what is needed, and insure it doesn't fall to the next cycle by forcing people</span></div><div class=""><span style="font-size: 12.48px;" class="">to support only what they<span class="Apple-converted-space"> </span></span>perceive<span style="font-size: 12.48px;" class=""> as the best option.</span></div></div></div></blockquote><div><br class=""></div>100% Agreed.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><span style="font-size: 12.48px;" class=""><br class=""></span></div><div class=""><span style="font-size: 12.48px;" class="">Assuming there is support for both "shall" and "should" the AC could </span></div><div class=""><span style="font-size: 12.48px;" class="">choose to move "shall" to last call, and if there are then issues, move</span></div><div class=""><span style="font-size: 12.48px;" class="">should to last call. </span></div></div></div></blockquote><div><br class=""></div>Excellent idea, IMHO.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><span style="font-size: 12.48px;" class=""><br class=""></span></div><div class=""><span style="font-size: 12.48px;" class=""><br class=""></span></div><div class=""><span style="font-size: 12.48px;" class="">We need to get clear on how to structure the question here.</span></div><div class=""><span style="font-size: 12.48px;" class=""><br class=""></span></div><div class=""><span style="font-size: 12.48px;" class="">My thoughts are </span></div><div class=""><span style="font-size: 12.48px;" class=""><br class=""></span></div><div class=""><span style="font-size: 12.48px;" class="">1. Do you support the policy with "shall" if </span><span style="font-size: 12.48px;" class="">it doesn't require an extra cycle</span></div><div class=""><span style="font-size: 12.48px;" class=""> and support "should" in this cycle if "shall" cannot advance?</span></div><div class=""><span style="font-size: 12.48px;" class=""><br class=""></span></div><div class=""><span style="font-size: 12.48px;" class="">2. Do you only support the policy as written?</span></div><div class=""><span style="font-size: 12.48px;" class=""><br class=""></span></div><div class=""><span style="font-size: 12.48px;" class="">3. Do you oppose both the policy as written and with "shall"?</span></div><div class=""><span style="font-size: 12.48px;" class=""><br class=""></span></div><div class=""><span style="font-size: 12.48px;" class="">When considering if there is enough support to move the policy as </span></div><div class=""><span style="font-size: 12.48px;" class="">written forward, the AC should consider the hands in both questions 1 & 2.</span></div><div class=""><span style="font-size: 12.48px;" class=""><br class=""></span></div><div class=""><span style="font-size: 12.48px;" class=""><br class=""></span></div><div class=""><span style="font-size: 12.48px;" class="">I </span>support the policy with "shall" with a fall back to "should".</div><div class=""><span style="font-size: 12.48px;" class=""><br class=""></span></div><div class="">__Jason</div><div class=""><br class=""></div><div class=""> </div></div><div class="gmail_extra" style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""><div class="gmail_quote">On Thu, Sep 28, 2017 at 1:18 PM, David Farmer<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:farmer@umn.edu" target="_blank" class="">farmer@umn.edu</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">I agree with Kevin if a bigger stick is need to ensure compliance in the future we can take that step if/when there proves to be a serious non-compliance issue in the future. Personally, I'm not ready to threaten revocation, in this case. My intent in suggesting what is now 6.5.5.4 was to crate an avenue for ARIN Staff to intervene with ISPs on behalf of customers, if a customer wanted their assignment registered and their ISP refused to register their assignment as requested, the customer can appeal the issue to ARIN. I'm fine with that intervention being short of threatening revocation, at least until their proves to be a serious issue with ISP's refusing valid requests by endusers to register assignments. I think the current language provides the proper balance.<div class=""><br class=""></div><div class="">I'm fine with the standard procedure starting with ARIN Staff forwarding such complaints to an ISP requesting an explanation of the situation. However, if this develops into a chronic matter for an ISP, I would expect ARIN Staff to escalate the issue beyond simply asking for an explanation. Further after escalation, if the matter continues to be chronic, I would expect eventually the community to be altered to the situation. Probably not the specifics of which ISP and customers, but at least that there is an issue and some sense of the situation involved. </div><div class=""><div class=""><br class=""></div><div class="">Therefore, I support the policy as written. I'm not strongly opposed to changing from "should" to "shall" for section 6.5.5.4, but I'd prefer keeping that change in reserve, so we can go there, if there proves to be serious issues with non-compliance in the future. Put another way, I think voluntary compliance is highly preferred for this issue, and if voluntary compliance proves insufficient, then we can deal with that in the future. </div><div class=""><br class=""></div><div class="">Thanks.<br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="h5">On Thu, Sep 28, 2017 at 10:46 AM, Kevin Blumberg<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:kevinb@thewire.ca" target="_blank" class="">kevinb@thewire.ca</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""></div></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class=""><div class="h5"><div lang="EN-CA" class=""><div class="m_2086653384843287505gmail-m_-3868886150614529843WordSection1"><p class="MsoNormal"><a name="m_2086653384843287505_m_-3868886150614529843__MailEndCompose" class=""><span class="">I support the policy as written.<u class=""></u><u class=""></u></span></a></p><p class="MsoNormal"><span class=""><span class=""><u class=""></u> <u class=""></u></span></span></p><p class="MsoNormal"><span class=""><span class="">If the stick isn’t big enough it appears a simple policy change could be used, not just for this section but all the other areas “should” is used.<u class=""></u><u class=""></u></span></span></p><p class="MsoNormal"><span class=""><span class=""><u class=""></u> <u class=""></u></span></span></p><p class="MsoNormal"><span class=""><span class="">I would like to point out that “should” is currently used 30 times in the NRPM.<u class=""></u><u class=""></u></span></span></p><p class="MsoNormal"><span class=""><span class=""><u class=""></u> <u class=""></u></span></span></p><p class="MsoNormal"><span class=""><span class="">In reading John’s explanation, I can’t see “should” and “shall” being considered an editorial change. To extend the policy cycle to another meeting would be far worse.<u class=""></u><u class=""></u></span></span></p><p class="MsoNormal"><span class=""><span class=""><u class=""></u> <u class=""></u></span></span></p><p class="MsoNormal"><span class=""><span class="">Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you?<u class=""></u><u class=""></u></span></span></p><p class="MsoNormal"><span class=""><span class=""><u class=""></u> <u class=""></u></span></span></p><p class="MsoNormal"><span class=""><span class="">Thanks,<u class=""></u><u class=""></u></span></span></p><p class="MsoNormal"><span class=""><span class=""><u class=""></u> <u class=""></u></span></span></p><p class="MsoNormal"><span class=""><span class="">Kevin Blumberg<u class=""></u><u class=""></u></span></span></p><p class="MsoNormal"><span class=""><span class=""><u class=""></u> <u class=""></u></span></span></p><p class="MsoNormal"><span class=""><span class=""><u class=""></u> <u class=""></u></span></span></p><span class=""></span><div class=""><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(225, 225, 225); padding: 3pt 0in 0in;" class=""><p class="MsoNormal"><b class=""><span lang="EN-US" class="">From:</span></b><span lang="EN-US" class=""><span class="Apple-converted-space"> </span>ARIN-PPML [mailto:<a href="mailto:arin-ppml-bounces@arin.net" target="_blank" class="">arin-ppml-bounces@arin<wbr class="">.net</a>]<span class="Apple-converted-space"> </span><b class="">On Behalf Of<span class="Apple-converted-space"> </span></b>John Curran<br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Wednesday, September 27, 2017 5:59 PM<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank" class="">jschiller@google.com</a>><br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span><a href="mailto:arin-ppml@arin.net" target="_blank" class="">arin-ppml@arin.net</a><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements<u class=""></u><u class=""></u></span></p></div></div><p class="MsoNormal"><u class=""></u> <u class=""></u></p><div class=""><p class="MsoNormal">On 26 Sep 2017, at 3:18 PM, Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank" class="">jschiller@google.com</a>> wrote:<u class=""></u><u class=""></u></p></div><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p><div class=""><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">I oppose as written.<u class=""></u><u class=""></u></span></p><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><u class=""></u> <u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">There should not be a different standard of requirement for:<u class=""></u><u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">- re-allocation<u class=""></u><u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">- reassignment containing a /47 or more addresses<u class=""></u><u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">- subdelegation of any size that will be individually announced<u class=""></u><u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><u class=""></u> <u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">which is "shall"<u class=""></u><u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><u class=""></u> <u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">and Registration Requested by Recipient<u class=""></u><u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><u class=""></u> <u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">which is "should"<u class=""></u><u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><u class=""></u> <u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">I would support if they are both "shall".<u class=""></u><u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><u class=""></u> <u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">Can ARIN staff discuss what actions it will take if an ISP's<u class=""></u><u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">down stream customer contacts them and explains that their<u class=""></u><u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">ISP refuses to SWIP their reassignment to them?<u class=""></u><u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><u class=""></u> <u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">Will they do anything more than reach out to the ISP and tell<u class=""></u><u class=""></u></span></p></div><div class=""><p class="MsoNormal"><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">them they "should" SWIP it?<u class=""></u><u class=""></u></span></p></div></div></div></blockquote><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Jason - <br class=""> <br class=""> If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> but routinely fails to publish registration information (for /47 or larger reassignments) <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> would be in violation, and ARIN would have clear policy language that would enable <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> us to discuss with the ISP the need to publish this information in a timely manner. <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><br class=""> Service providers who blatantly ignore such a provision on an ongoing basis will be <br class=""> in the enviable position of hearing me chat with them about their obligations to follow <br class=""> ARIN number resource policy, including the consequences (i.e. potential revocation <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> of the IPv6 number resources.)<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal"> If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient” <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> reads “… the ISP should register that assignment”, then ARIN would send on any<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> received customer complaint to the ISP, and remind the ISP that they should<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> follow number resource policy in this regard but not otherwise taking any action. <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal"> If the language for the new section 6.5.5.4 "Registration Requested by Recipient” <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> reads “… the ISP shall register that assignment”, then failure to do so would be<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> a far more serious matter that, if left unaddressed on a chronic manner, could have <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> me discussing the customer complaints as a sign of potential failure to comply with <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> number resource policy, including the consequences (i.e. potential revocation of <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> the IPv6 number resources.)<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal"> I would note that the community should be very clear about its intentions for ISPs<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> with regard to customer requested reassignment publication, given there is large <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> difference in obligations that result from policy language choice. ARIN staff remains, <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> as always, looking forward to implementing whatever policy emerges from the <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> consensus-based policy development process. <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Thanks!<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">/John<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">John Curran<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">President and CEO<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">American Registry for Internet Numbers<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div></div></div><br class=""></div></div><span class="">______________________________<wbr class="">_________________<br class="">PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" class="">http://lists.arin.net/mailman/<wbr class="">listinfo/arin-ppml</a><br class="">Please contact<span class="Apple-converted-space"> </span><a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a><span class="Apple-converted-space"> </span>if you experience any issues.<br class=""></span></blockquote></div><span class="HOEnZb"><font color="#888888" class=""><br class=""><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div class="m_2086653384843287505gmail_signature">==============================<wbr class="">=================<br class="">David Farmer <span class="Apple-converted-space"> </span><a href="mailto:Email%3Afarmer@umn.edu" target="_blank" class="">Email:farmer@umn.edu</a><br class="">Networking & Telecommunication Services<br class="">Office of Information Technology<br class="">University of Minnesota <span class="Apple-converted-space"> </span><br class=""><a href="https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g" class="">2218 University Ave SE</a> <span class="Apple-converted-space"> </span>Phone:<span class="Apple-converted-space"> </span><a href="tel:(612)%20626-0815" value="+16126260815" target="_blank" class="">612-626-0815</a><br class="">Minneapolis, MN 55414-3029 Cell:<span class="Apple-converted-space"> </span><a href="tel:(612)%20812-9952" value="+16128129952" target="_blank" class="">612-812-9952</a><br class="">==============================<wbr class="">=================<span class="Apple-converted-space"> </span><br class=""></div></font></span></div></div></div></div></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div class="gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace" class=""><div class=""><span style="font-family: arial;" class=""><font color="#555555" face="'courier new', monospace" class="">_______________________________________________________<br class=""></font><div class=""><font face="'courier new', monospace" class="">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank" class="">jschiller@google.com</a>|571-266-0006</font></div><div class=""><font face="'courier new', monospace" class=""><br class=""></font></div></span></div></font></div></div><span style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">PPML</span><br style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">You are receiving this message because you are subscribed to</span><br style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">the ARIN Public Policy Mailing List (</span><a href="mailto:ARIN-PPML@arin.net" style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">ARIN-PPML@arin.net</a><span style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">).</span><br style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Unsubscribe or manage your mailing list subscription at:</span><br style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Please contact<span class="Apple-converted-space"> </span></span><a href="mailto:info@arin.net" style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">info@arin.net</a><span style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><span class="Apple-converted-space"> </span>if you experience any issues.</span></div></blockquote></div><br class=""></body></html>