Re: [ietf-privacy] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt

Avri Doria <avri@acm.org> Wed, 25 September 2013 12:08 UTC

Return-Path: <avri@acm.org>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2205A21F9E40 for <ietf-privacy@ietfa.amsl.com>; Wed, 25 Sep 2013 05:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.288
X-Spam-Level:
X-Spam-Status: No, score=-110.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0078jhE39rCQ for <ietf-privacy@ietfa.amsl.com>; Wed, 25 Sep 2013 05:08:35 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id EEC8B21F9E85 for <ietf-privacy@ietf.org>; Wed, 25 Sep 2013 05:08:34 -0700 (PDT)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from <avri@acm.org>) id 1VOntR-000Jhd-69 for ietf-privacy@ietf.org; Wed, 25 Sep 2013 12:08:33 +0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1283)
From: Avri Doria <avri@acm.org>
In-Reply-To: <523C7912.1060206@cs.tcd.ie>
Date: Wed, 25 Sep 2013 08:08:32 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <87F3E6B1-1A51-424A-A3BA-EE65425550B9@acm.org>
References: <20130920162352.23295.48024.idtracker@ietfa.amsl.com> <523C7912.1060206@cs.tcd.ie>
To: ietf-privacy@ietf.org
X-Mailer: Apple Mail (2.1283)
Subject: Re: [ietf-privacy] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt
X-BeenThere: ietf-privacy@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Internet Privacy Discussion List <ietf-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-privacy>
List-Post: <mailto:ietf-privacy@ietf.org>
List-Help: <mailto:ietf-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2013 12:08:40 -0000

Hi

Very much support the draft and the idea of creating a BCP.

Have also appreciated the discussion on opportunistic encryption, which I consider akin to a holy grail.  Been thinking about it in a DTN context for a while, but don't feel like I ever got very far.

I am, however, looking at another part of the text.  I appreciate that the requirements are a MUST and that reads well, but, doesn't including a statement "Note that this is contingent on practicality" really downgrade it to a  SHOULD?

I think that "really has to be sent in clear for a protocol to be able to operate" is too hand wavy as a guideline.    Perhaps the draft could go deeper in the kinds of conditions that indicate that:

a) it was really necessary - what are the reasonable conditions for necessity?  
b) an indication of what practical actions have been taken to avoid this insurmountable obstacle and a discussion of which particular  requirements could not be met.
c) a guideline that indications be given on how can these instances be mitigated

This could well be a clue to what sort of information is needed to meet the requirement of explaining why the protocol does not fill the other requirements for protecting private data.

While I think that perhaps that I should go a little further breaking down a-c above, Irealized I would not get this sent of for several weeks if I were to try and go further and actually recommend text on a-c above.


avri