Subject: IETF privacy policy - update

From: Alissa Cooper <[email-masked]>
Date: Mon, 5 Jul 2010 17:05:50 +0100

A few months ago I drew up a strawman proposal for a public-facing  
IETF privacy policy (http://www.ietf.org/id/draft-cooper-privacy-policy-00.txt 
). I've submitted an update based on feedback received: http://www.ietf.org/id/draft-cooper-privacy-policy-01.txt

In discussing the policy with the IAOC and others, it seems clear that  
the RFC model is probably not the best model for maintaining and  
updating a document like this. It is more likely to fall within the  
scope of the IAOC and/or the Trust. In order for the IAOC to consider  
taking this on and devoting resources to figuring out what its format  
should be, they need to hear from the community that a public-facing  
privacy policy is something that the community wants. So I have two  
requests for those with any interest in this:

1) Respond on this list if you support the idea of the IETF having a  
privacy policy (a simple "+1" will do).

2) If you have comments and suggestions about the policy itself, send  
them to this list.

Thanks,
Alissa

---

From: Melinda Shore <[email-masked]>
Date: Mon, 05 Jul 2010 08:17:36 -0800

> privacy policy (a simple "+1" will do).

+1

It's time, I think.

Melinda

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Jul 2010 13:24:34 -0400

--On Monday, July 05, 2010 5:05 PM +0100 Alissa Cooper
<[email-masked]> wrote:

> A few months ago I drew up a strawman proposal for a
> public-facing IETF privacy policy
> (http://www.ietf.org/id/draft-cooper-privacy-policy-00.txt).
> I've submitted an update based on feedback received:
> http://www.ietf.org/id/draft-cooper-privacy-policy-01.txt
> 
> In discussing the policy with the IAOC and others, it seems
> clear that the RFC model is probably not the best model for
> maintaining and updating a document like this. It is more
> likely to fall within the scope of the IAOC and/or the Trust.
> In order for the IAOC to consider taking this on and devoting
> resources to figuring out what its format should be, they need
> to hear from the community that a public-facing privacy policy
> is something that the community wants. So I have two requests
> for those with any interest in this:
> 
> 1) Respond on this list if you support the idea of the IETF
> having a privacy policy (a simple "+1" will do).
> 
> 2) If you have comments and suggestions about the policy
> itself, send them to this list.

Alissa,

It is hard, and maybe impossible, to argue against the IETF
having an established privacy policy, so I agree with Melinda's
"about time".

However, while administering such a policy (to the degree to
which such a thing is needed) is a reasonable task for the IETF
community to assign to the IAOC (or Trust), those bodies are
quite explicitly not supposed to be represent or determine
community consensus: they are administrative, administrative
only, and part of a structure erected to handle administrative
tasks.  

So, while the RFC process may not be appropriate for handling a
privacy policy (I'm actually not convinced it is not, but that
is another matter), unless we are really going top-down around
here, the responsibility for determining community consensus
about such a policy for the IETF community and setting it has to
stay with the IESG.  I just don't see any way to avoid that.

     john

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 05 Jul 2010 11:16:16 -0700

On 7/5/2010 9:05 AM, Alissa Cooper wrote:
> In discussing the policy with the IAOC and others, it seems clear that the RFC
> model is probably not the best model for maintaining and updating a document
> like this.

While I could imagine that you are correct, the answer isn't at all clear to me.

Presumably it should represent community consensus and should not change all 
that often.  And having an archival copy makes sense.  So I'm not understanding 
why it should not be published as an RFC.

Please clarify.

Thanks.

d/

ps. I, too, like the idea of having the policy.  I'm only asking about its form.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 5 Jul 2010 14:28:36 -0400

<wearing no hats>

On Jul 5, 2010, at 2:16 PM, Dave CROCKER wrote:

> Presumably it should represent community consensus and should not  
> change all that often.  And having an archival copy makes sense.  So  
> I'm not understanding why it should not be published as an RFC.
>

I assume (for I do not know) that people are worried about time  
involved in bringing a new RFC to publication.

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

- an IAOC document for the actual privacy policy itself, which could  
be changed very quickly if (say) lawyers started beating down the doors.

Regards
Marshall

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 05 Jul 2010 11:40:11 -0700

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.

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

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.

> - an IAOC document for the actual privacy policy itself, which could be changed
> very quickly if (say) lawyers started beating down the doors.

if?  so we really don't have an urgent requirement?

d/
-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Mon, 05 Jul 2010 12:08:14 -0700

Hi Alissa,
At 09:05 05-07-10, Alissa Cooper wrote:
>IETF privacy policy 
>(http://www.ietf.org/id/draft-cooper-privacy-policy-00.txt ). I've 
>submitted an update based on feedback received: 

A BCP represents community consensus.  I don't see how using the RFC 
publication is not the best model for maintaining and updating a document.

According to BCP 101:

   "The IETF undertakes its technical activities as an ongoing, open,
    consensus-based process."

   "The IETF Administrative Support Activity (IASA) provides the
    administrative structure required to support the IETF standards
    process and to support the IETF's technical activities."

   "The IAOC determines what IETF administrative functions are to be
    performed, and how or where they should be performed (whether
    internally within the IASA or by outside organizations), so as to
    maintain an optimal balance of functional performance and cost of
    each such function.  The IAOC should document all such decisions, and
    the justification for them, for review by the community."

I doubt that it is up to the IAOC to determine whether there is 
consensus on a privacy policy as it is a policy and not an 
administrative matter.

According to BCP 78:

   "The IETF Trust was recently formed to act as the administrative
    custodian of all copyrights and other intellectual property rights
    relating to the IETF Standards Process that had previously been held
    by ISOC and the Corporation for National Research Initiatives (CNRI)"

If you want community support, ask for the I-D to be published as a 
RFC by putting in a request to the IETF Chair.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Jul 2010 21:39:07 -0400

--On Monday, July 05, 2010 11:40 AM -0700 Dave CROCKER
<[email-masked]> wrote:

>> I assume (for I do not know) that people are worried about
>> time involved in bringing a new 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
> 

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

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 06 Jul 2010 07:48:17 +0200

> privacy policy (a simple "+1" will do).

+1.
> 2) If you have comments and suggestions about the policy itself, send

Our lingua franca are internet-drafts & RFCs.

Eliot

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 6 Jul 2010 09:11:07 +0100

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:

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 the admission control for upcoming IETFs). 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.

Alissa

---

From: Eliot Lear <[email-masked]>
Date: Tue, 06 Jul 2010 10:32:24 +0200

Alissa,

Thanks very much for your elaboration.  I would agree with your

> allows) seems like a decent option.

A good policy allows for appropriate levels of delegation of authority
and flexibility.  It also allows the community to set bars beyond which
those charged with decisions may not go.  For instance, it may be the
case that the community values privacy so much that it would not be
possible to meet both the IETF privacy policy and local laws of certain
places, leading to an understanding of what venues would be available,
and what venues would not.

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 6 Jul 2010 12:56:51 +0200

On 5 jul 2010, at 18:05, Alissa Cooper wrote:

> 1) Respond on this list if you support the idea of the IETF having a privacy policy (a simple "+1" will do).

I'm torn between "good to have this written down" and "do we really need to go out and look for more process work".

> 2) If you have comments and suggestions about the policy itself, send them to this list.

What I'm missing is what happens with the information described under "Registering to attend a meeting or social event:", there are no retention periods mentioned (that I noticed).

---

From: Nathaniel Borenstein <[email-masked]>
Date: Tue, 6 Jul 2010 08:21:29 -0400

> 1) Respond on this list if you support the idea of the IETF having a privacy policy (a simple "+1" will do).

+1.  It's surprising it took us this long.  And this is one of the few groups where people might actually read such a policy!

---

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 06 Jul 2010 09:38:24 -0400

+1 on the IETF having a privacy policy.

I am undecided on the best mechanisms to develop, document, and maintain 
that policy.

Karen

On 7/5/10 12:05 PM, Alissa Cooper wrote:
> (http://www.ietf.org/id/draft-cooper-privacy-policy-00.txt). I've

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 06 Jul 2010 07:53:02 -0700

Hi,

I think this is an excellent straw man for an IETF privacy policy.  I have,
however, two issues with its adoption that makes me question the wisdom of
an unqualified "+1".

First, I'm not quite sure whether the IETf should adopt such a document
without providing clear guidelines to its I* people, the secretariat, or WG
chairs.  In the absence of such guidelines, those people could be seen as
responsible of upholding the policy without knowing the practical "how to",
which may create a certain personal liability on their side, to which they
may not have signed up to.  I believe that the pool of people on the hook
for this implementation is too big, to unstructured, and perhaps not
sufficiently trained (especially when it comes to the fine details) of the
implementation of the policy.  In other words, my fear is that we may
promise something to the outside world of which the people responsible are
not certain how exactly it needs to be delivered--which puts them into an
unenviable position.

Second, I fear that the draft policy (-01 draft) provides occasionally the
impression of a certain safety of private data, where no such safety exists.
For example, equipment that stores log files is moved frequently into areas
where US law does not apply.  I would assume (without knowing for certain)
that the machines dealing with on-site information do keep some sensitive
information on their local hard drives--which are outside the US for many of
our meetings.  And so on.

The second point may be easily addressable by adding sufficiently broad
disclaimers to the policy, and/or by documenting the corner cases mentioned
(I would not be surprised if there were many more of those).  The first
point would require a guidelines document for the mentioned officials, and I
think that the development of such a document needs to go hand-in-hand with
the development of the policy itself.  Alternatively, the first point could
be addressed by phrasing the policy as a statement of intent, rather than a
"bill of rights".  Of course, its value goes way down when doing so.

I personally couldn't care less how and where a privacy policy and its
accompanying guideline docs is being developed.  However, I do have an
observation to make with respect to the form of the document.  Even
single-national organizations (like my bank, or my insurers) do change their
privacy policy quite often--several times per decade.  They have to in order
to comply with the development of the local law.  I do not see that the IETF
would not have to do the same, once we have a first policy in place.  And
that does not count the implications of, in practice, being an international
organization doing business in places such as the US and China--just to make
two examples with fundamentally different privacy law and practice--and our
lack of experience and shortness of legal resources in creating one.  All
that would speak for an easily updateable format, and RFCs are not known to
fall into that category.  We will have a buggy document at the beginning,
and we need ways to fix it, quickly.

Regards,
Stephan 

On 7.5.2010 09:05 , "Alissa Cooper" <[email-masked]> wrote:

> ). I've submitted an update based on feedback received:

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Jul 2010 16:05:21 -0400

this makes sense to me, fwiw.

   john

--On Monday, July 05, 2010 2:28 PM -0400 Marshall Eubanks
<[email-masked]> wrote:

>...
> - an IAOC document for the actual privacy policy itself, which
> could be changed very quickly if (say) lawyers started beating
> down the doors.
> 
> Regards
> Marshall
> 
> 
> 
> 
>> Please clarify.
>> 
>> Thanks.
>> 
>> d/
>>

---

From: todd glassey <[email-masked]>
Date: Tue, 06 Jul 2010 08:50:26 -0700

On 7/6/2010 6:38 AM, Karen O'Donoghue wrote:
> I am undecided on the best mechanisms to develop, document, and
> maintain that policy.

I am not...  We need to create the Privacy Working Group and it will
produce a non-RFC based work product which is the Participation Privacy
Compliance Contract with the IETF's participants. There are certain
legal issues which the Founders never considered in their design of the
IETF which mandate a permanent type document status which is not part of
the Standards or Intellectual Property publication list unless it is a
specific template for other entities to use, and that would be out of
scope for the IETF.

What this means is we need a new class of legal framework document which
is not a RFC and all of the legal controls which have been
mis-implemented as "votable consensus" agreements are properly reduced
to policy and boiler plate so that anyone can easily figure out what
participation means.

That said, why is simply that since a privacy policy is something that
needs formal legal vetting and also something that a vote of the
officers of the Operating Board should weigh in on meaning that ISOC and
not the IETF's IAOC needs to formally ratify this since it is part of
the formal Charter Package of the IETF.

The privacy policy should be put together by a Working Group (lets call
it the PWG)  as a non-RFC type operating document. It is not a BCP
either, it is a statement of the legal controls pertaining to the
privacy of the parties participating in the IETF standards process.

Further in regard to the review of that document, since it is the ISOC
(and possibly the Trust) who is/are directly liable for damages therein
at this time, it is they who must embrace and assert those privacy
controls as operating policy. So they should have representation in this
special Privacy Working Group. And finally since the privacy controls
cannot set aside those laws in the EU and other places embracing strict
privacy controls since "it" (the IETF) must be compliant to all of those.

Think of it this way - Imaging having for parties in places in the EU
implement the Nevada State PCI DSS standards for information security
based on those privacy controls for someone collaborating on a
submission from both Nevada and another party in say Finland or Denmark
for instance.

Also realize that a one-size fits all type model will not work because
some people cannot contractually sign their right to privacy away and
for them a policy of "assignment obfuscating privacy" probably  also
doesn't work.

By the way - since the assignment of intellectual property rights has
provable cash money value, this is a real issue and it needs to be dealt
with both professionally and in a manner which makes the IETF more
transparent and less of a place where the politics of the day drive the
contract-controls on participation or use of the IETF intellectual
properties.

Todd Glassey
>> In discussing the policy with the IAOC and others, it seems clear
>> that the RFC model is probably not the best model for maintaining and

---

From: John Morris <[email-masked]>
Date: Tue, 6 Jul 2010 14:14:43 -0400

+1 on having a privacy policy in the first place

+1 on this possible approach on the procedural questions (although  
other approaches migth well be fine):

> allows) seems like a decent option.

+1 on the actual substance of the draft policy (which folks should  

> http://www.ietf.org/id/draft-cooper-privacy-policy-01.txt

As I understand the draft, it is attempting to document what is  
actually happening with data in people's interactions with the IETF  
today.  This documentation should happen sooner rather than later, and  
should happen in a formal manner.

If people want to debate what SHOULD the practice be with regard to x  
or y type of data (e.g., what happens to meeting registration info),  
that is also an important discussion to have, but that type of  
discussion need not delay a formal documentation of current practice  
(and any such documentation can change if the practice is later  
changed).  The core idea of a privacy policy is to inform users of  
current practice, and that should happen soon even if we know there  
may be changes after further discussions.

John

---

From: Bob Hinden <[email-masked]>
Date: Tue, 6 Jul 2010 11:18:55 -0700

John,

> stay with the IESG.  I just don't see any way to avoid that.

With no hats on, I agree with you that this should go through the consensus process.  If the IETF chooses to go forward with this or something similar, it should get lots of review and consideration.  It has the potential to have lots on unintended consequences.

I will hold off on commenting on the proposal itself until I have read it.

Bob

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Jul 2010 14:28:24 -0700

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

---

From: joel jaeggli <[email-masked]>
Date: Tue, 06 Jul 2010 14:45:42 -0700

On 2010-07-06 03:56, Iljitsch van Beijnum wrote:
>> 1) Respond on this list if you support the idea of the IETF having
>> a privacy policy (a simple "+1" will do).
>
> I'm torn between "good to have this written down" and "do we really
> need to go out and look for more process work".
>
> What I'm missing is what happens with the information described under
> "Registering to attend a meeting or social event:", there are no
> retention periods mentioned (that I noticed).

