Re: IETF subpoena processes update and a request

Pete Resnick <presnick@qti.qualcomm.com> Fri, 24 March 2017 16:47 UTC

Return-Path: <presnick@qti.qualcomm.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF63127078; Fri, 24 Mar 2017 09:47:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.022
X-Spam-Level:
X-Spam-Status: No, score=-7.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
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 kMtPatgOycRD; Fri, 24 Mar 2017 09:47:18 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E68120727; Fri, 24 Mar 2017 09:47:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1490374038; x=1521910038; h=from:to:subject:date:message-id:in-reply-to:references: mime-version:content-transfer-encoding; bh=sQlaUj4U1C2JXNxL4yzfeKQC6kwAshXZCkseapV4khQ=; b=WwY702xt879KmIb+AKPqjRBeaGpu/yJB49tYYtNZQGMZkyHUq9v32Mee 5JW625HDofB+3e6AIzt27LPxD6Cq6Y3IUHC3gEvM6tEjupmJJCeogGvfa 0Dlfwc+DCwPIAU0p65Rw9UAgpLTbqSJ+wcnnnjdbOaXAGvQlE+r/h1RHY s=;
X-IronPort-AV: E=Sophos;i="5.36,215,1486454400"; d="scan'208";a="367894461"
Received: from unknown (HELO ironmsg02-R.qualcomm.com) ([10.53.140.106]) by wolverine02.qualcomm.com with ESMTP; 24 Mar 2017 09:47:15 -0700
X-IronPort-AV: E=McAfee;i="5800,7501,8476"; a="925529008"
X-MGA-submission: MDHii+pdt/+FGnGuQYSPLAo9C7EPDlyXF4yO75qg/ImznO1NFQ2kOJZFS9VZN1JI0GRGb9+5eIzkVWWcVRAjuPtJTs9zfWL3TvbmqmtLlROV+dqjIgKFAkJ87UO+Ab6yEOtN3XGKtoHK3mPzuA5H0wXV
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Mar 2017 09:47:15 -0700
Received: from [10.64.118.210] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 24 Mar 2017 09:47:14 -0700
From: Pete Resnick <presnick@qti.qualcomm.com>
To: ietf@ietf.org, IETF Chair <chair@ietf.org>
Subject: Re: IETF subpoena processes update and a request
Date: Fri, 24 Mar 2017 11:47:13 -0500
Message-ID: <FB90DAC1-5822-4A33-9A06-C07B61CA9847@qti.qualcomm.com>
In-Reply-To: <149033560170.22298.4992160350083194861.idtracker@ietfa.amsl.com>
References: <149033560170.22298.4992160350083194861.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"; markup="markdown"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To NASANEXM01F.na.qualcomm.com (10.85.0.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/WhGSe894XVQrUL8JeyrQxP8_-C8>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Mar 2017 16:47:20 -0000

To deal with the second issue, it seems to me that we should address the 
first issue by making it crystal clear in the procedures that the 
subpoena must go to the entire IESG, not just the chair, and that 
whatever action is taken on the subpoena be approved by the IESG (with 
advice of counsel). If the entire IESG gets a copy of the subpoena, and  
our procedures make it clear to any court or other issuing authority 
that more than one person outside of their jurisdiction will be seeing 
the subpoena, perhaps that will mitigate the second issue.

If the current de-facto procedure has removed IETF leadership from the 
process, it is a problem that should be fixed not by changing the 
documented procedures, but by returning to them. It may be that most of 
the time IETF leadership ends up simply nodding at counsel, the IAOC, 
the IAD, etc., but they should absolutely be included.

Like others, I wonder about the prudence of naming ISOC (and certainly 
ISOC in the US) as the recipient for legal service. I'd like to hear 
from lawyers about other possibilities.

pr

On 24 Mar 2017, at 1:06, IETF Chair wrote:

> Occasionally the IETF is served with a subpoena, typically to assist
> finding prior art, documents and list discussions, in an effort to
> resolve patent disputes. We encourage everyone to just use our
> publicly available resources instead of formal requests, but we
> do get a few subpoenas every year. The IETF charges a fee
> for the service. The IETF makes these civil subpoenas and
> the primary response public at [1].
>
> The IAOC Legal Committee has identified two issues with the
> existing procedures [2]. First off, practices have evolved somewhat
> since the procedures were last updated in 2007, and are out of
> date. For instance, the subpoenas are today handled by IETF Legal
> Counsel, the Legal Committee Chair, the IAD and record custodians
> such as the Secretariat and the RFC Publisher. Others, such as the
> IETF Chair are not usually involved, despite what the existing
> procedures say.
>
> Secondly, due to a recent request that we received, we now
> realize that the existing procedures for the publication of
> subpoenas do not address situations where we might be
> ordered or requested by law enforcement authorities to not
> post the subpoena and response. These may include cases
> where a subpoena identifies a person or a company. These
> are criminal rather than civil cases. We do not think it is
> necessarily obvious what we should do here. For instance,
> it might not be the right thing from the privacy point to
> post details of requests that identify a person. There are
> more cases, and some tradeoffs to consider.
>
> Large Internet companies that hold user data have developed
> policies to deal with some of these issues. The IETF’s situation
> is of course somewhat different. For instance, most data that
> the IETF has is publicly visible anyway. There’s some additional
> data of course, and even for the public data our ability to vouch
> for the authenticity of, e.g., an Internet-Draft from a given year
> can be important. And of course, unlike the large Internet
> companies, our legal department consists of much smaller
> force, at least in terms of number of people :-)
>
> The IAOC legal committee believes that we need two things.
> First, we need an update of the procedures in general, which
> is largely an internal organisational matter. Secondly, we need
> to develop a policy to answer the cases where confidentiality
> is either requested by law enforcement authorities or is
> otherwise the right thing. This is a policy question which we
> believe is best answered through community opinion, and
> obviously also careful legal review.
>
> The plan is for the Legal committee to do two things this
> spring. First develop and post the general update, which we
> post to the community for information and feedback. Second,
> develop an initial approach regarding an answer to the policy
> question and post it to the community for discussion. Please
> participate in that discussion — we’ll send details about where
> and how when we post the initial proposal. Once the community
> discussion comes to a conclusion, we will adopt the policy as
> defined by the community and the legal situation. If anyone
> has input on this topic, let us know. It is also fine to send
> suggestions before the proposal is posted.
>
> Jari Arkko, IETF Chair
>
> [1] https://iaoc.ietf.org/subpoenas.html
> [2] https://iaoc.ietf.org/subpoena-procedures.html