<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:533887021;
mso-list-type:hybrid;
mso-list-template-ids:-697908932 -2111403376 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
{mso-level-start-at:3;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">IANAL, but I have worked enough with our legal department to see some red flags in the RPA:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Possibility for on-sided modifications of the T&C with automatic acceptance thereof<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Complete indemnification of ARIN et al.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">So I definitely sympathize with the point that the RPA as worded there is probably unacceptable for many carriers (us included)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">I also agree that it is a moot point whether this is a click through before a download is possible or fine print of the website which
is presumable accepted once the service is accessed; it is in fact indeed commendable that ARIN does not try to let companies agree to such far reaching legal language without at least raising the flag. Therefore the points made by Wes during his nanog talk
regarding the modification of the RPA are pertinent here.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">I wonder why the trustees have chosen to take such a defensive approach on information contained in the RKPI, after all we have had
RBL lists in the past for blocking mail, we pretty much all uses RIR routing registries for building our filters, many people rely on PeeringDB for keeping their peering records up to date and I have not encountered such defensive position before.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Especially RPKI requires a wide acceptance to be able to do anything useful.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">What would be the process for the trustees to review this matter and share their insights on this matter?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><b><span lang="FR-BE" style="font-size:11.0pt;font-family:"Arial",sans-serif;color:#555555">Eric Loos<o:p></o:p></span></b></p>
<p class="MsoNormal"><span lang="FR-BE" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#555555">Senior Product Manager - Capacity & IP<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR-BE" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#555555">Tel. +32 2 547 51 21
</span><span lang="FR-BE" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#DC006B">•</span><span lang="FR-BE" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#555555"> Mob. +32 475 40 94 44<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="mailto:eric.loos@bics.com"><span lang="FR-BE" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#DC006B">eric.loos@bics.com</span></a></span><span lang="FR-BE" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#DC006B"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR-BE" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="FR-BE" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#555555">BICS SA/NV<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR-BE" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#555555">Rue Lebeau 4, 1000 Brussels, Belgium<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="http://www.bics.com/"><b><span lang="FR-BE" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#DC006B">www.bics.com</span></b></a></span><b><span lang="FR-BE" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#DC006B"><o:p></o:p></span></b></p>
<p class="MsoNormal"><span lang="FR-BE" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#DC006B"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> ARIN-PPML [mailto:arin-ppml-bounces@arin.net]
<b>On Behalf Of </b>John Curran<br>
<b>Sent:</b> Wednesday 1 February 2017 15:54<br>
<b>To:</b> Job Snijders <job@ntt.net><br>
<b>Cc:</b> arin-ppml@arin.net<br>
<b>Subject:</b> Re: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">On 1 Feb 2017, at 4:01 AM, Job Snijders <<a href="mailto:job@ntt.net">job@ntt.net</a>> wrote:
<o:p></o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">I am certain that an appropriate (and equally short) wget command<br>
could suffice technically for installing ARIN’s TAL, but including<br>
such in a script (or including the TAL directly in the source code<br>
repository) would deprive parties of the ability to fully consider and<br>
accept the responsibilities involved. <o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
Correct. Thank you for this summary. Your summary narrows it down to<br>
exactly the point of friction.<br>
<br>
Questions that come to mind: are the responsibilities as outlined by the<br>
RPA proportional to the goals the RPA is intended to achieve? Should any<br>
responsibilities be associated with the distribution of cryptographic<br>
public keys? To me DNSSEC seems an apt comparison.</span><o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Job - <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The typical relying parties “usage” of certificates in DNSSEC is heavily proscribed by <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">both protocol and implementation, and occurs with only nominal configuration choices on <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">behalf of the relying party. Both the maturity of DNSSEC and deployment model greatly <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">minimize the potential for misconfiguration on behalf of a relying party, with the result being<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">that misconfiguration by zone administrators is a much more common occurrence and one<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">whose impact is limited to but their own domain (reference RFC 7646 for more detail on <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">same and thus the desire for locally administered negative trust anchors to address <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">such circumstances...) Even when a DNSSEC validation error occurs, there remains the<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">potential for self-help on behalf of end users (via the option to switch to a non-validating <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">resolver.)<o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal">Contrast this to RPKI, wherein the introduction of origin validation into an ISP’s routing <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">architecture has many operational considerations, and inherently includes the potential to <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">readily impact the ISP's primary business under anything less than carefully planned and <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">executed BGP origin validation deployment efforts. While I’m am certain that everyone <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">deploying RKPI has BCP 185 memorized, the scope of any such impacts (and lack of viable <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">workarounds by the impacted customers) inherently means the potential for business impact<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">is greater than exists with deployment of DNSEC validation by ISPs – i.e. while I do believe<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">that your comparison to DNSSEC is directionally correct, it fails overall due to the very real<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">and significant difference in the magnitude of potential business impact to the relying party.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">/John<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">John Curran<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">President and CEO<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">ARIN<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<br>
<hr>
<font face="Arial" color="Blue" size="2"><br>
**** DISCLAIMER****<br>
http://www.bics.com/maildisclaimer/<br>
</font>
</body>
</html>