Re: Future Handling of Blue Sheets

Tim Chown <tjc@ecs.soton.ac.uk> Sun, 17 June 2012 12:39 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
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 110C621F8610; Sun, 17 Jun 2012 05:39:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 JPlSFEBTXkht; Sun, 17 Jun 2012 05:39:53 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id C3B7521F8602; Sun, 17 Jun 2012 05:39:51 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q5HCdaAo013215; Sun, 17 Jun 2012 13:39:36 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q5HCdaAo013215
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1339936776; bh=9z+/MbbalsC8KuXJLzCHLGJsy9s=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=ue2dzfu4W4xvFyn9s7zzwBAHT05qs3/DUqpDWT1gscftkK9U6x2vfHRiGEGRZCReW HA24hs3DyOz2lJCAhiA452WoA7s+KV/VXiapCiHY1KW2v0VBJRXZHJq5YFdZsbnYOj RIRHc1KmQnGBijIYvmwLw8A4MdRIQRnx80qmkTyg=
Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP id o5GDdZ0544132751Fw ret-id none; Sun, 17 Jun 2012 13:39:36 +0100
Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q5HCcEKD016567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Jun 2012 13:38:17 +0100
Subject: Re: Future Handling of Blue Sheets
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F017A7C056CA6@il-ex01.ad.checkpoint.com>
Date: Sun, 17 Jun 2012 13:38:13 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|6b1bc7fb740b086f9e9016821e20f316o5GDdZ03tjc|ecs.soton.ac.uk|4DC36834-60DD-40A8-9C4F-A5BE295D4081@ecs.soton.ac.uk>
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> <D21AF73E-AC26-4ED7-9A85-2F4B6246E238@ietf.org> <F9874821-601D-4655-AB91-C648AC10E49D@standardstrack.com> <616737881-1339796556-cardhu_decombobulator_blackberry.rim.net-133583724-@b2.c2.bise6.blackberry> <4FDC0280.8060505@bogus.com> <E01DF13C-F351-4F3E-B82E-DBFFDB252500@ecs.soton.ac.uk> <EMEW3|71e7e6f840161bab9e911f1161b36a93o5FBre03tjc|ecs.soton.ac.uk|E01DF13C-F351-4F3E-B82E-DBFFDB252500@ecs.soton.ac.uk> <006FEB08D9C6444AB014105C9AEB133F017A7C056CA6@il-ex01.ad.checkpoint.com> <4DC36834-60DD-40A8-9C4F-A5BE295D4081@ecs.soton.ac.uk>
To: Yoav Nir <ynir@checkpoint.com>
X-Mailer: Apple Mail (2.1278)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=o5GDdZ054413275100; tid=o5GDdZ0544132751Fw; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: q5HCdaAo013215
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Cc: "ietf-bounces@ietf.org" <ietf-bounces@ietf.org>, IETF Chair <chair@ietf.org>, IETF <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: Sun, 17 Jun 2012 12:39:54 -0000

The registration number links to a registration that includes an email address, should that need to be looked up for some reason later.

Holding minimal information for the purpose, and keeping that information as non-identifiable to the holder as possible, would be nice properties?

Tim

On 17 Jun 2012, at 08:36, Yoav Nir wrote:

