Re: Future Handling of Blue Sheets

Tobias Gondrom <tobias.gondrom@gondrom.org> Mon, 23 April 2012 10:00 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 F171121F8669 for <ietf@ietfa.amsl.com>; Mon, 23 Apr 2012 03:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.159
X-Spam-Level:
X-Spam-Status: No, score=-96.159 tagged_above=-999 required=5 tests=[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, RCVD_IN_SORBS_WEB=0.619, 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 n4VqNRa9RqIN for <ietf@ietfa.amsl.com>; Mon, 23 Apr 2012 03:00:09 -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 C812321F8668 for <ietf@ietf.org>; Mon, 23 Apr 2012 03:00:08 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=W6StENztCZvoPgmmXGqQZ69luW1wcmNnA5zbt1EMPQXrHuuP6E1sS27gPCGYtneYMDtx0CQgsvlx0IezUkbXpvjKnnyGC0Kkj0Gvo++CqFOCs4aGXBk7med0pG8YJHyE; 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 2031 invoked from network); 23 Apr 2012 12:00:05 +0200
Received: from unknown (HELO ?172.27.51.107?) (203.127.223.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Apr 2012 12:00:05 +0200
Message-ID: <4F952821.8080808@gondrom.org>
Date: Mon, 23 Apr 2012 18:00:01 +0800
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: brian.e.carpenter@gmail.com
Subject: Re: Future Handling of Blue Sheets
References: <2AC114D8-E97B-47A0-B7E0-9EF016DCB09F@ietf.org> <4F94D01F.3070102@gondrom.org> <DDB8050A-7A04-4A0F-A364-0E3E511DCB43@vigilsec.com> <4F94E4AB.5080706@gondrom.org> <4F94FDDB.1050401@gmail.com>
In-Reply-To: <4F94FDDB.1050401@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: 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: Mon, 23 Apr 2012 10:00:10 -0000

Brian,

On 23/04/12 14:59, Brian E Carpenter wrote:
> On 2012-04-23 06:12, Tobias Gondrom wrote:
>> Hi Russ,
>>
>> thank you for the information.
>> In this case, my preference would be not to publish the blue sheets with
>> the proceedings.
>>
>> Reasoning:
>> The blue sheet data can at some point be used to determine movement
>> profiles of individual attendees at the meeting to a finer granularity
>> than today and therefore can be an issue for privacy (even though I
>> recognize that this is a public meeting). The fact that we "may reduce"
>> the amount of subpoenas is a viable reason, still personal data should
>> be handled as conservative as possible. Without a significant and
>> measurable economic advantage by the publication, we should rather not
>> publish this data with the proceedings.
> Transparency with respect to IPR disclosures, or missing IPR disclosures,
> seems to me more important than the privacy issue. I take Randy's point
> that the information can be trawled for unwanted purposes, but IETF
> participation always carries that risk.

Actually this is not a question of what is more important:
I agree that we should have the blue sheets for the IPR reasons (and 
also so the secretariat can determine room sizes based on previous 
numbers).
All this is already achieved as it is today without always publishing 
the blue sheets to public.
So my proposal is to keep blue sheets (be it in paper or electronic 
document form) access limited to the IETF secretariat for administrative 
purposes (meeting room size) and make them available in case of 
subpoenas on a per request basis.
This will be a balanced solution to both, our intended use cases and the 
privacy of the attendees.

Best regards, Tobias


>
> Tim raised a valid point: more people might decline to sign. We already
> have some of that, and I don't have a socially acceptable solution
> to that.
>
> Actually we already systematically break our rules in RFC 2418 (BCP 25):
>     All working group sessions (including those held outside of the IETF
>     meetings) shall be reported by making minutes available.  These
>     minutes should include the agenda for the session, an account of the
>     discussion including any decisions made, and a list of attendees.
> It's only a "should" but when did you last see WG minutes with a list
> of attendees? In the old days of hard copy proceedings, I seem to
> remember the blue sheets being included sometimes as the lazy way
> of satisfying this rule.
>
>      Brian
>
>
>
>
>