the trust's records retention policy already deals with registration.
  _______________________________________________
> Ietf mailing list [email-masked]

---

From: todd glassey <[email-masked]>
Date: Tue, 06 Jul 2010 15:06:36 -0700

> the trust's records retention policy already deals with registration.

These records are constrained by a number of privacy statutes which
cannot be signed away. That is why this must be done outside the IETF's
normal process.

What should happen is that a committee should produce this and then that
be formally disclosed to the entire IETF membership - meaning every
member of every list, the IESG, IRTF, and IAOC as well.

That way positive disclosure can be accomplished. This also should be
redone on a yearly basis to reinforce this mandate.

Todd

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Jul 2010 13:52:30 +0200

> the trust's records retention policy already deals with registration.

So? If you're going to have a privacy policy it should have this in it. Currently, there's not even a pointer.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 7 Jul 2010 13:02:14 +0100

Data retention is addressed explicitly in section 5:

> 5.  Data retention
>
>    All log files of automatically collected data about our site  
> visitors
>    are deleted every 1-3 months on average.  Aggregated data about
>    visitors to our web site which cannot be linked back to individual
>    visitors may be retained permanently.  Some of this data is  
> viewable
>    at [6].
>
>    Meeting registration information other than credit card information
>    is permanently retained (including cancelled registrations).   
> Credit
>    card processing records are retained for 18 months.
>
>    Letter of invitation information, including passport and date of
>    birth information, is permanently retained.
>
>    Blue sheets and IPR Disclosures are permanently retained.
>
>    IETF Tools inputs are retained for 1 month on average (the exact
>    retention period depends on the size of the log file for each tools
>    site).
>
>    More information about IETF data retention policies can be found in
>    the IETF Trust Records Retention Policy [7].
> ...
> [7] IETF Trust, "IETF Trust Records Retention and Management  
> Policy", http://trustee.ietf.org/docs/  
> IETF_Trust_Records_Retention_Policy_(Complete_Final).pdf, 2007.

What's missing?

Alissa

On Jul 7, 2010, at 12:52 PM, Iljitsch van Beijnum wrote:

> So? If you're going to have a privacy policy it should have this in  
> it. Currently, there's not even a pointer.
>
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Jul 2010 16:14:00 +0200

> What's missing?

What I said: the stuff that gets asked for during registration and payment.

Apparently I didn't notice the link to the IETF trust. However, I don't see the point of having a document like this if it only provides a subset of all information, there shouldn't be a separate privacy policy for the trust.

Or perhaps it's better to just forego this effort, as spends a lot of text kicking in open doors.

---

From: John Morris <[email-masked]>
Date: Wed, 7 Jul 2010 10:32:48 -0400

The draft, and the message that you responded to (but failed to quote  
fully), says:

>   is permanently retained (including cancelled registrations).  Credit

This seems to address precisely what you claim is missing:  "the stuff  
that gets asked for during registration and payment"

What "stuff" does this not address?

And, if you indeed think that something is missing, perhaps you could  
suggest some language to address your concern, rather than just  
dismiss the entire effort.

On Jul 7, 2010, at 10:14 AM, Iljitsch van Beijnum wrote:

> Apparently I didn't notice the link to the IETF trust. However, I  
> don't see the point of having a document like this if it only  
> provides a subset of all information, there shouldn't be a separate  
> privacy policy for the trust.
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Jul 2010 16:42:05 +0200

On 7 jul 2010, at 16:32, John Morris wrote:

> And, if you indeed think that something is missing, perhaps you could suggest some language to address your concern, rather than just dismiss the entire effort.

I think it's completely legitimate to question whether efforts like this are worth the resources they soak up. The first time I went to an IETF meeting I was shocked by the amount of talk about the internals of the IETF itself that went on. We should really try to minimize this navel gazing and only indulge in it when clearly needed, something that hasn't been shown to be the case here.

---

From: John Morris <[email-masked]>
Date: Wed, 7 Jul 2010 11:23:41 -0400

Well, as someone who believes that *all* websites and online-operating  
organizations should have a clear and accessible privacy policy, I  
think it is beyond embarrassing that the IETF does not have one.  As  
an organization that tries pretty hard to be sensitive to the privacy  
impacts of the technologies it creates, it is disappointing that the  
IETF does not itself meet even the most basic of privacy "best  
practices," that is, having a privacy policy.

But I appreciate that others may view privacy policies as navel  
gazing.  In this case, however, the gazing could be fairly short and  
focused -- there is already a draft policy that is in a second  
version, with an author who has sought to work closely with the powers- 
that-be to understand the IETF's current practices (and who is willing  
to finish that work).  The most important thing that needs to be  
decided is "what form should a policy take," and I think there were a  
number of good ideas on that point on the list.  So I would urge us to  
gaze into our navels just a little bit more to make this happen.

On Jul 7, 2010, at 10:42 AM, Iljitsch van Beijnum wrote:

>> And, if you indeed think that something is missing, perhaps you  
>> could suggest some language to address your concern, rather than  
>> just dismiss the entire effort.
>
> I think it's completely legitimate to question whether efforts like  
> this are worth the resources they soak up. The first time I went to  
> an IETF meeting I was shocked by the amount of talk about the  
> internals of the IETF itself that went on. We should really try to  
> minimize this navel gazing and only indulge in it when clearly  
> needed, something that hasn't been shown to be the case here.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Jul 2010 18:57:54 +0200

On 7 jul 2010, at 17:23, John Morris wrote:

> Well, as someone who believes that *all* websites and online-operating organizations should have a clear and accessible privacy policy, I think it is beyond embarrassing that the IETF does not have one.

The IETF got along without one for two decades just fine.

In the meantime, BGP and HTTP, to name just two of the protocols without which the internet and the web wouldn't exist, still don't have standard status.

What do we want to spend our time on? Create more text that people will end up reading that doesn't add anything to their life or the good of the internet, or make some progress on our chartered work?

---

From: Melinda Shore <[email-masked]>
Date: Wed, 7 Jul 2010 10:59:34 -0800

> In the meantime, BGP and HTTP, to name just two of the protocols without which the internet and the web wouldn't exist, still don't have standard status.

I think I'd probably argue that the context has changed.  It
wasn't *that* long ago that there were publicly-available 
systems with no root password that everybody knew about, too.

But anyway, I don't think it's at all clear to me that navel-
gazing is impeding progress on BGP or HTTP.  I think it's 
possible that more navel-gazing may be called for, actually,
to solve problems like this.  

I think there has been a sufficiently large number of ridiculous
legal threats thrown around to suggest that getting policies
nailed down and written up isn't a bad idea.

Melinda

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Jul 2010 15:49:22 -0400

>>>>> "Iljitsch" == Iljitsch van Beijnum <[email-masked]> writes:

    Iljitsch> On 7 jul 2010, at 17:23, John Morris wrote:
    >> Well, as someone who believes that *all* websites and
    >> online-operating organizations should have a clear and accessible
    >> privacy policy, I think it is beyond embarrassing that the IETF
    >> does not have one.

    Iljitsch> The IETF got along without one for two decades just fine.

Generally when I look for an idea of whether work is a good idea I look
for a clear statement of benefit.  I'll admit that I don't find privacy
policies so valuable that I think everyone should have one.  So, I'll
ask how will or work be improved or what problem are we running into
that a privacy policy will solve?  If that cannot clearly we be
answered, we should not engage in this activity.

---

From: Ole Jacobsen <[email-masked]>
Date: Wed, 7 Jul 2010 12:53:28 -0700 (PDT)

Sam,

I view this more or less as "standard boilerplate", something you find 
in a lot of "online places". I think it is reasonable to expect that 
if you register for a meeting your personal info (e-mail address 
mostly) won't be sold/used/harvested by someone for purposes other 
than what you think you signed up for. It's probably useful for us to 
have such a statement.

Ole

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Jul 2010 12:59:57 -0700

At 3:51 AM +0000 7/7/10, John Levine wrote:
>I think we all agree that having a privacy policy would be desirable,
>in the sense that we are in favor of good, and opposed to evil.  But I
>don't know what it means to implement a privacy policy, and I don't
>think anyone else does either.
>
>A privacy policy is basically a set of assertions about what the IETF
>will do with your personal information.  To invent a strawman, let's
>say that the privacy policy says that registration information will be
>kept in confidence, and some newly hired clerk who's a little unclear
>on the concept gives a list of registrants' e-mail addresses to a
>conference sponsor so they can e-mail everyone an offer for a free
>IETF tee shirt.
>
>Then what happens?  Is a privacy policy a contract, and if it is, what
>remedies do IETF participants have for non-performance?  And if it's
>not, and there aren't remedies, what's the point?

Thank you, Sam and John.

Do some people not come to IETF meetings because of the current null privacy policy? Do they say less than they would have if we had a typical non-null policy? If either of those two are answered yes, would those people contribute better knowing that the IETF had a policy but no real way to enforce it other than by apologizing when it failed to follow the policy?

If having a privacy policy, even one where there was no real enforcement mechanism, was free, nearly everyone would want it. Given that getting such a policy is not free, and will cause cycles to be lost from other IETF work, is the tradeoff worth it? At this point, I would say "no", but mostly because I don't know of anyone who contributes less due to the current null policy.

--Paul Hoffman, Director
--VPN Consortium

---

From: Melinda Shore <[email-masked]>
Date: Wed, 7 Jul 2010 12:05:48 -0800

On Jul 7, 2010, at 11:59 AM, Paul Hoffman wrote:
> Given that getting such a policy is not free, and will cause cycles to be lost from other IETF work, [ ... ]

That's the second time I've seen someone suggest that and I
wonder how true it is.

Melinda

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Jul 2010 16:40:00 -0400

>>>>> "Ole" == Ole Jacobsen <[email-masked]> writes:

    Ole> Sam,

    Ole> I view this more or less as "standard boilerplate", something
    Ole> you find in a lot of "online places". I think it is reasonable
    Ole> to expect that if you register for a meeting your personal info
    Ole> (e-mail address mostly) won't be sold/used/harvested by someone
    Ole> for purposes other than what you think you signed up for. It's
    Ole> probably useful for us to have such a statement.

I agree with the above.  however, the above doesn't sound like a
compelling justification to develop or review such a statement--just a
reason why we wouldn't mind having one.

For the development cost,  I don't care if people who want such a
statement go off and build one.

however, at least the IAOC has to review it.  I don't think that the
above justification is sufficient to place the review very high on the
priority list, nor do I think that in this instance the fact that
someone goes and spends time developing it should raise the review
priority. If the IAOC believes it needs to suck the rest of us into a
review, I think that pushes the priority even lower.

Now, there are things that in my mind would push the priority up:

* The IAOC isn't sure whether to use information in some way

* The community and IAOC disagree about how information is being used

* Something else

---

From: John Morris <[email-masked]>
Date: Wed, 7 Jul 2010 16:52:08 -0400

Paul, Sam,

I understand your arguments to bascially be "we've never had an  
internal privacy problem here at the IETF, and as far as I know no one  
decides not to participate because of the lack of a privacy policy, so  
we have no need to follow basic standards of privacy hygiene."

What would you say to a network operator who maintains an open mail  
relay, but says "we've never had any spam abuse on my open relay, and  
as far as I know I have never lost any business because of my relay,  
and so I have no need to follow basic standards of SMTP hygiene (as  
set out in RFCs 2505 and 5321)"?

I would say to the network operator that (a) open mail relays create a  
risk of abuse, (b) industry best practices discourage such relays to  
help minimize that risk, and so (c) unless you have a really really  
good reason to maintain an open relay, you should not do so.  And if  
the network operator were a prominent participant in the industry, I  
would add that maintaining an open relay sets a really bad example for  
other industry players and developers.

In the IETF privacy context, as far as I know, we have not had any  
significant internal privacy problems at the IETF, probably because  
the powers-that-be are generally pretty thoughtful, careful people.   
And I have no idea whether anyone was so put off by the lack of a  
privacy policy as to reduce their participation IETF -- probably no  
one (but that is pretty unknowable).

But there is a risk -- indeed, as we see going into the next two IETF  
meetings, there is a growing risk -- that the IETF will be collecting  
information that could be misused, in ways that none of us can foresee  
now.  A privacy policy would not eliminate that risk, but it would  
help to guide future efforts to minimize privacy risk, and it would  
tell IETF site visitors how much they are tracked, etc., should they  
decide to use the site.

So I, at least, would say to the IETF that (a) not having a privacy  
policy increases the risk of a privacy mistake, (b) online best  
practices encourage having a privacy policy, and so (c) unless you  
have a really really good reason not to have a privacy policy, you  
should have one.  And because lots of developers look to the IETF for  
guidance in their work, I think the IETF's lack of a policy sets a bad  
example.

And I think it is possible that having a clear, public, and well- 
thought-out set of principles and policies to guide the IETF's  
collection, retention, and use of data might even reduce or at least  
constrain the debates we have on this list every year or two about  
IETF data collection and retention....  Thus, spending what you view  
as wasted cycles now may well reduce wasted cycles later.  But even if  
it does not, I think any organization that promulgates a series of  
documents named "Best Current Practices" (and hopes that people will  
pay attention to them) should itself be prepared to follow widely  
accepted "best current practices" for its operations, even if the  
participants of the organization find those practices to be outside of  
the core work of the group.

John

On Jul 7, 2010, at 3:59 PM, Paul Hoffman wrote:

> Do some people not come to IETF meetings because of the current null  
> privacy policy? Do they say less than they would have if we had a  
> typical non-null policy? If either of those two are answered yes,  
> would those people contribute better knowing that the IETF had a  
> policy but no real way to enforce it other than by apologizing when  
> it failed to follow the policy?
>
> If having a privacy policy, even one where there was no real  
> enforcement mechanism, was free, nearly everyone would want it.  
> Given that getting such a policy is not free, and will cause cycles  
> to be lost from other IETF work, is the tradeoff worth it? At this  
> point, I would say "no", but mostly because I don't know of anyone  
> who contributes less due to the current null policy.
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Jul 2010 14:30:30 -0700

At 4:52 PM -0400 7/7/10, John Morris wrote:
>I understand your arguments to bascially be "we've never had an internal privacy problem here at the IETF, and as far as I know no one decides not to participate because of the lack of a privacy policy, so we have no need to follow basic standards of privacy hygiene."

Why do you understand that? It is absolutely unrelated to what I said (and I believe it is also unrelated to what Sam said, but he can speak to it). What I said was a reflection of what Sam said: if we don't know the problem is hurting, we can't weigh if the effort to form a solution is worthwhile. I never said "we've never had an internal privacy problem" because we have no data at all. I assume we do have some, but I have no idea if the result is trivial, substantial, or monumental.

>In the IETF privacy context, as far as I know, we have not had any significant internal privacy problems at the IETF, probably because the powers-that-be are generally pretty thoughtful, careful people.  
>And I have no idea whether anyone was so put off by the lack of a privacy policy as to reduce their participation IETF -- probably no one (but that is pretty unknowable).

Here we are in agreement.

