Re: [sidr] two stranded docuemnts - stake time

[Stephen Kent <[e-mail]>]

Chris,

Here is my message to the SIDR list from 6/16:


    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.