Re: Future Handling of Blue Sheets

Tobias Gondrom <tobias.gondrom@gondrom.org> Thu, 10 May 2012 07:59 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 3033321F85D4 for <ietf@ietfa.amsl.com>; Thu, 10 May 2012 00:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.778
X-Spam-Level:
X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[AWL=0.000, 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, 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 zK5voOqV3KK6 for <ietf@ietfa.amsl.com>; Thu, 10 May 2012 00:59:42 -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 25BED21F85C3 for <ietf@ietf.org>; Thu, 10 May 2012 00:59:41 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=qjbd9ydhMTn2aIPOgOTr11UAHK2l0pL65nEz2qeGSyeEOvXOcy4PGV2XY/DNpwPhXVgDB6KUaPXLyaYlwUvDPhrD7MM9l0xzO2BMGjEPks3wfF/KAcQNumuLN/0KtKGc; 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 1951 invoked from network); 10 May 2012 09:59:39 +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 09:59:39 +0200
Message-ID: <4FAB7567.7070402@gondrom.org>
Date: Thu, 10 May 2012 15:59:35 +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: john@jck.com
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>
In-Reply-To: <5D365E621E09E8B8DE2F4006@JcK-HP8200.jck.com>
Content-Type: text/plain; charset="ISO-8859-1"; 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: Thu, 10 May 2012 07:59:43 -0000

John,

sorry, maybe I did not articulate myself precisely enough. I did not 
intend to say it would be published in real-time. What I wanted to 
communicate is that we would collect that data only during daytime and 
only with 2hours-granularity as it's only meeting attendance in which 
room you are (and publish it at any point in time later). However, we 
would keep it public indefinitely (in the proceedings).

Like you, I am very cautious about broadcasting my travel plans. Plus, I 
am not only concerned about in advance and real-time, but also about 
broadcasting to the public places I've been in the past (or for that 
matter any personal information).

Best regards, Tobias



On 10/05/12 15:09, John C Klensin wrote:
> (top post)
> Tobias,
>
> Constructing and then attacking strawmen is not helpful.
>
> As far as I know, no one has proposed making blue sheet
> information --and hence precise location information for
> identified individuals-- available to the public in real time
> during the meetings.   As one of, I assume, many members of this
> community who will not broadcast my travel plans to social
> networks, etc., until after I return home, I would strenuously
> object to any such thing but, again, as far as I know, no one
> proposed it.
>
>       john
>
>
> --On Thursday, May 10, 2012 14:23 +0800 Tobias Gondrom
> <tobias.gondrom@gondrom.org>  wrote:
>
>> Dear Russ,
>>
>> please forgive me for adding one more comment on that after
>> you judged on rough consensus.
>>
>> As you said this rough consensus is quite rough (if we may
>> call it "rough consensus").
>> I would like to point out two things:
>> 1. the statement "(1) Rough consensus: an open and transparent
>> standards process is more important to the IETF than privacy
>> of blue sheet information." puts transparent process in
>> competition with privacy. This is misleading, because there is
>> no contradiction between an open and transparent process and
>> privacy of personal information on this one. For example the
>> availability of blue sheet information on request by an
>> authenticated person does allow full transparency without
>> broadcasting the personal location information. (e.g. see also
>> Ted's proposal from yesterday)
>> (Furthermore, if I would be devil's advocate, I would question
>> this comparison even further, because it could be misread as
>> stating that the current standards process as it is today
>> (with blue sheets on request) is not open or transparent...)
>>
>> 2. if consensus is so rough, we should also consider that the
>> subject of the email discussion was maybe not clear enough
>> about its impact to inform the audience of the consequences of
>> the discussion and the consensus to be measured. We could
>> equally have used a subject like this: "IETF wants to publish
>> your specific locations / whereabouts (within 10m) on an
>> 2-hourly basis during the day for each meeting and keep this
>> information available published on the website indefinitely."
>> It might have resulted in a different rough consensus.
>
>
>