>But there is a risk -- indeed, as we see going into the next two IETF meetings, there is a growing risk -- that the IETF will be collecting information that could be misused, in ways that none of us can foresee now.  A privacy policy would not eliminate that risk, but it would help to guide future efforts to minimize privacy risk, and it would tell IETF site visitors how much they are tracked, etc., should they decide to use the site.

And we agree here. Where we don't seem to agree is whether this risk is worth the effort to reduce it. We don't have agreement on what the effort will be, or even who is going to do it.

>So I, at least, would say to the IETF that (a) not having a privacy policy increases the risk of a privacy mistake, (b) online best practices encourage having a privacy policy, and so (c) unless you have a really really good reason not to have a privacy policy, you should have one.  And because lots of developers look to the IETF for guidance in their work, I think the IETF's lack of a policy sets a bad example.

Would you consider "we will try not to do stupid things with your private information" to be sufficient? Because, basically, that's the value I see in most privacy policies that I rely on. I can't think of a single privacy policy from a non-regulated entity (like banks) that I use that has any punishment for breaches other than the management needs to spend a few hours crafting a contrite apology.

>And I think it is possible that having a clear, public, and well-thought-out set of principles and policies to guide the IETF's collection, retention, and use of data might even reduce or at least constrain the debates we have on this list every year or two about IETF data collection and retention....

How well has that worked out in other areas of IETF policy? Boilerplate language, IPR, standards levels, RFC format: all have a clear, public, and well-thought-out set of principles, none of which have had the result you predict for "privacy policy".

>  Thus, spending what you view as wasted cycles now may well reduce wasted cycles later.  But even if it does not, I think any organization that promulgates a series of documents named "Best Current Practices" (and hopes that people will pay attention to them) should itself be prepared to follow widely accepted "best current practices" for its operations, even if the participants of the organization find those practices to be outside of the core work of the group.

