Re: Future Handling of Blue Sheets

David Morris <dwm@xpasc.com> Thu, 10 May 2012 09:17 UTC

Return-Path: <dwm@xpasc.com>
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 B547C21F84FD for <ietf@ietfa.amsl.com>; Thu, 10 May 2012 02:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.518
X-Spam-Level:
X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=-0.919, 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 rGJBV-WXg5Xn for <ietf@ietfa.amsl.com>; Thu, 10 May 2012 02:17:17 -0700 (PDT)
Received: from c2w3p-2.abacamail.com (c2w3p-2.abacamail.com [209.133.53.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4FB21F843A for <ietf@ietf.org>; Thu, 10 May 2012 02:17:17 -0700 (PDT)
Received: from xpasc.com (unknown [68.164.244.188]) by c2w3p-2.abacamail.com (Postfix) with ESMTP id 363BD3FBE7 for <ietf@ietf.org>; Thu, 10 May 2012 09:17:15 +0000 (UTC)
Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id q4A9HErr023369 for <ietf@ietf.org>; Thu, 10 May 2012 02:17:14 -0700
Date: Thu, 10 May 2012 02:17:14 -0700
From: David Morris <dwm@xpasc.com>
To: ietf@ietf.org
Subject: Re: Future Handling of Blue Sheets
In-Reply-To: <4FAB80F9.40207@gondrom.org>
Message-ID: <alpine.LRH.2.01.1205100210140.23269@egate.xpasc.com>
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>
User-Agent: Alpine 2.01 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-AV-Type: clean
X-AV-Accuracy: exact
X-Milter-Version: master.24-gef8a08a
X-CLX-ID: a120AD3GD7Hu1vr-4A0217G
X-CLX-Spam: false
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
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:17:17 -0000

On Thu, 10 May 2012, Tobias Gondrom wrote:

> On 10/05/12 16:35, John C Klensin wrote:
> > But it seems to me that takes us back to Russ's summary in that
> > it is normal, and arguably necessary, for a standards body to
> > record --and make available to those who are interested-- the
> > identities of those participating in meetings.
> 
> I do not dispute that.
> 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).
> As we did in the past, we can equally achieve this openness by requiring that
> an interested person requests this data (including then providing his own
> identify) as we do at the moment.

I object to the quantum change in ease of access and persistence of the
information. I see way too much aggregation of personal information and
don't think open-ness is justification for increasing that potential.

One of the ways we deal with SPAM and DOS attacks is to intentionally slow
the process. Ted's proposal would be vastly improved with the provision
that access, once authenticated, was delayed approximately the same
amount of time as the current manual process. Propably with some
form of the failed login approach ... maximum requests per week or
other similar unit of time.

David Morris