Re: Future Handling of Blue Sheets

Tobias Gondrom <tobias.gondrom@gondrom.org> Thu, 10 May 2012 09:42 UTC

Return-Path: <tobias.gondrom@gondrom.org>
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 A4F4D21F85E4 for <ietf@ietfa.amsl.com>; Thu, 10 May 2012 02:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.478
X-Spam-Level:
X-Spam-Status: No, score=-96.478 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_82=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4r24zrN6U3YI for <ietf@ietfa.amsl.com>; Thu, 10 May 2012 02:42:50 -0700 (PDT)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 96BB821F84FB for <ietf@ietf.org>; Thu, 10 May 2012 02:42:49 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=pmTHvogS8WLIBKYSKKdIS7xdr88EjU8zyweOS7E2/ftj4YyBOIbRx/CH0uzGNIk2qSXPQX4KLzX5442yCDFF5SvA6v++LYYXhTRr9tPAOz58hBocSRyrJcy+GT4bYREa; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
Received: (qmail 3487 invoked from network); 10 May 2012 11:42:46 +0200
Received: from n2028211917.imsbiz.com (HELO ?10.65.1.159?) (202.82.119.17) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 May 2012 11:42:46 +0200
Message-ID: <4FAB8D91.5060201@gondrom.org>
Date: Thu, 10 May 2012 17:42:41 +0800
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: dougb@dougbarton.us
Subject: Re: Future Handling of Blue Sheets
References: <97BB17A56A65B20E9FB38128@JcK-HP8200.jck.com> <360B33DF-0603-4B86-B488-DDDBEDF2B10B@bbn.com> <64D096E2-78E1-4B4F-B227-42AB7B658FF6@cs.columbia.edu> <BE62B481-1FBD-4F82-92BA-EAC0D0519639@ietf.org> <alpine.LRH.2.01.1205061559060.10886@egate.xpasc.com> <92DE3992-7212-4DE4-A4FA-57AED9DFE827@ietf.org> <alpine.LRH.2.01.1205061851340.12673@egate.xpasc.com> <2A1B808B-217C-4B09-B2A7-E179B3CA8FC8@ietf.org> <4FAB5ED8.7070004@gondrom.org> <5D365E621E09E8B8DE2F4006@JcK-HP8200.jck.com> <4FAB7567.7070402@gondrom.org> <12F34D6725B91B95351EB144@JcK-HP8200.jck.com> <4FAB80F9.40207@gondrom.org> <4FAB85EA.7080608@dougbarton.us>
In-Reply-To: <4FAB85EA.7080608@dougbarton.us>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: john-ietf@jck.com, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 10 May 2012 09:42:50 -0000

Doug,

you are right in the end I can not prevent someone else from publishing 
this. Even today a party that subpoena'ed them might publish the data. 
(Or a person might just take a photo of the blue sheet in the room and 
publish that...)

Of course we can not control other people's actions, however the 
question remains whether we (as the IETF) do publish that data and how 
easy/fast we make it for others to publish that data.

Just to be clear, I agree basically with most of the proposal from the 
IESG.*
But when it comes to privacy I think we must be extremely careful and 
conservative with information, only releasing information where it 
really adds benefit to transparency. Because once released, it's 
impossible to get it back.
Thinking about how to thread the needle (as you put it), I don't agree 
that the current proposal is optimal, and I would reiterate my proposal 
to not publish the bluesheets in the proceedings but to make them 
available to an individual upon email request to the IETF secretariat, 
providing name and email of the requesting person (and with a disclaimer 
in the IETF answer that this information is not meant to be re-published 
to the public (note I intentionally say "public", i.e. sharing among 
groups would still be ok.)).
If we are worried about high volumes of requests, I would like to ask 
for more information on current volumes of subpoenas and why we get high 
volumes in the future. And if it's really too cumbersome for a person to 
answer the requests, we could then still discuss to use an email account 
based request system (IETF tools login) as proposed by Ted yesterday.

Best regards, Tobias


Ps.: *just as a disclaimer regarding the scanning part of the IESG 
proposal: I like it, but IMHO I would be slightly more cautious than the 
IETF counsel with the admissibility of scanned documents in court 
compared to paper originals. I've experienced quite some cases and legal 
discussions around value of proof of scanned documents.... - what I 
basically learned there was: scanning is ok in most IP jurisdictions, 
but handling the scanned data must use well documented procedures and 
access controls to keep the same level of non-repudiation of integrity 
and authenticity later in court.


On 10/05/12 17:10, Doug Barton wrote:
> On 5/10/2012 1:48 AM, Tobias Gondrom wrote:
>> What I dispute is that "make available to those who are interested"
>> necessarily leads to the need to broadcast the data (i.e. publish in the
>> proceedings).
> What is the harm you are trying to guard against by requiring the request?
>
> Or, to take a completely different tack, given that there are a non-zero
> number of people who think the data should be published, how do you
> intend to deal with someone who makes the request, and then puts it up
> on their own website?
>
> I don't hesitate to criticize when I think that the IESG gets it wrong,
> but in this case I think they threaded the needle about as well as it
> could be threaded.
>
> Doug
>