It feels to me that the IETF approximately follows the best current practices for privacy without having a statement about them. If you believe that "having a statement about them" is a best practice, you need to show why it is worth the cost. If the cost is near-zero (and I don't think it is), then I agree that tossing one up somewhere is probably worthwhile.

--Paul Hoffman, Director
--VPN Consortium

---

From: joel jaeggli <[email-masked]>
Date: Wed, 07 Jul 2010 14:42:19 -0700

On 2010-07-07 12:53, Ole Jacobsen wrote:
> than what you think you signed up for.

the fact that you signed up for the meeting is publicly available so 
that we don't sell mailing lists to spammers seems sort of irrelevant.

> It's probably useful for us to
> have such a statement.
>
> Ole
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Jul 2010 17:58:51 -0400

>>>>> "John" == John Morris <[email-masked]> writes:

    John> Paul, Sam, I understand your arguments to bascially be "we've
    John> never had an internal privacy problem here at the IETF, and as
    John> far as I know no one decides not to participate because of the
    John> lack of a privacy policy, so we have no need to follow basic
    John> standards of privacy hygiene."

This is not an accurate characterization of my argument.

I substantially agree with Paul's message in response.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 8 Jul 2010 05:48:58 +0100

Hi Paul,

On Jul 7, 2010, at 8:59 PM, Paul Hoffman wrote:

> privacy policy?

Perhaps the better question is, do some people not sign the blue  
sheets because of whatever they think the current privacy policy is?

The issue of what happens when the IETF receives a subpoena for blue  
sheet information is what originally kicked off this entire effort.  
Organizations have choices about how they respond to government and  
civil-litigation-related demands for data. One policy option is to  
respond to every single demand no matter who it is from or whether it  
shows any signs of judicial oversight or legality. Another is to only  
respond to lawful orders.

Most organizations that I know of at least state what their policies  
are in this regard, so that people who become interested in which  
kinds of requests their data may be subject to can find out. The IETF  
seems to have some sort of latent policy on this, but it is not  
written down.

Questions about this have already been raised (outside of the blue  
sheet context) with respect to the upcoming admission control  
procedures [1]. A number of different privacy questions were also  
raised about the RFID experiment, and in both cases the IAOC has spent  
substantial time on the list trying to explain to the community what  
the latent policies are (and, in the RFID case, even updating and  
publishing the policy). It's impossible to calculate how many cycles  
have been "lost" to these discussions, but I think it's inaccurate to  
say that if there was no time spent on documenting the privacy policy,  
there would be no time spent on privacy issues at all. Writing the  
policy down should help save cycles down the road.

Alissa

[1] https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=52199&tid=1278564156

> Do they say less than they would have if we had a typical non-null  
> policy? If either of those two are answered yes, would those people  
> contribute better knowing that the IETF had a policy but no real way  
> to enforce it other than by apologizing when it failed to follow the  
> policy?
>

--
----------------------------------------------------
Alissa Cooper
Chief Computer Scientist
Center for Democracy and Technology
+44 (0)785 916 0031
Skype: alissacooper

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 8 Jul 2010 01:00:49 -0400

On Wed, Jul 07, 2010 at 02:30:30PM -0700, Paul Hoffman wrote:

>If the cost is near-zero

Given the number of messages so far, the denial of the antecedent is
already assured.  There is a clearly non-zero cost to this effort.
(This is not an argument about whether a privacy policy is needed;
it's simply an empirical observation about whether associated costs
are near-zero.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: John Morris <[email-masked]>
Date: Thu, 8 Jul 2010 01:10:13 -0400

Sam, Paul,

I did not mean to misrepresent your positions.  I honestly understood  
them to be as I stated, but I was wrong.  My apologies for that.

And yes, I agree with Paul that privacy policies are generally not  
worth all that much -- indeed, my organization (as well as, for  
example, the U.S. Federal Trade Commission and others) argue that we  
need stronger laws/regulations in the U.S. because of the failure of  
the privacy policy approach.  We want data collectors to be much more  
responsible (legally and otherwise) on privacy.  But privacy policies  
reflect the barest minimum that any responsible organization should do.

It is depressing, at least to me, that the dominant argument on this  
issue on this list - expressed by respected community members - is  
that the IETF should not expend the cycles to do even this barest  
minimum.

John

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Jul 2010 14:22:16 +0900

> sheets because of whatever they think the current privacy policy is?

or use bogus sig on blue sheet.  yes.  the rfid discussion pushed me
over the tolerance line on this class of issues in the ietf.

randy

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 8 Jul 2010 00:00:03 -0600

On Jul 5, 2010, at 10:05 AM, Alissa Cooper wrote:

> A few months ago I drew up a strawman proposal for a public-facing IETF privacy policy (http://www.ietf.org/id/draft-cooper-privacy-policy-00.txt). I've submitted an update based on feedback received: http://www.ietf.org/id/draft-cooper-privacy-policy-01.txt
> 
> In discussing the policy with the IAOC and others, it seems clear that the RFC model is probably not the best model for maintaining and updating a document like this. It is more likely to fall within the scope of the IAOC and/or the Trust. In order for the IAOC to consider taking this on and devoting resources to figuring out what its format should be, they need to hear from the community that a public-facing privacy policy is something that the community wants. So I have two requests for those with any interest in this:
> 

+1 

> 2) If you have comments and suggestions about the policy itself, send them to this list.

I would be very happy if the IETF adopted the privacy policy proposed in your draft.

It seems to me the work of writing an acceptable policy is 90% done and the arguments that creating a privacy policy will detract from other work are pretty weak. It's a volunteer organization, people vote with their feet with what they want to work on. Just because Alissa spend time writing a policy document does not mean that time would be directed to other things if we did not want to do a privacy policy document. I don't think that having a privacy policy is going to bring a bunch of new contributors to the IETF, but I can imagine a case where the lack of a privacy policy caused some administrative group to do something really unfortunate which resulted in some good people leaving the IETF. 

A privacy policy is not something the IETF typically has a lot of people that are really experienced and qualified to draft. But we are very lucky here - we have multiple people that understand IETF culture and values, understand internet privacy policies and laws, and are willing to write a proposal. Unless this proposal is deeply flawed in some way I can't see, why wouldn't we just do it.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 07 Jul 2010 22:11:01 -0700

> Do some people not come to IETF meetings because of the current null

Do some people not come because attendance is a matter of public record?

> Do they say less than they would have if we had a
> typical non-null policy?

do people not speak or participate, due to the note well, audio 
recording in the meeting rooms or the mailing list policy?

> If either of those two are answered yes,

practices that result in the retention of pii information seem by in 
large fairly well documented as part of the ietf process (consider 
nomcom for example).

to the extent that there are gaps they appear to be associated with 
secretarial tasks not with the ietf activity itself which by in large 
favors transparency through publication.

> enforcement mechanism, was free, nearly everyone would want it. Given
> that getting such a policy is not free, and will cause cycles to be
> lost from other IETF work, is the tradeoff worth it? At this point, I
> would say "no", but mostly because I don't know of anyone who
> contributes less due to the current null policy.
>
> --Paul Hoffman, Director --VPN Consortium
> _______________________________________________ Ietf mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Jul 2010 11:59:12 +0300

> that we don't sell mailing lists to spammers seems sort of irrelevant.

This is the way things are *now*. Discussion of a privacy statement may lead to changes, such as keeping the attendee list confidential, and destroying it on the Monday following the meeting.

I personally don't care if the whole world knows I've been to an IETF meeting, but the decision to publish the list on the website has privacy consequences. Without a privacy policy, it's hard to say whether that is acceptable or not.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 8 Jul 2010 11:18:07 +0200

> What do we want to spend our time on? Create more text that people will end up reading that doesn't add anything to their life or the good of the internet, or make some progress on our chartered wo…

Didn't you post a message earlier today criticising IETF navel-gazing? 
And now you suggest that changing an adjective in the boilerplate on the 
first page of an RFC would be "progress"?

Arnt

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 08 Jul 2010 11:21:10 +0200

(Wearing no hats)

On 08/07/2010 10:59, Yoav Nir wrote:
>> the fact that you signed up for the meeting is publicly available so that
>> we don't sell mailing lists to spammers seems sort of irrelevant.

The attendee list does not contain email adresses, making it a lot less
useful for spammers than a list of working email addresses.

> This is the way things are *now*. Discussion of a privacy statement may lead
> to changes, such as keeping the attendee list confidential, and destroying it
> on the Monday following the meeting.

I'm not sure what problem we are trying to solve but I don't think that it will
solve it anyway.   The documents related to the meeting (ID's, minutes,
WG pages, WG mail archives) are full with names and, in most cases, detailed
contact information such as email, phone and postal address.  Nobody seems
to have a problem with that, removing those details from the documents is
a lot of work and will make the resulting docs useless.

> I personally don't care if the whole world knows I've been to an IETF
> meeting, 

I think this should be the basic assumption.  The IETF is a public event,
you will have to walk around with a name badge and your name will be in
the meeting materials.  There is an easy solution if you don't like
this.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

I confirm today what I denied yesterday.            Anonymous Politician.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 8 Jul 2010 11:15:35 -0400

On Thu, Jul 08, 2010 at 11:59:12AM +0300, Yoav Nir wrote:
 
> Without a privacy policy, it's hard to say whether that is
> acceptable or not.

I keep seeing arguments of this sort in the current thread, and it
seems to me to be backwards.  Surely it is not the privacy _policy_
that determines whether something is acceptable.  For instance,
imagine a website privacy policy that says, "We take your personal
information, including your credit card number, expiry date, and CCD
number, and post it on our website."  The existence of that privacy
policy would not make the actions somehow better or defensible: it
would be a bad policy.  I suppose posting somewhere that you're going
to do that would be better than just doing it without any warning, but
the action would be unacceptable regardless.

If the current no-written-policy arrangement is working, it is
presumably because people are making the right choices.  One analysis
of that is that there is an implicit policy, that it is acceptable,
and that the present effort to write down a policy is just a way of
making that implicit policy explicit.  But writing the policy down
does not in itself do anything about whether a given activity with a
given bit of PII is ok.

On the larger topic of whether a privacy policy is actually needed, I
am undecided.  On the one hand, it does seem to me to be a good idea
to have one place where the IETF states what it is going to do with
any PII.  On the other hand, I can easily imagine that such a privacy
policy could end up being used as a mechanism to justify bad ideas in
the event something comes up: it will be more work to change the
policy if it turns out to be inadequate than it will be to accept the
inadequacy.  The present arrangement means that, if a bad idea crops
up, it can be dealt with on its own (de)merits without dragging in a
meta-issue about whether the proposal is consistent with some holy
policy document.  

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 08 Jul 2010 08:36:33 -0700

On 2010-07-08 01:59, Yoav Nir wrote:
> meeting, but the decision to publish the list on the website has
> privacy consequences. Without a privacy policy, it's hard to say
> whether that is acceptable or not.

Or you could just refer to the RFC series since the contents of the 
proceedings are described in the tao.

e.g. 4677 4.12 1718 2.13 etc.

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 8 Jul 2010 12:21:23 -0400

> does not in itself do anything about whether a given activity with a

I see this as a normal part of an organization growing up. Small,  
young, organizations don't
typically need much structure, as everyone knows everybody, people  
trust each other,
and everything tends to be in people's heads. That doesn't scale.  
Putting
implicit policies down in writing is an attempt to make sure that the  
organization doesn't
change in adverse ways as it grows and matures.

Regards
Marshall

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Thu, 8 Jul 2010 21:05:34 +0200

I tend to agree with Andrew and Marshall.

However, from our own JEDI's (so-labelled "Jefsey's disciples") experience I
would suggest some kind of "ietf privacy netiquette". It could be equivalen
to architectural quotes like "dumb network", "end to end", "protocol on the
wire", "rough consensus", etc. It could be added to the Tao.

This way everyone would know-where he/she comes and can behave equally. This
could concern the so-called "puppets", negative privacy (ad hominem have a
perpetual impact on private reputation), disclosed/non-disclosed
affiliations, who paid for the travel tickets and attendance fees,
architectural perspective, mailing list participations, etc. I think this
could be proactive if the information is not "protected" but "personally and
optionally disclosed". There could be a database where every IETF
participant could document what he/she wants on him/herself. I am sure that
what would not be disclosed would eventually inform more than what is
disclosed and help better debates, avoiding misunderstandings, and focusing
on concepts rathers than on percepts.

Portzamparc

2010/7/8 Marshall Eubanks <[email-masked]>

> I see this as a normal part of an organization growing up. Small, young,
> organizations don't
> typically need much structure, as everyone knows everybody, people trust
> each other,
> and everything tends to be in people's heads. That doesn't scale. Putting

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Jul 2010 12:07:01 -0700

+1 for a privacy policy. As to the question of this particular one, I'm going to profess some level of ignorance. I suggested starting from Google, Cisco, and/or ISOC's privacy policies and editing from there, and someone said I should pick a more appropriate starting point. What would be appropriate privacy policies to compare/contrast?

Personally, apart from references to ISOC-specific things, I thought ISOC's privacy policy was relatively simple and covered the major points. The draft is more detailed and more complete. The differences may be a matter of taste: look at http://www.isoc.org/help/privacy/ and ask yourself whether the provisions in "what do we collect" and "what do we do with it" are reflected in the draft, and I think you might agree that they are, with the draft being more explicit in different areas. But I think that the ISOC rules, when considered in an IETF light, are actually the same. We collect things that are standardly collected, but we don't share them, and we do use them to make our internal processes work better.

If there are others to compare/contrast, to see if we have missed a point or are stating for something not usually said, I'd be interested to know.

I would agree that this statement should be made by someone in I* leadership, either the IESG, IAOC, or perhaps IAB, and that it belongs on a web page as opposed to being in an RFC. 

I would suggest that a consensus be called for via a hum over VoIPv6. But the web page should be in flat ASCII with no graphics other than ASCII-art.

> A privacy policy is not something the IETF typically has a lot of people that are really experienced and qualified to draft. But we are very lucky here - we have multiple people that understand IET…

http://www.ipinc.net/IPv4.GIF

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Jul 2010 13:14:35 -0600

+1 on all counts.

Now looking forward to a debate over the ASCII art... ;-)

On 7/8/10 1:07 PM, Fred Baker wrote:
> +1 for a privacy policy. As to the question of this particular one,
> I'm going to profess some level of ignorance. I suggested starting
> from Google, Cisco, and/or ISOC's privacy policies and editing from
> there, and someone said I should pick a more appropriate starting
> point. What would be appropriate privacy policies to
> compare/contrast?
> 
> Personally, apart from references to ISOC-specific things, I thought
> ISOC's privacy policy was relatively simple and covered the major
> points. The draft is more detailed and more complete. The differences
> may be a matter of taste: look at http://www.isoc.org/help/privacy/
> and ask yourself whether the provisions in "what do we collect" and
> "what do we do with it" are reflected in the draft, and I think you
> might agree that they are, with the draft being more explicit in
> different areas. But I think that the ISOC rules, when considered in
> an IETF light, are actually the same. We collect things that are
> standardly collected, but we don't share them, and we do use them to
> make our internal processes work better.
> 
> If there are others to compare/contrast, to see if we have missed a
> point or are stating for something not usually said, I'd be
> interested to know.
> 
> I would agree that this statement should be made by someone in I*
> leadership, either the IESG, IAOC, or perhaps IAB, and that it
> belongs on a web page as opposed to being in an RFC.
> 
> I would suggest that a consensus be called for via a hum over VoIPv6.
> But the web page should be in flat ASCII with no graphics other than
> ASCII-art.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 8 Jul 2010 11:14:55 -0800

On Jul 8, 2010, at 11:05 AM, jean-michel bernier de portzamparc wrote:
> However, from our own JEDI's (so-labelled "Jefsey's disciples") experience I would suggest some kind of "ietf privacy netiquette". It could be equivalen to architectural quotes like "dumb network", "end to end", "protocol on the wire", "rough consensus", etc. 

I'm not sure I'd want to go the good-soundbite-but-low-
compliance route.  Either writing it up and making it
explicit or dropping it completely and never again
speaking of it seem like better options and likely
to lead to fewer problems in the future.

Melinda

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Jul 2010 12:25:49 -0700

> Do some people not come because attendance is a matter of public record?

Frankly, if people are not attending for that reason and that reason alone, I have some questions. I would have to assume it is the only forum in the world in which they expect that level of anonymity, which raises the question of whether it is a rational expectation. 

Walking into an ITU meeting, I have to show a passport and have a permanent photographic record taken. If I want to participate in RIPE's general meeting, I have to register, and I can expect to find myself in RIPE's attendee list. That is true in a wide variety of places.

- ?

---

From: Melinda Shore <[email-masked]>
Date: Thu, 8 Jul 2010 11:32:56 -0800

> Walking into an ITU meeting, I have to show a passport and have a permanent photographic record taken. If I want to participate in RIPE's general meeting, I have to register, and I can expect to fi…

I think there's actually a slightly different question in there.
Those are not open organizations.  The IETF is.  I think that 
there might be a question about what "open participation" means
and whether or not there's an expectation that participants will
identify themselves, and if so, what the expectations are around
the identity being presented.  

Melinda

---

From: joel jaeggli <[email-masked]>
Date: Thu, 08 Jul 2010 13:05:58 -0700

On 2010-07-08 12:25, Fred Baker wrote:
> Frankly, if people are not attending for that reason and that reason
> alone, I have some questions. I would have to assume it is the only
> forum in the world in which they expect that level of anonymity,
> which raises the question of whether it is a rational expectation.

I meant the question as a rhetorical exercise.

3979 5378 and their explication through note well are collectively 
unequivocal as to the rational and requirement for the public record.

I've made the note well statement so many times now that I can do it in 
my sleep.

> Walking into an ITU meeting, I have to show a passport and have a
> permanent photographic record taken. If I want to participate in
> RIPE's general meeting, I have to register, and I can expect to find
> myself in RIPE's attendee list. That is true in a wide variety of
> places.
>
> - ?
>

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Jul 2010 13:08:42 -0700

On Jul 8, 2010, at 12:32 PM, Melinda Shore wrote:

> I think there's actually a slightly different question in there. Those are not open organizations. The IETF is.

Boy, would they dispute that. ITU has claimed that the IETF is not an open organization because a government cannot join it. Most membership organizations, RIPE, being an example, have a definition of how someone can become a member (members of RIPE are companies and pay a fee), and are considered open to that class of membership.

> I think that there might be a question about what "open participation" means and whether or not there's an expectation that participants will identify themselves, and if so, what the expectations are around the identity being presented.  

That is of course true. I think my comment stands. If the IETF is not the only organization in the world in which otherwise rational people expect to pay money for privileges, make material contributions that might change the world, and might have companies off suing each other over IPR, and none-the-less expect to remain absolutely anonymous, it is one of a very small number.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 8 Jul 2010 12:18:27 -0800

> Boy, would they dispute that. ITU has claimed that the IETF is not an open organization because a government cannot join it. Most membership organizations, RIPE, being an example, have a definition…

But the IETF isn't a membership organization - isn't that
at least in part what's meant by "open," and why at least in
part we don't have voting (in theory)?

> That is of course true. I think my comment stands. If the IETF is not the only organization in the world in which otherwise rational people expect to pay money for privileges, make material contrib…

I'm not a big fan of anonymity here, mostly because I don't 
know how consensus would work - in practice - with anonymous 
participants, as well as several of the issues you've identified.
I don't think that "nobody else does it" is a good argument,
unless what it actually means is "few companies will allow their
employees to contribute to an organization with those kinds of
policies," which is a very compelling argument.

But I don't think privacy are that tightly coupled and I wonder
what a privacy policy should say about that.

Melinda

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Jul 2010 13:24:54 -0700

> part we don't have voting (in theory)?

We don't have voting because we don't have members, yes. Definitions of "open" vary, and boil down to a statement of what kind of actor an organization is open to. IETF is open to individuals.

---

From: Larry Smith <[email-masked]>
Date: Thu, 8 Jul 2010 15:33:13 -0500

On Thu July 8 2010 15:24, Fred Baker wrote:
> >> Boy, would they dispute that. ITU has claimed that the IETF is not an
> >> open organization because a government cannot join it. Most membership
> >> organizations, RIPE, being an example, have a definition of how someone
> >> can become a member (members of RIPE are companies and pay a fee), and
> >> are considered open to that class of membership.
> >
> We don't have voting because we don't have members, yes. Definitions of
> "open" vary, and boil down to a statement of what kind of actor an
> organization is open to. IETF is open to individuals.
>

Appears to me this conversation/thread is leaning toward "open" being
used synonymous to "anonymous"....

-- 
Larry Smith
[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Thu, 8 Jul 2010 15:05:00 -0700

Alissa,

No hats on, these are my personal views.

I have now read the draft.  My overall comment is that I am not convinced if this is needed and am sympathetic to the views expressed on the mailing list that this is solving a problem the IETF doesn't have.

Comments below.

Bob

General comments:

If the IETF is to have a privacy policy, I would prefer it to be much simpler and of the form where it first starts with a general statement that the IETF does it's work in public and almost all information information supplied to the IETF is made public and will be available on the IETF (and other related) web sites.  I would then list the exceptions.  For example, credit card information for meeting registration and social tickets, and information for "letters of invitation".   Note: As I read the draft, there is very little that actually falls into the private category.  This leads to to wonder about the scope of the problem this draft is solving.

The IETF goes to great length to tell people about how we do our work and what is considered a public contribution, via the Note Well.  I would be surprised if anyone thought otherwise.  Doing our work in public is essential to how the IETF works.

Detailed Comments:

I have issues with the Introduction.  The first sentence says: 

   In keeping with the goals and objectives of this standards body, the
   IETF is committed to the highest degree of respect for the privacy of
   IETF participants and site visitors.

This makes it sound like the highest priority of the IETF is Privacy.  I don't think this is true as I described above.  The vast majority of what the IETF does in Public.  There is very little that is Private.  The IETF is careful about what needs to be kept private and does not disclose it.

The Introduction says:

   This policy explains how the IETF applies the Fair
   Information Practices -- a widely accepted set of privacy principles
   [1] -- to the data we obtain.

I don't know if it is appropriate that the IETF apply these practices.  Or if there are other practices that would be more appropriate.  The IETF is different from other organizations in that much of our data is public and not private.

The rest of the Introduction appears to be a summary of the first reference:

   [1]  Organization for Economic Cooperation and Development, "OECD
        Guidelines on the Protection of Privacy and Transborder Flows of
        Personal Data",  http://www.oecd.org/document/18/
        0,3343,en_2649_34255_1815186_1_1_1_1,00.html, 1980.

I don't know anything about this web page, who produced it, how stable it is, etc, etc.  It is fairly long, around 21 pages.  I don't know if this is appropriate for the IETF.  I think it would better to not include this information as it is hard to judge how appropriate it is.  Also, some of the practices seem to be at odds with normal IETF practices.  For example, it implies that individuals have complete control of the data the IETF makes public.  This isn't true in most cases.

Section 2 and 3

A lot these section is a summary of what is defined in other places (References 2, 3, 4, 5, 7, 8).  Other parts of the text are fairly generic, such as the information that a web server can learn about a web client.  Not thing very IETF specific here.  I don't see very much value repeating this.

Section 4

The first paragraph:

   The IETF does not sell, rent, or exchange any information that we
   collect about our participants or site visitors.  However, we will
   disclose information under the following circumstances:

The first two "sell & rent" is true, but the "exchange" is not true as you state later in the section.  Much of the data we collect is exchanged.  

Section 5

I am not really qualified to comment on the specifics here, such as how long credit card or letter of invitation information needs to be retained.  I would have thought that all financial data needs to be kept for some number of years.  

This describes our current operational practices regarding log files.  Including specific times for retention will make it hard to change this in the future.  Also, if log files are going to be covered, what happens to the backups?  Are we required to scrub the backups?  This would be difficult and expensive.  What about backups of credit card information?

Section 10

In the acknowledgment section you cite the IAOC.  The IAOC has not done any formal review of this draft.  It is better if you cite the people in the IAOC you have discussed this with you and not list the IAOC.  

Now that I have written this, you can cite me if you choose :-)

Section 11

I think most of the references are Normative, not Informative.  That is, this draft depends on these documents.

---

From: David Morris <[email-masked]>
Date: Thu, 8 Jul 2010 15:08:54 -0700 (PDT)

> used synonymous to "anonymous"....

Not to me ... open means any can participate ... doesn't mean
that other participants can't know who they are.

People come with experience and resumes which document that
experience. If I don't know who is speaking, their credibility
(to me) is limited.

---

From: Randy Bush <[email-masked]>
Date: Fri, 09 Jul 2010 08:18:36 +0900

> I would have to assume it is the only forum in the world in which they
> expect that level of anonymity

aside from payment possibly uncloaking you, i am not aware of an ops
meeting that checks id or even considers the issue interesting.

randy

---

From: Martin Rex <[email-masked]>
Date: Fri, 9 Jul 2010 05:43:46 +0200 (MEST)

+1

The IETF used to be an organization running on respect for the
guidance provide by their leaders.

Policies and their enforcement are means of control for rulers/government
in the absence of respect.

A written down privacy policy does not define what is acceptable,
it can only define what is compliant (with that policy).

"Acceptable" means different things to different people.

Someone suggested we could start with the privacy policy from
Google and work from there, but forgot the Sarcasm tags.

On my scale, Google is a serious and probably the largest privacy
offender world-wide.  example: "Google Street View"

I'm also being a little confused about seeing a solution
(a privacy policy draft) being proposed before there is consent
on what exactly is the problem that should be solved and whether
it is really worth solving.

I might have missed it, but all I remeber about the problem
being stated was "we don't have such a document, but almost everybody
else has one".

But for solving the "lack of paper" problem, a document with a neat title
"IETF Privacy Policy", and a crisp content "We care."
might be equally sufficient.

-Martin

---

From: "GTW" <[email-masked]>
Date: Fri, 9 Jul 2010 02:26:11 -0400

my experience suggests that IETF WG mailing lists and participation lists in 
meetings will be used  as evidence in litigation related to whether an 
individual or the organization which sponsored that individidual met the 
obligation of the relevant IETF patent policy now 
http://www.ietf.org/rfc/rfc3979.txt

my concept of an SDO that is not "open" is one that limits membership and 
disallows membership for some party with a potential material interest to 
benefit the interests of the existing members.

What is the specific reference that ITU has made w/r to IETF not being open? 
I would like to see it.

Best Regards,

George T. Willingmyre, P.E.
President, GTW Associates
1012 Parrs Ridge Drive
Spencerville, MD 20868 USA
1.301.421.4138
----- Original Message ----- 
From: "Fred Baker" <[email-masked]>
To: "Melinda Shore" <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>; "Paul Hoffman" 
<[email-masked]>; "IETF-Discussion list" <[email-masked]>
Sent: Thursday, July 08, 2010 4:24 PM
Subject: Re: IETF privacy policy - update

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 09 Jul 2010 08:06:47 +0200

>>> are considered open to that class of membership.

Wait...  There are two organizations: RIPE and RIPE NCC.

RIPE is an open group of people interested in IP based networks in Europe
and surrounding areas.   There is no formal membership, work is done by
volunteers, anybody who is interested can join the mailing lists and
participate, anybody who pays the meeting fee can attend the meeting and
participate there.  From an organizational point of view, it is pretty
similar to the IETF.

RIPE NCC is an organization established to do whatever ISP's and other
network providers have to organize as a group, even though they are
competitors, on a professional basis.  It is a membership organization
open to everybody who meets the criteria (which is essential: run a
network).  The RIPE NCC has an annual meeting, where the members decide
on what activities will be carried out in the next year.  This meeting
is open to members only, which makes a lot of sense as the members also
write the checks to cover the costs.

And to answer the original question: yes, if you register for the RIPE
or RIPE NCC meetings, your name will appear on the public attendees list.

Henk

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 9 Jul 2010 09:12:38 +0200

> or RIPE NCC meetings, your name will appear on the public attendees list.

Thanks Henk. Let me just add that the policies and rules RIPE NCC follow are developed in the open RIPE process.

   Patrik

---

From: Fred Baker <[email-masked]>
Date: Fri, 9 Jul 2010 02:45:49 -0700

> participate there.  From an organizational point of view, it is pretty

This is getting fairly far afield of the topic, but let me explain where I'm coming from.

I did a google search for privacy statements, and came to http://labs.ripe.net/node/49. Poking around, I found http://www.ripe.net/membership/gm/gm-may2010/evoting-announcement.html, which is about RIPE NCC membership, attendees, and voting. I also found another statement that said it was from RIPE (as opposed to the RIPE NCC) and listed members, voting, and attendees, but now I'm not dredging that up.

To bring matters back to the topic, the discussion was on Alissa's draft, and I was looking for comparable privacy statements to compare. My question was "is this a reasonable statement? Are there things it could have said more simply? Are there things it left out? Are there things it should not have included?"

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 09 Jul 2010 13:32:24 +0200

Hi Bob, 

just a very quick reaction to your mail: 

~snip~ 
> This makes it sound like the highest priority of the IETF is Privacy.  I
> don't think this is true as I described above.  The vast majority of what
> the IETF does in Public.  There is very little that is Private.  The IETF is
> careful about what needs to be kept private and does not disclose it.

The Fair Information Practices are a set of principles most of us are quite likely to believe in, such as (copied from the Alissa's draft):
"
  o  Collection Limitation: There should be limits to the collection of
      data about people.

   o  Data Quality: Personal data should be accurate, complete, up-to-
      date, and relevant to the purposes for which it was collected.

   o  Purpose Specification: The purpose of collecting personal data
      should be specified in advance of collection.

   o  Use Limitation: Personal data should only be used for the purposes
      for which it was collected.

   o  Security: Personal data should be protected by reasonable security
      safeguards against unauthorised access, use, and disclosure.

   o  Openness: Practices and policies with respect to personal data
      should be open and transparent.

   o  Individual Participation: Individuals should have choice, access,
      correction, and redress rights with respect to their data.

   o  Accountability: Those that collect and use data should be
      accountable for complying with the above principles.
"

When you read "privacy" then replace it with these principles and everything makes much more sense to you. 

As an example, imagine some researchers doing some interesting network testing and collect data that travels over the IETF network then these principles say that you should be transparent in what you do, you should tell people what you collect and why, etc. 

I think that this is something we want people to do. And "yes" we have researchers looking into the traffic, people storing all sorts of data, etc.

I don't think we have anything to hide. 

It would be a bad sign to say that the IETF is so special that we don't need to follow privacy principles (even if we try to consider privacy in the development of our protocols and tell other SDOs that it is really important to do so).

Ciao
Hannes

PS: If you do not know about the "OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data" then maybe some other folks have not heard about these privacy principles either. Maybe we should add privacy to our Sunday education program.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 9 Jul 2010 20:47:38 +0900

On Fri, Jul 9, 2010 at 6:45 PM, Fred Baker <[email-masked]> wrote:

> To bring matters back to the topic, the discussion was on Alissa's draft, and I was
>looking for comparable privacy statements to compare. My question was "is this a
>reasonable statement? Are there things it could have said more simply? Are there
>things it left out? Are there things it should not have included?"

Would a pointer to the W3C's help?  It is actually a collection, found here:

http://www.w3.org/Consortium/Legal/privacy-statement-20000612

regards,

Ted Hardie

---

From: Randy Bush <[email-masked]>
Date: Fri, 09 Jul 2010 21:04:09 +0900

[ fwiw, i am not bothered if some folk well-versed in such things
  develop and put forth a policy about how the ietf treats data
  about members, attendees, network, ... ]

> And "yes" we have researchers looking into the traffic, people storing
> all sorts of data, etc.

we do?  about our traffic on the ietf meeting network?  stuff other than
the _ephemeral_ data the noc ops use to manage the network?

as far as i know

  o data collection has been done very rarely.  and when it has been, it
    has been widely announced.

  o there is no plan known by the net ops to do so in maastricht or
    beijing at either of those meetings.

  o aside from issues in the wireless deployment, the data about net use
    at ietf meeings seems pretty boring to me from a research view

  o but i am sure there are wifi spies snooping and playing.  and i
    suspect that they will not be very respectful of any policy put in
    place.

given the latter, i focus more on prudent personal net hygene and less
on prose.

randy

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 09 Jul 2010 14:15:50 +0200

Hi Randy, 

> the _ephemeral_ data the noc ops use to manage the network?

Yes, the IETF meeting network. 

>     has been widely announced.

Openness and transparency is one of the privacy principles. 
(but there are others...)

>     beijing at either of those meetings.

I don't know. There is no central place where I could lookup any of this info. 

>     at ietf meeings seems pretty boring to me from a research view

Maybe boring for you. 
Some consider it a very large WLAN network, some others test their favorite tunneling technology with it, etc.  

>     suspect that they will not be very respectful of any policy put in

You have to see all privacy principles in combination in order for them to make sense. 

> given the latter, i focus more on prudent personal net hygene and less
That's fine. 

Ciao
Hannes

---

From: Randy Bush <[email-masked]>
Date: Fri, 09 Jul 2010 21:28:43 +0900

> Yes, the IETF meeting network. 

cites, please.

> I don't know. There is no central place where I could lookup any of

but you suspect the worst?  i am on the noc ops team.  you can trust my
statement or not.

> Some consider it a very large WLAN network, some others test their
> favorite tunneling technology with it, etc.

that is not gathering data on others' use of the network.

randy

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 9 Jul 2010 14:20:25 +0100

A few more privacy policies for comparison:

ISO -- http://www.iso.org/iso/support/privacy_policy.htm
IEEE -- http://www.ieee.org/security_privacy.html?WT.mc_id=hpf_priv

Note that IEEE uses a "layered" notice to some extent, which is fairly  
popular among privacy policy authors these days -- a layered policy  
shows the essential information on one page or at the top of the page  
and includes links to other pages or sections with further  
information. That could certainly be an option for the IETF.

IEEE also includes a section on law enforcement requests for data.

In my strawman, I was aiming to be as comprehensive as possible on the  
theory that it would be easier to take things out than to dig them up  
and add them later. I used a few models (most obviously CDT's policy  
-- http://cdt.org/content/privacy-policy) and cribbed some language  
directly from the ISOC policy.

Alissa

On Jul 9, 2010, at 10:45 AM, Fred Baker wrote:

> I did a google search for privacy statements, and came to http://labs.ripe.net/node/49 
> . Poking around, I found http://www.ripe.net/membership/gm/gm-may2010/evoting-announcement.html 
> , which is about RIPE NCC membership, attendees, and voting. I also  
> found another statement that said it was from RIPE (as opposed to  
> the RIPE NCC) and listed members, voting, and attendees, but now I'm  
> not dredging that up.
>
> To bring matters back to the topic, the discussion was on Alissa's  
> draft, and I was looking for comparable privacy statements to  
> compare. My question was "is this a reasonable statement? Are there  
> things it could have said more simply? Are there things it left out?  
> Are there things it should not have included?"

---

From: todd glassey <[email-masked]>
Date: Fri, 09 Jul 2010 07:36:36 -0700

On 7/9/2010 5:15 AM, Hannes Tschenig wrote:

WHAT specifically does "Openness and Transparency" mean - not in
nebulous namby pamby terms but specific sets of "use rules and their
oversight" - what exactly does this mean?

---

From: todd glassey <[email-masked]>
Date: Fri, 09 Jul 2010 07:36:57 -0700

On 7/9/2010 4:32 AM, Hannes Tschofenig wrote:
>> careful about what needs to be kept private and does not disclose it

Everything you have said is true but in this case the specific use of
the privacy policy is in this case to provide people who are slammed
with SPAM from people illegally harvesting contact information from IETF
postings and mailing list activity to create their own personal
commercial email lists and NOT to protect their identity or who they
represent...

You cannot take that away from them no matter what - and since the IETF
in its raging toothless manner fails to protect that data itself, it is
up to the IETF to enable everyone else to protect themselves from damage
which occurs to them by being in the IETF.

Also on the other side of the privacy coin, you will find that EVERYONE
here has a formal legal right to know who everyone else is representing
in the IETF meaning that there is no direct privacy control possible.

Todd Glassey

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 09 Jul 2010 16:39:44 +0200

Randy, 

this privacy policy effort is not a means to put someone in the spotlight because a mistake has been made. 

I think it is good that we do all sorts of experiments with the IETF network and use it for research purposes. 

Still, if someone wants to do their tests then they should do it in an open and transparent fashion and tell people what they do. The writeup should then contain information like
* what data is collected
* what is the purpose
* how long is it stored
* how is responsible 
* how does the opt-in procedure work

It would also be nice to hear the results of the effort afterwards as well. 

Without listing other persons efforts I would like to mention the location server experiment a few of us did from the GEOPRIV working group. I don't recall anymore how we announced it and what we said in our announcement (it was a few years ago already) but a document like the one written by Alissa would have helped us. Richard Barnes might remember the details.  

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Fri, 09 Jul 2010 21:28:43 +0900
> Von: Randy Bush <[email-masked]>
> An: "Hannes Tschofenig" <[email-masked]>
> CC: [email-masked]
> Betreff: Re: Comments on <draft-cooper-privacy-policy-01.txt>

> > Yes, the IETF meeting network. 

Remember the discussion about the RFID experiment, the location server experiment, 
> but you suspect the worst?  i am on the noc ops team.  you can trust my

I don't suspect anything. I believe it is good if people use the network for all sorts of tests, if they tell us what they do.

---

From: Randy Bush <[email-masked]>
Date: Sat, 10 Jul 2010 00:04:24 +0900

> this privacy policy effort is not a means to put someone in the
> spotlight because a mistake has been made.

what an amazing turn of argument.  there are communists in the state
department, i have their names on this sheet of paper which i will not
reveal.  -- joe mcarthy

as a researcher, a net op, and one involved in the ietf network, i took
it very seriously when you said ietf *network traffic* was measured and
stored for research.

>>>> we do?  about our traffic on the ietf meeting network?  stuff other
> Remember the discussion about the RFID experiment, the location server
> experiment

those are not network traffic

i am specifically concerned about the allegation that network traffic
was captured and stored.  either cite or retract.

randy, who thinks it is time to get back off this list

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 9 Jul 2010 08:16:36 -0700

With all due respect the geopriv held experiment at ietf71 could have been done anywhere, and had no impact on participants who were not involved in them.

I have zero interest in building process that might impede the activity of people conducting protocol experiments that occur effectively in isolation.

Joel's iPad

On Jul 9, 2010, at 7:39 AM, "Hannes Tschofenig" <[email-masked]> wrote:

>> than

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 09 Jul 2010 17:24:02 +0200

Very good question, Todd. 
Nowadays everyone claims to be open and transparent. 

As an example, here is what the Madrid Resolution 
http://www.gov.im/lib/docs/odps//madridresolutionnov09.pdf
has to say about the "openness principle": 

1. Every responsible person shall have transparent
policies with regard to the processing of personal
data.
2. The responsible person shall provide to the
data subjects, as a minimum, information about
the responsible person’s identity, the intended
purpose of processing, the recipients to whom
their personal data will be disclosed and how
data subjects may exercise the rights provided in
this Document, as well as any further information
necessary to guarantee fair processing of such
personal data.
3. When personal data have been collected directly
from the data subject, the information must
be provided at the time of collection, unless it has
already been provided.
4. When personal data have not been collected
directly from the data subject, the responsible
person must also inform him/her about the
source of personal data. This information must be
given within a reasonable period of time, but may
be replaced by alternative measures if compliance
is impossible or would involve a disproportionate
effort by the responsible person.
5. Any information to be furnished to the data
subject must be provided in an intelligible form,
using a clear and plain language, in particular for
any processing addressed specifically to minors.
6. Where personal data are collected on line by
means of electronic communications networks,
the obligations set out in the first and second paragraphs
of this section may be satisfied by posting
privacy policies that are easy to access and
identify and include all the information mentioned
above.

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Fri, 09 Jul 2010 07:36:36 -0700
> Von: todd glassey <[email-masked]>
> An: [email-masked]

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 09 Jul 2010 17:35:24 +0200

I understand that you don't like process. Who does? 

The good thing is that there is very little process (or even no process) for you. The additional effort is for those who run the experiment and maybe they come to the conclusion that there is no risk for others. 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Fri, 9 Jul 2010 08:16:36 -0700
> Von: Joel Jaeggli <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>
> CC: "[email-masked]" <[email-masked]>

> With all due respect the geopriv held experiment at ietf71 could have been
> done anywhere, and had no impact on participants who were not involved in
> them.
> 
> I have zero interest in building process that might impede the activity of
> people conducting protocol experiments that occur effectively in
> isolation.
> 
> Joel's iPad
> 
> > I think it is good that we do all sorts of experiments with the IETF
> network and use it for research purposes. 
> > 
> > Still, if someone wants to do their tests then they should do it in an
> open and transparent fashion and tell people what they do. The writeup
> should then contain information like
> > * what data is collected
> > * what is the purpose
> > * how long is it stored
> > * how is responsible 
> > Without listing other persons efforts I would like to mention the
> location server experiment a few of us did from the GEOPRIV working group. I
> don't recall anymore how we announced it and what we said in our announcement
> (it was a few years ago already) but a document like the one written by
> Alissa would have helped us. Richard Barnes might remember the details.  
> > 
> > Ciao
> > Hannes
> > 
> experiment, 
> > I don't suspect anything. I believe it is good if people use the network
> for all sorts of tests, if they tell us what they do. 
> > 
> > 
> >>

---

From: Fred Baker <[email-masked]>
Date: Fri, 9 Jul 2010 10:24:46 -0700

Randy, we have had at least one "researcher" sniffing passwords in plenary WiFi traffic and posting them, to embarrass people into using more secure technology. I believe he was an Ops AD at the time :-)

Agreed that personal net hygiene is the solution there.

---

From: Randy Bush <[email-masked]>
Date: Sat, 10 Jul 2010 05:39:50 +0900

> Randy, we have had at least one "researcher" sniffing passwords in
> plenary WiFi traffic and posting them, to embarrass people into using
> more secure technology. I believe he was an Ops AD at the time :-)

and if you are remembering that i did so, my admittedly mediocre memory
tells me it was not i.  though i may have help get stage time for it,
not sure.

randy

---

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Sat, 10 Jul 2010 07:11:27 +0200

+1 also

Monique

---

From: Randy Bush <[email-masked]>
Date: Sun, 11 Jul 2010 22:04:56 +0530

> That started when Jeff Schiller was security AD. Though I can't
> remember who actually did the code.
> 
> Though at the time the issue was no so much the carelessness of the
> users as the fact that the IETF password protocols were broken.

i am not confident of either of those statements

randy

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 11 Jul 2010 11:24:52 -0700

Hannes,

On 7/9/2010 4:32 AM, Hannes Tschofenig wrote:
> The Fair Information Practices are a set of principles most of us are quite
> likely to believe in, such as (copied from the Alissa's draft):

Likely, yes.  But do any of us know how to translate those principles into
particular behaviors?  Is it likely that any two of us will make the same
translation?  What about enough of us to constitute rough consensus?

Note, for example, my earlier comment that the draft's use of "the IETF" treats 
it as an entity when in fact it has little legal standing and even less 
cohesiveness in its behaviors.  Who does the term refer to?

Principles need to be accompanied with very concrete behavioral prescriptions
and proscriptions, for the principles to have real meaning.  That's what the
remaining sections of the draft seek to do.

The draft currently gives too little introduction to IETF-specific precepts, 
concepts and motivation.  All presented more simply, as Bob Hinden suggests.

> As an example, imagine some researchers doing some interesting network
> testing and collect data that travels over the IETF network then these
> principles say that you should be transparent in what you do, you should
> tell people what you collect and why, etc.
>
> I think that this is something we want people to do. And "yes" we have
> researchers looking into the traffic, people storing all sorts of data, etc.

This issue of measuring the network for research raises a deeper and more
serious problem:  informed consent.  Telling people about the work after the
fact violates this requirement.

As soon as the word "privacy" becomes relevant, an implication for research is
that we are in the realm of human subjects ethics, and the research world has
produced some fairly strict rules concerning this.  For example:

    <http://www.hhs.gov/ohrp/humansubjects/guidance/45cfr46.htm>

    especially section 46.116

Has "the IETF" been authorizing people to conduct human subjects research 
without the informed consent of the subjects?

d/
-- 

   Dave Crocker

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 11 Jul 2010 21:17:11 -0400

The sniffed "passwords" were sometimes displayed in real time on a
monitor facing the audience from the front of the room. This activity
was never called "research" that I can recall. I think the majority
reaction was that this was a fine thing to motivate improvements in
security practice. Only one person was upset, that I remember. And
several people, seeing that this was going on, wrote little network
apps to give the appearance to sniffers that plaintext passwords were
being sent so use they could display messages on said monitor, like
"this" "is" "not" "my" "real" "password", etc.

Thanks,
Donald

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 12 Jul 2010 07:53:15 -0700

On 7/11/10 11:24 AM, Dave CROCKER wrote:
> Has "the IETF" been authorizing people to conduct human subjects
> research without the informed consent of the subjects?

I'm going to insert the root trust anchor into our recursive nameservers 
for this meeting. For obvious reasons this will be the first time that 
this have every been done at an IETF meeting.

Do I require the informed consent of the ietf participants to do that or 
should I just chalk it up to tinkering?

joel

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Jul 2010 08:31:41 -0400

-- 
Website: http://hallambaker.com/

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 12 Jul 2010 09:12:37 -0700

On 7/12/2010 7:53 AM, Joel Jaeggli wrote:
> I'm going to insert the root trust anchor into our recursive nameservers for
>  this meeting. For obvious reasons this will be the first time that this have
>  every been done at an IETF meeting.
>

One view that is expressed in this thread is that folks will generally know to
make reasonable choices.

The nature of your question suggests that, indeed, we need to be quite a bit
more clear about what it is that requires consent and what doesn't.  I would
have thought that the difference between human subjects research versus network
management functionality changes would be pretty obvious.  But what's obvious is
that it isn't.

d/
-- 

   Dave Crocker

---

From: Randy Bush <[email-masked]>
Date: Mon, 12 Jul 2010 22:18:47 +0600

>> research without the informed consent of the subjects?

yes, we drag them into black helicopter and mess with their genitals.
you can be the first in maastricht.

sheesh!

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 12 Jul 2010 10:42:55 -0700

> you can be the first in maastricht.

Thanks for demonstrating the type of knowledge and professionalism that makes 
clear why the IETF needs to pay more careful attention to this.

d/
-- 

   Dave Crocker

---

From: Fred Baker <[email-masked]>
Date: Mon, 12 Jul 2010 13:16:36 -0700

I would suggest you discuss it the with IAOC. That said, assuming it doesn't create problems, I can't imagine them having an issue with it.

On Jul 12, 2010, at 7:53 AM, Joel Jaeggli wrote:

> I'm going to insert the root trust anchor into our recursive nameservers for this meeting. For obvious reasons this will be the first time that this have every been done at an IETF meeting.
> 
> Do I require the informed consent of the ietf participants to do that or should I just chalk it up to tinkering?
> 
> joel
> 
>> d/
>

---

From: Martin Rex <[email-masked]>
Date: Mon, 12 Jul 2010 22:37:24 +0200 (MEST)

> translation?  What about enough of us to constitute rough consensus?

Exactly.

As I previously mentioned, "acceptable" means different things to
different people.

Some people seem to hope that creation of a "privacy policy" is going
to improve things.  Personally, I don't think so.  Likely it will get
worse, and it may get *much* worse.  While a privacy policy may look
nice, it adds A LOT of wiggle room for lawyers.  Most companies
privacy policies are created for the "cover your ass" (CYA) purpose
by lawyers.

Going back to the Google example (because they made news several times here):

Excerpts from what they've posted:

http://www.google.com/intl/en/privacy.html

  We have 5 privacy principles that describe how we approach privacy
  and user information across all of our products:

   1. Use information to provide our users with valuable products and services.
   2. Develop products that reflect strong privacy standards and practices.
   3. Make the collection of personal information transparent.
   4. Give users meaningful choices to protect their privacy.
   5. Be a responsible steward of the information we hold. 

http://www.google.com/intl/en/privacypolicy.html

  At Google we recognize that privacy is important. This Privacy Policy
  applies to all of the products, services and websites offered by
  Google Inc. or its subsidiaries or affiliated companies except
  DoubleClick (DoubleClick Privacy Policy) and Postini (Postini Privacy
  Policy); collectively, Googles services.

But the reality actually looks like this:

  http://www.spiegel.de/international/zeitgeist/0,1518,626075,00.html
  http://www.spiegel.de/international/germany/0,1518,631149,00.html
  http://www.spiegel.de/international/business/0,1518,695718,00.html
  http://www.spiegel.de/international/germany/0,1518,645581,00.html

i.e. the government must step in to stop them from committing
large scale illegal privacy violations, because their own focus is
much more on their business model than on respect for the privacy of
the people about which they collect data.

I would be OK with consenting to very specific and explicit
PII usage scenarios within the IETF.  But many "privacy policies"
I've come across are simple inacceptable to _me_.  Probably every
"social networking site" out there, or businesses with ridiculous
policies, such as e.g. PayPal.

-Martin

---

From: todd glassey <[email-masked]>
Date: Mon, 12 Jul 2010 13:53:22 -0700

On 7/12/2010 1:37 PM, Martin Rex wrote:
> to improve things.  Personally, I don't think so.  

You mean that you think change that will protect the disclosure of
identities and proper notice as to who people represent is a bad thing?
> Likely it will get
> nice, it adds A LOT of wiggle room for lawyers. 

It can't possibly have any more wiggle room that the IETF's current
processes and that also is something worth looking at since it says the
people writing those policies either have the intent to create that
wiggle room - which is the case from my perspective or that they are so
stupid that they are dangerous to themselves and everyone around them.

Personally I think most of the people here are pretty smart - not all
ethical but damn smart. Meaning that the inclusion of the wiggle room is
intentional. That unfortunately has ethical constraints which are also
important and is a key reason why public disclosure of who you represent
is so critical here in the IETF. That being so that they can be held
accountable in a court of law for your actions here.

Todd
>  Most companies

---

From: Martin Rex <[email-masked]>
Date: Mon, 12 Jul 2010 23:34:01 +0200 (MEST)

todd glassey wrote:
> Martin Rex wrote:

If there is no written privacy policy, then one has to make assumption
about the consent on the use of PII.  And if the assumption is
conservative (as I think it has been in the IETF), then it is going
to be in the interest of the data subject, and if unclear, one
should resort to ask the data subject (= opt-in).

> > nice, it adds A LOT of wiggle room for lawyers. 

Once you have a written privacy policy, a conservative assumption about
consent is no longer necessary and will likely no longer be used,
instead an interpretation of that written policy is going to be used.
And if that written policy is interpreted based on the underlying
(lack of) data protection laws, then it could get awful
for the data subject (=opt-out).

-Martin

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 12 Jul 2010 14:52:23 -0700

> should resort to ask the data subject (= opt-in).

have we all read the note well?

http://www.ietf.org/about/note-well.html

	Your ietf contribution will be made public.

	It was accepted by everyone who registered for the meeting.

"All IETF Contributions are subject to the rules of RFC 5378 and RFC 
3979 (updated by RFC 4879)."

etc.

While it is technically possible to attend an IETF meeting without 
making a contribution what exactly is the point in doing so? you can 
save a few thousand dollars by staying home and listening to the recordings.

---

From: todd glassey <[email-masked]>
Date: Mon, 12 Jul 2010 15:16:44 -0700

>     It was accepted by everyone who registered for the meeting.

Only if a NOTEWELL commentary was publicly posted at the meeting and
notice was given at the time the person registered.

> save a few thousand dollars by staying home and listening to the

That brings up another issue of whether the requirements to attend
prevent those without the wherewithall to travel to be member's of the
IETF right?

---

From: Randy Bush <[email-masked]>
Date: Wed, 14 Jul 2010 15:10:32 +0600

> Thanks for demonstrating the type of knowledge and professionalism
> that makes clear why the IETF needs to pay more careful attention to
> this.

oh wow!  you were talking about networking, not human subject research.
fooled me.  well, i guess one hyperbole deserves another.  sorry you did
not like being hoist on your own petard.

as to the network, how many people and times need to tell you that the
ops team is unaware of anyone doing anything untoward with people's
packets or other data?  aside from the authentication which has been
pretty well discussed, no one is doing any experiments, either with your
packets or with any of your network data, of which the net ops are
aware.

i guess it serves some layer nine purpose to play demogogue on this.
may your first born suffer the micro-management of being an unpaid
volunteer net op :)

randy

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 14 Jul 2010 05:39:26 -0700

On 7/14/2010 2:10 AM, Randy Bush wrote:
> packets or other data?

How is that relevant?

d/
-- 

   Dave Crocker

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 14 Jul 2010 10:10:06 -0400

> notice was given at the time the person registered.

WG chairs are required to post the NOTE WELL notice at the beginning
of sessions.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: John C Klensin <[email-masked]>
Date: Wed, 14 Jul 2010 17:53:24 -0400

--On Wednesday, 14 July, 2010 05:39 -0700 Dave CROCKER
<[email-masked]> wrote:

>> as to the network, how many people and times need to tell you
>> that the ops team is unaware of anyone doing anything
>> untoward with people's packets or other data?

> How is that relevant?

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.  

My recollection is that the short-lived password sniffing and
posting experiment was fairly well publicized in advance and
that people with weak systems were warned to either upgrade or
stay off the wireless network.  That constituted a fairly clear
"opt-out by doing something else" possibility (not very unlike
the upcoming network access authentication issues), not a secret
experiment. 

FWIW, my experience with the folks who have had long-term
involvement with IETF networks is that they are far more
sensitive to privacy and network integrity issues than the IETF
average as well as investing a huge amount of time which the
community often seems to not recognize and for which they are
not thanked nearly often enough.  The implication that they are
somehow involved in, or turning a blind eye to, nefarious
activities is very unfortunate.

    best,
      john

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 14 Jul 2010 15:55:23 -0700

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

Given that the effort effort was initiated, a variety of implications follow.  I 
was merely citing one, based on references that were made to using the data for 
"research".

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.

d/
-- 

   Dave Crocker

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 Jul 2010 12:02:52 +0600

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

i think you had better have a cite for where a message was posted and
ietf network data were disclosed.  or is this more wild hyperbole?

randy

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 15 Jul 2010 00:02:26 -0700

Randy,

As always, a delight to watch you in action.  So, thanks for your kind 
suggestion but I don't feel the need of trying to defend a statement that I did 
not make.  In this case, I never made the claim that data was divulged.  Others 
did.  Please consider reading the text that is actually in front of you.[*]

Since your goal in an exchange like this is to keep things unproductive, to 
distract from the original goal, I'll leave you on your own for any further 
creative misinterpretations.  Heck, you might even find then sitting on a petard.

d/

[*] Perhaps you meant to challenge:

> "this" "is" "not" "my" "real" "password", etc.

or:

On 7/9/2010 10:24 AM, Fred Baker wrote:
 > Randy, we have had at least one "researcher" sniffing passwords in plenary
 > WiFi traffic and posting them, to embarrass people into using more secure
 > technology. I believe he was an Ops AD at the time:-)

