Re: IETF privacy policy - update

Eliot Lear <lear@cisco.com> Tue, 06 July 2010 08:32 UTC

Return-Path: <lear@cisco.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD8E3A67EB for <ietf@core3.amsl.com>; Tue, 6 Jul 2010 01:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvxi9vI529JZ for <ietf@core3.amsl.com>; Tue, 6 Jul 2010 01:32:19 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2C7B63A67DB for <ietf@ietf.org>; Tue, 6 Jul 2010 01:32:19 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAGeGMkxAZnwN/2dsb2JhbACDHJxmcaQBiSiRAoEpgwpyBIg6
X-IronPort-AV: E=Sophos;i="4.53,545,1272844800"; d="scan'208";a="128998870"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2010 08:32:20 +0000
Received: from ams3-vpn-dhcp4923.cisco.com (ams3-vpn-dhcp4923.cisco.com [10.61.83.58]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o668WJuv003898; Tue, 6 Jul 2010 08:32:20 GMT
Message-ID: <4C32EA18.4020402@cisco.com>
Date: Tue, 06 Jul 2010 10:32:24 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: Alissa Cooper <acooper@cdt.org>
Subject: Re: IETF privacy policy - update
References: <7022DEA1-7FC0-4D77-88CE-FA3788720B43@cdt.org> <4C322170.9040903@dcrocker.net> <4B42EB41-0502-4D51-8B43-A3EC30B58643@americafree.tv> <4C32270B.9020703@dcrocker.net> <61A4F69BF743EFD59BA45181@[192.168.1.128]> <12333DE7-DE1E-4306-87AE-ACB605585245@cdt.org>
In-Reply-To: <12333DE7-DE1E-4306-87AE-ACB605585245@cdt.org>
X-Enigmail-Version: 1.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 06 Jul 2010 08:32:20 -0000

 Alissa,

Thanks very much for your elaboration.  I would agree with your
conclusion at the bottom of your note:

> With that said, laying out the core of the policy in an RFC and then
> having a speedier mechanism to publish changes (which can also be
> incorporated into the core policy when the RFC publication schedule
> allows) seems like a decent option.

A good policy allows for appropriate levels of delegation of authority
and flexibility.  It also allows the community to set bars beyond which
those charged with decisions may not go.  For instance, it may be the
case that the community values privacy so much that it would not be
possible to meet both the IETF privacy policy and local laws of certain
places, leading to an understanding of what venues would be available,
and what venues would not.

Eliot