[arin-ppml] Revisit RPKI TAL Relying Party Agreement?

[Job Snijders]

On Tue, Jan 31, 2017 at 09:42:50PM +0000, John Curran wrote:
> On 30 Jan 2017, at 3:14 PM, Job Snijders <job at ntt.net> wrote:
> > 
> >> Is it the presence of legal constraints that it is the concern, or the
> >> fact that ARIN requires explicit downloading (and thus awareness of
> >> this fact) that is the issue?
> > 
> > Both are a concern. Please note that I am not advocating that all legal
> > constraints should be lifted, for me its the results that matter: at
> > this point in time it appears that ARIN's TAL is not bundled with common
> > RPKI tools, and that to me is a problem.
> 
> Job - 
> 
> ARIN’s TAL is readily available (for any who wish it) via a simple
> download that requires a trivial amount of technical effort when
> compared to the related task of introducing RPKI data into a networks
> routing decisions. The act of obtaining ARIN’s TAL, while technically
> quite simple, is one that must be done explicitly.
>
> The reason that obtaining ARIN’s TAL must be done explicitly that the use 
> of ARIN’s RPKI data is not an activity to be undertaken lightly, and includes 
> responsibilities that we wish parties to carefully consider.   As others have 
> noted elsewhere in this thread, under US law it is indeterminate whether use 
> of an open RPKI repository would entail agreement to the corresponding terms 
> of usage (despite this practice being used by other RIRs), whereas obtaining
> ARIN’s TAL via explicit act is much more certain in this regard. 
> 
> > We seek to reduce friction down to the point of:
> >    `sudo apt-get install -y arin-rpki-magic`,
> > or that the RIPE NCC RPKI Validator can add the TAL directly to its
> > source code repository.
> 
> 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.

> While ARIN’s Board of Trustees has been quite consistent in its
> position that RPKI services are to be offered under clear terms and
> conditions, I will also bring this email thread to their attention for
> further consideration.

Thank you.

Kind regards,

Job