While my own note was responding to:

-- 

   Dave Crocker

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 Jul 2010 13:51:06 +0600

> distract from the original goal

you have no concept of what my goal is and have no prerogative to say
so.  it is mostly to try and cut through the bs, hyperbole, innuendo
about network experiments which have never happened, and emotionally
loaded crap about experiments on human subjects.

> I'll leave you on your own for any further creative
> misinterpretations.  Heck, you might even find then sitting on a
> petard.

cool!  you go back in my procmailrc.  bummer that i will miss your
well known wide-ranging contributions to the internet.

randy

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 15 Jul 2010 06:58:26 -0700

On 7/15/2010 12:51 AM, Randy Bush wrote:
>    what my goal is ... mostly to try and cut through the bs, hyperbole, innuendo
...
> you go back in my procmailrc.  bummer that i will miss your

If that's what it take to get you to refrain from contributing distracting 
misrepresentations, it will be an effective way to reduce one source of bs, 
hyperbole and innuendo.

Thanks.

d/

-- 

   Dave Crocker

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 15 Jul 2010 15:36:55 +0100

Hi Stephan,

Thanks.

> not certain how exactly it needs to be delivered--which puts them  

Point taken. The document currently lacks clarity about who is  
actually doing the data handling. I think the process of sorting that  
out will be highly instructive. Getting a general understanding of who  
is responsible for what will be the first step towards being able to  
give those people guidance about data handling.