> This creates a distinguished identity, so if two "Fei Zhang"s attended in Paris (only case I found in the attendee list), this would distinguish which of them attended a particular meeting. It would not, however, tie them to an identity on the mailing list, or to the "Fei Zhang" who attends the Vancouver meeting, so I'm not sure what purpose it serves.
> 
> Yoav
> 
> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Tim Chown
> Sent: 16 June 2012 13:54
> To: Joel jaeggli
> Cc: IETF Chair; IETF; ietf-bounces@ietf.org
> Subject: Re: Future Handling of Blue Sheets
> 
> If the purpose is simply differentiation of people with the same names, could we not ask people to enter the last four digits of their IETF registration number, which would presumably be unique, while being easy to remember?  The number could even be on your badge to always be easy to look up.
> 
> Unless there's some reason to keep registration numbers private?
> 
> That would also allow poorly handwritten names to more readily be checked/corrected by OCR when the sheets are scanned.
> 
> Tim
> 
> On 16 Jun 2012, at 04:50, Joel jaeggli wrote:
> 
>> On 6/15/12 14:42 , edj.etc@gmail.com wrote:
>>> I presume it is the same data that people input into the "Organization" field when they register for the meeting.
>> 
>> I do change mine based on what capacity I'm attending a particular 
>> meeting in. That goes for email address on existing blue sheets as well...
>> 
>> The nice people who send me a check every two weeks don't generally 
>> fund my attendance.
>> 
>>> Regards,
>>> 
>>> Ed  J.
>>> 
>>> -----Original Message-----
>>> From: Eric Burger <eburger-l@standardstrack.com>
>>> Sender: ietf-bounces@ietf.org
>>> Date: Fri, 15 Jun 2012 17:37:50
>>> To: IETF Chair<chair@ietf.org>
>>> Cc: IETF<ietf@ietf.org>
>>> Subject: Re: Future Handling of Blue Sheets
>>> 
>>> Do we have guidelines as to what is an "organization affiliation"?
>>> 
>>> On Jun 14, 2012, at 5:26 PM, IETF Chair wrote:
>>> 
>>>> Two things have occurred since the message below as sent to the IETF mail list.  First, we got a lawyer in Europe to do some investigation, and the inclusion of the email address on the blue sheet will lead to trouble with the European privacy laws.  Second, Ted Hardie suggested that we could require a password to access the scanned blue sheet.
>>>> 
>>>> Based on the European privacy law information, the use of email will result in a major burden.  If the email address is used, then we must provide a way for people to ask for their email address to be remove at any time in the future, even if we got prior approval to include it.  Therefore, I suggest that we collect organization affiliation to discriminate between multiple people with the same name instead of email address.
>>>> 
>>>> Based on Ted's suggestion, I checked with the Secretariat about using a datatracker login to download the scanned blue sheet.  This is fairly easy to do, once the community tracking tools are deployed.  However, with the removal of the email addresses from the blue sheets, it is unclear that there is any further need for password protection of these images.  Therefore, I suggest that we proceed without password protection for the blue sheet images.
>>>> 
>>>> Here is a summary of the suggested way forward:
>>>> 
>>>> - Stop collecting email addresses on blue sheets;
>>>> 
>>>> - Collect organization affiliation to discriminate between multiple 
>>>> people with the same name;
>>>> 
>>>> - Scan the blue sheets and include the images in the proceedings for 
>>>> the WG session;
>>>> 
>>>> - Add indication to top of the blue sheet so people know it will be 
>>>> part of the proceedings; and
>>>> 
>>>> - Discard paper blue sheets after scanning.
>>>> 
>>>> Russ
>>>> 
>>>> 
>>>> On May 6, 2012, at 12:46 PM, IETF Chair wrote:
>>>> 
>>>>> We have heard from many community participants, and consensus is quite rough on this topic.  The IESG discussed this thread and reached two conclusions:
>>>>> 
>>>>> (1) Rough consensus: an open and transparent standards process is more important to the IETF than privacy of blue sheet information.
>>>>> 
>>>>> (2) Rough consensus: inclusion of email addresses is a good way to distinguish participants with the same or similar names.
>>>>> 
>>>>> 
>>>>> Based on these conclusions, the plan is to handle blue sheets as follows:
>>>>> 
>>>>> - Continue to collect email addresses on blue sheets;
>>>>> 
>>>>> - Scan the blue sheet and include the image in the proceedings for 
>>>>> the WG session;
>>>>> 
>>>>> - Add indication to top of the blue sheet so people know it will be 
>>>>> part of the proceedings; and
>>>>> 
>>>>> - Discard paper blue sheets after scanning.
>>>>> 
>>>>> 
>>>>> On behalf of the IESG,
>>>>> Russ
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> Scanned by Check Point Total Security Gateway.