Re: [sidr] two stranded docuemnts - stake time

Stephen Kent <> Mon, 01 August 2016 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DD8F12D9BE for <>; Mon, 1 Aug 2016 05:50:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.588
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D5VuuU5nb4fA for <>; Mon, 1 Aug 2016 05:50:06 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 136EA12DB31 for <>; Mon, 1 Aug 2016 05:43:02 -0700 (PDT)
Received: from ([]:60644 helo=COMSEC.fios-router.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1bUCYZ-000GaD-1G; Mon, 01 Aug 2016 08:42:55 -0400
To: Tim Bruijnzeels <>
References: <> <> <> <> <> <> <> <>
From: Stephen Kent <>
Message-ID: <>
Date: Mon, 01 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: <>
Content-Type: multipart/alternative; boundary="------------77998F755231D8449E4DFEFA"
Archived-At: <>
Cc: Chris Morrow <>, sidr <>
Subject: Re: [sidr] two stranded docuemnts - stake time
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Aug 2016 12:50:08 -0000


> Although I appreciate that Randy is trying to explain the case in 
> terms anyone can understand, it would be preferable to keep it general.
>> (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.