Re: IETF privacy policy - update

John C Klensin <john-ietf@jck.com> Tue, 06 July 2010 01:39 UTC

Return-Path: <john-ietf@jck.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 9FA853A6811 for <ietf@core3.amsl.com>; Mon, 5 Jul 2010 18:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.732
X-Spam-Level:
X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599]
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 WvwCRTD3cjs2 for <ietf@core3.amsl.com>; Mon, 5 Jul 2010 18:39:08 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 7B8C23A67B7 for <ietf@ietf.org>; Mon, 5 Jul 2010 18:39:08 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OVx7s-00016C-MN; Mon, 05 Jul 2010 21:39:08 -0400
Date: Mon, 05 Jul 2010 21:39:07 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net, Marshall Eubanks <tme@americafree.tv>
Subject: Re: IETF privacy policy - update
Message-ID: <61A4F69BF743EFD59BA45181@[192.168.1.128]>
In-Reply-To: <4C32270B.9020703@dcrocker.net>
References: <7022DEA1-7FC0-4D77-88CE-FA3788720B43@cdt.org> <4C322170.9040903@dcrocker.net> <4B42EB41-0502-4D51-8B43-A3EC30B58643@americafree.tv> <4C32270B.9020703@dcrocker.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: 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 01:39:10 -0000

--On Monday, July 05, 2010 11:40 AM -0700 Dave CROCKER
<dhc2@dcrocker.net> wrote:

> Marshall,
> 
> On 7/5/2010 11:28 AM, Marshall Eubanks wrote:
>> I assume (for I do not know) that people are worried about
>> time involved in bringing a new RFC to publication.
> 
> The IESG often states that it is not difficult to bring an RFC
> to publication.
> 
> In any event, what makes this document more urgent, and in
> need of less scrutiny and processing, that any other potential
> RFC?
> 
> Personally, I would expect a document that attends to
> explicitly and complexly legal concerns to need /more/
> scrutiny than an entry-level technical specification, not less.

Agreed.

>> I don't see why this couldn't be divided in the way that the
>> Trust Legal Provisions have been :
>> 
>> - a RFC to set the _goals_ and basic framework of the privacy
>> policy, which might change something like every 5 years (or
>> less often if we are lucky) and
> 
> You expect the privacy policy, itself, to change more
> frequently than this?

I would hope not (either), but experience indicates that we have
even more trouble getting legal documents right than we do
protocol documents.  Having a lightweight and speedy mechanism
for correcting an incorrect realization of a policy outline laid
out by the IETF seems reasonable.  While I agree with you (Dave)
that getting the policy principles in place should not be so
urgent as to justify being done in haste, our experience
(especially in the IPR area, which is likely to involve the same
lawyers, both professional and amateur) has been that,
sometimes, making a correction to specific mechanisms already
deployed may be urgent.

> Also, the implication of your suggestion is that we would have
> a goals and framework document /after/ we have actual
> policies. This seems a bit, ummmm, backward.  It would make
> more sense to have the two in one document, absent some
> expectation of one being more stable than the other.

I did not read that into Marshall's note but assumed that we
would lay out the policy principles (the "goals and framework
document") in the IETF first and then proceed to instruct the
IASA to generate a specific policy statement for community
review.     "Policies first" would seem backwards to me too...
to put it mildly.

    john