At Fri, 22 Jul 2016 11:48:30 -0400, Stephen Kent <k...@bbn.com> wrote: > > [1 <text/plain; utf-8 (8bit)>] > Chris, > > Here is my message to the SIDR list from 6/16: >
great, thanks! > > 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. > > [2 <text/html; utf-8 (8bit)>] > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
