Hi SM, let me just pick a few points:
On Feb 24, 2013, at 6:25 PM, SM wrote: > Hi Alissa, > At 09:10 23-02-2013, Alissa Cooper wrote: >> 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. > > From Section 1: > > "Privacy is a complicated concept with a rich history that spans many > disciplines." > > The draft starts by saying that it is a complicated concept. In order to address this comment we could either a) change the meaning of the sentence. For example, we could come to the conclusion that privacy is not that complicated after all. b) we could delete the sentence, or c) explain a bit more why it is complicated. I just googled for "privacy complicated concept" and found this link from Stanford: http://plato.stanford.edu/entries/privacy/ There it says: ' Discussion of the concept is complicated by the fact that privacy appears to be something we value to provide a sphere within which we can be free from interference by others, and yet it also appears to function negatively, as the cloak under which one can hide domination, degradation, or physical harm to women and others. " When I look at the Google search results it seems that it is also a complicated concept for others. One additional reason why it is even more complicated for us is since there is not such a rich experience in the technical community with designing privacy into protocols. That does not mean that I think other disciplines are easy. > It then tries to fit in "data and "personal data". It then goes into data > and analysis, identifiability and then communication models. I think that > the problem stems from trying to cover the major points of all the authors. Why is this structure a problem? These are core concept in privacy and they have to be explained somewhere. For example, whether something is personal data or not determines whether the guidelines apply. Not all protocols deal with personal data. You can essentially stop reading if you find out that your protocol has nothing to do with personal data. When we talk about personal data then the concept of identifiability is certainly something that jumps into a discussion next. > > The threat model is too broad, or rather, it tries to be exhaustive. In general, the threat model is an extension of RFC 3552. The list of threats we have added after feedback from others that we need to be a bit more specific about the threats in the Internet protocol context. The available literature often talks about privacy threats without making the distinction between the real of Internet protocol engineering and what deployments impact. So, what threats should be skipped in your opinion? > > I suggest removing: > > "[RFC3552] provides detailed guidance to protocol designers about both > how to consider security as part of protocol design and how to inform > readers of protocol specifications about security issues. This > document intends to provide a similar set of guidance for considering > privacy in protocol design." > > Start with the Introduction. Move Section 6 after by introducing the reader > to scope. In Section 6: > > "Transparency of data collection and use -- often effectuated through > user interface design -- is normally a key factor in determining the > privacy impact of a system. Although most IETF activities do not > involve standardizing user interfaces or user-facing communications, > in some cases understanding expected user interactions can be > important for protocol design. Unexpected user behavior may have an > adverse impact on security and/or privacy." > > User interface is out of scope. :-) I suggest not saying anything about it. It is not that simple. Just because we do not standardize user interfaces does not mean they are not important. I guess we both agree that the interaction of the user with the system is important (not only for privacy reasons). Just as an example from an IETF working group charter: " 7. Descriptions of usability and user-interface concerns related to this work (informational). " The reason it is there is because of the subtle impact of the AAA architecture on the user interaction. If you, for example, use a Web SSO mechanism then you get a permission dialog presented from the IdP before you release your personal data to the relying party. The AAA architecture is, however, different in the type of communication interaction and therefore such interaction between the IdP and the user is relayed through the RP only through a standardized protocol (EAP; not HTTP/HTML/JavaScript). While we cannot present super-long stories for every aspect in the document we are still planning to write a few long example documents (IPv6, for example, is one of them). > Transparency of data collection takes us into issues which are generally > discussed outside the IETF. I'll say remove this for now. I believe there is value in outlining what is typically part of the work in the IETF and what isn't. Not everyone who reads our document is familiar with the detailed scope of our work (which btw changes over time). I do believe it is important to say where the boundaries of the IETF work are and to state them because otherwise the next person shows up and says that you have forgotten X, Y, and Z just because we deleted it earlier due to your comments. Ciao Hannes _______________________________________________ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
