Comments on <draft-cooper-privacy-policy-01.txt>

Bob Hinden <bob.hinden@gmail.com> Thu, 08 July 2010 22:05 UTC

Return-Path: <bob.hinden@gmail.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 B85B23A681F for <ietf@core3.amsl.com>; Thu, 8 Jul 2010 15:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.484
X-Spam-Level:
X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=1.256, BAYES_20=-0.74, GB_I_INVITATION=-2, GB_I_LETTER=-2]
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 YWneiZq7eqmP for <ietf@core3.amsl.com>; Thu, 8 Jul 2010 15:05:16 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id CDAE43A68F9 for <ietf@ietf.org>; Thu, 8 Jul 2010 15:05:02 -0700 (PDT)
Received: by pzk6 with SMTP id 6so356868pzk.31 for <ietf@ietf.org>; Thu, 08 Jul 2010 15:05:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Ajz3Pao8utvCQRciNjy02NBfFmrPxF+WdrCZzcjlaSU=; b=Oq78DzzwphCvjVPVSl32YNLQFJ0uueSrcuFzJfpvd7suVX16bflAvtPQsP6vhmX7EU GIO0SOMi3EBdKVlTIBAZva5zGzyxikIQmStTa+ahxCLLn7mxHL5sW3ntVq+rQr+NiqfZ hz/MSg1T95tLbMdQKKFhlyxqBl0HvbAW42aO0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=XxIT6Gnh5wEE2GIO0X5P8msnJ3NnHie/l6/OA+ZYPWz0ldPUPv3pBSs7Gtlatz0g1B q/Nq+Pdrsb+rJ7gzNsGxGdu1FsKDjrP66tnL/jH3GLNDU5Ij0Wgmnq59MBof7WnGAZO1 84v/mgS4NGt/JuLSYZdm6P2yhM0IqS656HHPo=
Received: by 10.114.24.3 with SMTP id 3mr10192595wax.177.1278626704336; Thu, 08 Jul 2010 15:05:04 -0700 (PDT)
Received: from dhcp-209.97.124.227.us.checkpoint.com ([209.97.124.227]) by mx.google.com with ESMTPS id k23sm2261121waf.17.2010.07.08.15.05.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 08 Jul 2010 15:05:03 -0700 (PDT)
Subject: Comments on <draft-cooper-privacy-policy-01.txt>
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Bob Hinden <bob.hinden@gmail.com>
In-Reply-To: <7022DEA1-7FC0-4D77-88CE-FA3788720B43@cdt.org>
Date: Thu, 08 Jul 2010 15:05:00 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <47076F01-CC4C-45E6-803E-8E2516BE15AC@gmail.com>
References: <7022DEA1-7FC0-4D77-88CE-FA3788720B43@cdt.org>
To: Alissa Cooper <acooper@cdt.org>
X-Mailer: Apple Mail (2.1081)
Cc: Bob Hinden <bob.hinden@gmail.com>, IETF-Discussion list <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: Thu, 08 Jul 2010 22:05:23 -0000

Alissa,

No hats on, these are my personal views.

I have now read the draft.  My overall comment is that I am not convinced if this is needed and am sympathetic to the views expressed on the mailing list that this is solving a problem the IETF doesn't have.

Comments below.

Bob


General comments:

If the IETF is to have a privacy policy, I would prefer it to be much simpler and of the form where it first starts with a general statement that the IETF does it's work in public and almost all information information supplied to the IETF is made public and will be available on the IETF (and other related) web sites.  I would then list the exceptions.  For example, credit card information for meeting registration and social tickets, and information for "letters of invitation".   Note: As I read the draft, there is very little that actually falls into the private category.  This leads to to wonder about the scope of the problem this draft is solving.

The IETF goes to great length to tell people about how we do our work and what is considered a public contribution, via the Note Well.  I would be surprised if anyone thought otherwise.  Doing our work in public is essential to how the IETF works.

Detailed Comments:

I have issues with the Introduction.  The first sentence says: 

   In keeping with the goals and objectives of this standards body, the
   IETF is committed to the highest degree of respect for the privacy of
   IETF participants and site visitors.

This makes it sound like the highest priority of the IETF is Privacy.  I don't think this is true as I described above.  The vast majority of what the IETF does in Public.  There is very little that is Private.  The IETF is careful about what needs to be kept private and does not disclose it.

The Introduction says:

   This policy explains how the IETF applies the Fair
   Information Practices -- a widely accepted set of privacy principles
   [1] -- to the data we obtain.

I don't know if it is appropriate that the IETF apply these practices.  Or if there are other practices that would be more appropriate.  The IETF is different from other organizations in that much of our data is public and not private.

The rest of the Introduction appears to be a summary of the first reference:

   [1]  Organization for Economic Cooperation and Development, "OECD
        Guidelines on the Protection of Privacy and Transborder Flows of
        Personal Data",  http://www.oecd.org/document/18/
        0,3343,en_2649_34255_1815186_1_1_1_1,00.html, 1980.

I don't know anything about this web page, who produced it, how stable it is, etc, etc.  It is fairly long, around 21 pages.  I don't know if this is appropriate for the IETF.  I think it would better to not include this information as it is hard to judge how appropriate it is.  Also, some of the practices seem to be at odds with normal IETF practices.  For example, it implies that individuals have complete control of the data the IETF makes public.  This isn't true in most cases.

Section 2 and 3

A lot these section is a summary of what is defined in other places (References 2, 3, 4, 5, 7, 8).  Other parts of the text are fairly generic, such as the information that a web server can learn about a web client.  Not thing very IETF specific here.  I don't see very much value repeating this.

Section 4

The first paragraph:

   The IETF does not sell, rent, or exchange any information that we
   collect about our participants or site visitors.  However, we will
   disclose information under the following circumstances:

The first two "sell & rent" is true, but the "exchange" is not true as you state later in the section.  Much of the data we collect is exchanged.  

Section 5

I am not really qualified to comment on the specifics here, such as how long credit card or letter of invitation information needs to be retained.  I would have thought that all financial data needs to be kept for some number of years.  

This describes our current operational practices regarding log files.  Including specific times for retention will make it hard to change this in the future.  Also, if log files are going to be covered, what happens to the backups?  Are we required to scrub the backups?  This would be difficult and expensive.  What about backups of credit card information?


Section 10

In the acknowledgment section you cite the IAOC.  The IAOC has not done any formal review of this draft.  It is better if you cite the people in the IAOC you have discussed this with you and not list the IAOC.  

Now that I have written this, you can cite me if you choose :-)


Section 11

I think most of the references are Normative, not Informative.  That is, this draft depends on these documents.