Re: [lmap] incoming liaison statement from IEEE Project P802.16.3

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 09 April 2013 20:31 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2477B21F9816 for <lmap@ietfa.amsl.com>; Tue, 9 Apr 2013 13:31:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.3
X-Spam-Level:
X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, 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 8-razMfyvSnE for <lmap@ietfa.amsl.com>; Tue, 9 Apr 2013 13:31:11 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id DD09221F981C for <lmap@ietf.org>; Tue, 9 Apr 2013 13:31:09 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M38kj-1Uh3id2mjn-00sz1m for <lmap@ietf.org>; Tue, 09 Apr 2013 22:31:00 +0200
Received: (qmail invoked by alias); 09 Apr 2013 20:30:58 -0000
Received: from 199-119-118-18.i95.net (EHLO [10.0.1.136]) [199.119.118.18] by mail.gmx.net (mp029) with SMTP; 09 Apr 2013 22:30:58 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+AInh6yT2AzvnF4XJ0STqLs8oqSZfG/+nUEszW3s Mn6PxICOwigo90
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com>
Date: Tue, 09 Apr 2013 23:30:50 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <AACFB86F-983C-4CF4-9AC2-C7FCBA50D095@gmx.net>
References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: "ops-ads@tools.ietf.org" <ops-ads@tools.ietf.org>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, Roger Marks <r.b.marks@ieee.org>, "ippm@ietf.org" <ippm@ietf.org>, "lmap@ietf.org" <lmap@ietf.org>
Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lmap>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2013 20:31:12 -0000

Hi Dan, 

thanks for sending the liaison around. I read through it and I have a few remarks. 

It might be useful to highlight that the IETF#86 discussion was a BOF and the purpose of the BOF is not to work out the solution but rather to discuss whether a working group should be formed. As such, it is quite naturual that not all design aspects have been discussed during that meeting. 

With regard to the questions:

Question 1: "we wonder if the LMAP discussions have considered the use of both public and private Measurement Servers

Protocol work, as it is usually done in the IETF, does not imply that a specific entity runs the server. As such, any work that comes out of a (yet-to-be-created) LMAP working group will most likely be run by public and privacy entities. I would in general say that there is a distinction between the protocol aspects and the deployment aspect. Who runs a specific service is a deployment question and not necessarily a protocol design question. 

"Private" in this context is a also a bit confusing because it does not necessarily mean that private only refers to a server run by the same entity that runs the client, particularly if the client is located on the end device (under the control of the end user).

Question 2: "From our perspective, privacy is a core issue and helped to motivate our architecture at the most basic level."

Security and privacy are certainly dealt with in IETF protocols although I have to say that the range of what an acceptable level of privacy and security protection constitutes varies quite significantly between different participants. Even the understanding of what privacy and security is varies quite a lot. I am sure the IEEE in the meanwhile has noticed that as well with their experience in WEP. There are two documents that are worthwhile to look at to make sure that we actually talk the same language: 

For security have a look at RFC 3552 (see http://tools.ietf.org/html/rfc3552) and for privacy take a look at http://tools.ietf.org/html/draft-iab-privacy-considerations-07. 

In Section 7 of the privacy document you can find a couple of questions that are, of course, also applicable to the LMAP work, namely: 

 - Data Minimization
 - User Participation
 - Security
 - General

Have a look at this document since there are not too many documents around that give privacy guidelines for people working in a standards developing context. 

One of the most important parts in this work is certainly the user participation, which typically is easier to accomplish when the architecture allows the end user to actually give consent to the data collection selectively and also allows the end user to revoke their consent at any time. In general, such consent is more difficult to provide when the functionality is provided purely network internally, i.e., when the user does not have any new software running on their end devices. Luckily the measurements are most meaningful when they are truely end-to-end tests rather than testing a sub-set of the end-to-end communication path (which had been earlier in other measurement projects). 

Another important point is certainly what information is collected and provided to third parties. Anonymizing data might be a possibility but truely anonymized data are less meaningful. A future working group will have to certainly look at the trade-offs between the different identifiers involved. 

Ciao
Hannes

PS: I may not know enough about the IEEE but the statement "our project is targeted directly at mobile users (independent of air interface technology)" raised some questions for me. I believe the IEEE could best provide their expertise when they work on radio related technology. 

On Mar 28, 2013, at 10:17 AM, Romascanu, Dan (Dan) wrote:

> Hi,
> 
> Please note the following incoming liaison statement from IEEE Project P802.16.3 concerning the LMAP activity. 
> 
> https://datatracker.ietf.org/liaison/1244/
> 
> Comments and discussions are welcome. 
> 
> Regards,
> 
> Dan
> 
> 
> _______________________________________________
> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap