--On Thursday, July 15, 2010 16:37 +0100 Alissa Cooper
I tend to think that privacy risk isn't so much about the
percentage of sensitive data collected as about the
sensitivity of any data collected. The IETF interacts with
credit card numbers, passport numbers, authentication
credentials, and other kinds of data that are widely perceived
to be sensitive. I think those deserve documentation (as do
less sensitive data elements like web logs, but I can
understand why others may disagree on that point).
Perhaps the above suggests that we need to parse this discussion
into two separate privacy policies. The IETF went to a great
deal of effort a few years ago to reorganize its administrative
functions and clearly separate them from
IETF-as-Standards-Developer. Remembering that neither the IETF
nor the IASA have an actual corporate existence, the IETF
actually does _not_ "interact[s] with credit card numbers [or]
passport numbers". The IASA does. There is some IETF
interaction with "authentication credentials" (such as email
addresses), but that is fairly lightweight and rather public.
Would it be useful to redefine the question into
in furtherance of its administrative role.
and related capacities.
While there may be some gray areas at the margins (e.g., I don't
know whether a meeting attendance list would fall most naturally
under an IASA or IETF policy statement even though I'm pretty
such I know what should be said above it), it seems to me that
the IASA one is far more important and much more easily
accomplished, in part because most IASA operations should
already be covered by ISOC's policies and in part because the
issues are much more straightforward than ones involving the
tradeoff between privacy and the requirements for openness of
the standards process.
And, of course, that split would permit deferring the second
topic until the community was a lot more convinced that the
benefits were worth the costs and risks than I see being the
case right now.
Ietf mailing list