On Tue, Jul 6, 2010 at 1:11 AM, Alissa Cooper <acooper(_at_)cdt(_dot_)org>
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(_at_)dcrocker(_dot_)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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf