Re: [Pidloc] Pidloc in IETF Prague #104
Behcet Sarikaya <sarikaya2012@gmail.com> Fri, 29 March 2019 16:10 UTC
Return-Path: <sarikaya2012@gmail.com>
X-Original-To: pidloc@ietfa.amsl.com
Delivered-To: pidloc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E73120447 for <pidloc@ietfa.amsl.com>; Fri, 29 Mar 2019 09:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3K3dSVgF268 for <pidloc@ietfa.amsl.com>; Fri, 29 Mar 2019 09:10:39 -0700 (PDT)
Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B52C120464 for <pidloc@ietf.org>; Fri, 29 Mar 2019 09:10:39 -0700 (PDT)
Received: by mail-yb1-xb33.google.com with SMTP id a84so1029973ybg.10 for <pidloc@ietf.org>; Fri, 29 Mar 2019 09:10:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=9l0t/CezPHpCAg+NG71kCpL/nv1DQyFrZepB7Q3JsK0=; b=Itm5o6BOrz3MW7ajy3wz4hiAcoc22pqvoyT6bZ96IvrcKqA7W/1kX/4pIm3UK55H2P LIX6dFC6giYitAkD6TJY0CEKc3Op91lGoixJbO6Fry1HaiJr65xN5A9c61Jc8dgO1l67 UbOfKKP2mIJTFBEGII8w7yWmu3EftZuUqCB01TiXsoyMD6eXzJeU2puWD7P8BcdwerJ3 LjhfYZ3ROvPEM0asjDWvZQARk+RbcuCfIgUmhJXIDPMESCD/UkTFyM59v+NyS9nyjTt0 GA6gXhAOjdam0MDK+ijx6N3ekSUHByKAM5cxXT3IjMklj5Oh5AKfD1tGtkaD7u1RLOW1 cYfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=9l0t/CezPHpCAg+NG71kCpL/nv1DQyFrZepB7Q3JsK0=; b=C1cPcDYjzLDvZA4lboQi7R5DBc9MYKvokfKmbebhGgzWwpAH73cJtm70c4eVaGXSx+ 5NLHxKZC10BvCxrrG5orwZrbxqQdJ3rSt5afUWywtFpcl8ZwXxahFwhdUn4rWYkNw3GN 9uqvYDbrL4ix/pvXUubeH9t8m6Ug0V8NhQOoRMiAY+d/INpJ2RR47nYA/1gpjyLjZ6ok 2w3xdt6rGdjcTS/3OmnD23uhgxLNUrhLMkBhbb4UzQ92WeIBBTw03/C/6o5STQRMAkjr HUZeyfhldX94/uGvtipYse/cCYUHjW+ZSzCr0u0Z/ANeWkCSBs061VaVmVmgokDI4nEZ xtRA==
X-Gm-Message-State: APjAAAW6HoBHliAnnBL1qhU3aUICjckVMYGIVgXBbmSh0XPHMFC2CBG7 gEy20wmBdFVTpr7vFUFLaazbZ9g2y8j7IVHKxH4=
X-Google-Smtp-Source: APXvYqzi5qGBvysD2uO9MVr2KOR2i/Vih1jvz8pkE2FpL761d6IZaYCoq7CvcxknMHqF6DsR2hZsELeBCWEVwDjmrNM=
X-Received: by 2002:a5b:643:: with SMTP id o3mr11697788ybq.410.1553875838440; Fri, 29 Mar 2019 09:10:38 -0700 (PDT)
MIME-Version: 1.0
References: <LEXPR01MB06697AD320805F58B004443FD15A0@LEXPR01MB0669.DEUPRD01.PROD.OUTLOOK.DE>
In-Reply-To: <LEXPR01MB06697AD320805F58B004443FD15A0@LEXPR01MB0669.DEUPRD01.PROD.OUTLOOK.DE>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Fri, 29 Mar 2019 11:10:27 -0500
Message-ID: <CAC8QAcfZUiCfNwXf4vaTbdUg+AZMCayZKg40Tc3LUkgGk9Ctdg@mail.gmail.com>
To: "<Dirk.von-Hugo@telekom.de>" <Dirk.von-Hugo@telekom.de>
Cc: pidloc@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006017f605853de9e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pidloc/MMuWtwXW0O2eOcQ9WOxYH9grrQI>
Subject: Re: [Pidloc] Pidloc in IETF Prague #104
X-BeenThere: pidloc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <pidloc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pidloc>, <mailto:pidloc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pidloc/>
List-Post: <mailto:pidloc@ietf.org>
List-Help: <mailto:pidloc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pidloc>, <mailto:pidloc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2019 16:10:42 -0000
Hi Dirk, Thanks for the minutes. Let me add that there was some discussion on whether we should concentrate the privacy work on the control or data plane. I thought the conclusion was control plane. However, thinking a little bit more on this, I came to the conclusion that we also need to work on the data plane. The reason being as some previous work has shown, changing identifiers/locators that the UE uses from one session to another improves a lot the privacy issues. What do you think? Regards, Behcet On Fri, Mar 29, 2019 at 10:52 AM <Dirk.von-Hugo@telekom.de> wrote: > Dear all, > > as announced before we actually had our side meeting here in Prague and > some fruitful discussions. > > I’d like to share with you some notes of the 1-hour session where seven > people attended on site and about four more on the phone/webex. Sorry for > the inconvenience of a sub-optimum audio connection. > > I will also attach the slides shown and the link provided by Marco. > > > > Dirk presented chairs slides - focus was more on the open questions (gaps > and problems) to be solved than on solutions. > > Erik commented on use cases as edge computing in IoT (location is an issue > here) and consumers sharing voluntarily Id and Location on application > layer – which of course also should not be leaked beyond intended > recipients. > > VPN like closed groups pose less problem than rather consumer scale device > numbers (walled garden or separate domains). > > > > Shunsuke presented 5G use case attempting to include Id-Loc compatible > with 3GPP architecture. > > Location exposure of nearest UPF to local (non-3GPP) Data Networks (maybe > untrusted) may raise privacy issues on related location information (from > UPF to derive that of UE). > > > > Next steps might be a more complete collection and classification of use > cases and thereof identification of a requirements set to be demanded from > potential solutions. > > > > Marco and Umberto promised and meanwhile did to provide a link to related > slides in DMM (draft at > https://www.ietf.org/id/draft-fattore-dmm-n6-trafficsteering-01.txt) > pointing to the LDN problem: > > > > ID-LOC applies to the data network’s DPN and the user’s current (edge) UPF > (serving as session anchor). > > > > > https://datatracker.ietf.org/meeting/104/materials/slides-104-dmm-control-data-plane-for-n6-traffic-steering-00 > > > > A question was whether slicing shall be provided via Id-Loc? Rather than > that a low latency service on DP/UP would be the goal. > > Somebody mentioned that also tunneling between two endpoints could be seen > as Id-Loc approach. > > Thanks for comments and updates/corrections by all participants. > > Let’s continue discussion on the list. > > > > Kind regards > > Dirk > > > -- > Pidloc mailing list > Pidloc@ietf.org > https://www.ietf.org/mailman/listinfo/pidloc >
- Re: [Pidloc] Pidloc in IETF Prague #104 Dirk.von-Hugo
- Re: [Pidloc] Pidloc in IETF Prague #104 Behcet Sarikaya
- Re: [Pidloc] Pidloc in IETF Prague #104 Dirk.von-Hugo
- Re: [Pidloc] Pidloc in IETF Prague #104 Marco Liebsch
- Re: [Pidloc] Pidloc in IETF Prague #104 Dirk.von-Hugo