Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 15 July 2013 11:44 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57A921F9E0A for <ecrit@ietfa.amsl.com>; Mon, 15 Jul 2013 04:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.594
X-Spam-Level:
X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 iPYs781+wrCo for <ecrit@ietfa.amsl.com>; Mon, 15 Jul 2013 04:44:06 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6062621F9DEE for <ecrit@ietf.org>; Mon, 15 Jul 2013 04:44:06 -0700 (PDT)
Received: from [172.16.254.104] ([80.92.118.93]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LrePN-1U1tio1kwn-013LZH; Mon, 15 Jul 2013 13:44:03 +0200
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="iso-8859-2"
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
In-Reply-To: <39B5E4D390E9BD4890E2B310790061010F63EB@ESESSMB301.ericsson.se>
Date: Mon, 15 Jul 2013 13:44:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AA25A28-2AC6-42FB-9115-CA319785A555@gmx.net>
References: <39B5E4D390E9BD4890E2B310790061010EF4FC@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061010F63EB@ESESSMB301.ericsson.se>
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
X-Pgp-Agent: GPGMail 1.4.1
X-Mailer: Apple Mail (2.1085)
X-Provags-ID: V03:K0:u/e/IQJ21Wd0uoxu5qF3N+T/tXtbwoQ8N6pVXeiB/nLBzBskXfy UD1cUCC0jaPIMDRHrfjPIn81jUWK21s3U3jgd/mihA3GH4YNHw6Z9Y4ZsbxQay0aK21NhrT OBFfVIdOlZWgZtMswbxy5yNHyzrjPAgy7060gsGsrQDSpSw2FFniej/8ZQqHFgsnTS9IJxt ZhBiZ32ba6OuMuyUXBKGQ==
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 11:44:10 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Ivo, 

sorry for the delay and for the quick response. A more detailed response will follow tomorrow. 

We have worked on a subscribe/notify document (that also works with this document) in the past and the initial plan was to go through it in ATOCA (because it was perceived to be  the fastest route). Obviously that did not turn out to be correct. 

Maybe we should consider it in this working group. 

Here is the document: 
http://tools.ietf.org/html/draft-rosen-sipping-cap-04

We would be happy to get help (=co-authorship) from you (or anymore else) to progress the document. 

Ciao
Hannes

On Jul 15, 2013, at 1:23 PM, Ivo Sedlacek wrote:

> Any comments to the issues below? 
> 
> Kind regards
> 
> Ivo Sedlacek
> 
> This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer 
> 
> 
> -----Original Message-----
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek
> Sent: 26. června 2013 8:26
> To: ecrit@ietf.org
> Subject: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05
> 
> Hello,
> 
> draft-ietf-ecrit-data-only-ea-05 states:
> 
> 
>    This document does not define a mechanism for updates to the data
>    contained in data-only emergency calls.
> 
> 
> Is there another I-D describing how to provide the updates of the data to the PSAP? I saw some post suggesting that a SUBSCRIBE/NOTIFY mechanism could be used where the PSAP is subscriber and the UA is notifier, however I have not found such draft.
> 
> Issue 1: If SUBSCRIBE/NOTIFY mechanism is used, the PSAP is the subscriber and the UA is the notifier, this would require reachability of UA for initial request for dialog (i.e. SUBSCRIBE). However, when the UA is not registered e.g. due to missing credentials, the UA is normally not reachable for SIP requests other than those sent within the dialog of the emergency call.
> 
> Issue 2: How to send the update of the data __triggered by the UA__? Do we assume that if the PSAP subscription is not available, the PSAP prevents the UE from sending further information?
>             If so, assuming PSAP is interested in any information available, PSAP will need to subscribe in every single case of MESSAGE with CAP where UA can potentially provide the update of the data.
>             If not, do we assume that the UE would send updates of data triggered by UE using other mechanism (MESSAGE?) than updates of data requested by PSAP (NOTIFY)?
> 
> Issue 3: In some architectures (like 3GPP), signalling path for inital request for dialog from the PSAP to the UA is different than signalling path for the emergency request from the UA to the PSAP. If the UA has subscription from network in country X and roams in country Y, there is likelyhood that information that request comes from the PSAP is lost due to missing trust among PSAP (in country Y), transit networks (in country Y and X and possibly other transit countries), network of registrar and proxy of the UA (in country X), transit networks (in country X and Y and possibly other transit countries) and network of edge proxy serving the UA (in country Y) . If so, the UA would then handle the inital request for dialog as coming from an attacker UE and possibly reject it.
> 
> Is draft-ietf-ecrit-data-only-ea-05 supposed to be a  base for future solution where updates of the data to the PSAP are sent? I do not think it would work due to issues above.
> 
> If the UA ever wants to provide the updates of the data to the PSAP, either triggred by the UA or requested by the PSAP, it would be better to establish a dialog from beginning, e.g. send the initial data in INVITE and updates (from UE) and requests for updates (from PSAP) in INFOs.
> 
> Kind regards
> 
> Ivo Sedlacek 
> 
> Ericsson
> Mobile +420 608 234 709
> ivo.sedlacek@ericsson.com
> www.ericsson.com 
> 
> This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJR4+CCAAoJEGhJURNOOiAt50IH/1r04pjqikpsvo+Mb7uExHWJ
dM4zjOWZarOLyhglCcXddCi5EgaeIJ0myYhtc2qcJ9aCHqs7m5c5pfn0M9EZogUO
PHd0uT4d4a5aXr0eBFhva6W4t4j/aLGHBiVrpakX3hIveVYBfKNnwC1yMxgO1BUs
otCOmFjnEcykLe8ko6JRVRrHR7vEtYGltMR8IierpHap8C5zkXDB+NpdinCKNkeO
wHJZ72HD2sQi9qHYCI/VvgyMxkrCg05BvspixEkA4cIUL5lqeR4VIgENngofJ76f
Ub6mwtRgFNORRI3Tw2GJsM3RRg0zxrCh5Iv98DOmxsCeL6JdtSGYkLxm0Nj3qCU=
=FcHc
-----END PGP SIGNATURE-----