[sidr] draft-ietf-sidr-lta-use-cases-05.txt

[Stephen Kent <[e-mail]>]

I read the latest version of this document and have a few comments, some 
of which I have made before, to no avail ;-).

I still find the wording of the three examples in Section 4 to be 
unnecessarily informal. I’ve provided suggested text for previous 
versions of this document that probably is still applicable, since the 
examples do not seem to have changed much. It seems preferable to 
describe the first motivating case without reference to a specific RIR. 
(Including a parenthetical note about the historical precedent of a 
Dutch court order involving RIPE is relevant and might be included.) 
There is language in the adverse actions document that could be used 
here to be more formal, less folksy. Since adverse actions is now a Wg 
document, one might even cite sections of it to support the examples. In 
the second example, the term “borrowed” is not defined. I think I know 
what is implied, and it seems inappropriate to possibly condone 
advertisement of address space allocated to another party, just because 
that party is not advertising the space to the global Internet. Why not 
just stick with private address space in this example? The third example 
is a six-line, run-on sentence, so it’s not easy for a reader to be 
certain what the example really implies.

The Notes section (5) seems to offer an analysis of requirement for 
potential solutions to address the use cases. Maybe a better section 
title is warranted.

David’s SLURM document describes a mechanism that seems to address the 
local, customized view requirements described in Section 4. (David says 
that it addresses the second and maybe third uses cases, but I think he 
was modest in his assertion.) SLURM could support the first use case, if 
the community decided on a mechanism to distribute SLURM files in 
response to a CA being compelled to modify RPKI data. (It would be easy 
to ad a digital signature to the files, to provide authentication and 
integrity, but the there’s the little issue of key management and a 
suitable trust model …) The design accommodates merging of multiple 
SLURM files, meeting that requirement as stated in this section. Note 
that SLURM does not require modifying ROAs or GB records. It is a 
post-processing mechanism using “local” configuration data that 
overrides the global data acquired from the RPKI. This suggests that 
some of the comments in Section 5 are not accurate, e.g., ones that 
allude to the problems posed by not having keys to sign ROAs, etc. 
Although there is a need to achieve the effect of modifying, creating 
and/or replacing ROAs and GB records, that effect does not have to 
involve signatures on the affected data, as suggested in the first and 
third paragraphs of Section 5.

Typos:

… to be a formally formally defined set … (repeated word)

… 'recipes' should be mergable (mergeable?)

The Security Considerations text seems unduly negative. The approach 
being proposed here is not violating global security, because the 
results are intended to be local. How about the following wording:

The use cases described in Section 4, and the notes for suggested 
solution approaches in Section 5, are not intended to undermine the 
security provided by the RPKI. Rather they identify potential obstacles 
to widespread adoption of the RPKI, and suggest changes that would 
enable network operators to generate custom “views” of the RPKI for use 
on a local basis. Providing the ability to create local RPKI views does 
not adversely affect global routing security.