Re: IETF privacy policy - update

Dave CROCKER <> Mon, 05 July 2010 18:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C05E73A690D for <>; Mon, 5 Jul 2010 11:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UUOD5ZUQBSVM for <>; Mon, 5 Jul 2010 11:40:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B526A3A676A for <>; Mon, 5 Jul 2010 11:40:17 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id o65IeCNV023010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jul 2010 11:40:17 -0700
Message-ID: <>
Date: Mon, 05 Jul 2010 11:40:11 -0700
From: Dave CROCKER <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: Marshall Eubanks <>
Subject: Re: IETF privacy policy - update
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Mon, 05 Jul 2010 11:40:18 -0700 (PDT)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Jul 2010 18:40:18 -0000


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.

> 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?

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.

> - an IAOC document for the actual privacy policy itself, which could be changed
> very quickly if (say) lawyers started beating down the doors.

if?  so we really don't have an urgent requirement?


   Dave Crocker
   Brandenburg InternetWorking