Re: Future Handling of Blue Sheets

Tobias Gondrom <tobias.gondrom@gondrom.org> Thu, 10 May 2012 09:43 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 E4F2A21F866E for <ietf@ietfa.amsl.com>; Thu, 10 May 2012 02:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.735
X-Spam-Level:
X-Spam-Status: No, score=-96.735 tagged_above=-999 required=5 tests=[AWL=0.043, 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 L2NXyzonGOj1 for <ietf@ietfa.amsl.com>; Thu, 10 May 2012 02:43:13 -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 0BAAF21F866C for <ietf@ietf.org>; Thu, 10 May 2012 02:43:12 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=rd8HUd+t9O8a4g9PiPPwxP91UsinWDVHtA1KidXiCTow0dFs8XaqyoUNKbMim4xPa9aFPhnxyUG5FzOn8kpETfiJGknyxF/wUMkKwG51NCHENprFQwpL2jY3krS9xc30; 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 3515 invoked from network); 10 May 2012 11:43:11 +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:43:10 +0200
Message-ID: <4FAB8DA9.6060104@gondrom.org>
Date: Thu, 10 May 2012 17:43:05 +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: ynir@checkpoint.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> <4FAB7567.7070402@gondrom.org> <12F34D6725B91B95351EB144@JcK-HP8200.jck.com> <4FAB80F9.40207@gondrom.org> <4FAB85EA.7080608@dougbarton.us> <CE1FAD6B-C8D6-4BBC-9938-1E3A34B51782@checkpoint.com>
In-Reply-To: <CE1FAD6B-C8D6-4BBC-9938-1E3A34B51782@checkpoint.com>
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:43:14 -0000

+1
Agree with Yoav.
BR, Tobias

On 10/05/12 17:35, Yoav Nir wrote:
> On May 10, 2012, at 12:10 PM, 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?
> Well, there's the obvious issue of spam, although this post that I'm making right now provides my email address to the spammers in a much more convenient form. It's also convenient for headhunters. It also allows my employer to check whether I really went to sessions instead of just touring Paris. Is it the business of the IETF to help in these activities?
>
> I still don't get why you would want this published. My name on a blue sheet could mean that I was presenting for half the session, or that I was at the mike telling people they were wrong, or just sitting quietly in the back minding my own business and reading email. Blue sheets (unlike minutes and jabber logs) don't make such a distinction.
>
>> 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 think this would be a copyright violation, unless the IETF specifically authorized them to do so (which it shouldn't). I don't think the IETF should prosecute, but it's still a violation.
>
>> 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.
> I think that needle should not be threaded at all. A list of participants should maybe be kept (scanned or not) but never published without subpoena, just as it is now. I don't see any reason why publishing it (as opposed to recording actual participation) is a requirement for an open process.
>
> Yoav
>