--On Wednesday, July 14, 2010 15:55 -0700 Dave CROCKER
<dcrocker@xxxxxxxx> wrote:
>...
>> If no one had suggested either that someone might be capturing
>> private data or tracking the contents of IETF network traffic
>> for either evil purposes or unauthorized/ undocumented
>> research on human subjects, we presumably wouldn't be having
>> this discussion, relevant or not.
> Between your use of the "or" and the "presumably", your
> response does not seem a very definitive.
>
> The fact of the matter is that a privacy policy draft was put
> forward.
>
> Whatever prompted it, it's not that remarkable to have such an
> effort. Stray assurances that there's never been a problem so
> far might or might not be valid. That doesn't really matter.
> What matters is that privacy is a serious topic that should be
> taken seriously.
>...
Dave,
In principle, I'm in favor of having a published privacy policy.
If you recall, I said so at the very beginning of this thread.
I am concerned about processes for getting from "here" to
"there". Those concerns include:
(1) Being sure that whatever is written actually
reflects IETF consensus, IETF assumptions about
participation and contributions being open and
attributable except in very special cases. I am
concerned that we not end up with some collection of
boilerplate or platitudes drawn from other sources that
doesn't really reflect our needs or situation.
(2) Recognizing that, despite the desirability of a
written policy, the IETF often does better when we rely
on oral tradition, trusting that people we have trusted
with leadership roles are responsible and will make good
decisions if required to think about them rather than
trying to blindly interpret poorly-written rules, and so
on. Part of that recognition is that, when we have
tried to reduce practices to rules that can be applied
mechanically, we have regularly done a very poor job of
it, ending up with nasty edge cases, undesired side
effects, etc. I believe you have made essentially that
point even more often over the years than I have
although we tend to couch it differently. The concerns
of Paul Hoffman and others that such a statement might
make promises that cannot be kept and/or might cost us
time or money long-term, are very much part of this
concern, at least from my point of view.
(3) Wondering whether the amount of energy required to
get to a satisfactory policy document is worth it
relative to other things the community could be doing
with its collective time and energy. But differently, I
wonder whether the probably-inevitable extended debate
on this subject is blocking or impeding critical-path
pre-IETF work for those who are actually trying to get
such work done.
(4) Wondering whether there is any justification for the
sense of urgency that some seem to associate with this
work. We have a long history of not doing well when we
put "get it done fast" ahead of "get it done at least
reasonably well" in our priorities, especially where
policy matters and documents that will be read carefully
by people outside the community are concerned. Again, I
think that, over the years, you have made that point at
least as often as I have. If it is not urgent, then I
wonder if this topic would not be better discussed
during the usual lull in, say, mid-August through late
September rather than in the three weeks prior to IETF
78.
(5) Wanting to be sure that this particular issue
doesn't become a context in which the IAOC makes policy
and essentially dictates it to the community via short
notice, lack of documentation of IAOC thinking, and/or a
"you can advise us if you like but we will decide
according to our best judgment" model. If this is going
to be an IETF Policy, then decisions about it ought to
be made according to our usual mechanisms for
determining such policies. Despite seeing the current
mechanisms as somewhat problematic, the ones we have
clearly require an IESG determination of community
consensus, not an IAOC vote. I think that process
should necessarily (i) start with the IESG determining
that there is community consensus for _having_ a written
policy or at least that they are willing to seriously
entertain such a proposal, followed by (ii) a proposal
for how that policy should be evaluated (such proposals
are normally called "BOFs" or "proposed WG charters",
but I favor letting the IESG be creative if they
conclude that is appropriate)), (iii) followed by a
community discussion using that evaluation framework,
followed by (iv) the usual Last Call mechanism. I note
that we aren't at "step (i)" yet. I hope it is clear,
but I think that necessarily is "principles first,
policy document second", not, e.g., "IAOC creates policy
rules and posts them and then lets the community develop
corresponding principles". I think you have made
essentially the latter comment as well.
IMO, those are the types of issues we should be discussing and
that several people on the list have been discussing.
Hyperbole, wild extrapolations, assumptions that network
research (even if it were occurring) was actually research on
human subjects, unfounded accusations about bad behavior or
hidden conspiracies, etc., don't further that discussion.
Instead, they tend to block it and take us off into the weeds.
> The assumption that simply posting a notice constitutes
> sufficient "permission" to disclose data is one more example
> of the challenges we face in producing reasonable policies and
> following them.
And, fwiw, I agree with that as a principle. Whether a
demonstration from many years ago could or would be taken as a
justifying precedent today, even if it constituted a
counterexample from the "never, never, happened" statements that
I don't remember anyone making, is another matter. It is also
relevant that what was disclosed, if I recall, were passwords.
Not password-user pairs or anything else that would constitute
what is normally considered personally identifiable information.
So it is not even clear that a "privacy policy" has much to do
with it-- further confirming your observation that we face
challenges in doing this and some of my concerns above.
best,
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf