Return-Path: <kent@bbn.com>
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 0DD8F12D9BE
 for <sidr@ietfa.amsl.com>; Mon,  1 Aug 2016 05:50:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.588
X-Spam-Level: 
X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 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 D5VuuU5nb4fA for <sidr@ietfa.amsl.com>;
 Mon,  1 Aug 2016 05:50:06 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 136EA12DB31
 for <sidr@ietf.org>; Mon,  1 Aug 2016 05:43:02 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:60644 helo=COMSEC.fios-router.home)
 by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD))
 (envelope-from <kent@bbn.com>)
 id 1bUCYZ-000GaD-1G; Mon, 01 Aug 2016 08:42:55 -0400
To: Tim Bruijnzeels <tim@ripe.net>
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>
 <99F55C95-7589-4594-B1B1-8988682FBB46@ripe.net>
From: Stephen Kent <kent@bbn.com>
Message-ID: <67f9b7b7-d490-1671-3b30-8c1ab73d2d12@bbn.com>
Date: Mon, 1 Aug 2016 08:42:57 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <99F55C95-7589-4594-B1B1-8988682FBB46@ripe.net>
Content-Type: multipart/alternative;
 boundary="------------77998F755231D8449E4DFEFA"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/uFDVjsQCq65rkZtp7LV_0779GQQ>
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: Mon, 01 Aug 2016 12:50:08 -0000

This is a multi-part message in MIME format.
--------------77998F755231D8449E4DFEFA
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Tim,



>
> Although I appreciate that Randy is trying to explain the case in 
> terms anyone can understand, it would be preferable to keep it general.
agreed.
>
>> (Including a parenthetical note about the historical precedent of a 
>> Dutch court order involving RIPE is relevant and might be included.)
>
> If there was such a precedent, but there isn't. I have raised this 
> before, but again...
I am familiar with the incident. While it is true that the court did not 
order RIPE to do anything with RPKI data, the precedent it set has often 
been cited as an indication of what might happen in the future. That's 
why the adverse actions document identifies the following cause for some 
types of actions:

    There is also the possibility that a CA or repository operator may
    be subject to legal measures that compel them to generate "bogus"
    signed objects or remove legitimate repository data.

This is the sort of more formal language I have encouraged Randy to use 
in the LTA use cases doc, to no avail.

Steve

--------------77998F755231D8449E4DFEFA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Tim,<br>
    </p>
    <br>
    <div class="moz-cite-prefix"><br>
    </div>
    <blockquote cite="mid:99F55C95-7589-4594-B1B1-8988682FBB46@ripe.net"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div class="">
        <div>
          <div><br class="">
          </div>
          <div>Although I appreciate that Randy is trying to explain the
            case in terms anyone can understand, it would be preferable
            to keep it general.</div>
        </div>
      </div>
    </blockquote>
    agreed.<br>
    <blockquote cite="mid:99F55C95-7589-4594-B1B1-8988682FBB46@ripe.net"
      type="cite">
      <div class="">
        <div>
          <div><br class="">
          </div>
          <blockquote type="cite" class="">
            <div class=""><span style="font-family: Courier; font-size:
                12px; font-style: normal; font-variant-caps: normal;
                font-weight: normal; letter-spacing: normal; orphans:
                auto; text-align: start; text-indent: 0px;
                text-transform: none; white-space: normal; widows: auto;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                background-color: rgb(255, 255, 255); float: none;
                display: inline !important;" class="">(Including a
                parenthetical note about the historical precedent of a
                Dutch court order involving RIPE is relevant and might
                be included.)</span></div>
          </blockquote>
        </div>
        <br class="">
      </div>
      <div class="">If there was such a precedent, but there isn't. I
        have raised this before, but again...</div>
    </blockquote>
    I am familiar with the incident. While it is true that the court did
    not order RIPE to do anything with RPKI data, the precedent it set
    has often been cited as an indication of what might happen in the
    future. That's why the adverse actions document identifies the
    following cause for some types of actions:<br>
    <blockquote>There is also the possibility that a CA or repository
      operator may be subject to legal measures that compel them to
      generate "bogus" signed objects or remove legitimate repository
      data.<br>
    </blockquote>
    This is the sort of more formal language I have encouraged Randy to
    use in the LTA use cases doc, to no avail.<br>
    <br>
    Steve<br>
  </body>
</html>

--------------77998F755231D8449E4DFEFA--

