IANAL, but I have worked enough with our legal department to see some red flags in the RPA:
- Possibility for on-sided modifications of the T&C with automatic acceptance thereof - Complete indemnification of ARIN et al. So I definitely sympathize with the point that the RPA as worded there is probably unacceptable for many carriers (us included) 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. 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. Especially RPKI requires a wide acceptance to be able to do anything useful. What would be the process for the trustees to review this matter and share their insights on this matter? Eric Loos Senior Product Manager - Capacity & IP Tel. +32 2 547 51 21 • Mob. +32 475 40 94 44 [email protected]<mailto:[email protected]> BICS SA/NV Rue Lebeau 4, 1000 Brussels, Belgium www.bics.com<http://www.bics.com/> From: ARIN-PPML [mailto:[email protected]] On Behalf Of John Curran Sent: Wednesday 1 February 2017 15:54 To: Job Snijders <[email protected]> Cc: [email protected] Subject: Re: [arin-ppml] Revisit RPKI TAL Relying Party Agreement? On 1 Feb 2017, at 4:01 AM, Job Snijders <[email protected]<mailto:[email protected]>> wrote: I am certain that an appropriate (and equally short) wget command could suffice technically for installing ARIN’s TAL, but including such in a script (or including the TAL directly in the source code repository) would deprive parties of the ability to fully consider and accept the responsibilities involved. Correct. Thank you for this summary. Your summary narrows it down to exactly the point of friction. Questions that come to mind: are the responsibilities as outlined by the RPA proportional to the goals the RPA is intended to achieve? Should any responsibilities be associated with the distribution of cryptographic public keys? To me DNSSEC seems an apt comparison. Job - The typical relying parties “usage” of certificates in DNSSEC is heavily proscribed by both protocol and implementation, and occurs with only nominal configuration choices on behalf of the relying party. Both the maturity of DNSSEC and deployment model greatly minimize the potential for misconfiguration on behalf of a relying party, with the result being that misconfiguration by zone administrators is a much more common occurrence and one whose impact is limited to but their own domain (reference RFC 7646 for more detail on same and thus the desire for locally administered negative trust anchors to address such circumstances...) Even when a DNSSEC validation error occurs, there remains the potential for self-help on behalf of end users (via the option to switch to a non-validating resolver.) Contrast this to RPKI, wherein the introduction of origin validation into an ISP’s routing architecture has many operational considerations, and inherently includes the potential to readily impact the ISP's primary business under anything less than carefully planned and executed BGP origin validation deployment efforts. While I’m am certain that everyone deploying RKPI has BCP 185 memorized, the scope of any such impacts (and lack of viable workarounds by the impacted customers) inherently means the potential for business impact is greater than exists with deployment of DNSEC validation by ISPs – i.e. while I do believe that your comparison to DNSSEC is directionally correct, it fails overall due to the very real and significant difference in the magnitude of potential business impact to the relying party. /John John Curran President and CEO ARIN ________________________________ **** DISCLAIMER**** http://www.bics.com/maildisclaimer/
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
