Re: [sidr] two stranded docuemnts - stake time

Chris Morrow <morrowc@ops-netman.net> Sun, 24 July 2016 17:24 UTC

Return-Path: <morrowc@ops-netman.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA8312D56D for <sidr@ietfa.amsl.com>; Sun, 24 Jul 2016 10:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level:
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQV7aov_lND0 for <sidr@ietfa.amsl.com>; Sun, 24 Jul 2016 10:24:50 -0700 (PDT)
Received: from relay.kvm02.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938B712D556 for <sidr@ietf.org>; Sun, 24 Jul 2016 10:24:49 -0700 (PDT)
Received: from mail.ops-netman.net (unknown [208.76.12.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 6DAB240918; Sun, 24 Jul 2016 17:24:46 +0000 (UTC)
Received: from morrowc-glaptop4.roam.corp.google.com.ops-netman.net (static-96-241-182-39.washdc.fios.verizon.net [96.241.182.39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 322338812DF; Sun, 24 Jul 2016 17:24:46 +0000 (UTC)
Date: Sun, 24 Jul 2016 18:24:45 +0100
Message-ID: <yj9oshuz3q5e.wl%morrowc@ops-netman.net>
From: Chris Morrow <morrowc@ops-netman.net>
To: Stephen Kent <kent@bbn.com>
In-Reply-To: <4866b582-0016-2136-1dc6-e95946eeff78@bbn.com>
References: <yj9oinvzi8gj.wl%morrowc@ops-netman.net> <87E65996-2ACD-4A3A-8D20-1C7911CBBB72@tislabs.com> <58c60c65-b96c-4984-4ba4-4d4e64e51538@bbn.com> <yj9ofur2iqgd.wl%morrowc@ops-netman.net> <m28twudtww.wl%randy@psg.com> <CAL9jLab9Zaz1UjJfjJNmjU3FcMkF+mSYKLj7VGKEydK0FKOjJg@mail.gmail.com> <4866b582-0016-2136-1dc6-e95946eeff78@bbn.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO)
Organization: Operations Network Management, Ltd.
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="ISO-2022-JP"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/_SKAGSL8Ztgt3hk88PPikO0MwJc>
Cc: Chris Morrow <morrowc@ops-netman.net>, sidr <sidr@ietf.org>
Subject: Re: [sidr] two stranded docuemnts - stake time
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jul 2016 17:24:52 -0000

At Fri, 22 Jul 2016 11:48:30 -0400,
Stephen Kent <kent@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)>]
>