Re: IETF subpoena processes update and a request

"John R Levine" <johnl@taugh.com> Sat, 25 March 2017 00:50 UTC

Return-Path: <johnl@taugh.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 07BAA1293E1 for <ietf@ietfa.amsl.com>; Fri, 24 Mar 2017 17:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=J5E1nHPp; dkim=pass (1536-bit key) header.d=taugh.com header.b=DV0ryk7+
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 Vl1QAauxZ50T for <ietf@ietfa.amsl.com>; Fri, 24 Mar 2017 17:50:08 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16CC126D73 for <ietf@ietf.org>; Fri, 24 Mar 2017 17:50:07 -0700 (PDT)
Received: (qmail 40658 invoked from network); 25 Mar 2017 00:50:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9ed0.58d5bebc.k1703; bh=ySbYqfojilZEr1+yQgEV8iclrPHulLJOsLtEUtyhufc=; b=J5E1nHPpwoNSAogOBqVSQAZq+eGrz6CAvwYacYHuiQTQafYwvE+BTvBInRp31M6G/R5RUtfl+9q1ZH/b1y3lJbo4XY0AF+uSGL8B5k3ZrGwK5LETZsNwhvb56RjaOfpgJgABd7lc0aOGiRqy6QTV4K0dOQWIoWrS+ExA1zksTryPJTpxnpODuOOpoNeCsPZo5JjoD8sMiqR8OiEbp5WJTsilxf/3Lr4qTldtO5xL5J19bwhRB0+9X/JMMliMLSjf
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9ed0.58d5bebc.k1703; bh=ySbYqfojilZEr1+yQgEV8iclrPHulLJOsLtEUtyhufc=; b=DV0ryk7+b2ULMr3R/+DJbFlAhFsMhPbgD4a1uaaw8HD37Wgvj2bSajoRQJsb1xyp3rFZMnYrZDSVf5KY9UpdCR92B6vLZGBYTokw9huXhi/uLzH7t050d7WqQDI5ktues9azr8M3DIBB4Tq78LzreqiyWoD9lmkDJaQKeryBPdJpBHkr3VqSuTuqi4e4gKjfUBzFdi+9UtoEvLG+OmrGGpfAGCv+Uw5SFe1SLgSVWfbwnoqZN4Rm3lNSPUrccO2R
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 25 Mar 2017 00:50:04 -0000
Date: Fri, 24 Mar 2017 20:50:04 -0400
Message-ID: <alpine.OSX.2.20.1703241826550.72979@ary.qy>
From: John R Levine <johnl@taugh.com>
To: Pete Resnick <presnick@qti.qualcomm.com>
Cc: IETF general list <ietf@ietf.org>
Subject: Re: IETF subpoena processes update and a request
In-Reply-To: <5DAE09F6-D7DE-47B4-ABA6-BC9A92DDEE4E@qti.qualcomm.com>
References: <20170324193951.85037.qmail@ary.lan> <5DAE09F6-D7DE-47B4-ABA6-BC9A92DDEE4E@qti.qualcomm.com>
User-Agent: Alpine 2.20 (OSX 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Vfx5AuLCi4tQ2vKJp-vfnqR0NqI>
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: Sat, 25 Mar 2017 00:50:10 -0000

>> Nearly all of the subpoenas that the IETF gets are stupendously boring
>> and routine, and I think this would be a poor addition to the IESG's
>> crowded schedule.
>
> And hence my earlier comment that I expect that "most of the time IETF 
> leadership ends up simply nodding at counsel, the IAOC, the IAD, etc.". ...

You've been on the IESG and I haven't, but I'm still scratching my head 
about why this process needs to change to give the IESG even a little more 
work after it's been working OK for over a decade.

>> ...there's no compelling reason for the IESG to know who it is.
>
> Whenever someone says, "there's no need for you to know this information", 
> when not preceded by a long explanation of an additional harm one is 
> incurring by simply knowing the piece of information, particularly when "you" 
> is the leadership of an organization, it sends up a giant red flag for me.

See Klensin's previous message.  The chance of reputation damage to 
someone named in a subpoena is significant, and the IESG has no legal 
expertise.

Here's a scenario: ISOC gets a subpoena from the L.A. county attorney, in 
connection with an investigation of abuse of a minor, send them what you 
have that shows whether Bob and Pete were in the foo session on March 25, 
2015.  Fine says the IESG, send them the blue sheets and the recording. 
The backstory is that Bob is in a messy divorce with accusations going 
back and forth, and he told the cops that he couldn't have done it because 
he was in Texas at the IETF, in fact he was in a session where Pete was 
presenting and they had a long argument at the mike which Pete will surely 
recall, but of course that's not in the subpoena.  So the cops sent the 
subpoena to see if the story holds up.

An IESG member, who was selected for his expertise in crypto algorithms, 
not criminal law, mentions in the bar late some evening, wow, there's 
something going on in L.A. about Bob and Pete and child abuse, and word 
gets around, with bad effects on Pete's career.  The timing makes it clear 
that the leak was from the IETF, the guilty party doesn't confess (he 
doesn't remember talking about it) so ISOC is hauled in front of a judge 
who asks why we show criminal subpoenas to a bunch of nerds with no legal 
experience rather than having our lawyer handle it like everyone else 
does.

Maybe that wouldn't happen, but the more people who know about something, 
the more likely it is to leak with bad results.

R's,
John