Re: IETF privacy policy - update

[Alissa Cooper <[e-mail]>]

Obviously, I started this process as an I-D, so I'm not necessarily  
opposed to having the privacy policy exist as an RFC. But in  
conversations with the IAOC and others, it seemed as though the RFC  
process might have two drawbacks for this kind of document:

1) While the RFC process is community consensus-based, the designation  
of IETF policies about personal data handling is not necessarily so.  
The policies around the RFID experiment at IETF 76 [1] and the  
policies around admission control data for IETF 78 and 79 [2] are both  
examples of this -- these policies were developed by the IAOC and  
others, and while in some cases they may have been put out to the  
community for comment after they were developed, their initial  
development was certainly not done via the community consensus-based  
model. Ideally the IETF privacy policy would document all of these  
policies before they come into force. If the privacy policy was an  
RFC, the substance of these policies would be subject to community  
review and would require consensus as well.

2) If the privacy policy is to be accurate, I do think it would change  
more often than an average RFC (considering things like the RFID  
experiment and the admission control for upcoming IETFs). Furthermore,  
even if changes are infrequent, they may come up quickly. A good  
privacy policy would document these changes before they occur. I think  
the argument can be made that if the policy has to go through the RFC  
process for each change, the changes may not be documented before they  
actually occur.

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.

Alissa

On Jul 6, 2010, at 2:39 AM, John C Klensin wrote:

>
>
> --On Monday, July 05, 2010 11:40 AM -0700 Dave CROCKER
> <[e-mail]> 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
>
>
>
>
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>