Hi SM,
Thanks for your comments. Some responses are inline.
On Jan 30, 2013, at 7:29 PM, SM wrote:
At 14:30 16-01-2013, IAB Chair wrote:
This is an announcement of an IETF-wide Call for Comment on 'Privacy
Considerations for Internet Protocols'.
The document is being considered for publication as an Informational RFC
within the IAB stream, and is available for inspection here:
http://tools.ietf.org/html/draft-iab-privacy-considerations
In Section 1:
'With regard to data, often it is a concept applied to
"personal data," information relating to an identified or
identifiable individual.'
I suggest rewriting the above sentence.
The authors have re-written that sentence several times and in different ways
already. Do you have a specific suggestion about how to improve it?
"Many sets of privacy principles and privacy design frameworks have been
developed in different forums over the years."
There is also some work in the APEC region (see
http://publications.apec.org/publication-detail.php?pub_id=390 (payware)).
As far as I know the APEC framework is one of many frameworks (none of which we
cite since there are so many) based on the OECD-style FIPs. Is that incorrect?
As a nit, the draft-ietf-geopriv-policy-27 reference should be RFC 6772.
Fixed.
I read some of the previous versions of this draft. The Abstract Section
describes the document as providing guidance for developing privacy
considerations for inclusion in protocol specifications. I found the draft
difficult to digest. I suggest simplifying the draft to make the guidance
accessible to the target audience.
I'm not quite sure what you are recommending here, but we have had
conversations in the IAB privacy program about moving the guidance part up, or
otherwise trying to make the focus on the guidance piece more prominent. The
difficulty is that there is a broad range in the extent to which potential
readers are familiar with privacy concepts, so jumping straight into the
guidance would not be appropriate for some portion of the audience. If you have
concrete suggestions for how to simplify, those would be helpful.
One of the issues nowadays is what to do about intermediaries. If I am not
mistaken RFC 3238 was one of the first documents to tackle that question from
a privacy perspective. There have been a few proposals to introduce
intermediaries as part of the architecture (I am using the word is used
loosely). It is easy to argue for intermediaries based on use cases. There
was a case recently where the users only became aware that they have signed
up for using an intermediary through the EULA.
The draft introduces the concept of secondary use (Section 4.2.3). Strictly
speaking, it is a disclosure (Section 4.2.4).
Not all secondary uses involve disclosure (such as the example given in 4.2.3).
I have added a sentence to clarify this, however:
"Secondary use encompasses any use of data, including disclosure."
The draft mentions consent in several places. The authors are likely aware
that consent was a hot topic for DNT. It's easier to start with something
that is easy for the average person to understand and build from there.
Section 7.2 could more about consent instead of user participation or control.
We tried to think of a case where a consent mechanism was actually developed in
the IETF, but as a general matter consent mechanisms tend to be out of scope,
which is why we focus more on user controls (which still show up rarely but do
show up).
Thanks,
Alissa
Regards,
-sm