Re: IETF privacy policy - update

[Ted Hardie <[e-mail]>]

On Tue, Jul 6, 2010 at 1:11 AM, Alissa Cooper <[e-mail]> wrote:
> 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:

First, I strongly support having the privacy policy written down.  On several
occasions we've had folks conduct experiments where there was an obvious
need for a guiding policy.  Thanks for taking on the work.

But a bit more below.
>
> 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
>

But changing the policy to deal with things like the experiments is not
where I would want us to go.  Ideally, those constructing the experiments
do so within the framework of the policy, so that there is no need for
a change.

On some level, you may still need an elaboration if there is a judgment call
about whether some piece of data has specific characteristics, and I am
happy for that process to have a very quick resolution time (though I
suspect an appeals mechanism will be necessary).

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

If we construct your statement above as either "to publish elaborations"
or "to publish  understanding of the privacy sensitivity of specific data",
I think we're in agreement.

regards,

Ted Hardie



> 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
>>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>