> our meetings.

The jurisdiction of stored data is definitely one point that needs to  
be better documented, I agree.

> And so on.

If you have specific ideas of other spots where the document over- 
promises, a list would be appreciated. I can take further  
clarifications back to the secretariat or whoever the responsible  
party is.

Thanks,
Alissa

>> that

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Jul 2010 08:26:51 -0700

At 3:36 PM +0100 7/15/10, Alissa Cooper wrote:
>If you have specific ideas of other spots where the document over-promises, a list would be appreciated. I can take further clarifications back to the secretariat or whoever the responsible party is.

For me, the biggest over-promise is that someone reading the document might think that there is some remedy if the I* fails to live up to it. The line between principles and promises in your document is quite unclear. Very specifically: I don't want the IETF to adopt your document if it opens up an avenue for an aggrieved participant (which, in the IETF, is anyone who knows how to subscribe to a mailing list, even this one) can cause damage to the IETF if the IETF doesn't meet the promise in that person's eyes.

If you feel that it is valuable to list privacy principles for an organization like the IETF, great. If you want the IETF to promise something that would cost us money or, possibly worse, much lost time from the I*, please don't move this forwards.

There are already many reasons why some people don't participate in the IETF. For some, the IETF is too informal for their comfort; those folks gravitate towards other SDOs who have more formal membership and rules. For some, the inability to rant freely on mailing lists without being barred is too high a bar. For some, If we lose a few people (and it does seem like a very few) for lack of a privacy policy that could be enforced by civil law or threat of civil lawsuits, that may be an acceptable risk.

--Paul Hoffman, Director
--VPN Consortium

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 15 Jul 2010 16:37:27 +0100

Hi Bob,

Thanks for your comments. Responses inline.

On Jul 8, 2010, at 11:05 PM, Bob Hinden wrote:

> I have now read the draft.  My overall comment is that I am not  
> convinced if this is needed and am sympathetic to the views  
> expressed on the mailing list that this is solving a problem the  
> IETF doesn't have.
>
> Comments below.
>
> Bob
>
>
> General comments:
>
> If the IETF is to have a privacy policy, I would prefer it to be  
> much simpler and of the form where it first starts with a general  
> statement that the IETF does it's work in public and almost all  
> information information supplied to the IETF is made public and will  
> be available on the IETF (and other related) web sites.

A simpler intro with a focus on the public-ness of the IETF is  
definitely doable.

> I would then list the exceptions.  For example, credit card  
> information for meeting registration and social tickets, and  
> information for "letters of invitation".   Note: As I read the  
> draft, there is very little that actually falls into the private  
> category.  This leads to to wonder about the scope of the problem  
> this draft is solving.

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

>
> The IETF goes to great length to tell people about how we do our  
> work and what is considered a public contribution, via the Note  
> Well.  I would be surprised if anyone thought otherwise.  Doing our  
> work in public is essential to how the IETF works.
>
> Detailed Comments:
>
> This makes it sound like the highest priority of the IETF is  
> Privacy.  I don't think this is true as I described above.  The vast  
> majority of what the IETF does in Public.  There is very little that  
> is Private.  The IETF is careful about what needs to be kept private  
> and does not disclose it.

That sentence was cribbed straight from ISOC's policy and could easily  
be removed.

> I don't know if it is appropriate that the IETF apply these  
> practices.  Or if there are other practices that would be more  
> appropriate.

I know that the IETF is different from many other organizations, but  
the Fair Information Practices form the basis of more or less every  
information privacy law, regime, policy, best practices, self- 
regulatory framework, and guidance document around the world. The IETF  
doesn't have to reference them, but I think the reference makes the  
document better rather than worse -- at least we're basing it on some  
well-accepted framework.

> The IETF is different from other organizations in that much of our  
> data is public and not private.

It might make sense to remove the parts of the document that discuss  
public data so that it only focuses on private data.

> The rest of the Introduction appears to be a summary of the first  

One suggestion I got on the -00 was to summarize the Fair Information  
Practices up front since they may not be familiar to many people. So  
the summary was by design.

> I don't know anything about this web page, who produced it, how  
> stable it is, etc, etc.

On who produced it, I think it's fairly obviously produced by the OECD.

> It is fairly long, around 21 pages.  I don't know if this is  
> appropriate for the IETF.  I think it would better to not include  
> this information as it is hard to judge how appropriate it is.   
> Also, some of the practices seem to be at odds with normal IETF  
> practices.  For example, it implies that individuals have complete  
> control of the data the IETF makes public.  This isn't true in most  
> cases.

Removing the public data parts of the policy might help here.

>
> Section 2 and 3
>
> A lot these section is a summary of what is defined in other places  
> (References 2, 3, 4, 5, 7, 8).  Other parts of the text are fairly  
> generic, such as the information that a web server can learn about a  
> web client.  Not thing very IETF specific here.  I don't see very  
> much value repeating this.

One benefit would be having all of it in one place, especially if this  
turns into a layered policy that is referenced from a central location  
(like www.ietf.org).

> The first two "sell & rent" is true, but the "exchange" is not true  
> as you state later in the section.  Much of the data we collect is  
> exchanged.
>

Correct. This was more language pulled from ISOC's policy that I can  
fix.

> Section 5
>
> I am not really qualified to comment on the specifics here, such as  
> how long credit card or letter of invitation information needs to be  
> retained.  I would have thought that all financial data needs to be  
> kept for some number of years.
>
> This describes our current operational practices regarding log  
> files.  Including specific times for retention will make it hard to  
> change this in the future.

If the written policy is not too difficult to change, the actual  
policy shouldn't be hard to change either.

> Also, if log files are going to be covered, what happens to the  
> backups?  Are we required to scrub the backups?  This would be  
> difficult and expensive.  What about backups of credit card  
> information?

I need to find out the back-up policies, but the idea right now is  
just to document the current policy, not change it.

>
>
> Section 10
>
> In the acknowledgment section you cite the IAOC.  The IAOC has not  
> done any formal review of this draft.  It is better if you cite the  
> people in the IAOC you have discussed this with you and not list the  
> IAOC.
>

Got it.

>
>
> Section 11
>
> I think most of the references are Normative, not Informative.  That  
> is, this draft depends on these documents.
>
>

Fine by me.

Thanks,
Alissa

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Jul 2010 12:42:25 -0400

--On Wednesday, July 14, 2010 15:55 -0700 Dave CROCKER
<[email-masked]> wrote:

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Jul 2010 12:57:06 -0400

--On Thursday, July 15, 2010 16:37 +0100 Alissa Cooper
<[email-masked]> wrote:

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

Alissa,

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 

	(a) Privacy policy for the IASA and the data it handles
	in furtherance of its administrative role.
	
	(b) Privacy policy for the IETF in its standards-making
	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.

    john

---

From: todd glassey <[email-masked]>
Date: Thu, 15 Jul 2010 12:09:19 -0700

> For me, the biggest over-promise is that someone reading the document might think that there is some remedy if the I* fails to live up to it. 
There is and its litigation. Also not having the policy also causes the
same liability and there is significant precedent to prove this... So it
doesnt matter from a liability standard whether the IETF puts this in
place or not, the IETF is liable already

The best part is the intentional destruction of evidence of anything is
very very expensive these days and the IETF needs to 'get' that the
people in this WG have no real interest in making the IETF legally
functional - they have the interest in providing as much smoke and
mirrors as it takes to say "we have a policy so go away"...

http://www.google.com/search?q=spoliation+sanctions&sourceid=ie7&rls=com.microsoft:en-us:IE-SearchBox&ie=&oe=

and the above search should give you what you need to see this is true...

Todd Glassey
> The line between principles and promises in your document is quite unclear. Very specifically: I don't want the IETF to adopt your document if it opens up an avenue for an aggrieved participant (which, in the IETF, is anyone who knows how to subscribe to a mailing list, even this one) can cause damage to the IETF if the IETF doesn't meet the promise in that person's eyes.
>

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 15 Jul 2010 14:34:22 -0700

> In principle, I'm in favor of having a published privacy policy.
...
    < extended repetition of based goals elided >
...
...
> hidden conspiracies, etc., don't further that discussion.

Anyone who has dealt with a human subjects review panels would wish to be as 
dismissive of them as you are.  But it's a serious topic and I offered it 
seriously.  Perhaps the scope of the IETF's privacy work does not need to 
include it.  But perhaps it does.  The discussion was raising areas of concern. 
  I offered one more.

That you might believe it doesn't fall within scope is fine, although I'll 
suggest that such an opinion is always strengthened when accompanied by 
considered reasons, rather than being facilely to lump them in with red-flag 
labels like hyperbole.  (If you wish to address thread activity involving those 
red-flag behaviors, please direct your mail to your buddy.)

That anyone would be so mechanically dismissive of this issue underscores the 
challenges of discussing privacy in this community.

I explained why I thought the issue was worth considering along with the rest of 
the concerns about privacy.  I didn't generate the reference to doing research 
and I didn't generate the reference to unauthorized disclosure of personal data.

So please do feel free to respond with relevant substance rather than a quick 
hand wave.

>     It is also

OK.  And none of those passwords were sufficient to identify their owner, right?

d/

-- 

   Dave Crocker

---

From: John Morris <[email-masked]>
Date: Thu, 15 Jul 2010 23:50:58 +0100

Paul,

You appear to be concerned about exposing the IETF to risk by the  
adoption of a privacy policy (but apologies if I am misunderstanding  
the concern you expressed).  The absence of a privacy policy, however,  
actually increases risk to the IETF in at least three ways:

1.  As a general matter, many organizations that interact with lots of  
people (especially collecting financial information from them) use a  
broad range of written policies to reduce risk, by plainly stating a  
position on an issue so that employees have clear guidance about how  
to act or respond in a given situation.  Policies could be  
particularly useful (for example) during a busy crush of new in-person  
registrations for an IETF meeting, when there are lots of interactions  
with personal data but senior management may not be immediately  
available in-person to give guidance if an unusual situation arises.   
Having written policies in that kind of situation reduces risk.

2.  We have many examples of leading banks, stores, and others  
mishandling credit card and other records, so unless the IETF has come  
up with some secret security sauce to eliminate all possibility of a  
human or technical screwup with personal info, there is clear risk  
that the IETF could mishandle data and be at the wrong end of a  
litigation.  The IETF would likely face liability risk with or without  
a privacy policy, but the fact that it could not even be bothered to  
have such a policy would certainly be used by the plaintiffs to argue  
for an increase in the damages that the IETF might have to pay.   
Having a written privacy policy would avoid this particular risk, and  
might even reduce the risk of a screwup in the first place.

3.  And, although my legal expertise is limited to U.S. law, I think  
is very likely (if not certain) that right now the IETF is operating  
in violation of the European Union's Data Protection Directive, which  
requires that any entity that collects personal information must  
provide clear prior notice to affected individuals about the data  
collection.  The EU is particularly sensitive when European citizens'  
data is collected by U.S. entities, which happens all of the time when  
European citizens register with the IETF's California-based  
administrative secretariat.  (There is similar risk with regard to the  
California Online Privacy Protection Act, which specifically requires  
the posting of a privacy policy by entities that collect personal  
information online from California citizens - there is a good chance  
the law would not apply to the IETF, but there is some risk that it  
would.)  Having a privacy policy would help the IETF comply with  
European law, which would reduce risk (and the uncertainly about the  
California law would be avoided).

So if one's goal is to reduce risk to the IETF so the IETF is not  
harmed by legal liability, I think there are very strong arguments to  
have a privacy policy.  Indeed, the legal-risk-related arguments in  
favor of a having a privacy policy are so strong that I believe the  
powers-that-be should move to promulgate such a policy even if there  
is not consensus in the broader IETF community (just like, I assume,  
the powers-that-be have purchased a range of standard business  
insurance policies without ever having consulted the IETF community).   
The draft of a proposed privacy policy was submitted as an I-D and  
circulated to the [email-masked] mailing list simply because that was  
suggested to be the most appropriate way for individual members of the  
IETF community to raise this issue.  A decision to adopt a privacy  
policy is not one, IMO, that should rise or fall on a community hum  
(although in the end, I think there been more +1s than -1s put forward  
on this list).

John

On Jul 15, 2010, at 4:26 PM, Paul Hoffman wrote:

> For me, the biggest over-promise is that someone reading the  
> document might think that there is some remedy if the I* fails to  
> live up to it. The line between principles and promises in your  
> document is quite unclear. Very specifically: I don't want the IETF  
> to adopt your document if it opens up an avenue for an aggrieved  
> participant (which, in the IETF, is anyone who knows how to  
> subscribe to a mailing list, even this one) can cause damage to the  
> IETF if the IETF doesn't meet the promise in that person's eyes.
>
> If you feel that it is valuable to list privacy principles for an  
> organization like the IETF, great. If you want the IETF to promise  
> something that would cost us money or, possibly worse, much lost  
> time from the I*, please don't move this forwards.
>
> There are already many reasons why some people don't participate in  
> the IETF. For some, the IETF is too informal for their comfort;  
> those folks gravitate towards other SDOs who have more formal  
> membership and rules. For some, the inability to rant freely on  
> mailing lists without being barred is too high a bar. For some, If  
> we lose a few people (and it does seem like a very few) for lack of  
> a privacy policy that could be enforced by civil law or threat of  
> civil lawsuits, that may be an acceptable risk.
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 15 Jul 2010 18:59:42 -0400

I'm not really keen on getting involved in this discussion any more
than I have been, but I can't help noting one thing:

On Thu, Jul 15, 2010 at 11:50:58PM +0100, John Morris wrote:

> human or technical screwup with personal info, there is clear risk that 
> the IETF could mishandle data and be at the wrong end of a litigation.  

Given that practically every such leading back and store and so on had
a rich, long, detailed, hard to read privacy policy, I fail completely
to see how the having of a policy provides any value at all to the
IETF in such cases.  In the case of companies and so on, it has a
value, because firing people for violating the policy is the sort of
consequence that employers can use.  But the IETF isn't like that.  It
isn't even a legal entity.  So it doesn't have anyone to fire, &c.

As I've said before, I can see arguments in both directions on this
topic.  But I don't think it does us any good to keep saying,
"Everyone else has one."  Everyone else is also incorporated.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Martin Rex <[email-masked]>
Date: Fri, 16 Jul 2010 01:59:10 +0200 (MEST)

John Morris wrote:
> to act or respond in a given situation.

I think you misrepresent the purpose of these policies.
The issues are
 1. a blame-shifting tool for PR if something goes wrong
 2. limit liabilities by disclaiming as much as legally possible,
 3. have yet another means to fire an employee/clerk.

How often have you seen it happening that an employee or clerk
(or federal agent for that matter) pulls out a big binder of policies
when being faced with a new situation and study them carefully while
you (and others) wait paitently?

> mishandling credit card and other records

Yeah -- and that happens although all of these have big binders
full of policies.  

>
>                                            so unless the IETF has come  

This is ridiculous.  I have not seen a single privacy policy
that is in the interest of the data subject.  They're all in the
interest of the data collector for 1+2+3 above.

> 
> 3.  And, although my legal expertise is limited to U.S. law

it shows.

>                                                              I think  
> in violation of the European Union's Data Protection Directive,

nope, never while they're in the U.S.  National data protection laws do
not apply for someone operating entirely in a different country.

>
> which requires that any entity that collects personal information must  
> collection.

While this is true in principle, there are some exemptions in that law.
You can collect data that you need for billing an order placed by
a data subject for the purpose of billing and for as long as you
legally need it _without_ having to get a consent agreement from
the data subject.

btw. the EU data protection directive is a framework for which each
national EU legislator has to create a national law.

>             The EU is particularly sensitive when European citizens'  
> administrative secretariat.

The EU is particularly sensitive about passing on data that was collected
_within_ the EU, potentially with a clear usage restriction, outside of
the EU jurisdiction without consent of the data subject and without
control whether the permitted usage is not exceeded and whether the
data subjects can still exert its personal rights to that data granted
by the EU data protection laws.

> is not consensus in the broader IETF community

The world is going to end!  News at 11:00

-Martin

---

From: John Morris <[email-masked]>
Date: Fri, 16 Jul 2010 01:13:19 +0100

> not apply for someone operating entirely in a different country.

Without trying to response to your scattershot of assertions and  
attacks, I'll just ask:  Where is the IETF meeting in 10 days?  And  
citizens of what continent are most likely be walk-in registrants?   
And you think that the IETF is not subject to the laws in Europe?   
Good luck with that....

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 20 Jul 2010 10:16:40 +0100

> not apply for someone operating entirely in a different country.

I have no idea about to what extent the EU directive applies. But I
would
have thought it would be tricky to argue that the IETF is operating
entirely in the US when it's about to meet and collect data in
Maastricht.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: John Levine <[email-masked]>
Date: 21 Jul 2010 22:33:55 -0000

>actually increases risk to the IETF in at least three ways:

 ... none of which applies since 

a) the IETF has no formal legal existence
b) the IETF has no employees
c) the IETF signs no contracts

It would be helpful for someone, anyone, to explain in terms specific
to the IETF what a privacy policy will accomplish.  Please be sure to
make no references whatsoever to any other organization, since none of
them are (un)organized like the IETF is.  While you're at it, be sure
not to use the word "obvious" or its synonyms.

I could be persuaded that there is a reason to have a privacy policy,
but everything I've seen so far has been a combination of faulty
analogies and mistaken premises.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 22 Jul 2010 01:30:30 +0200

> Exceptionalism really does not work very well as a legal strategy.

I'm not saying that the IETF is unique in the universe, but I am saying 
that all of the arguments advanced so far for privacy policies are 
relevant to corporations with employees and revenue and contacts, which 
the IETF definitely is not.

Someone pointed out that the IAOC, which does have a legal existence, 
could find a privacy policy useful, which is not unreasonable, but I do 
think that anyone who proposes such a policy should at least be familiar 
with the (non)structure of the IETF and identify what aspects of it apply 
to what four-letter bits.

R's,
John

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 21 Jul 2010 19:39:27 -0400

On Jul 21, 2010, at 7:30 PM, John R. Levine wrote:

> I'm not saying that the IETF is unique in the universe, but I am  
> saying that all of the arguments advanced so far for privacy  
> policies are relevant to corporations with employees and revenue and  
> contacts, which the IETF definitely is not.
>
> Someone pointed out that the IAOC, which does have a legal  
> existence, could find a privacy policy useful, which is not  
> unreasonable, but I do think that anyone who proposes such a policy  
> should at least be familiar with the (non)structure of the IETF and  
> identify what aspects of it apply to what four-letter bits.

The IETF Trust is a legal entity, as is ISOC. I am not aware of any  
reasons for considering the IAOC as having a legal existence.

Regards
Marshall

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 21 Jul 2010 17:10:42 -0700

> a) the IETF has no formal legal existence

With creation of the IETF Trust, that is no longer true.  There also have been 
comments from one or another attorney that the absence of formal legal formation 
is not the same as no "formal" legal existence.  All of which at least suggests, 
once again, that we ought to leave legal pronouncements to attorneys (and even 
then, seek a second opinion.)

> b) the IETF has no employees

Well, again, there's a formal correctness to that statement and a practical 
incorrectness.

> c) the IETF signs no contracts

I was under the impression that the IAOC now signs the event contracts. But 
perhaps that's not correct.

> to the IETF what a privacy policy will accomplish.

Ahh, well.  That's a good idea, not matter your earlier assertions.

d/
-- 

   Dave Crocker

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 21 Jul 2010 20:18:27 -0400

Dear Dave;

On Jul 21, 2010, at 8:10 PM, Dave CROCKER wrote:

> With creation of the IETF Trust, that is no longer true.  There also  
> have been comments from one or another attorney that the absence of  
> formal legal formation is not the same as no "formal" legal  
> existence.  All of which at least suggests, once again, that we  
> ought to leave legal pronouncements to attorneys (and even then,  
> seek a second opinion.)
>
>
> Well, again, there's a formal correctness to that statement and a  
> practical incorrectness.

We come close - from BCP 101
The IASA consists initially of a single full-time ISOC employee, the  
IETF Administrative Director (IAD), who is entitled to act on behalf  
of the IASA at the direction of the IAOC.
> I was under the impression that the IAOC now signs the event  
> contracts. But perhaps that's not correct.

ISOC signs any such contracts.

Regards
Marshall

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 21 Jul 2010 17:22:26 -0700

On 7/21/2010 5:18 PM, Marshall Eubanks wrote:

> The IASA consists initially of a single full-time ISOC employee, the IETF
> Administrative Director (IAD), who is entitled to act on behalf of the IASA at
> the direction of the IAOC.

I thought that the tRSE (or iRSE, or whatever the first letter is) also 
qualifies in practical terms as an employee of the IETF (and, yes, I realize 
it's a short-term contract, but I continue to hope we aren't trying to be overly 
clever or precise here.)

> ISOC signs any such contracts.

ahh.

We certainly live with some complicated arrangements...

d/
-- 

   Dave Crocker

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 Jul 2010 19:24:52 -0400

My memory of partnership law is that if an agreement has the form of a
partnership it is a partnership regardless of claims in the contract
document explicitly stating it is not. It does not seem very likely
that the courts would take a different line with respect to
organizations that claim not to be organizations.

There may be some ambiguity as to what the status of the IETF is, but
that does not help.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 Jul 2010 21:11:35 -0400

On Wed, Jul 21, 2010 at 8:10 PM, Dave CROCKER <[email-masked]> wrote:
> With creation of the IETF Trust, that is no longer true.  There also have
> been comments from one or another attorney that the absence of formal legal
> formation is not the same as no "formal" legal existence.  All of which at
> least suggests, once again, that we ought to leave legal pronouncements to
> attorneys (and even then, seek a second opinion.)

Especially when what is being suggested is an exception to the normal
case. In general, the more different a legal situation is, the more
important it is to take regular and specific legal advice.

A => B does not mean that !A => !B.

That is called denying the antecedent.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Jul 2010 23:27:01 -0400

> We certainly live with some complicated arrangements...

Without wishing to weigh in on whether the privacy policy is a good
idea, I think that "living with" was an important part of John
Levine's argument up-thread.  In many cases, the actual governing
organization that actually gets hold of the bit of PII isn't the IETF
at all.  It's the privacy policy of _that_ organization that's going
to govern for real the treatment of the PII.  This makes the analogy
between the IETF and other privacy-policy-having organizations weaker.
So if you think having a privacy policy is a good idea, and you think
so because other organizations have such a policy, you'll need to show
why the analogy between the IETF and other organizations is strong in
relevant ways.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 23 Jul 2010 23:59:49 -0400

> why the analogy between the IETF and other organizations is strong in

I must admit that I am not following this. What organization are you  
talking about ?
ISOC ? The IETF Trust ? Something else ?

Further, I can't see why the IETF can have a privacy policy or why  
that would be
different from having a patent policy or, for that matter, a NOTE WELL.

Regards
Marshall

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 24 Jul 2010 00:11:57 -0400

> ISOC ? The IETF Trust ? Something else ?

The analogy coming from those arguing for the privacy policy has been,
in part, "The IETF should have a privacy policy because N has one,"
where N is some non-IETF organization.  One of them seems to be ISOC,
although the policy itself is reputedly partly taken from that of the
CDT.

I believe John Levine's point, up-thread, was that differences in the
way the IETF operates, as compared to those other organizations (for
all N, that is), are entirely relevant to whether the IETF needs a
privacy policy.

I am not personally convinced that another policy is a good idea,
especially if it has no practical consequences; though I'm not willing
just now to say that I think it's a bad idea.  I'd just like clearer
arguments as justifications.  One thing that would help me a lot is
for those justifications to be part of an introduction in the I-D.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 24 Jul 2010 06:30:24 +0200

On 7/24/2010 6:11 AM, Andrew Sullivan wrote:
> especially if it has no practical consequences;

At this point, I'd go further and say /specifically/ if it has no practical 
consequences.

To the point:

A 'policy' does not mean much if it does not affect behaviors.  If instead it is 
to affect behaviors, then those behaviors need to be specified.

The IETF has people who act as its agents.  Some of those agents have access to 
information that can be considered sensitive.

We should stop talking about this topic as if we were lawyers and start talking 
as if we cared about how agents of the IETF handle sensitive information.  That 
is what I understand the practical purpose of a privacy policy to be.

d/

-- 

   Dave Crocker

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 24 Jul 2010 00:42:06 -0400

On Sat, Jul 24, 2010 at 06:30:24AM +0200, Dave CROCKER wrote:
> We should stop talking about this topic as if we were lawyers and start 
> talking as if we cared about how agents of the IETF handle sensitive 
> information.  That is what I understand the practical purpose of a 
> privacy policy to be.

I'm about to exceed my self-imposed rate limit, so I'll not respond
again in this thread, but I half agree with the above.

If what we want is a statement of principles about what things the
IETF considers private and not private in the context of IETF
interactions, I think that's reasonable.  I understood his remarks as
meaning that this was also what Bob Hinden wanted (in his comments
on the I-D in question).  I don't think that's a privacy policy,
however, even if I might think it a good idea.

A privacy policy is normally something like what's in the I-D: it
specifies what the parties will do and will not do.  It sometimes even
specifies what happens when the policy is violated.  It is (or ought
to be, if useful) quite specific.  I haven't yet seen an argument that
convinces me that such a policy is something the IETF should have,
given that "the IETF" is a sort of hydra in which different policies
might apply depending on the head with which one interacted.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Fred Baker <[email-masked]>
Date: Sat, 24 Jul 2010 07:03:09 +0200

The IETF has a legal home, named ISOC. Let me rephrase: "Do you think ISOC is not subject to the laws of Europe?"

Good grief.

---

From: Ole Jacobsen <[email-masked]>
Date: Fri, 23 Jul 2010 23:13:58 -0700 (PDT)

How about if we ONLY had a privacy policy which pertained to the data 
we have to collect in order to register people for our meetings? It 
seems reasonable to have a statement that says we (the secretariat or
its agents) will only use the info as needed to process payments etc,
will not use the data to make, sell or otherwise create lists for 
purposes other than the meetings?

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 24 Jul 2010 08:45:26 +0200

there you go, defeating the real purpose of these threads.

stop trying to be practical.

d/

ps. whither?  i'm staying at the van der valk hotel.

-- 

   Dave Crocker

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 24 Jul 2010 12:58:13 +0200

> to the IETF what a privacy policy will accomplish.

Prevent cockups.

Too much time is spent discussing these issues over and over again. 
Remember that RFID experiment and how the IETF list blew up with privacy 
discussion?

I'd love to have a privacy policy done, so that next time the poor fools 
won't accidentally cause another of those threads. (God, it must suck to 
want to run an experiment and run into one of those threads.)

Arnt

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 24 Jul 2010 08:21:39 -0400

On Jul 24, 2010, at 6:58 AM, Arnt Gulbrandsen wrote:

> Remember that RFID experiment and how the IETF list blew up with  
> privacy discussion?
>
> I'd love to have a privacy policy done, so that next time the poor  
> fools won't accidentally cause another of those threads. (God, it  
> must suck to want to run an experiment and run into one of those  
> threads.)

Oh, I don't know about that - it seems to me that the experimenters  
would get the equivalent of 6 months of high profile discussion and  
criticism from the likes of Slashdot, Techcrunch and the Register in a  
few weeks, and without requiring an expensive product launch. True, if  
the experiment was purely technical that would be a pain, but if the  
experimenters had commercial intents I think that that would be pretty  
valuable.

Regards
Marshall

---

From: "John R. Levine" <[email-masked]>
Date: 24 Jul 2010 18:36:32 -0400

> The IETF has a legal home, named ISOC. Let me rephrase: "Do you think 
> ISOC is not subject to the laws of Europe?"

Of course they are.  But that's OK, since ISOC has had a privacy policy in 
place since 2006, which makes specific reference to the "safe harbor" 
policy kludge worked out between the US and EU:

http://www.isoc.org/help/privacy/

> Good grief.

Indeed.  Do we agree that this means we're done?

R's,
John

---

From: Fred Baker <[email-masked]>
Date: Sat, 24 Jul 2010 19:02:36 +0200

> Indeed.  Do we agree that this means we're done?

I'm not opposed to the IETF having a privacy policy separate from ISOC's; I'm also not opposed to simply using ISOC's. Whatever we use, I think we should agree to it.

What I don't understand is the amount of arm wrestling that happens on this list. If I were to assert that the sky was blue, someone would want to know the frequency of the color, and someone else would report that the sky as s/he observed it was grey. The discussion would last for weeks, with the person who observed that it was grey periodically reporting a change in status.

I think we are done if we have agreed on a privacy policy. That could mean that we have agreed that there is no policy (and were willing to, as a result, stop screaming about the privacy implications of every little thing that cropped up; we have RFCs that have arisen from such rants), agreed to use ISOC's policy (see http://www.isoc.org/help/privacy/), have agreed to the one Alissa has proposed, or have agreed to something else. At this point, I'm not sure we agree on anything in particular.

I read Alissa's proposal. I might have a few nit points, and back when the thread was about that proposal I thought some others had interesting points. On the whole, it is a privacy policy I could subscribe to, and those points might improve it.

---

From: todd glassey <[email-masked]>
Date: Sat, 24 Jul 2010 10:07:05 -0700

On 7/24/2010 3:36 PM, John R. Levine wrote:
> Of course they are.  But that's OK, since ISOC has had a privacy
> policy in place since 2006, which makes specific reference to the
> "safe harbor" policy kludge worked out between the US and EU:
>

No, we are NOT done with this, not unless that is the IETF is formally
acknowledging that its practices meet that existing privacy mandate and
in a manner which provides a demonstration of how that process is
implemented in the IETF.

Todd Glassey

---

From: "John R. Levine" <[email-masked]>
Date: 24 Jul 2010 21:37:41 -0400

> What I don't understand is the amount of arm wrestling that happens on this list.

You're certainly right, there's a culture of nitpicking.  In this case I 
think some of the issues are nitpicks, while some are significant.  The 
IETF is very peculiarly organized, which suggests that it would need a 
somewhat peculiar privacy policy.  Here are some questions that I think 
are not nits:

Although the IETF per se has no legal existence, ISOC, the IETF Trust, and 
perhaps other things I haven't noticed do.  How should an IETF privacy 
policy relate to the ISOC's existing privacy policy?  Does the IETF Trust 
need a privacy policy?

The IETF potentially collects PII in various ways, including publication 
of Internet Drafts and RFCs, messages on mailing lists, registration info 
for meetings, and activities in meetings.  Meeting activites include paper 
documents (meeting attendance sheets), electronic session presentation 
material, oral session material which is transmitted over the voice feeds, 
jabber chats, and random traffic sent over meeting networks.  Are there 
other forms of PII?  Should a privacy policy treat them all the same, or 
differently?

Some people have argued that it should be possible to participate in some 
or all IETF processes while remaining partly or completely anonymous.  Is 
this a reasonable expectation?

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 26 Jul 2010 11:36:39 -0400

I would prefer it if the IETF stopped publishing the phone numbers of
every IETF attendee for IETF 52, and quite possibly some other
meetings as well.

This would appear to me to be a privacy issue.

On Sat, Jul 24, 2010 at 9:37 PM, John R. Levine <[email-masked]> wrote:
> think some of the issues are nitpicks, while some are significant.  The IETF
> is very peculiarly organized, which suggests that it would need a somewhat
> peculiar privacy policy.  Here are some questions that I think are not nits:
>
> The IETF potentially collects PII in various ways, including publication of
> Internet Drafts and RFCs, messages on mailing lists, registration info for
> meetings, and activities in meetings.  Meeting activites include paper
> Some people have argued that it should be possible to participate in some or
> all IETF processes while remaining partly or completely anonymous.  Is this
> a reasonable expectation?
>
> R's,
> John