On Tue, Jul 6, 2010 at 1:11 AM, Alissa Cooper <acooper@xxxxxxx> 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 >> <dhc2@xxxxxxxxxxxx> 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 >> Ietf@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf >> > > > > > > > > > > > > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf