Subject: [ietf-privacy] Fwd: New Version Notification for draft-iab-privacy-considerations-01.txt

From: Alissa Cooper <[email-masked]>
Date: Sun, 23 Oct 2011 10:28:39 +0100

Per the announcement below, a new draft of the privacy considerations document, formerly draft-morris-privacy-considerations-03 and now draft-iab-privacy-considerations-01, has been submitted.* The major changes from the previous version are:

-- New guidelines for protocol designers (section 4). These are based on the output from the privacy workshop, the recent privacy reviews, the joint meeting we had with the privacy directorate at IETF 81, and the last technical plenary.

-- Re-written and shortened introduction that describes the purpose of the document.

-- Re-written and shortened scope section (section 2).

-- Removal of the examples with a plan to write up an example that uses the section 4 guidance in a future rev.

-- Removal of the appendix.

If you have comments on the document, please send them to both [email-masked] and [email-masked], or submit them via Trac (see instructions below). Several IAB members' comments are already in Trac (http://trac.tools.ietf.org/group/iab/trac/query?component=draft-morris-privacy-considerations&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority).

Thanks,
Alissa

*draft-iab-privacy-considerations-00 and draft-iab-privacy-considerations-01 are identical but for a formatting change that makes draft-iab-privacy-considerations-01 easier to read.

Submitting Comments via TRAC:

1.       To submit an issue in TRAC, you first need to login to the IAB site on the tools server:  http://tools.ietf.org/wg/iab/trac/login

2.       If you don’t already have a login ID, you can obtain one by navigating to this site:   http://trac.tools.ietf.org/newlogin

3.       Once you have obtained an account, and have logged in, you can file an issue by navigating to the  ticket entry form:http://trac.tools.ietf.org/wg/iab/trac/newticket

4.       When opening an issue:

a.       The Type: field should be set to “defect” for an issue with the current document text, or “enhancement” for a proposed addition of functionality (such as an additional requirement). 
b.      The Priority: field is set based on the severity of the Issue.   For example, editorial issues are typically “minor” or “trivial”. 
c.       The Milestone: field should be set to milestone1 (useless, I know). 
d.      The Component: field should be set to the document you are filing the issue on.  
e.      The Version: field should be set to “1.0”. 
f.        The Severity: field should be set to based on the status of the document (e.g. “In WG Last Call” for a document in IAB last call)
g.        The Keywords: and CC: fields can be left blank unless inspiration seizes you. 
h.      The Assign To: field is generally filled in with the email address of the editor. 

5.       Typically it won’t be necessary to enclose a file with the ticket, but if you need to, select “I have files to attach to this ticket”. 

6.       If you want to preview your Issue, click on the “Preview” button.  When you’re ready to submit the issue, click on the “Create Ticket” button. 

7.       If you want to update an issue, go to the "View Tickets" page:  http://trac.tools.ietf.org/wg/iab/trac/report/1

Click on the ticket # you want to update, and then modify the ticket fields as required

Begin forwarded message:

> From: [email-masked]
> Date: October 23, 2011 9:46:22 AM GMT+01:00
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
> Subject: New Version Notification for draft-iab-privacy-considerations-01.txt
> 
> A new version of I-D, draft-iab-privacy-considerations-01.txt has been successfully submitted by Alissa Cooper and posted to the IETF repository.
> 
> Filename:	 draft-iab-privacy-considerations
> Revision:	 01
> Title:		 Privacy Considerations for Internet Protocols
> Creation date:	 2011-10-23
> WG ID:		 Individual Submission
> Number of pages: 15
> 
> Abstract:
>   This document offers guidance for developing privacy considerations
>   for IETF documents and aims to make protocol designers aware of
>   privacy-related design choices.
> 
>   Discussion of this document is taking place on the IETF Privacy
>   Discussion mailing list (see
>   https://www.ietf.org/mailman/listinfo/ietf-privacy).
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: SM <[email-masked]>
Date: Mon, 24 Oct 2011 01:01:29 -0700

Hi Alissa,
At 02:28 23-10-2011, Alissa Cooper wrote:
>Per the announcement below, a new draft of the privacy 
>considerations document, formerly 
>draft-morris-privacy-considerations-03 and now 
>draft-iab-privacy-considerations-01, has been submitted.* The major 
>changes from the previous version are:

 From Section 2:

   "As an example, consider HTTP [RFC2616], which was designed to allow
    the exchange of arbitrary data.  A complete analysis of the privacy
    considerations for uses of HTTP might include what type of data is
    exchanged, how this data is stored, and how it is processed.  Hence
    the analysis for an individual's static personal web page would be
    different than the use of HTTP for exchanging health records.  A
    protocol designer working on HTTP extensions (such as WebDAV
    [RFC4918]) is not expected to describe the privacy risks derived from
    all possible usage scenarios, but rather the privacy properties
    specific to the extensions and any particular uses of the extensions
    that are expected and foreseen at design time."

There are several other protocols which are designed to allow the 
exchange of arbitrary data.  The above mentions that a complete 
analysis should cover:

  (1) Type of data being exchanged

  (2) How the data is stored

  (3) How it is processed

and mentions personal web pages and health records as examples.  This 
sounds more like usage of a technology instead of privacy 
considerations in designing a protocol.  My view of privacy 
considerations in protocol design is to consider implications when 
making design decisions.  As an example, HTTP has a Referer 
request-header field.  That field leaks information.  From a protocol 
design perspective, it is good to consider the privacy implications 
in having such a field and whether it is really needed for the 
protocol to work.

I'll give another example.  draft-vandergaast-edns-client-ip-01 
defines an EDNS0 to carry network range information.  It's an 
extension of the DNS protocol.  That protocol already discloses the 
source IP address.  If the extension functions the same way as the 
basic protocol, we do not have to get into privacy 
considerations.  As the extension is designed to communicate 
information to another party (something that the basic protocol does 
not do), there are privacy implications.

If you want me to discuss usage scenarios, I am going to say:

   This protocol is designed to discloses personal information and it
    offers no privacy.

It's going to the classic fare for most protocols (it's like crying 
wolf) and it goes against the purpose of having privacy considerations.

I like the guidelines in Section 4.  It lists easy questions for the 
protocol designer to think about.

Regards,
-sm