From nobody Wed Dec 3 18:17:24 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB641A882C; Wed, 3 Dec 2014 18:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 y_j-XIRQ2sUG; Wed, 3 Dec 2014 18:13:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D54CD1A1A3C; Wed, 3 Dec 2014 18:13:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141204021317.7932.84218.idtracker@ietfa.amsl.com> Date: Wed, 03 Dec 2014 18:13:17 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/tEjvOeTRMIrA8gpMSwQjpybk4dU Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-25.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 02:13:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Authors : Randall Gellens Brian Rosen Hannes Tschofenig Roger Marshall James Winterbottom Filename : draft-ietf-ecrit-additional-data-25.txt Pages : 105 Date : 2014-12-03 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any application service provider in the path of the call, or access network provider through which the call originated may have information about the call, the caller or the location which the PSAP may be able to use. This document describes data structures and a mechanism to convey such data to the PSAP. The mechanism uses a Uniform Resource Identifier (URI), which may point to either an external resource or an object in the body of the SIP message. The mechanism thus allows the data to be passed by reference (when the URI points to an external resource) or by value (when it points into the body of the message). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in body of the SIP message) and also by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-25 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-25 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 3 18:55:32 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165011A6F44 for ; Wed, 3 Dec 2014 18:52:41 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -5.611 X-Spam-Level: X-Spam-Status: No, score=-5.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 A4i47c6-CpoV for ; Wed, 3 Dec 2014 18:52:34 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8861A6FEC for ; Wed, 3 Dec 2014 18:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1417661553; x=1449197553; h=x-ojodefuego:message-id:x-mailer:date:to:from:subject: content-type; bh=hYPJ8oqveGIFy4WDkjZyOIhtXP6N+E1yHlIOEATBnys=; b=xhQl4f1iwW/M/ECpgL/dJO4iqWkwnRt9tUzvd0Yy8/gYM2g3MJtQIjX2 uE9JgfpHLdkmzRn0xz0sm5segb7PCq1S/0Eor+VxRiy0VhR4aZz3EkOn8 TKFY/FALj/88asPyuNHf3mu2WeakeDoHkCerkr0E2ho9tx6C23uFfoSuV 4=; X-IronPort-AV: E=McAfee;i="5600,1067,7641"; a="182678287" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2014 18:52:33 -0800 X-IronPort-AV: E=Sophos;i="5.07,511,1413270000"; d="scan'208";a="804723967" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2014 18:52:33 -0800 Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id sB42qU3m011942; Wed, 3 Dec 2014 18:52:31 -0800 X-IronPort-AV: E=Sophos;i="5.07,511,1413270000"; d="scan'208";a="804723932" X-ojodefuego: yes Received: from myvpn-l-01457.ras.qualcomm.com (HELO [99.111.97.136]) ([10.64.140.63]) by Ironmsg03-R.qualcomm.com with ESMTP; 03 Dec 2014 18:52:30 -0800 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Wed, 3 Dec 2014 18:50:13 -0800 To: "Marc Linsner (mlinsner)" , Roger Marshall , ecrit@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/WMpgbndRvqB7K9kjpOE88DFtsRY Subject: [Ecrit] draft-ietf-ecrit-additional-data-25 published and ready for IETF LC X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 02:52:43 -0000 Version -25 is submitted. This addresses all known issues. As discussed in Honolulu, this version is ready for IETF Last Call. Many thanks to those who have reviewed and commented! Further reviews and comments are welcome and will be addressed during IETF LC. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- "When I use a word," Humpty Dumpty said, in a rather scornful tone, "it means just what I choose it to mean -- neither more nor less. "The question is," said Alice, "whether you can make words mean so many different things." "The question is," said Humpty Dumpty, "which is to be master -- that's all." From nobody Mon Dec 8 10:20:15 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EB11ACD3B; Mon, 8 Dec 2014 10:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 MF1ANZJbCrbA; Mon, 8 Dec 2014 10:20:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 682101A877E; Mon, 8 Dec 2014 10:20:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141208182004.22683.71593.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 10:20:04 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/IQtuMQStfqLiP3o47iXyb_1fhOg Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-26.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 18:20:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Authors : Randall Gellens Brian Rosen Hannes Tschofenig Roger Marshall James Winterbottom Filename : draft-ietf-ecrit-additional-data-26.txt Pages : 105 Date : 2014-12-08 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any application service provider in the path of the call, or access network provider through which the call originated may have information about the call, the caller or the location which the PSAP may be able to use. This document describes data structures and a mechanism to convey such data to the PSAP. The mechanism uses a Uniform Resource Identifier (URI), which may point to either an external resource or an object in the body of the SIP message. The mechanism thus allows the data to be passed by reference (when the URI points to an external resource) or by value (when it points into the body of the message). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in body of the SIP message) and also by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-26 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-26 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 8 10:30:52 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8C81A87BF for ; Mon, 8 Dec 2014 10:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wDVxdZYMDGfc for ; Mon, 8 Dec 2014 10:30:42 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5A501A87BC for ; Mon, 8 Dec 2014 10:30:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1418063442; x=1449599442; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=5f6OhBi9S4v55KlokcYbriCouuPAvhfeiw0n5tGAWLs=; b=PF0jzZF4qwK9y9fLcXBOjM4qDAjW1RYFcyPKP/WOnOMZBK+pMZRlPqZX z7RtWifHFDUirq56MixmH0MVo0TaxvNQKRkIVHSItidGLQChcHZI41TvE XWVyPqT12DjzS6g265kD63oxeDxjXhDvk9JC+u3nUHclUDiDD07gHOdKb A=; X-IronPort-AV: E=McAfee;i="5600,1067,7646"; a="92174250" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Dec 2014 10:30:42 -0800 X-IronPort-AV: E=Sophos;i="5.07,539,1413270000"; d="scan'208";a="807829724" Received: from nasanexm01e.na.qualcomm.com ([10.85.0.31]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Dec 2014 10:30:41 -0800 Received: from [99.111.97.136] (10.80.80.8) by NASANEXM01E.na.qualcomm.com (10.85.0.31) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 8 Dec 2014 10:30:41 -0800 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 8 Dec 2014 10:30:20 -0800 To: "Marc Linsner (mlinsner)" , Roger Marshall , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01H.na.qualcomm.com (10.85.0.34) To NASANEXM01E.na.qualcomm.com (10.85.0.31) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/Ae7X5Q-xBP9CP2QEwINe7aar_QU Cc: Brian Rosen Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-26 published and ready for IETF LC X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 18:30:48 -0000 I fixed a remaining XML schema error in -25 and submitted -26, which is ready for IETF LC. Marc and Roger: Please start the IETF LC process. Further reviews and comments are welcome and will be addressed during IETF LC. At 6:50 PM -0800 12/3/14, Randall Gellens wrote: > Version -25 is submitted. This addresses all known issues. As > discussed in Honolulu, this version is ready for IETF Last Call. > > Many thanks to those who have reviewed and commented! > > Further reviews and comments are welcome and will be addressed > during IETF LC. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The challenge of computer science is: How NOT to make a mess of it. -Edsger W. Dijkstra From nobody Thu Dec 11 03:37:42 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913981ACDF0 for ; Thu, 11 Dec 2014 03:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 N0TiWZP4PygW for ; Thu, 11 Dec 2014 03:37:39 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812D41ACDD2 for ; Thu, 11 Dec 2014 03:37:38 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-19-54898200c541 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E7.94.04231.00289845; Thu, 11 Dec 2014 12:37:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 12:37:35 +0100 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AdAVNoK4d0cbFFNJSQWyPFAruzY03w== Date: Thu, 11 Dec 2014 11:37:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvjS5DU2eIwa+3WhaNi56yOjB6LFny kymAMYrLJiU1J7MstUjfLoEr48XGdpaCc5wVLTsmsTUwnmbvYuTkkBAwkTi47xsLhC0mceHe erYuRi4OIYEjjBL3Ni9hhXCWMEq8uNcA5HBwsAlYSHT/0wZpEBFQldhwZiUjiC0sECmxYdcr Zoh4nETz5UksELaexPQ7p1hBbBag+ifbboDZvAK+Ek33WsBqGIEWfz+1hgnEZhYQl7j1ZD4T xEECEkv2nGeGsEUlXj7+xwphK0rsPNvODFGvI7Fg9yc2CFtbYtnC18wQ8wUlTs58wjKBUXgW krGzkLTMQtIyC0nLAkaWVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBIX5wy2/dHYyrXzse YhTgYFTi4TWo7AwRYk0sK67MPcQozcGiJM676Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTByc Ug2MMw/Uiz5bPffZ5E1vHIzD/iQb765S8KmXnr/r7Mru2fdbV/Zb8XwrVb6mzhb4f1vN56CJ Qt5TQ2W33bntfbz1i+hL/R+x2Sl/WLgZf7ysuPb2fszOC01X4115DgULZH3t+Fgs6Ffo8O5W qs9RrR1bGqd8MdxwnG/DobT/ylNWODfHG17/brWQQYmlOCPRUIu5qDgRAHxFxa5SAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/RQ9wNIzORckPplOl8eP52GVMvmQ Subject: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 11:37:40 -0000 Hi, draft-ietf-ecrit-ecall seems to assume that, whatever is sent from a vehicl= e to the PSAP (or in the other direction), is considered "additional data" = carried in SIP requests. I think there may be issues with such approach. For example, the vehicle may be requested to send picture(s). Sending those= on the signaling plane could create very large SIP requests. Also, the vehicle may be requested to provide lots of sensor data etc. Send= ing that on the signaling plane could create a very large number of SIP req= uests. Finally, the draft seems to assume that data can be sent also in INFO respo= nses - which is not correct. Data can only be carried in INFO requests, and= because of that the number of SIP messages could double in the worst case = scenario. So, I don't think we can consider everything sent from the vehicle to the P= SAP as "additional data" carried in SIP requests, as it would very likely c= ause issues in the network. (Yes, I know data can also be provided e.g. by providing a URL, but I am no= t sure whether that will actually work - enabling the UA to send IP packets= to the PSAP could open an opportunity for attacks on the PSAP). Regards, Christer From nobody Thu Dec 11 06:24:15 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8971A896E for ; Thu, 11 Dec 2014 06:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Nh8a28gnpg7b for ; Thu, 11 Dec 2014 06:24:12 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F9E1A89A5 for ; Thu, 11 Dec 2014 06:24:11 -0800 (PST) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id sBBEKZde026857; Thu, 11 Dec 2014 09:24:08 -0500 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1r6vyrs9bh-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Dec 2014 09:24:08 -0500 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.204]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 11 Dec 2014 09:24:08 -0500 From: "Rosen, Brian" To: Christer Holmberg Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AQHQFU4fyqjBBnWouEycqam7y1XMLg== Date: Thu, 11 Dec 2014 14:24:07 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.44] Content-Type: text/plain; charset="us-ascii" Content-ID: <9CD6C9F9FCA7174D85CE5734573FC174@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7648 signatures=670593 X-Proofpoint-Spam-Reason: safe Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/4lKya8oGTxrjEgsiLD7d0MNuWeE Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 14:24:13 -0000 I do agree that when there is a lot of data, we want to send URIs, and let = the PSAP pull the data over HTTP. I believe we can do that with this mecha= nism. The same problem occurs in data related to a location. One might have surv= eillance video available, for example. The answer is the same, send it via= URI. The document does not provide guidance on this point, and maybe it should. Brian > On Dec 11, 2014, at 6:37 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > draft-ietf-ecrit-ecall seems to assume that, whatever is sent from a vehi= cle to the PSAP (or in the other direction), is considered "additional data= " carried in SIP requests. I think there may be issues with such approach. >=20 > For example, the vehicle may be requested to send picture(s). Sending tho= se on the signaling plane could create very large SIP requests. >=20 > Also, the vehicle may be requested to provide lots of sensor data etc. Se= nding that on the signaling plane could create a very large number of SIP r= equests. >=20 > Finally, the draft seems to assume that data can be sent also in INFO res= ponses - which is not correct. Data can only be carried in INFO requests, a= nd because of that the number of SIP messages could double in the worst cas= e scenario. >=20 > So, I don't think we can consider everything sent from the vehicle to the= PSAP as "additional data" carried in SIP requests, as it would very likely= cause issues in the network. >=20 > (Yes, I know data can also be provided e.g. by providing a URL, but I am = not sure whether that will actually work - enabling the UA to send IP packe= ts to the PSAP could open an opportunity for attacks on the PSAP). >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Dec 11 09:20:01 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6DA1A7113 for ; Thu, 11 Dec 2014 09:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.611 X-Spam-Level: X-Spam-Status: No, score=-5.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wViF-fJrvPgb for ; Thu, 11 Dec 2014 09:19:55 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C581A6FC8 for ; Thu, 11 Dec 2014 09:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1418318395; x=1449854395; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=43023BuaKggtEYaYfohC8Nu9y1rjGdx98z74PIvlNfA=; b=evJZ7Kf6n0Z4hhmNqBCe2gDa0zdTmv2TBXXe8LY9NnBDS/BOKRmyLm/c muElW2LVmYJJ2qNqjoaSll0lLY6riO6stbvASiXVihXrPXZckyG41Lv0Y YqdKrCP3RGaSWm7E7xcvG/+rb1JTdTUCnXDkkiJXE0fYMYV9nzMqCrzZj Q=; X-IronPort-AV: E=McAfee;i="5600,1067,7648"; a="184648313" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Dec 2014 09:19:35 -0800 X-IronPort-AV: E=Sophos;i="5.07,558,1413270000"; d="scan'208";a="864367862" Received: from nasanexm01d.na.qualcomm.com ([10.85.0.84]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Dec 2014 09:19:35 -0800 Received: from [99.111.97.136] (10.80.80.8) by NASANEXM01D.na.qualcomm.com (10.85.0.84) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 11 Dec 2014 09:19:34 -0800 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Thu, 11 Dec 2014 09:19:32 -0800 To: Christer Holmberg , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01D.na.qualcomm.com (10.85.0.84) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/mwhcahMQM4_zbsvGbazG0ajCM0U Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 17:19:57 -0000 Hi Christer, The document builds on existing emergency calling, and hence does not specify non-eCall aspects, such as media, since those are already addressed in the underlying documents. As you know, those existing emergency calling documents currently cover streaming media, but not non-streaming media such as pictures or video clips. There is work going on is some SDOs to address how non-streaming media will be carried in an emergency call. I think everyone involved can easily see that such media will be carried using existing mechanisms, most likely as file attachments using MSRP. There is no intent for the eCall document to specify its own mechanism for transferring non-streaming media (and it would be quite silly dor it to do so). At 11:37 AM +0000 12/11/14, Christer Holmberg wrote: > Hi, > > draft-ietf-ecrit-ecall seems to assume that, whatever is sent from > a vehicle to the PSAP (or in the other direction), is considered > "additional data" carried in SIP requests. I think there may be > issues with such approach. > > For example, the vehicle may be requested to send picture(s). > Sending those on the signaling plane could create very large SIP > requests. > > Also, the vehicle may be requested to provide lots of sensor data > etc. Sending that on the signaling plane could create a very large > number of SIP requests. > > Finally, the draft seems to assume that data can be sent also in > INFO responses - which is not correct. Data can only be carried in > INFO requests, and because of that the number of SIP messages could > double in the worst case scenario. > > So, I don't think we can consider everything sent from the vehicle > to the PSAP as "additional data" carried in SIP requests, as it > would very likely cause issues in the network. > > (Yes, I know data can also be provided e.g. by providing a URL, but > I am not sure whether that will actually work - enabling the UA to > send IP packets to the PSAP could open an opportunity for attacks > on the PSAP). > > Regards, > > Christer > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Nearly all men can stand adversity, but if you want to test a man's character, give him power. --Abraham Lincoln From nobody Thu Dec 11 09:52:02 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED7B1ACEBD for ; Thu, 11 Dec 2014 09:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 wJp_jWAO93sK for ; Thu, 11 Dec 2014 09:51:58 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9861ACE44 for ; Thu, 11 Dec 2014 09:51:57 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-4e-5489d9bc8134 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 38.95.24955.CB9D9845; Thu, 11 Dec 2014 18:51:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 18:51:55 +0100 From: Christer Holmberg To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AQHQFWak0uRS4Ax35EOPqX4Fu4w7i5yKqOyA Date: Thu, 11 Dec 2014 17:51:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D58F3DE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje6em50hBgffyVk0LnrKanHtUQez A5PHkiU/mTwWTX3GGMAUxWWTkpqTWZZapG+XwJXR1zuDreC3WMXJ1/+ZGhhnC3UxcnJICJhI XDm9nhXCFpO4cG89WxcjF4eQwBFGib73O9lAEkICSxgl3jyI72Lk4GATsJDo/qcNEhYRCJTo 3LadGcQWFkiTWLzuNitEPF3ia99mKNtI4sLVy8wgrSwCqhLrJxqBhHkFfCX67uxhhJheLjF7 xSEwmxPonIZZt1lAbEagc76fWsMEYjMLiEvcejKfCeJMAYkle84zQ9iiEi8f/4M6X0li7eHt LBD1OhILdn9ig7C1JZYtfM0MsVdQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcUoWpxanJSb bmSsl1qUmVxcnJ+nl5dasokRGCMHt/xW3cF4+Y3jIUYBDkYlHl6Dys4QIdbEsuLK3EOM0hws SuK8C8/NCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaPJt5/zJqVJnXVqW90p/KO1IPHBb n092C9fFnd2R8ydMYq55WB4cMicwvtx7ggrP/4f/7JxtPqe7Cn697z+JL/hN4g+LOWtuhK+Z bXhq1ZHOOXMd/La4Jv7e4blRUep0SF6QbO7imNbFf6Z//RnWwvvizvr/XoGR7QIbReaWhmU+ 5AvavHO5qxJLcUaioRZzUXEiAHtcqz1yAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/5pWwjjbNclYHihqgno2HbgdYmww Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 17:52:00 -0000 Hi Randall, >The document builds on existing emergency calling, and hence does not spec= ify non-eCall aspects, such as media, since those are already addressed in = the underlying >documents. As you know, those existing emergency calling d= ocuments currently cover streaming media, but not non-streaming media such = as pictures or video clips. >There is work going on is some SDOs to addres= s how non-streaming media will be carried in an emergency call. I think ev= eryone involved can easily see that such media will >be carried using exist= ing mechanisms, most likely as file attachments using MSRP. There is no in= tent for the eCall document to specify its own mechanism for transferring >= non-streaming media (and it would be quite silly dor it to do so). My thinking has been that other SDOs should be able to reference this docum= ent, and that it would include a mechanism on how to transport non-streamin= g media. Currently the draft gives a picture that everything is carried in SIP - so = it should at least state that media plane mechanisms can also be used. Regards, Christer =20 At 11:37 AM +0000 12/11/14, Christer Holmberg wrote: > Hi, > > draft-ietf-ecrit-ecall seems to assume that, whatever is sent from a=20 > vehicle to the PSAP (or in the other direction), is considered=20 > "additional data" carried in SIP requests. I think there may be issues=20 > with such approach. > > For example, the vehicle may be requested to send picture(s).=20 > Sending those on the signaling plane could create very large SIP=20 > requests. > > Also, the vehicle may be requested to provide lots of sensor data=20 > etc. Sending that on the signaling plane could create a very large=20 > number of SIP requests. > > Finally, the draft seems to assume that data can be sent also in INFO=20 > responses - which is not correct. Data can only be carried in INFO=20 > requests, and because of that the number of SIP messages could double=20 > in the worst case scenario. > > So, I don't think we can consider everything sent from the vehicle to=20 > the PSAP as "additional data" carried in SIP requests, as it would=20 > very likely cause issues in the network. > > (Yes, I know data can also be provided e.g. by providing a URL, but I=20 > am not sure whether that will actually work - enabling the UA to send=20 > IP packets to the PSAP could open an opportunity for attacks on the=20 > PSAP). > > Regards, > > Christer > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Nearly all men can st= and adversity, but if you want to test a man's character, give him power. --Abraham Lincoln From nobody Thu Dec 11 09:56:15 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F3B1A907D for ; Thu, 11 Dec 2014 09:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 tg9LMHARSgkb for ; Thu, 11 Dec 2014 09:56:13 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157E31A6F80 for ; Thu, 11 Dec 2014 09:56:12 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-6b-5489daba6f9c Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C7.D3.29772.ABAD9845; Thu, 11 Dec 2014 18:56:10 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 18:56:10 +0100 From: Christer Holmberg To: "Rosen, Brian" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AdAVNoK4d0cbFFNJSQWyPFAruzY03wADzrKAAAlhGdA= Date: Thu, 11 Dec 2014 17:56:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D58F420@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje6uW50hBvdmWVlMO3mZ2aJx0VNW ByaPJUt+MnnsaHjOHMAUxWWTkpqTWZZapG+XwJWxd94s1oIzwhUbp+xmb2Dcyt/FyMkhIWAi 0b/mNjOELSZx4d56ti5GLg4hgSOMEnvn3GSGcJYwStyZcpe1i5GDg03AQqL7nzZIg4iAjkTf NIhmZgFViXONj1lAbGGBVIneW3/YIGrSJJZPucwOYVtJLD50CcxmAap/P/0jE4jNK+ArcXnZ G1YQW0igiVFi5VlfEJtTwF5iyvVWsDmMQMd9P7WGCWKXuMStJ/OZII4WkFiy5zzUA6ISLx// Y4WwlSTWHt7OAlGvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUWwWkrGzkLTMQtIyC0nLAkaW VYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiB8XNwy2+DHYwvnzseYhTgYFTi4TWo7AwRYk0s K67MPcQozcGiJM678Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2Mk3luhUf1XLrzUfDE tp1lS/l6GsV+z5z963j1tVRv9i/bJURnbGme07fSMn32pKMWhRnxn8p2+Uq2rdee83pG0hFV /hfWAo95OjN53J/93u80tzLU5ad+4ysJLZFv09Sfbe3saYxt1Ppc/OnT8lfbzU41rjqRnrqH v//2iXm9MenBO2dHdNx/qsRSnJFoqMVcVJwIAKbZwxOAAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/BJW3V33TUrK5KCuohNN2eQ_oib8 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 17:56:15 -0000 Hi Brian, > I do agree that when there is a lot of data, we want to send URIs, and le= t the PSAP pull the data over HTTP. I believe we can do that with this mec= hanism. > > The same problem occurs in data related to a location. One might have su= rveillance video available, for example. The answer is the same, send it v= ia URI. > > The document does not provide guidance on this point, and maybe it should= . I think there are issues with providing a URI, and sending data over HTTP. - If the PSAP provides a URI to the UA for fetching data, the URI could ope= n possibilities for attacks on the PSAP. - If the UA provides a URI to the PSAP for fetching data, the URI could res= ult in privacy issues. Also, there may be NAT related issues when the PSAP = tries to connect to the UA. I think a media plane mechanism should be considered for transporting big- = and/or frequent data (pictures, sensor data, etc). Regards, Christer > On Dec 11, 2014, at 6:37 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > draft-ietf-ecrit-ecall seems to assume that, whatever is sent from a vehi= cle to the PSAP (or in the other direction), is considered "additional data= " carried in SIP requests. I think there may be issues with such approach. >=20 > For example, the vehicle may be requested to send picture(s). Sending tho= se on the signaling plane could create very large SIP requests. >=20 > Also, the vehicle may be requested to provide lots of sensor data etc. Se= nding that on the signaling plane could create a very large number of SIP r= equests. >=20 > Finally, the draft seems to assume that data can be sent also in INFO res= ponses - which is not correct. Data can only be carried in INFO requests, a= nd because of that the number of SIP messages could double in the worst cas= e scenario. >=20 > So, I don't think we can consider everything sent from the vehicle to the= PSAP as "additional data" carried in SIP requests, as it would very likely= cause issues in the network. >=20 > (Yes, I know data can also be provided e.g. by providing a URL, but I am = not sure whether that will actually work - enabling the UA to send IP packe= ts to the PSAP could open an opportunity for attacks on the PSAP). >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Dec 11 10:04:35 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB101A907D for ; Thu, 11 Dec 2014 10:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pnUieeiptyvd for ; Thu, 11 Dec 2014 10:04:27 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EACF1ACF0F for ; Thu, 11 Dec 2014 10:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1418321059; x=1449857059; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=pziCGEtW2hjC/Mai0+52bjsCzY8NHQuFDTbKvTz7Yas=; b=mXVmDT4EvXrDkl4+P9yWuynXcBnxzH7/gwiY3F5wW7LYGDLWzPRIDqsH s4If4fpO6EX/G8LD3teiCEfLfbmR5urZjgPW75eFUvB2T0rQOmHGRYr6R SDv+e+t0ziQIGmc94ynBps2pmylvO9jwptRnG3MLTOpZa40tPenX4jA5I k=; X-IronPort-AV: E=McAfee;i="5600,1067,7649"; a="79891842" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Dec 2014 10:04:18 -0800 X-IronPort-AV: E=Sophos;i="5.07,558,1413270000"; d="scan'208";a="795340444" Received: from nasanexm02d.na.qualcomm.com ([10.46.200.113]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Dec 2014 10:04:18 -0800 Received: from [99.111.97.136] (10.80.80.8) by NASANEXM02D.na.qualcomm.com (10.46.200.113) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 11 Dec 2014 10:04:17 -0800 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D58F3DE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D58F3DE@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Thu, 11 Dec 2014 10:03:55 -0800 To: Christer Holmberg , Randall Gellens , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01D.na.qualcomm.com (10.85.0.84) To NASANEXM02D.na.qualcomm.com (10.46.200.113) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/N4qNKCZ76ft7XRX7piBsBxLtws0 Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 18:04:30 -0000 Hi Christer, At 5:51 PM +0000 12/11/14, Christer Holmberg wrote: >> >The document builds on existing emergency calling, and hence >> does not specify non-eCall aspects, such as media, since those are >> already addressed in the underlying >documents. As you know, >> those existing emergency calling documents currently cover >> streaming media, but not non-streaming media such as pictures or >> video clips. >There is work going on is some SDOs to address how >> non-streaming media will be carried in an emergency call. I think >> everyone involved can easily see that such media will >be carried >> using existing mechanisms, most likely as file attachments using >> MSRP. There is no intent for the eCall document to specify its >> own mechanism for transferring >non-streaming media (and it would >> be quite silly dor it to do so). > My thinking has been that other SDOs should be able to reference > this document, and that it would include a mechanism on how to > transport non-streaming media. Of course other SDOs should be able to reference this document, but common mechanisms (that are usable in all forms of emergency calls) should be in their respective documents and included by reference here. This goes for both streaming and non-streaming media, since those are or will be common to all emergency calls. > Currently the draft gives a picture that everything is carried in > SIP - so it should at least state that media plane mechanisms can > also be used. I'm happy to include some explanatory text to this effect. I certainly don't want the document to give the wrong impression that media will be carried in the signaling plane! > > At 11:37 AM +0000 12/11/14, Christer Holmberg wrote: > >> Hi, >> >> draft-ietf-ecrit-ecall seems to assume that, whatever is sent from a >> vehicle to the PSAP (or in the other direction), is considered >> "additional data" carried in SIP requests. I think there may be issues >> with such approach. >> >> For example, the vehicle may be requested to send picture(s). >> Sending those on the signaling plane could create very large SIP >> requests. >> >> Also, the vehicle may be requested to provide lots of sensor data >> etc. Sending that on the signaling plane could create a very large >> number of SIP requests. >> >> Finally, the draft seems to assume that data can be sent also in INFO >> responses - which is not correct. Data can only be carried in INFO >> requests, and because of that the number of SIP messages could double >> in the worst case scenario. >> >> So, I don't think we can consider everything sent from the vehicle to >> the PSAP as "additional data" carried in SIP requests, as it would >> very likely cause issues in the network. >> >> (Yes, I know data can also be provided e.g. by providing a URL, but I >> am not sure whether that will actually work - enabling the UA to send >> IP packets to the PSAP could open an opportunity for attacks on the >> PSAP). >> >> Regards, >> >> Christer >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- Nearly all > men can stand adversity, but if you want to test a > man's character, give him power. --Abraham Lincoln -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- C++ is pronounced "C cross cross." Not one but two crosses to bear: C and a broken interpretation of object-orientation. From nobody Thu Dec 11 10:07:37 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EBC1ACF77 for ; Thu, 11 Dec 2014 10:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 WajKYRTy2J3y for ; Thu, 11 Dec 2014 10:07:31 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FA71ACF73 for ; Thu, 11 Dec 2014 10:07:29 -0800 (PST) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id sBBI0Ohd025132; Thu, 11 Dec 2014 13:07:26 -0500 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1r7d0y8c9j-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Dec 2014 13:07:26 -0500 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.204]) by stntexhc10.cis.neustar.com ([169.254.4.119]) with mapi id 14.03.0158.001; Thu, 11 Dec 2014 13:07:26 -0500 From: "Rosen, Brian" To: Christer Holmberg Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AQHQFU4fyqjBBnWouEycqam7y1XMLg== Date: Thu, 11 Dec 2014 18:07:25 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D58F420@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D58F420@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.33.193.44] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <25DFB3CAF6018440A8A6B5B360900EC9@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7649 signatures=670595 X-Proofpoint-Spam-Reason: safe Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/kmJV-mglob689TTRmeb-YpeYaE0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 18:07:35 -0000 > >- If the PSAP provides a URI to the UA for fetching data, the URI could >open possibilities for attacks on the PSAP. That is correct, but the possibilities for pushing huge data to the PSAP without the PSAP being able to throttle it effectively are worse. In fact, I think we could reasonably put an upper bound on the size of data and tell the PSAP they can ignore it if it=B9s bigger than that. Now, for well known service providers, the SP can make this reasonable itself. But then, for well known service providers, there is no security problem with a fetch. All-in-all, I=B9d prefer an HTTP fetch to a data or control plane push for large content with respect to security issues >- If the UA provides a URI to the PSAP for fetching data, the URI could >result in privacy issues. Also, there may be NAT related issues when the >PSAP tries to connect to the UA. I do not see any privacy issues. For one thing, privacy expectations are significantly lower in emergency calls (by statute in many jurisdictions). PSAPs will need credentials for any form of security. In North America, we have a reasonable PKI worked out and we have some commitments to start deployment of it. The credentials can be used to make sure only authorized entities have access to the data. The URI should be some ephemeral id, so an attacker would need to observe the signaling to get it. But then, if the attacker can observe the signaling, it can observe a push. Doing something in the data plane would be something along the lines of MSRP file. Not really opposed to that. Brian From nobody Thu Dec 11 10:29:04 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10651A875D for ; Thu, 11 Dec 2014 10:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pEXfcBglEULr for ; Thu, 11 Dec 2014 10:28:59 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 73C851A1A64 for ; Thu, 11 Dec 2014 10:28:59 -0800 (PST) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 11 Dec 2014 13:28:52 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.03.0210.002; Thu, 11 Dec 2014 13:28:52 -0500 From: Andrew Allen To: Christer Holmberg , "Rosen, Brian" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AdAVNoK4d0cbFFNJSQWyPFAruzY03wAQYViAAAdn4AAAChNM4A== Date: Thu, 11 Dec 2014 18:28:52 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D58F420@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D58F420@ESESSMB209.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/cW5kVOwCwIoVGLNPn6g5h8gZNhU Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 18:29:02 -0000 Isn't this the media plane negotiation and setup mechanism for transferring= a file when using SIP? http://www.rfc-editor.org/rfc/rfc5547.txt Or am I missing something? Andrew -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, December 11, 2014 12:56 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" = carried in SIP requests? Hi Brian, > I do agree that when there is a lot of data, we want to send URIs, and le= t the PSAP pull the data over HTTP. I believe we can do that with this mec= hanism. > > The same problem occurs in data related to a location. One might have su= rveillance video available, for example. The answer is the same, send it v= ia URI. > > The document does not provide guidance on this point, and maybe it should= . I think there are issues with providing a URI, and sending data over HTTP. - If the PSAP provides a URI to the UA for fetching data, the URI could ope= n possibilities for attacks on the PSAP. - If the UA provides a URI to the PSAP for fetching data, the URI could res= ult in privacy issues. Also, there may be NAT related issues when the PSAP = tries to connect to the UA. I think a media plane mechanism should be considered for transporting big- = and/or frequent data (pictures, sensor data, etc). Regards, Christer > On Dec 11, 2014, at 6:37 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > draft-ietf-ecrit-ecall seems to assume that, whatever is sent from a vehi= cle to the PSAP (or in the other direction), is considered "additional data= " carried in SIP requests. I think there may be issues with such approach. >=20 > For example, the vehicle may be requested to send picture(s). Sending tho= se on the signaling plane could create very large SIP requests. >=20 > Also, the vehicle may be requested to provide lots of sensor data etc. Se= nding that on the signaling plane could create a very large number of SIP r= equests. >=20 > Finally, the draft seems to assume that data can be sent also in INFO res= ponses - which is not correct. Data can only be carried in INFO requests, a= nd because of that the number of SIP messages could double in the worst cas= e scenario. >=20 > So, I don't think we can consider everything sent from the vehicle to the= PSAP as "additional data" carried in SIP requests, as it would very likely= cause issues in the network. >=20 > (Yes, I know data can also be provided e.g. by providing a URL, but I am = not sure whether that will actually work - enabling the UA to send IP packe= ts to the PSAP could open an opportunity for attacks on the PSAP). >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > 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 From nobody Thu Dec 11 10:34:59 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AE51A87E2 for ; Thu, 11 Dec 2014 10:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 eUNa1Bt4Nwwy for ; Thu, 11 Dec 2014 10:34:56 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE351A6FC0 for ; Thu, 11 Dec 2014 10:34:55 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-05-5489e3cd4f98 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C5.09.24955.DC3E9845; Thu, 11 Dec 2014 19:34:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 19:34:53 +0100 From: Christer Holmberg To: Andrew Allen , "Rosen, Brian" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AdAVNoK4d0cbFFNJSQWyPFAruzY03wADzrKAAAlhGdD///lZAP//7iWw Date: Thu, 11 Dec 2014 18:34:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D58F7DD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D58F420@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvje65x50hBs2fmC3uz9vKaDHt5GVm i8ZFT1kdmD1mNaxl91iy5CeTx46G58wBzFFcNimpOZllqUX6dglcGUfW/mEuOCJVceNWC3sD 4wTRLkYODgkBE4mNq227GDmBTDGJC/fWs3UxcnEICRxhlOh4u4cVwlnCKHFr5j5mkAY2AQuJ 7n/aIA0iAiESW39PYgOxmQVUJc41PmYBsYUFUiV6b/1hg6hJk1g+5TI7SKuIgJvE4h/OIGEW oPINjz6wgti8Ar4Sc6f/Z4FY1coksXZLOzNIglPAU2LerXdgNiPQcd9PrWGC2CUucevJfCaI owUkluw5zwxhi0q8fPyPFcJWklh7eDsLRL2OxILdn6Du1JZYtvA1M8RiQYmTM5+wTGAUm4Vk 7CwkLbOQtMxC0rKAkWUVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmBEHdzyW3UH4+U3jocY BTgYlXh4DSo7Q4RYE8uKK3MPMUpzsCiJ8y48Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A6O79U/VMmdFuwfPM8S5u/2vXZGyz9XQ5L7013SL2Zp1THoHrk226j218t6m64yW6qdunuJa vZ7ZbrfodoevxyOvR/2d9nF2pIht+osXVWvYQsJ5tAQdsif7tQWt3VhZefrnvpIXfgqCh8LX Nd9lDVXU2HL/+uXTT5fet50Tb5Z3OP4nQ7lgSZMSS3FGoqEWc1FxIgBtt8fBiQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/bXkhocgmr2uDEeb_LdIxhUSQ3L0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 18:34:58 -0000 Hi, >Isn't this the media plane negotiation and setup mechanism for transferrin= g a file when using SIP? > >http://www.rfc-editor.org/rfc/rfc5547.txt > >Or am I missing something? I didn't suggest that we would need to define a new mechanism for transferr= ing data. My issue was that, the way I read the ecall draft, it only "allows" data tr= ansfer using SIP. But, Randall has indicated that is not the intention. Regards, Christer -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, December 11, 2014 12:56 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" = carried in SIP requests? Hi Brian, > I do agree that when there is a lot of data, we want to send URIs, and le= t the PSAP pull the data over HTTP. I believe we can do that with this mec= hanism. > > The same problem occurs in data related to a location. One might have su= rveillance video available, for example. The answer is the same, send it v= ia URI. > > The document does not provide guidance on this point, and maybe it should= . I think there are issues with providing a URI, and sending data over HTTP. - If the PSAP provides a URI to the UA for fetching data, the URI could ope= n possibilities for attacks on the PSAP. - If the UA provides a URI to the PSAP for fetching data, the URI could res= ult in privacy issues. Also, there may be NAT related issues when the PSAP = tries to connect to the UA. I think a media plane mechanism should be considered for transporting big- = and/or frequent data (pictures, sensor data, etc). Regards, Christer > On Dec 11, 2014, at 6:37 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > draft-ietf-ecrit-ecall seems to assume that, whatever is sent from a vehi= cle to the PSAP (or in the other direction), is considered "additional data= " carried in SIP requests. I think there may be issues with such approach. >=20 > For example, the vehicle may be requested to send picture(s). Sending tho= se on the signaling plane could create very large SIP requests. >=20 > Also, the vehicle may be requested to provide lots of sensor data etc. Se= nding that on the signaling plane could create a very large number of SIP r= equests. >=20 > Finally, the draft seems to assume that data can be sent also in INFO res= ponses - which is not correct. Data can only be carried in INFO requests, a= nd because of that the number of SIP messages could double in the worst cas= e scenario. >=20 > So, I don't think we can consider everything sent from the vehicle to the= PSAP as "additional data" carried in SIP requests, as it would very likely= cause issues in the network. >=20 > (Yes, I know data can also be provided e.g. by providing a URL, but I am = not sure whether that will actually work - enabling the UA to send IP packe= ts to the PSAP could open an opportunity for attacks on the PSAP). >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > 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 From nobody Thu Dec 11 23:31:32 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0620F1A88A1 for ; Thu, 11 Dec 2014 23:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 bd60VRqo3MME for ; Thu, 11 Dec 2014 23:31:29 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715D81A001C for ; Thu, 11 Dec 2014 23:31:29 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-66-548a99cfe3be Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CA.D0.04231.FC99A845; Fri, 12 Dec 2014 08:31:27 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.89]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 08:31:27 +0100 From: Ivo Sedlacek To: "Rosen, Brian" , Christer Holmberg Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AdAVNoK4d0cbFFNJSQWyPFAruzY03wADzrKAAAlhGdD///NagP//EJxQ Date: Fri, 12 Dec 2014 07:31:27 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127BC26F@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D58F420@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvje75mV0hBqcvGFtMO3mZ2aJx0VNW ByaPJUt+MnnsaHjOHMAUxWWTkpqTWZZapG+XwJUx99shloJznBXne16wNjDuZe9i5OSQEDCR OHl8AyOELSZx4d56ti5GLg4hgSOMEhcOH4JyFjNK/Prxng2kik1AT2LiliOsILaIQJLE1JM/ weLMAqoS5xofs4DYwgKpEr23/rBB1KRJLJ9yGWgbB5DtJrFjpiFImAWo/NDidrAjeAV8JXrb mtghdn1klPjx5QrYHE4BU4mm5Q1guxgFZCWu/ullhNglLnHryXwmiKsFJJbsOc8MYYtKvHz8 jxXCVpJoXPKEFaJeR2LB7k9Qd2pLLFv4mhlisaDEyZlPWCYwis1CMnYWkpZZSFpmIWlZwMiy ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwgg5u+a27g3H1a8dDjAIcjEo8vAWTukKEWBPL iitzDzFKc7AoifMuOjcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjb3Xa71X2z9cpXskW F45yuFz7fe/3mueha0p4vz9+tlfA9p/XnEOP7G5Oy2679zry8vpTmdN3BS3oKXu3pjaIi0U0 TcBb47Lbgufrvq5xsGLaX/3GUP5949075rpa+/JLIqa7Msn88r3iKCPKpBDwqeau7tvJOWsX 3Zbnf7ZF5mSxRY71bYt6JZbijERDLeai4kQASJPQOYECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/HR3CPkjg5Ed5M0AKwIMVo7Vz1yU Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 07:31:31 -0000 Hello, > >- If the UA provides a URI to the PSAP for fetching data, the URI could= =20 > >result in privacy issues. Also, there may be NAT related issues when=20 > >the PSAP tries to connect to the UA. > > I do not see any privacy issues. For one thing, privacy expectations are= =20 > significantly lower in emergency calls (by statute in many jurisdictions)= . > PSAPs will need credentials for any form of security. In North America,= we=20 > have a reasonable PKI worked out and we have some commitments to start=20 > deployment of it. The credentials can be used to make sure only authoriz= ed=20 > entities have access to the data. The URI should be some ephemeral id, s= o an=20 > attacker would need to observe the signaling to get it. But then, if the= =20 > attacker can observe the signaling, it can observe a push. The identified privacy issue: - a famous person is hurt in car accident. - the car provides a URI at which photo of the hurt person can be fetched. It is perfectly OK for PSAP personnel to fetch the photo at the URI. However, non-PSAP personnel, if they happen to get the URI, should not be a= ble to fetch the photo at the URI. Kind regards Ivo Sedlacek From nobody Thu Dec 11 23:51:05 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44261AC415 for ; Thu, 11 Dec 2014 23:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 mosusx1Xcxr2 for ; Thu, 11 Dec 2014 23:51:02 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08ED81AC402 for ; Thu, 11 Dec 2014 23:51:01 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-1a-548a9e633fc6 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EE.36.04076.36E9A845; Fri, 12 Dec 2014 08:51:00 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.89]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 08:50:59 +0100 From: Ivo Sedlacek To: Randall Gellens , Christer Holmberg , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AQHQFWagd0cbFFNJSQWyPFAruzY035yLka3Q Date: Fri, 12 Dec 2014 07:50:58 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvjW7KvK4Qg81ruS0aFz1ltbj2qIPZ gcljyZKfTB6Lpj5jDGCK4rJJSc3JLEst0rdL4Mq48Okra8F37op9N6YwNjAe5Oxi5OSQEDCR ONT6nhXCFpO4cG89WxcjF4eQwBFGicsn7rBCOIsZJQ7MfsAGUsUmoCcxccsRsISIQCujxPp5 28HahQVSJXpv/QErEhFIk1g+5TJ7FyMHkG0k8eSrKkiYRUBV4uS9NSwgNq+Ar8TPOz1g5UIC 5RKzVxxiBLE5gS5qmHUbrIZRQFbi6p9esDizgLjErSfzmSAuFZBYsuc8M4QtKvHy8T+oD5Qk Gpc8YYWo15FYsPsTG4StLbFs4WtmiL2CEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG0eLU 4uLcdCMjvdSizOTi4vw8vbzUkk2MwEg5uOW31Q7Gg88dDzEKcDAq8fAWTuoKEWJNLCuuzD3E KM3BoiTOu/DcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjAGeGg1FlbZPd3U4605SnBD2 Xn+bdOrir9GZD2cJPngvd3tx5aTl0Sm2y+VOfDsSzB0pMPPyGpNHAcem3mic6PffOOlpgdEq D1ePdVOuPFgmGhAVNDE9fOFpkxc7S6cdzhWI/1SQklN0vzI+8KvQK4mHClksWu/v2D372sbA fXyat2ymxMZZOUosxRmJhlrMRcWJAHi4hhN1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/twGVE-pVqCoy0yCYaG9PMgZYlmk Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 07:51:05 -0000 Hello, > The document builds on existing emergency calling, and hence does not spe= cify=20 > non-eCall aspects, such as media, since those are already addressed in th= e=20 > underlying documents. As you know, those existing emergency calling=20 > documents currently cover streaming media, but not non-streaming media su= ch=20 > as pictures or video clips. There is work going on is some SDOs to addre= ss=20 > how non-streaming media will be carried in an emergency call. I think=20 > everyone involved can easily see that such media will be carried using=20 > existing mechanisms, most likely as file attachments using MSRP. There i= s no=20 > intent for the eCall document to specify its own mechanism for transferri= ng=20 > non-streaming media (and it would be quite silly dor it to do so). Let's assume PSAP sends a request for a photo to be taken by a car camera (= e.g. in SIP INFO as in I-D-ietf-ecrit-ecall-01). Let's assume the car sends the actual photo to PSAP using a media stream (e= .g. MSRP media stream as suggested above). The PSAP knows that an MSRP media stream is negotiated in the emergency cal= l and that the MSRP message carrying the actual photo is sent within that M= SRP media stream.=20 However, there needs to be a mechanism enabling the PSAP personnel to assoc= iate the actual photo (sent via the MSRP media stream) with the request for= the photo (sent via the SIP INFO). This does not seem to be possible today= . Kind regards Ivo Sedlacek From nobody Fri Dec 12 00:17:30 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5171AC42D for ; Fri, 12 Dec 2014 00:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 lpnl9Ay9NNXd for ; Fri, 12 Dec 2014 00:17:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4B31AC41F for ; Fri, 12 Dec 2014 00:17:24 -0800 (PST) Received: from [192.168.131.137] ([80.92.119.109]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LcFTN-1Xa95B03u9-00jXw3; Fri, 12 Dec 2014 09:17:20 +0100 Message-ID: <548AA48E.8090601@gmx.net> Date: Fri, 12 Dec 2014 09:17:18 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivo Sedlacek , Randall Gellens , Christer Holmberg , "ecrit@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WGgM8Dw0UXG6WSDkmtaCca2sm63Re4oIr" X-Provags-ID: V03:K0:+Nw3wI0VwS/74qFB188O6j74bZ5xgb1Ph3tqcIZw7cQGeTsaj/5 9QOPf81RTVFuW8myRJpfgd3J+18IFKVjPtvhl6XocSyyhkEnKxhACk1seNMZNE/fPuyF1jc GXiiyXd1ZbeHVZs8ruzNHRsl+Rb5BUF1P1imX/5RmksW36RDAKN9EJ4+AGUjSozyi8QBSq5 SbVaXmoS1ttxkN/zltWeQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/7VGCknpcOlOHtCXaFk6vaZjwJyA Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 08:17:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WGgM8Dw0UXG6WSDkmtaCca2sm63Re4oIr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ivo, I don't know whether it matters but I have doubts that a photo will be sent as a media stream. When you talk about a photo I guess you actually don't mean a photo but rather to enable a webcam. Ciao Hannes On 12/12/2014 08:50 AM, Ivo Sedlacek wrote: > Hello, >=20 >> The document builds on existing emergency calling, and hence does not = specify=20 >> non-eCall aspects, such as media, since those are already addressed in= the=20 >> underlying documents. As you know, those existing emergency calling=20 >> documents currently cover streaming media, but not non-streaming media= such=20 >> as pictures or video clips. There is work going on is some SDOs to ad= dress=20 >> how non-streaming media will be carried in an emergency call. I think= =20 >> everyone involved can easily see that such media will be carried using= =20 >> existing mechanisms, most likely as file attachments using MSRP. Ther= e is no=20 >> intent for the eCall document to specify its own mechanism for transfe= rring=20 >> non-streaming media (and it would be quite silly dor it to do so). >=20 > Let's assume PSAP sends a request for a photo to be taken by a car came= ra (e.g. in SIP INFO as in I-D-ietf-ecrit-ecall-01). >=20 > Let's assume the car sends the actual photo to PSAP using a media strea= m (e.g. MSRP media stream as suggested above). >=20 > The PSAP knows that an MSRP media stream is negotiated in the emergency= call and that the MSRP message carrying the actual photo is sent within = that MSRP media stream.=20 >=20 > However, there needs to be a mechanism enabling the PSAP personnel to a= ssociate the actual photo (sent via the MSRP media stream) with the reque= st for the photo (sent via the SIP INFO). This does not seem to be possib= le today. >=20 > Kind regards >=20 > Ivo Sedlacek >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 --WGgM8Dw0UXG6WSDkmtaCca2sm63Re4oIr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUiqSOAAoJEGhJURNOOiAtSHgH/iwCjYTouBNu/gLoxDv10naU x46xaslEOfv8PK8mpKeAP+z8qunzokk/maW4Nms6/t2uAGtf1kK7v0tfpcRLxzqb w9Dw7W904ZrP2bm+MdjDv/yuJ+Obw/hzYUr3CmUQA3VExWVnk2bsaBYSr9vKhkEg JFanTserNJHQ9hmA3UfiX66QlW87pwhL2RfFY6DH3ujNul6E3r/TZA40O3+wjfun YdB5wyf1DOSxkCWdapqBZ14i25U4ytih460j9abjW7p3QIi82Jnb602Kj40RVs9F tXDECwNXOpswK4XCXqxOi6UkWIezF8NIhldR49nEOH3hOIAyEbE/u6UBrE5PE7w= =y1I5 -----END PGP SIGNATURE----- --WGgM8Dw0UXG6WSDkmtaCca2sm63Re4oIr-- From nobody Fri Dec 12 00:46:38 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81881A90D3 for ; Fri, 12 Dec 2014 00:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 X-5pRGZSI5BB for ; Fri, 12 Dec 2014 00:46:35 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD001AC432 for ; Fri, 12 Dec 2014 00:46:35 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-f8-548aab6804c2 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C4.48.29772.86BAA845; Fri, 12 Dec 2014 09:46:33 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.89]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 09:46:32 +0100 From: Ivo Sedlacek To: Hannes Tschofenig , Randall Gellens , Christer Holmberg , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AQHQFeQOwgk4pLdJuUS3ALW3mQJUDJyLoDIg Date: Fri, 12 Dec 2014 08:46:32 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> In-Reply-To: <548AA48E.8090601@gmx.net> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+JvjW7m6q4Qg45lfBaNi56yWizdeY/V 4tqjDmYHZo/Fm/azeSxZ8pPJY9HUZ4wBzFFcNimpOZllqUX6dglcGT/bfzIV3GatWPXrJ0sD 4zaWLkZODgkBE4nGNy1QtpjEhXvr2boYuTiEBI4wSnzZPZ8RwlnMKPF30TxGkCo2AT2JiVuO sIIkRAS2MUo0bTjOCpIQFkiV6L31hw3EFhFIk1g+5TI7hG0kceHPJLAVLAKqEh8XHACzeQV8 Jc6e28cMseEGo8THbxfBNnAKqEt8bP0LVsQoICtx9U8vWJxZQFzi1pP5TBC3Ckgs2XOeGcIW lXj5+B8rhK0k0bjkCStEvY7Egt2f2CBsbYllC18zQywWlDg58wnLBEbRWUjGzkLSMgtJyywk LQsYWVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbQwS2/DXYwvnzueIhRgINRiYe3YFJX iBBrYllxZe4hRmkOFiVx3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYNR1Z2Q3W23/ Pm6BISez6ZRsk2WX7WxnmRVtFXS4ouvk+PoF/7Pe6p5ZEl3i/uFmE7c4LlS6OCVwnadc3QXl /3VPvpzItGJUuPlu7gTLTDenJ1si7rXuv3TxYsD3PzLnWfaUTN86bb/uo3MrOZt877Bsne0z h43V8M7ekynT/tpIJr10Kfo6cYsSS3FGoqEWc1FxIgC0DgLygQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/6aOau46mfzcmYnW9m0p9T8-WXJo Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 08:46:36 -0000 Hello, > I don't know whether it matters but I have doubts that a photo will be=20 > sent as a media stream. When you talk about a photo I guess you=20 > actually don't mean a photo but rather to enable a webcam. draft-ietf-ecrit-ecall-01 states: ------------------ NG-eCall is expected to offer: ... o The ability for the PSAP to access vehicle components (e.g., an onboard camera (such as rear facing or blind-spot cameras) for a visual assessment of the crash site situation) .... ------------------ I can imagine that PSAP will be interested in both photos and video media s= tream.=20 Photos normally have higher resolution than video media stream. Kind regards Ivo Sedlacek From nobody Fri Dec 12 00:53:42 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FC31AC439 for ; Fri, 12 Dec 2014 00:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 fWY5noUczRbi for ; Fri, 12 Dec 2014 00:53:40 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB501A90D3 for ; Fri, 12 Dec 2014 00:53:39 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-a0-548aad11b7e7 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 76.EB.24955.11DAA845; Fri, 12 Dec 2014 09:53:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 09:53:37 +0100 From: Christer Holmberg To: "Rosen, Brian" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AdAVNoK4d0cbFFNJSQWyPFAruzY03wADzrKAAAlhGdD///NagP/++BFA Date: Fri, 12 Dec 2014 08:53:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5910E3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D58F420@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvja7Q2q4QgwlreC2mnbzMbNG46Cmr A5PHkiU/mTx2NDxnDmCK4rJJSc3JLEst0rdL4Mo40tDPWjCJuWLBr1VsDYxbmboYOTkkBEwk uua+ZYewxSQu3FvP1sXIxSEkcIRR4vH8mUwQzhJGiW33tjN3MXJwsAlYSHT/0wZpEBHQkeib dpsZxGYWUJU41/iYBcQWFkiV6L31hw2iJk1i+ZTL7BC2m8T6V7PAFrMA1f9unMsKYvMK+ErM 7b0Dtesjo8SPL1fABnEKmEo0LW8AK2IEuu77qTVMEMvEJW49mQ/1gYDEkj3nmSFsUYmXj/+x gtwpIaAosbxfDqJcR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo9gsJFNnIWmZhaRlFpKWBYws qxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjEC4+fglt+qOxgvv3E8xCjAwajEw1swqStEiDWx rLgy9xCjNAeLkjjvwnPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw1ryZ6mwwu2A7jzh7 /+7Qq30fru506+evVP+gfsVp28kO/15tLub+OmsV9blX6wKvZ6lN4PVkPqW+/8eP110NhdNy w1/zuc8VXHlm6Uf/qfpTVByvm17LE0zh9nryV1Z0QuKUn7eKFlrcvXTz1l2n/tP2Hx07n1/M LWo9/3PPsReZzpNkzzRYK7EUZyQaajEXFScCABtxtQ6AAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/2czmQWkG-ibFQ_YwBI1NPWo2Dbc Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 08:53:41 -0000 Hi, >Doing something in the data plane would be something along the lines of MS= RP file. Not really opposed to that. MSRP seems to be what most people have been talking about, and assumed that= will be used. However, now we also have the data channel, defined in rtcweb. I am not say= ing that would be a better solution, but perhaps something to look into :) Regards. Christer From nobody Fri Dec 12 00:57:47 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EA11A90D3 for ; Fri, 12 Dec 2014 00:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TdyDt9b6JGKy for ; Fri, 12 Dec 2014 00:57:44 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2753F1A8A0F for ; Fri, 12 Dec 2014 00:57:44 -0800 (PST) Received: from [192.168.131.137] ([80.92.119.109]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LxxNo-1XvxvJ45nY-015FcG; Fri, 12 Dec 2014 09:57:38 +0100 Message-ID: <548AAE01.10201@gmx.net> Date: Fri, 12 Dec 2014 09:57:37 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivo Sedlacek , Randall Gellens , Christer Holmberg , "ecrit@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="05bLfrH2iitsnO4bRoQaQdsrlQwxws0Tc" X-Provags-ID: V03:K0:TZOisObRGN6v5c21BSX2uZZzLXbQPlvGRwdXUaGeKsej9vZVY/h 5iptjsCcHPGIFiPXZT2P8Ycwpm3lFZNrcG7ramfJMjmSuie6bMyQoIu38Yvn0zHzb/5VKIF ViGMCjlThOsq0VhIRLWAWMe1+bePX8rPNpSBm5yPE2pdMMkNBPQlL6YX9Y1V962S6/JlesP ls+YRQx8FCL5BDfWAYY+A== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/ZNNkqJyyE-c24qQBpLDzSt_pdHA Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 08:57:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --05bLfrH2iitsnO4bRoQaQdsrlQwxws0Tc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ivo, I fully agree that it is useful to send pictures and videos around but the mechanisms for doing so might be different. For the video I could imagine that the PSAP sends updates the existing session using an INVITE while a file transfer is most likely done differently. Ciao Hannes On 12/12/2014 09:46 AM, Ivo Sedlacek wrote: > Hello, >=20 >> I don't know whether it matters but I have doubts that a photo will be= =20 >> sent as a media stream. When you talk about a photo I guess you=20 >> actually don't mean a photo but rather to enable a webcam. >=20 >=20 > draft-ietf-ecrit-ecall-01 states: > ------------------ > NG-eCall is expected to offer: > ... > o The ability for the PSAP to access vehicle components (e.g., an > onboard camera (such as rear facing or blind-spot cameras) for a > visual assessment of the crash site situation) > .... > ------------------ >=20 > I can imagine that PSAP will be interested in both photos and video med= ia stream.=20 >=20 > Photos normally have higher resolution than video media stream. >=20 > Kind regards >=20 > Ivo Sedlacek >=20 --05bLfrH2iitsnO4bRoQaQdsrlQwxws0Tc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUiq4BAAoJEGhJURNOOiAtEd4H/3q876/OYcB/DkG9a+fIaCzW oCXiiOoayLXGIIj7R/bWtXQtFIf1VWiQ2XYJnQqN1DlHYKCQW/kWDUJCmw+lbzAc M3p/ChJoZLQ6ddnyhrgUmvXLkZK1NWm7WVH44tN5YW8UYzBh2yZ02ikn4lpDeQgn +qWfICLzTUNY4R0Fw359hQJdYn780C8hIC7Ec1t9GzE9C2n5YdggidvxDCwp7DBC WDTq60ZnuE75V1pKeu7223f88y+ffUOmX+h+yW68zcNI2DzCW0Pk9BNQo3fQ3QhB lblSyvB30UPM4L9V72zl4y41uGf9K6QUuZlY3mKMELoV+ryCQj2nf/GhK/ZY+3s= =F1gb -----END PGP SIGNATURE----- --05bLfrH2iitsnO4bRoQaQdsrlQwxws0Tc-- From nobody Fri Dec 12 02:12:59 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158DE1A1AF2 for ; Fri, 12 Dec 2014 02:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 k_NK3brZnUku for ; Fri, 12 Dec 2014 02:12:54 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5761ACC7F for ; Fri, 12 Dec 2014 02:12:54 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-60-548abfa49965 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C4.61.04231.4AFBA845; Fri, 12 Dec 2014 11:12:52 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 11:12:52 +0100 From: Christer Holmberg To: Hannes Tschofenig , Ivo Sedlacek , Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AQHQFeBe2H4DQv8a3UWASlFbpilRUpyLi5IAgAAIKwCAAAMYgIAAJQmA Date: Fri, 12 Dec 2014 10:12:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> In-Reply-To: <548AAE01.10201@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje6S/V0hBr+Oa1o0LnrKarF05z1W i2uPOpgdmD0Wb9rP5rFkyU8mj0VTnzEGMEdx2aSk5mSWpRbp2yVwZeyeeoqtYBl3xdbvi1kb GB9zdDFyckgImEi8v7iTCcIWk7hwbz1bFyMXh5DAEUaJb1OOMUM4Sxgllm3oY+li5OBgE7CQ 6P6nDRIXEVjDKDGp7x4jSLewQKpE760/bCC2iECaxPIpl9khbDeJxVPOs4L0sgioSrTeiAIJ 8wr4Shw+8gFq/nYmiXv3+8HmcALVTG55ANbLCHTR91NrwK5jFhCXuPVkPtSlAhJL9pxnhrBF JV4+/gc2X0JAUWJ5vxxEuY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEbRWUimzkLSMgtJyywk LQsYWVYxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBMbOwS2/dXcwrn7teIhRgINRiYe3YFJX iBBrYllxZe4hRmkOFiVx3kXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYPQVbuJ45p7x QdTu+47bl2ZF6G0SV/UJ3sz0n/vzAYuCAH+TOiNV0frua+YLXGZM3vls5VQZp9sTXl7XaxQW iv4TcuVTt/mVvxoh+U7Pax22FfXsWLR4h828fBuet10m/YsfGtllZS8N0o0/t6po8fU/pdZK rbpHXqYvzFJ7E5DH3rzWQdMlT4mlOCPRUIu5qDgRAM0Bjr9+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/cFoudDyR_ToAoc7bV84u4X27wr4 Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 10:12:56 -0000 Hi, >I fully agree that it is useful to send pictures and videos around but the= mechanisms for doing so might be different. > >For the video I could imagine that the PSAP sends updates the existing ses= sion using an INVITE while a file transfer is most likely done differently. That is true. I assume "traditional" real-time audio/video very likely be s= ent using RTP. But, the issue has not been on the specific protocols, but more about not h= aving to send big data on the signaling plane, and to be able to use *some*= media plane mechanism instead. Regards, Christer On 12/12/2014 09:46 AM, Ivo Sedlacek wrote: > Hello, >=20 >> I don't know whether it matters but I have doubts that a photo will=20 >> be sent as a media stream. When you talk about a photo I guess you=20 >> actually don't mean a photo but rather to enable a webcam. >=20 >=20 > draft-ietf-ecrit-ecall-01 states: > ------------------ > NG-eCall is expected to offer: > ... > o The ability for the PSAP to access vehicle components (e.g., an > onboard camera (such as rear facing or blind-spot cameras) for a > visual assessment of the crash site situation) .... > ------------------ >=20 > I can imagine that PSAP will be interested in both photos and video media= stream.=20 >=20 > Photos normally have higher resolution than video media stream. >=20 > Kind regards >=20 > Ivo Sedlacek >=20 From nobody Fri Dec 12 02:16:54 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478BB1ACC8D for ; Fri, 12 Dec 2014 02:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GVpA3pMdSfqs for ; Fri, 12 Dec 2014 02:16:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F041ACC7F for ; Fri, 12 Dec 2014 02:16:50 -0800 (PST) Received: from [192.168.131.137] ([80.92.119.109]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lz3JU-1Xuotl1g5Q-0149en; Fri, 12 Dec 2014 11:16:41 +0100 Message-ID: <548AC088.5020003@gmx.net> Date: Fri, 12 Dec 2014 11:16:40 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Christer Holmberg , Ivo Sedlacek , Randall Gellens , "ecrit@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2dawvE40oq0SODA4nEbVFRe0iPm7oorR9" X-Provags-ID: V03:K0:/YUCbqPdlyoxQRU6GkJUWCYq6QGsuPU0NypeL+aOpCMVKu+yj3v pRO1V7+q6yFjboemym2Qkpq0ow3pJwRE85aRHf3Yi6OmEEsWVmvT12hCKecnAjOk0sKokeK 667v4DWJw3lOlinBqNLXaP+uqPdtWgT8HyINBLJ9aBD4FZANbLL2bkxVEBBZNN1eYfCyFLE tA8EtvDNjyoXCNZ7UmxZA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/rz3w5kfGzQPeWIQnaoJOB5Ny29Y Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 10:16:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2dawvE40oq0SODA4nEbVFRe0iPm7oorR9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Christer, the use of the additional data draft in the context of the ecall draft does not mean that everything has to be sent in the signaling plane. Nothing prevents the PSAP from using the ordinary SIP mechanisms. Maybe I am just failing to see the problem. Ciao Hannes On 12/12/2014 11:12 AM, Christer Holmberg wrote: > Hi, >=20 >> I fully agree that it is useful to send pictures and videos around but= the mechanisms for doing so might be different. >> >> For the video I could imagine that the PSAP sends updates the existing= session using an INVITE while a file transfer is most likely done differ= ently. >=20 > That is true. I assume "traditional" real-time audio/video very likely = be sent using RTP. >=20 > But, the issue has not been on the specific protocols, but more about n= ot having to send big data on the signaling plane, and to be able to use = *some* media plane mechanism instead. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > On 12/12/2014 09:46 AM, Ivo Sedlacek wrote: >> Hello, >> >>> I don't know whether it matters but I have doubts that a photo will=20 >>> be sent as a media stream. When you talk about a photo I guess you=20 >>> actually don't mean a photo but rather to enable a webcam. >> >> >> draft-ietf-ecrit-ecall-01 states: >> ------------------ >> NG-eCall is expected to offer: >> ... >> o The ability for the PSAP to access vehicle components (e.g., an >> onboard camera (such as rear facing or blind-spot cameras) for a= >> visual assessment of the crash site situation) .... >> ------------------ >> >> I can imagine that PSAP will be interested in both photos and video me= dia stream.=20 >> >> Photos normally have higher resolution than video media stream. >> >> Kind regards >> >> Ivo Sedlacek >> >=20 --2dawvE40oq0SODA4nEbVFRe0iPm7oorR9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUisCIAAoJEGhJURNOOiAtLDAH/RGD7SoyAytsFm5K0IFF2nNi ozHwx6w9oDvF3ifHzNZ7oao53a3fmx6zx14i++oqUHRANFRj3teTPZ2K/x7Cqn50 sjsoNLXDSrVrtxi/j7LevkR0kW88MegsXd0nLRk3hC/Znqav2LE1zi2Op6CcWO7c wTRXDCCuZ6TIEFhl6tPSlLmchPufClflWZ4TAd69vjMGeY1L6AjtcTZz69rIvJpn BSG1R4eE7OugR+Sv7R553Bg8JS9AZbRONDm+ZL/+g4USm0zwqte6770UBTQtgk8t MvUpQBy279cDAMBFaQ1MIBhwWCwtbiK3m3/1e+MdocQnuz/gfBphebAndnI15ac= =LbEj -----END PGP SIGNATURE----- --2dawvE40oq0SODA4nEbVFRe0iPm7oorR9-- From nobody Fri Dec 12 02:30:44 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6F21ACCDC for ; Fri, 12 Dec 2014 02:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 6xxzmAYdX7Tq for ; Fri, 12 Dec 2014 02:30:40 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB591ACC81 for ; Fri, 12 Dec 2014 02:30:40 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-40-548ac3ce3893 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 79.70.24955.EC3CA845; Fri, 12 Dec 2014 11:30:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 11:30:38 +0100 From: Christer Holmberg To: Hannes Tschofenig , Ivo Sedlacek , Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AQHQFeBe2H4DQv8a3UWASlFbpilRUpyLi5IAgAAIKwCAAAMYgIAAJQmA///xDgCAABRCUA== Date: Fri, 12 Dec 2014 10:30:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> <548AC088.5020003@gmx.net> In-Reply-To: <548AC088.5020003@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje65w10hBisWS1s0LnrKarF05z1W i2uPOpgdmD0Wb9rP5rFkyU8mj0VTnzEGMEdx2aSk5mSWpRbp2yVwZRzbMJGxYD1/xb6Oy0wN jF+5uxg5OSQETCQmz3jPAmGLSVy4t56ti5GLQ0jgCKPEtPa97BDOEkaJzUu2ADkcHGwCFhLd /7RB4iICaxglJvXdYwTpFhZIlei99YcNxBYRSJNYPuUyO4QdJtG+bDtYnEVAVaJx5yNWEJtX wFfi18spzBALZjBLbD5+H6yIU0Bd4uLHS2A2I9BJ30+tYQKxmQXEJW49mc8EcaqAxJI955kh bFGJl4//sYIcJyGgKLG8Xw6iXEdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRTZyFpmYWk ZRaSlgWMLKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAqPn4JbfqjsYL79xPMQowMGoxMNb MKkrRIg1say4MvcQozQHi5I478Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MMreD2e+ dL+JP3aXc8tKxbr3zecvbTy9MvZORNsjj0y9Q45GlSICrE4qLd8W8y25/zrJJ2rrOmNWyTcW YvOvaauYH92b9HZmZGnr2uRzgn8SWrOPzdmx0zT72eIrl6MVVngle9WsLt/9h+3vzw/XY5w1 Tymcentudutn6X0zEw5VXlvGfao3Y54SS3FGoqEWc1FxIgBmoXYyfwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/Szf0iE8ZTd78RDRipbQ-NJP7nxA Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 10:30:42 -0000 Hi, > the use of the additional data draft in the context of the ecall draft do= es not mean that everything has to be sent in the signaling plane. > Nothing prevents the PSAP from using the ordinary SIP mechanisms. And that has been clarified now :) But, that is not how I read the draft, and I think Randall has also said th= at some clarification text will be added. Regards, Christer On 12/12/2014 11:12 AM, Christer Holmberg wrote: > Hi, >=20 >> I fully agree that it is useful to send pictures and videos around but t= he mechanisms for doing so might be different. >> >> For the video I could imagine that the PSAP sends updates the existing s= ession using an INVITE while a file transfer is most likely done differentl= y. >=20 > That is true. I assume "traditional" real-time audio/video very likely be= sent using RTP. >=20 > But, the issue has not been on the specific protocols, but more about not= having to send big data on the signaling plane, and to be able to use *som= e* media plane mechanism instead. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > On 12/12/2014 09:46 AM, Ivo Sedlacek wrote: >> Hello, >> >>> I don't know whether it matters but I have doubts that a photo will=20 >>> be sent as a media stream. When you talk about a photo I guess you=20 >>> actually don't mean a photo but rather to enable a webcam. >> >> >> draft-ietf-ecrit-ecall-01 states: >> ------------------ >> NG-eCall is expected to offer: >> ... >> o The ability for the PSAP to access vehicle components (e.g., an >> onboard camera (such as rear facing or blind-spot cameras) for a >> visual assessment of the crash site situation) .... >> ------------------ >> >> I can imagine that PSAP will be interested in both photos and video medi= a stream.=20 >> >> Photos normally have higher resolution than video media stream. >> >> Kind regards >> >> Ivo Sedlacek >> >=20 From nobody Fri Dec 12 02:33:39 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCFA1ACCDC for ; Fri, 12 Dec 2014 02:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 cTNNyqnYmVF8 for ; Fri, 12 Dec 2014 02:33:37 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5351ACCE0 for ; Fri, 12 Dec 2014 02:33:37 -0800 (PST) Received: from [192.168.131.137] ([80.92.119.109]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M9sa0-1Y61Mk34oK-00B2Mj; Fri, 12 Dec 2014 11:33:34 +0100 Message-ID: <548AC47E.5020002@gmx.net> Date: Fri, 12 Dec 2014 11:33:34 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Christer Holmberg , Ivo Sedlacek , Randall Gellens , "ecrit@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> <548AC088.5020003@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x9evSJ8s0nCQa08pSnjHhPREtN8c4keba" X-Provags-ID: V03:K0:XFh9xZi2qyaITu1/jjoYejciBoRe2JeYwcLvFt7tmy4kraOIN46 lrAJgwjAuCXQxgMkzj6DpJQipEhE0xcWURQ+VYgewGdX6q6nt7YArI3a25F2QLmcy3MHurB n2PwJuQET3dsSsEyuVPOluliNz3lz0KnoEzWr0RYpXPrdin9u1e/e/CEGBVhTRg8/l4tHae OyBtbSXNyXGLS2LzNFY0w== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/9vVWKGasIZ_jPB91VPNqUsBaexg Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 10:33:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x9evSJ8s0nCQa08pSnjHhPREtN8c4keba Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/12/2014 11:30 AM, Christer Holmberg wrote: > But, that is not how I read the draft, and I think Randall has also sai= d that some clarification text will be added. Perfect. Issue solved! --x9evSJ8s0nCQa08pSnjHhPREtN8c4keba Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUisR+AAoJEGhJURNOOiAtFDwH/1rb6rrD42N2f3sp6LGyYtcz 9WfW5q2vI0Vr5JW/0uT/uT4fZp/hdgHW29YfZ3dCMESNo1b1dGg5Wa6uoNPlRnQx 6ciGDaDPafW/01NWhkWRO8c8VAnEUbOUh1fkS8SAh4KEUNiGqbgh6s5/+s60xPxV zY7ChmF3DFksPOxIQuD5Ea30zbAl4FmTmhpVa+U5bqrCF6eTEVY+qx7oEhezn7xd nsje0xODDIKS/7/jnPP5MQQO7wAo4xnx0OB/pSsdjsmKHYUu7tNB8f3CaF7jkopM Nw6QKnVOfRvRZJeC19U8TAvBzzMMBdMe9fj0diJ1l0NjAkuz8+DfCMxsdo9zRDY= =5VDL -----END PGP SIGNATURE----- --x9evSJ8s0nCQa08pSnjHhPREtN8c4keba-- From nobody Fri Dec 12 09:31:48 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADACF1A6FB5 for ; Fri, 12 Dec 2014 09:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 UnJybmUT4bRr for ; Fri, 12 Dec 2014 09:31:45 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B321A1A9C for ; Fri, 12 Dec 2014 09:31:44 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-29-548b267e40f2 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A2.9E.24955.E762B845; Fri, 12 Dec 2014 18:31:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 18:31:42 +0100 From: Christer Holmberg To: Hannes Tschofenig , Ivo Sedlacek , Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AQHQFeBe2H4DQv8a3UWASlFbpilRUpyLi5IAgAAIKwCAAAMYgIAAJQmA///xDgCAABRCUP//8HYAgACFFPA= Date: Fri, 12 Dec 2014 17:31:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D592601@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> <548AC088.5020003@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> <548AC47E.5020002@gmx.net> In-Reply-To: <548AC47E.5020002@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW6dWneIwZ5FlhaNi56yWizdeY/V 4tqjDmYHZo/Fm/azeSxZ8pPJY9HUZ4wBzFFcNimpOZllqUX6dglcGfvO3GcqmMhS0XL4PHMD 4xzmLkZODgkBE4mVF76zQdhiEhfurQeyuTiEBI4wSrz6e5ARwlnCKHFjw0agDAcHm4CFRPc/ bZC4iMAaRolJffcYQbqFBVIlem/9AZskIpAmsXzKZXYIO0li8/fdTCA2i4CqxNrNT1lAbF4B X4lfvztZIRb8ZJa4cOsKWAOngLrEiTXfwc5jBDrp+6k1YM3MAuISt57MZ4I4VUBiyZ7zUC+I Srx8/I8VwlaSWHT7M1S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQt CxhZVjGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExs/BLb9VdzBefuN4iFGAg1GJh7dgUleI EGtiWXFl7iFGaQ4WJXHehefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpgjONXvZ/DNO9V gOOn89/elUvay6qnfGrYJd3SYPNRMLnr9K+DBlIlDxZH33m5WvZ670L+jHnuH9Pz5xzeXKuq fMtm/ZIjB76E9f89YJPrd+bBPUaub+/277say+ydkCXzrGTDxbN6zEcd7aITfrkZuTPd1fgc PJ91yt2qKfEfTq9euO96p8GtM0osxRmJhlrMRcWJAK+QCP2AAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/xGPOQUw1N2qH27l06MoY2KcNPXQ Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 17:31:46 -0000 Hi, >> But, that is not how I read the draft, and I think Randall has also said= that some=20 >> clarification text will be added. > > Perfect. Issue solved! So, while the draft can use SIP INFO as an example, it need to make it clea= r that the MSD, eCall-Specific Control/Metadata etc can also be transported= using another mechanisms (media plane mechanisms). If we don't want to define such mechanism(s) in the draft, it should be cle= ar that it's up to other SDOs to define them. Regards, Christer From nobody Fri Dec 12 10:02:12 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EED1ACF11 for ; Fri, 12 Dec 2014 10:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7IkcjKYM9LEo for ; Fri, 12 Dec 2014 10:02:06 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649691A7113 for ; Fri, 12 Dec 2014 10:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1418407325; x=1449943325; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=dn8TLNx3b8+Sgny44KavjsD03CRfUOAGyjp2MFVBnlQ=; b=UyRpj+UC27GW0y8TF0mJm/+oFaMPNnF3a81hRK4r0tgF4T225sNsu1P7 NcrPLFVIukrTSY+sAqkH3aQEcm7fUXFXErnxlUss9SxDAX/zzj/RhEQAp GC8IDmKfSUBy4rH0X7Mw54kYfVH6ug9Xxuh5NuZ6sqjFTFNNODqbYozLo M=; X-IronPort-AV: E=McAfee;i="5600,1067,7650"; a="79956428" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Dec 2014 10:02:04 -0800 X-IronPort-AV: E=Sophos;i="5.07,565,1413270000"; d="scan'208";a="796168592" Received: from nasanexm02c.na.qualcomm.com ([10.46.200.74]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Dec 2014 10:02:04 -0800 Received: from [99.111.97.136] (10.80.80.8) by NASANEXM02C.na.qualcomm.com (10.46.200.74) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 12 Dec 2014 10:02:04 -0800 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D592601@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> <548AC088.5020003@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> <548AC47E.5020002@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D592601@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Fri, 12 Dec 2014 10:02:01 -0800 To: Christer Holmberg , Hannes Tschofenig , Ivo Sedlacek , Randall Gellens , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To NASANEXM02C.na.qualcomm.com (10.46.200.74) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/mQyngXPtwTLGfa38S_ka-0ILQ5c Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 18:02:10 -0000 At 5:31 PM +0000 12/12/14, Christer Holmberg wrote: > >> But, that is not how I read the draft, and I think Randall has > also said that some >>> clarification text will be added. >> >> Perfect. Issue solved! > > So, while the draft can use SIP INFO as an example, it need to make > it clear that the MSD, eCall-Specific Control/Metadata etc can also > be transported using another mechanisms (media plane mechanisms). We're all agreed that media should be transmitted via a media plane, not the signaling plane. I can add a caution that excessively large sensor data should not be sent by value in the signaling plane. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Vous etes ici From nobody Fri Dec 12 10:15:54 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392CB1A872A for ; Fri, 12 Dec 2014 10:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 vnj3iWsmLN75 for ; Fri, 12 Dec 2014 10:15:52 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020E01A0141 for ; Fri, 12 Dec 2014 10:15:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1418408152; x=1449944152; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=i5DXMIES4ygU6y5hlhxfF0R+Zujkhve9yS/tKNB5XPI=; b=wz0+KgHH/DJ4wO7uw47lvsZCw6QNLhgFOCNZ4PsWhgm90EpXBihSSJta qcfab+qT5NRf2gXxUpBT4Il3cO4ZxCk7rGA6kXm5RorJ/7WzC7rgyGaB+ 7AQk/pOpR14lYD2LR3onoPEfhXu5SthrYIYrUbNhK27QN6tz+rRKMw7Sx o=; X-IronPort-AV: E=McAfee;i="5600,1067,7650"; a="80690400" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Dec 2014 10:15:51 -0800 X-IronPort-AV: E=Sophos;i="5.07,565,1413270000"; d="scan'208";a="796174648" Received: from nasanexm01d.na.qualcomm.com ([10.85.0.84]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Dec 2014 10:15:51 -0800 Received: from [99.111.97.136] (10.80.80.8) by NASANEXM01D.na.qualcomm.com (10.85.0.84) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 12 Dec 2014 10:15:50 -0800 Message-ID: In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Fri, 12 Dec 2014 10:15:36 -0800 To: Ivo Sedlacek , Christer Holmberg , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01D.na.qualcomm.com (10.85.0.84) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/cqF90iaV05o_Ly3TgG4gzda8ozQ Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 18:15:53 -0000 At 7:50 AM +0000 12/12/14, Ivo Sedlacek wrote: > Hello, > >> The document builds on existing emergency calling, and hence does >> not specify >> non-eCall aspects, such as media, since those are already addressed in the >> underlying documents. As you know, those existing emergency calling >> documents currently cover streaming media, but not non-streaming media such >> as pictures or video clips. There is work going on is some SDOs to address >> how non-streaming media will be carried in an emergency call. I think >> everyone involved can easily see that such media will be carried using >> existing mechanisms, most likely as file attachments using MSRP. >> There is no >> intent for the eCall document to specify its own mechanism for transferring >> non-streaming media (and it would be quite silly dor it to do so). > > Let's assume PSAP sends a request for a photo to be taken by a car > camera (e.g. in SIP INFO as in I-D-ietf-ecrit-ecall-01). > > Let's assume the car sends the actual photo to PSAP using a media > stream (e.g. MSRP media stream as suggested above). > > The PSAP knows that an MSRP media stream is negotiated in the > emergency call and that the MSRP message carrying the actual photo > is sent within that MSRP media stream. > > However, there needs to be a mechanism enabling the PSAP personnel > to associate the actual photo (sent via the MSRP media stream) with > the request for the photo (sent via the SIP INFO). This does not > seem to be possible today. Why is this an IETF protocol issue rather than a client-side issue for the PSAP equipment? PSAP equipment must log everything and associate information with an incident. If the call taker requests a still image or a video stream, presumably the media must be associated with the call (the incident ID) and archived with other media and other data. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Lansing Residents Can Drop Off Trees --Newspaper headline From nobody Fri Dec 12 10:17:00 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F77D1A902B for ; Fri, 12 Dec 2014 10:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 C5sRhQ4J1SmB for ; Fri, 12 Dec 2014 10:16:55 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A8F1A8AC1 for ; Fri, 12 Dec 2014 10:16:55 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-39-548b31153d5c Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E4.32.24955.5113B845; Fri, 12 Dec 2014 19:16:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 19:16:53 +0100 From: Christer Holmberg To: Randall Gellens , Hannes Tschofenig , Ivo Sedlacek , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AQHQFjW/qnX3AA1i7EyYNN4SMbsf7JyMQeyg Date: Fri, 12 Dec 2014 18:16:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D592841@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> <548AC088.5020003@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> <548AC47E.5020002@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D592601@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja6oYXeIwYbl0haNi56yWizdeY/V 4tqjDmYHZo/Fm/azeSxZ8pPJY9HUZ4wBzFFcNimpOZllqUX6dglcGT8nr2UuWMZRMfP8HvYG xtNsXYwcHBICJhKvdqh2MXICmWISF+6tZwOxhQSOMEq8uyLYxcgFZC9hlHj/7AETSD2bgIVE 9z9tkLiIwBpGiQ//ZzKBNAgLpEksXnebFcQWEUiX+Nq3Gco2kjj84DqYzSKgKrFl6zJGEJtX wFdi4/9mdogFz1kklqz4A1bECXTQhdP7wIoYgS76fmoN2AJmAXGJW0/mM0FcKiCxZM95Zghb VOLl43+sELaSxKLbn6HqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrOQjJ2FpKWWUhaZiFp WcDIsopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMHYObvmtuoPx8hvHQ4wCHIxKPLwFk7pC hFgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo+6OtDQDZcnf of8XXnsvWHA6XWWHvcCBaXbzXes5FIX/2W5znfOTa8aB0OfS63eIZv54rOcpLxfU+DytxG/X ufOGDjVVln/ytLKTb/1fGPyqTX2hxaPEJX2Waz63i0pcU0s4+ulo5+e9rraf3j/KOrTlce2E W5Zv9thcm9rD7PI3Rjyzg/fLBCWW4oxEQy3mouJEAOhNKLR+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/wR3NaAg75cRiA2iL62QZPdVnyh4 Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 18:16:57 -0000 Hi, >>> But, that is not how I read the draft, and I think Randall has=20 >>> also said that some clarification text will be added. >>> >>> Perfect. Issue solved! >> >> So, while the draft can use SIP INFO as an example, it need to make=20 >> it clear that the MSD, eCall-Specific Control/Metadata etc can also be=20 >> transported using another mechanisms (media plane mechanisms). > > We're all agreed that media should be transmitted via a media plane, not = the signaling plane. =20 > I can add a caution that excessively large sensor data should not be sent= by value in the signaling plane. I don't think we need to go into specifics, and it's not only about media. = And, it's not only about size, but also frequency. I think we should simply say that the the MSD, eCall-Specific Control/Metad= ata, media and data can also be sent using a media plane mechanism, and tha= t each SDO needs to make a decision which mechanism to use, based on networ= k characteristics, expected data/frequency, etc etc. Regards, Christer From nobody Fri Dec 12 10:20:34 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474901A6F20 for ; Fri, 12 Dec 2014 10:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5OVWljVRBt9z for ; Fri, 12 Dec 2014 10:20:30 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D9B1A6ED8 for ; Fri, 12 Dec 2014 10:20:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1418408430; x=1449944430; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=6MmvFLfJ61iQDmbPB2wQIZ4d4bwziwIcnrK4mnQx3F8=; b=HPrdYEGYl9odWsM1L1b/AD+t/81MNpCjplsQhfmgu++WGn3BYE7tsFZ6 Z2JQEIydiAlg7O3BS96Dxp+20pC1UynLczQdJ9ggWiXQJsPyxtzFTqr+1 AWFMqyd9TrWFe8ZQ3UpdoEdxPoxf/Dp7S4G/vstGuKPvJckZtw5EDeS4U U=; X-IronPort-AV: E=McAfee;i="5600,1067,7650"; a="79957356" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Dec 2014 10:20:29 -0800 X-IronPort-AV: E=Sophos;i="5.07,565,1413270000"; d="scan'208";a="796176860" Received: from nasanexm01a.na.qualcomm.com ([10.85.0.81]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Dec 2014 10:20:13 -0800 Received: from [99.111.97.136] (10.80.80.8) by nasanexm01a.na.qualcomm.com (10.85.0.81) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 12 Dec 2014 10:20:11 -0800 Message-ID: In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Fri, 12 Dec 2014 10:20:08 -0800 To: Ivo Sedlacek , Hannes Tschofenig , Randall Gellens , Christer Holmberg , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01H.na.qualcomm.com (10.85.0.34) To nasanexm01a.na.qualcomm.com (10.85.0.81) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/PtHG1lw0XsHBn6e0-zhDa4KxQGE Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 18:20:31 -0000 At 8:46 AM +0000 12/12/14, Ivo Sedlacek wrote: > Hello, > >> I don't know whether it matters but I have doubts that a photo will be >> sent as a media stream. When you talk about a photo I guess you >> actually don't mean a photo but rather to enable a webcam. > > > draft-ietf-ecrit-ecall-01 states: > ------------------ > NG-eCall is expected to offer: > ... > o The ability for the PSAP to access vehicle components (e.g., an > onboard camera (such as rear facing or blind-spot cameras) for a > visual assessment of the crash site situation) > .... > ------------------ > > I can imagine that PSAP will be interested in both photos and video > media stream. > > Photos normally have higher resolution than video media stream. It's increasingly common that videos and still images have the same resolution (although in some cases the frames per second might be lower for higher resolution). However, this is all besides the point. The point of the discussion has since yesterday been agreed: I will add clarifying text to the eCall document to say that media is sent using a media plane and not the signaling plane. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Computers are useless. They can only give you answers. --Pablo Picasso (1881-1973) From nobody Fri Dec 12 11:43:51 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49AB1A870F for ; Fri, 12 Dec 2014 11:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7l1lC3Kj6Slm for ; Fri, 12 Dec 2014 11:43:47 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C991A870A for ; Fri, 12 Dec 2014 11:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1418413427; x=1449949427; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=kBp8R4ch8hiWixA1x6SBzSVc1f6D56XjtJBH3yfhN9U=; b=jBQsBt7NN1EGaexhXtL9TXgLPz52SS13R1P+A0Gr8eCvVFIuNN1KNRUw /XO8kdggrTFetm+4q3+gX3O+vmd7Gsph2QXqO264YmXboonNGxGjZY4jN ZaC6Gy7UtcGX69fGhLgSnMiUuHv5BtrQDbqsplRrIfytl+qMACpre5b0x Q=; X-IronPort-AV: E=McAfee;i="5600,1067,7650"; a="79961053" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Dec 2014 11:43:47 -0800 X-IronPort-AV: E=Sophos;i="5.07,565,1413270000"; d="scan'208";a="810849534" Received: from nasanexm01b.na.qualcomm.com ([10.85.0.82]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Dec 2014 11:43:47 -0800 Received: from [99.111.97.136] (10.80.80.8) by NASANEXM01B.na.qualcomm.com (10.85.0.82) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 12 Dec 2014 11:43:46 -0800 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D592841@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> <548AC088.5020003@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> <548AC47E.5020002@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D592601@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D592841@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Fri, 12 Dec 2014 11:43:44 -0800 To: Christer Holmberg , Hannes Tschofenig , Ivo Sedlacek , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To NASANEXM01B.na.qualcomm.com (10.85.0.82) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/OTR1XzRSoNBFn12UhoywbP6Zsiw Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 19:43:49 -0000 At 6:16 PM +0000 12/12/14, Christer Holmberg wrote: > Hi, > >>>> But, that is not how I read the draft, and I think Randall has >>>> also said that some clarification text will be added. >>>> >>>> Perfect. Issue solved! >>> >>> So, while the draft can use SIP INFO as an example, it need to make >>> it clear that the MSD, eCall-Specific Control/Metadata etc can also be >>> transported using another mechanisms (media plane mechanisms). >> >> We're all agreed that media should be transmitted via a media >> plane, not the signaling plane. >> I can add a caution that excessively large sensor data should not >> be sent by value in the signaling plane. > > I don't think we need to go into specifics, and it's not only about > media. And, it's not only about size, but also frequency. The frequency shouldn't be an issue. The eCall draft says that the IVS sends the MSD in the initial INVITE, and then on request of the PSAP. > I think we should simply say that the the MSD, eCall-Specific > Control/Metadata, media and data can also be sent using a media > plane mechanism, and that each SDO needs to make a decision which > mechanism to use, based on network characteristics, expected > data/frequency, etc etc. I don't see a need to get into hypotheticals. The eCall draft says how the MSD is sent using the ECRIT additional-data mechanism, which is the direction of ECRIT. If in the future there is a need to define a mechanism to send emergency call related data using a media stream, let's work on the problem at that time. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Democracy is a government where you can say what you think even if you don't think. --Winston Churchill From nobody Fri Dec 12 12:15:20 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9934C1A8952 for ; Fri, 12 Dec 2014 12:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 0BGAkowboVTj for ; Fri, 12 Dec 2014 12:15:11 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F16A1A1B8B for ; Fri, 12 Dec 2014 12:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=413; q=dns/txt; s=iport; t=1418415300; x=1419624900; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=rlYyle6RYFEwN3d6obetKFNZRwxJsrj05lAzfQeiW+A=; b=nKUpshZFcXyqVwLCl0XN3DXiDkQANVmv+GGOzabKWPeePspx6ujOM3ol 51yYCTm1/C/NFs47iagtFlFbBqGdL+ARK/jSzY9P+cZR3HZOvxgc1OFsI 0AQcQ83zw9Z/UpyODq6NeaO3gfXiR/oguca1CkWwM+/8R8Jch1OaVos+Y c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAB5Mi1StJV2b/2dsb2JhbABZgwZSXMV7hwMWAQEBAQF9hBM6UQE+QicEiD8NslGldwEBAQEBAQQBAQEBAQEBAQEVBJMPgRMFjX+DPoUxgQuCXo1OIoNsgjN+AQEB X-IronPort-AV: E=Sophos;i="5.07,566,1413244800"; d="scan'208";a="379856283" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 12 Dec 2014 20:14:59 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sBCKExE1028462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 12 Dec 2014 20:14:59 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.59]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 14:14:59 -0600 From: "Marc Linsner (mlinsner)" To: "ecrit@ietf.org" Thread-Topic: ETSI Liaison & draft-winterbottom-ecrit-priv-loc Thread-Index: AQHQFkhNm6P0gtYJlE2l46wGe8qvRg== Date: Fri, 12 Dec 2014 20:14:59 +0000 Message-ID: <021A9BCE-3E2A-4B06-9493-D3FD031B0B14@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.138.168] Content-Type: text/plain; charset="us-ascii" Content-ID: <04034F8696882B4AB58ACA60B3F93A21@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/GZIfqWGrTYF5Ktc8_6ndJRNpSeM Subject: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 20:15:12 -0000 All, Please review the liaison from ETSI and the draft from James and Laura (it'= s expired by still viewable). https://datatracker.ietf.org/liaison/1362/ Please respond to the list if you agree to create an ECRIT milestone to do = this work and you agree to accept the draft as a WG item to achieve the mil= estone. Please respond to the list by COB December 19, 2014. Thanks, Marc & Roger From nobody Fri Dec 12 12:44:55 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8C01A1DBC for ; Fri, 12 Dec 2014 12:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 gpOGXbL3jEHW for ; Fri, 12 Dec 2014 12:44:52 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26DC1A6F05 for ; Fri, 12 Dec 2014 12:44:52 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fb1so7957325pad.13 for ; Fri, 12 Dec 2014 12:44:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=RHC0wz7k0jR2/3gjQ7ylXh3QJOu03uZBxEQx1tenAEE=; b=lrSpIWECdmyIpvlf3513cpT7xG5ZUgqDtWw8moBgL+WVyKLY8dzdB4Iei0MCpd6RPj BEB49DQYW0hX0DWELRDgKEBbn5kDg6sD1HpmfnLqWA2ksBhFd7Cpwe9rS18WYl3RyO2R OS2HKMHKMhDWeKakX0gTiMWR9hvNN+AZTSv2lvuUjYCQ0Guxw6ibzjCDJE4c7fPQbGir XlHU8//LKM9t87mkyLntwdg73saAfj9ggxSBrT+U6jtsMXJvGVE+OJhv22ODiDH7T2CQ GmJmHB6l6HAdr26sh92yJE8H7KlyaceqXltza568SJAHGEc3FHfx6balB637HELC+jKf pY6A== X-Received: by 10.70.15.229 with SMTP id a5mr29949375pdd.79.1418417091960; Fri, 12 Dec 2014 12:44:51 -0800 (PST) Received: from [192.168.1.11] (124-168-29-88.dyn.iinet.net.au. [124.168.29.88]) by mx.google.com with ESMTPSA id wg7sm2315871pac.44.2014.12.12.12.44.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 12:44:51 -0800 (PST) References: <021A9BCE-3E2A-4B06-9493-D3FD031B0B14@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <021A9BCE-3E2A-4B06-9493-D3FD031B0B14@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6F7958BF-6508-42FD-ABE5-DC09B524C0CB@gmail.com> X-Mailer: iPhone Mail (11D201) From: James Winterbottom Date: Sat, 13 Dec 2014 07:44:46 +1100 To: "Marc Linsner (mlinsner)" Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/eI4eFosu2jlbIWpmaBq9xZmN2yw Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 20:44:54 -0000 I agree! Sent from my iPhone > On 13 Dec 2014, at 7:14 am, "Marc Linsner (mlinsner)" = wrote: >=20 > All, >=20 > Please review the liaison from ETSI and the draft from James and Laura (it= 's expired by still viewable). >=20 > https://datatracker.ietf.org/liaison/1362/ >=20 > Please respond to the list if you agree to create an ECRIT milestone to do= this work and you agree to accept the draft as a WG item to achieve the mil= estone. >=20 > Please respond to the list by COB December 19, 2014. >=20 > Thanks, >=20 > Marc & Roger >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Sat Dec 13 02:21:26 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C771A000E for ; Sat, 13 Dec 2014 02:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 wjv8k2HfYX4r for ; Sat, 13 Dec 2014 02:21:21 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A5BA1A0007 for ; Sat, 13 Dec 2014 02:21:20 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-3f-548c131f062c Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4D.E5.04076.F131C845; Sat, 13 Dec 2014 11:21:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0195.001; Sat, 13 Dec 2014 11:21:18 +0100 From: Christer Holmberg To: Randall Gellens , Hannes Tschofenig , Ivo Sedlacek , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AQHQFkP0uJeOHPzQbU2mpPDfH23onJyNS/lg Date: Sat, 13 Dec 2014 10:21:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5AA111@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> <548AC088.5020003@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> <548AC47E.5020002@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D592601@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D592841@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvja68cE+IwdnTfBaNi56yWizdeY/V 4tqjDmYHZo/Fm/azeSxZ8pPJY9HUZ4wBzFFcNimpOZllqUX6dglcGd1TfAraBSt2fjrL2sC4 jbeLkZNDQsBEYs6bflYIW0ziwr31bF2MXBxCAkcYJea9nwGWEBJYzCgxexJQAwcHm4CFRPc/ bZAaEYE1jBIf/s9kAqkRFkiXOH3yA1i9iECGxJXfX5lA6kUEjCT+PxIECbMIqEq8ffcarJxX wFdi1b5XzBC7rrJKdB5Zxw6S4AQ66PujJ2BFjEAHfT+1BsxmFhCXuPVkPhPEoQISS/acZ4aw RSVePv4H9YCSxKLbn6HqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrOQjJ2FpKWWUhaZiFp WcDIsopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMHIObvlttYPx4HPHQ4wCHIxKPLwbVneH CLEmlhVX5h5ilOZgURLnXXhuXrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRo5Z1jtaAl8G hx0u19RU1Gft2DC3Rba4Yu5fNtnWfayHu2ceeFu94TGHvvgCkfhVIeqXm0P+vNtU1qvypSXN 3X7Viu8/lda9cDuft+Ylv8rnjIW7Ju2xfqn1NW7ekjYfn/3lbtl/7QIa67vrChYfZj8/ie/6 0vdZ996lH8h5z7tCKObyLJ3IY0osxRmJhlrMRcWJANFg2/J9AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/HEOvy9A535_yit-2CSGvZUkixHQ Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 10:21:24 -0000 Hi, >>>> So, while the draft can use SIP INFO as an example, it need to=20 >>>> make it clear that the MSD, eCall-Specific Control/Metadata etc can=20 >>>> also be transported using another mechanisms (media plane mechanisms)= . >>> >>> We're all agreed that media should be transmitted via a media plane,=20 >>> not the signaling plane. >>> I can add a caution that excessively large sensor data should not be=20 >>> sent by value in the signaling plane. >> >> I don't think we need to go into specifics, and it's not only about=20 >> media. And, it's not only about size, but also frequency. > > The frequency shouldn't be an issue. The eCall draft says that the IVS s= ends the MSD in the initial INVITE, and then on request of the PSAP. And, how often can those "request of the PSAP" occur? Also, as the draft also indicates, the PSAP can request other kind of data = ("an enhanced MSD or an MSD plus additional sets of data") from the UA. And= , the more data that is available, the more often those requests may be sen= t by the PSAP. So, it should be possible to send those requests, and the associated data, = e.g. using a media plane mechanism. Obviously, any data that is needed in order to route the INVITE to the corr= ect PSAP in the first place needs to be sent in the INVITE. >> I think we should simply say that the the MSD, eCall-Specific=20 >> Control/Metadata, media and data can also be sent using a media plane=20 >> mechanism, and that each SDO needs to make a decision which mechanism=20 >> to use, based on network characteristics, expected data/frequency, etc=20 >> etc. > > I don't see a need to get into hypotheticals. The eCall draft says how t= he MSD is sent using the ECRIT=20 > additional-data mechanism, which is the direction of ECRIT. If in the fu= ture there is a need to define a=20 > mechanism to send emergency call related data using a media stream, let's= work on the problem at that time. Well, my comments are against the ecall draft, and are based on the potenti= al problems I see in the future, in the type of networks that the draft tar= gets. Regards, Christer From nobody Sat Dec 13 10:47:03 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F79C1A1B16 for ; Sat, 13 Dec 2014 10:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 qMja-_ix5Rgx for ; Sat, 13 Dec 2014 10:46:59 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC0A1A1B11 for ; Sat, 13 Dec 2014 10:46:59 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-b7-548c89a1cdda Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 40.8B.29772.1A98C845; Sat, 13 Dec 2014 19:46:57 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0195.001; Sat, 13 Dec 2014 19:46:57 +0100 From: Christer Holmberg To: "Marc Linsner (mlinsner)" , "ecrit@ietf.org" Thread-Topic: ETSI Liaison & draft-winterbottom-ecrit-priv-loc Thread-Index: AQHQFkhNm6P0gtYJlE2l46wGe8qvRpyN3X3A Date: Sat, 13 Dec 2014 18:46:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5ACDE9@ESESSMB209.ericsson.se> References: <021A9BCE-3E2A-4B06-9493-D3FD031B0B14@cisco.com> In-Reply-To: <021A9BCE-3E2A-4B06-9493-D3FD031B0B14@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje7Czp4Qg8XXZSwaFz1ltTh7+Tqj A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJWx98QHloL/bBWTrn5jbmC8ytrFyMkhIWAi cebyWWYIW0ziwr31bCC2kMARRokLNyK7GLmA7MWMErsnNzB1MXJwsAlYSHT/0wapEREIl5hw +BBYvbCArcSfZ/MZIeJ2Ene232OBsI0k3p18BVbDIqAq8XP7bSYQm1fAV+Lp041gI4UEbCRm 9KiChDmBxjyddBWslRHonO+n1oCVMwuIS9x6Mp8J4kwBiSV7zkOdLCrx8vE/qFeUJNYe3s4C Ua8jsWD3JzYIW1ti2cLXzBBrBSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjKLFqcVJuelG RnqpRZnJxcX5eXp5qSWbGIExcnDLb4MdjC+fOx5iFOBgVOLh3bC6O0SINbGsuDL3EKM0B4uS OO/Cc/OChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCmvFG7w5vwfnGNfvLGNe5zvDgNZy3r sL/3a4G69sO0I5Ur5Bwl5eYc9BBp3TLtre0Xh0KRGtUPpedNeS98NzmU+7XY0X3iZ/PFHx/t PSGXYdHZFhIqWvAozMjh0retdw6aVm2S5Jj1sK5iC8O78JdT/n3haokNm8zI5BQ/Pf548cnD +VbfD9xSYinOSDTUYi4qTgQA2kbuInICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/vxUFdvDRG8q_GX6CN255YTaPxes Subject: Re: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 18:47:01 -0000 Hi, I support creating a milestone, and to use the draft as base for the delive= ry. Regards, Christer -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner (mlin= sner) Sent: 12 December 2014 22:15 To: ecrit@ietf.org Subject: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc All, Please review the liaison from ETSI and the draft from James and Laura (it'= s expired by still viewable). https://datatracker.ietf.org/liaison/1362/ Please respond to the list if you agree to create an ECRIT milestone to do = this work and you agree to accept the draft as a WG item to achieve the mil= estone. Please respond to the list by COB December 19, 2014. Thanks, Marc & Roger _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Sat Dec 13 11:25:07 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891431A1A7B for ; Sat, 13 Dec 2014 11:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 bOUOx7d1Ivr5 for ; Sat, 13 Dec 2014 11:25:04 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9081A00C2 for ; Sat, 13 Dec 2014 11:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1418498704; x=1450034704; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=LLiBJtz8mm2Di2cCva3GEyunURE40PNTRfkrxByBm9o=; b=veHSKGNvf1wEIiNRoa2ksPeQirMezjng+F3G1al+slLQhdeIGktIsS+f d6Zpp9oZhFMSbAl+L/sHIR34fW5H9yYwvO3kdS/HKgCI/B51/lPsbDmMK WlJj/8oa18A1usl/+1nYTn5f0h6pAX8xfAzzk0NX8DQJcDTSkrpnLyZsw k=; X-IronPort-AV: E=McAfee;i="5600,1067,7651"; a="93263535" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2014 11:25:04 -0800 X-IronPort-AV: E=Sophos;i="5.07,572,1413270000"; d="scan'208";a="770878072" Received: from nasanexm01h.na.qualcomm.com ([10.85.0.34]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Dec 2014 11:25:04 -0800 Received: from [99.111.97.136] (10.80.80.8) by NASANEXM01H.na.qualcomm.com (10.85.0.34) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sat, 13 Dec 2014 11:25:03 -0800 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5AA111@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> <548AC088.5020003@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> <548AC47E.5020002@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D592601@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D592841@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AA111@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Sat, 13 Dec 2014 11:24:15 -0800 To: Christer Holmberg , Randall Gellens , Hannes Tschofenig , Ivo Sedlacek , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01H.na.qualcomm.com (10.85.0.34) To NASANEXM01H.na.qualcomm.com (10.85.0.34) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/HctpRAGQJ_3Bq4Ri0wMPU-v2ZDM Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 19:25:06 -0000 Hi Christer, At 10:21 AM +0000 12/13/14, Christer Holmberg wrote: > >>>> So, while the draft can use SIP INFO as an example, it need to >>>>> make it clear that the MSD, eCall-Specific Control/Metadata etc can >>>>> also be transported using another mechanisms (media plane mechanisms). >>>> >>>> We're all agreed that media should be transmitted via a media plane, >>>> not the signaling plane. >>>> I can add a caution that excessively large sensor data should not be >>>> sent by value in the signaling plane. >>> >>> I don't think we need to go into specifics, and it's not only about >>> media. And, it's not only about size, but also frequency. >> >> The frequency shouldn't be an issue. The eCall draft says that >> the IVS sends the MSD in the initial INVITE, and then on request >> of the PSAP. > > And, how often can those "request of the PSAP" occur? The frequency of request is obviously up to the PSAP, but the expectation is that these requests will be infrequent, especially over the duration of a call. > Also, as the draft also indicates, the PSAP can request other kind > of data ("an enhanced MSD or an MSD plus additional sets of data") > from the UA. And, the more data that is available, the more often > those requests may be sent by the PSAP. It's unlikely that PSAPs will be requesting multiple data objects or doing so frequently. More likely is that PSAPs may request an updated MSD if the call-taker thinks the vehicle state may have changed. If in the future a more comprehensive set of data is standardized and used in Europe, PSAPs may request that form, but again the expectation is that this might occur once at the start of the call, and possibly again if the call-taker thinks the vehicle state may have changed. > So, it should be possible to send those requests, and the > associated data, e.g. using a media plane mechanism. I don't see how this follows. > > Obviously, any data that is needed in order to route the INVITE to > the correct PSAP in the first place needs to be sent in the INVITE. > >>> I think we should simply say that the the MSD, eCall-Specific >>> Control/Metadata, media and data can also be sent using a media plane >>> mechanism, and that each SDO needs to make a decision which mechanism >>> to use, based on network characteristics, expected data/frequency, etc >>> etc. >> >> I don't see a need to get into hypotheticals. The eCall draft >> says how the MSD is sent using the ECRIT >> additional-data mechanism, which is the direction of ECRIT. If in >> the future there is a need to define a >> mechanism to send emergency call related data using a media >> stream, let's work on the problem at that time. > > Well, my comments are against the ecall draft, and are based on the > potential problems I see in the future, in the type of networks > that the draft targets. If we identify a need to transmit data associated with an emergency call over a media plane, this should be done as an extension to the additional-data draft and then incorporated by reference into all documents that use additional-data. Otherwise we risk creating multiple incompatible mechanisms. However, I don't see any such need at this time. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- yoin (yoh-EEN; Japanese; noun): experiential reverberation that continues to move one long after the initial external stimulus has ceased. From nobody Sat Dec 13 11:48:23 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54471A00B7 for ; Sat, 13 Dec 2014 11:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 EWCTcURdQMXG for ; Sat, 13 Dec 2014 11:48:19 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09EC51A1B36 for ; Sat, 13 Dec 2014 11:48:19 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id gq15so7779893lab.18 for ; Sat, 13 Dec 2014 11:48:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FRLs17LN2vj3UxL3ebxm9UYH/o+X/FukAYRpQZiB4Cw=; b=ikazzA1SF3B5LkopUmQ2aBQPJSOwUVIBDNp2xkn4ZY+kmz3oqMg1HZd2VcLM/rxsG/ WF6a5PTVme4mDRKXmI4tYuwucx5KrYvdklRewdF/6luZeaZI2LGT9HRQ6FivtU8EXLlY YcNBLiaJ2uRbuPtTZFEQjMDkNewRL4XHwWpVkxjHTKzK+yk8MZxJiKpPnEsYdg3XxbHI 2FOVhoo9n+vU1tRosPzlzejLM6+gJOq8+lEggynpWOCMpwLTT/NOU225704tJA3pRyQW p6IfWlAN5cJDS1Aa+Dlah3mv3D/wZ9CFQn2PK9054PmXVk6IXBUIhZN44QNzw/wdfv7j 2wHQ== MIME-Version: 1.0 X-Received: by 10.112.146.37 with SMTP id sz5mr21962144lbb.27.1418500097266; Sat, 13 Dec 2014 11:48:17 -0800 (PST) Received: by 10.114.182.212 with HTTP; Sat, 13 Dec 2014 11:48:17 -0800 (PST) In-Reply-To: <021A9BCE-3E2A-4B06-9493-D3FD031B0B14@cisco.com> References: <021A9BCE-3E2A-4B06-9493-D3FD031B0B14@cisco.com> Date: Sat, 13 Dec 2014 20:48:17 +0100 Message-ID: From: Laura Liess To: "Marc Linsner (mlinsner)" Content-Type: multipart/alternative; boundary=047d7b3a8b1e695bb1050a1e4aee Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/VO086vL6u8qVZBEQygIRTOuuyvs Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 19:48:20 -0000 --047d7b3a8b1e695bb1050a1e4aee Content-Type: text/plain; charset=ISO-8859-1 Hi, I agree to create a milestone and to accept the draft as a WG item. Thank you Laura 2014-12-12 21:14 GMT+01:00 Marc Linsner (mlinsner) : > > All, > > Please review the liaison from ETSI and the draft from James and Laura > (it's expired by still viewable). > > https://datatracker.ietf.org/liaison/1362/ > > Please respond to the list if you agree to create an ECRIT milestone to do > this work and you agree to accept the draft as a WG item to achieve the > milestone. > > Please respond to the list by COB December 19, 2014. > > Thanks, > > Marc & Roger > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --047d7b3a8b1e695bb1050a1e4aee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I agree to create a milestone and to= accept the draft as a WG item.

Thank you
Laura

2014-12-12 21= :14 GMT+01:00 Marc Linsner (mlinsner) <mlinsner@cisco.com>:=
All,

Please review the liaison from ETSI and the draft from James and Laura (it&= #39;s expired by still viewable).

ht= tps://datatracker.ietf.org/liaison/1362/

Please respond to the list if you agree to create an ECRIT milestone to do = this work and you agree to accept the draft as a WG item to achieve the mil= estone.

Please respond to the list by COB December 19, 2014.

Thanks,

Marc & Roger


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ecrit
--047d7b3a8b1e695bb1050a1e4aee-- From nobody Sat Dec 13 12:26:40 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0731A1B2F for ; Sat, 13 Dec 2014 12:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 HjwPzaN0TODa for ; Sat, 13 Dec 2014 12:26:37 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DEFE1A1A38 for ; Sat, 13 Dec 2014 12:26:35 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-b0-548ca0f902b6 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BA.04.04231.9F0AC845; Sat, 13 Dec 2014 21:26:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0195.001; Sat, 13 Dec 2014 21:26:33 +0100 From: Christer Holmberg To: Randall Gellens , Hannes Tschofenig , Ivo Sedlacek , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AQHQFwqBoTaueeWGlkq/NfOv7VYUu5yN82Mg Date: Sat, 13 Dec 2014 20:26:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5AE141@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> <548AC088.5020003@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> <548AC47E.5020002@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D592601@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D592841@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AA111@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje6vBT0hBs/uc1k0LnrKarF05z1W i2uPOpgdmD0Wb9rP5rFkyU8mj0VTnzEGMEdx2aSk5mSWpRbp2yVwZVzccoGloFm+4utJvgbG ExJdjBwcEgImEv1f07oYOYFMMYkL99azdTFycQgJHGGUuHHiCyOEs5hR4smOeUwgDWwCFhLd /7RB4iICaxglPvyfyQTSLSyQJrF43W1WEFtEIF3ia99mKNtI4s6PRcwgvSwCqhKbl/iBhHkF fCW+bl/MCjH/MJvEmwN3GUESnEAHnX34hAXEZgS66PupNWDzmQXEJW49mc8EcamAxJI955kh bFGJl4//sULYShKLbn+GqteRWLD7ExuErS2xbOFrZojFghInZz5hmcAoOgvJ2FlIWmYhaZmF pGUBI8sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMDIObjlt+4OxtWvHQ8xCnAwKvHwbljd HSLEmlhWXJl7iFGag0VJnHfRuXnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhh1KoTKs+4d znx8a87cu1O8iy2XR9vM4JZZFX5SfSaXdoBeVf7Hf4pLjzbLme827Pr56u+jJv9tQXnHdtbf LjtuGZUm5+7Pe/33r9KO2kksar2vxD47LjqXrzErNMP6R6x2znMTZfbNcRLHIpyZv1q/sn+V zJ/v2swwd+nUw1qql1k4f7y6PFuJpTgj0VCLuag4EQD48nERfQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/MKgWsbN2hNZlDvOGEibYOX_diIE Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 20:26:38 -0000 Hi, >>>>>> So, while the draft can use SIP INFO as an example, it need to >>>>>> make it clear that the MSD, eCall-Specific Control/Metadata etc=20 >>>>>> can also be transported using another mechanisms (media plane=20 >>>>>> mechanisms). >>>>> >>>>> We're all agreed that media should be transmitted via a media=20 >>>>> plane, not the signaling plane. >>>>> I can add a caution that excessively large sensor data should not=20 >>>>> be sent by value in the signaling plane. >>>> >>>> I don't think we need to go into specifics, and it's not only=20 >>>> about media. And, it's not only about size, but also frequency. >>> >>> The frequency shouldn't be an issue. The eCall draft says that the=20 >>> IVS sends the MSD in the initial INVITE, and then on request of the=20 >>> PSAP. >> >> And, how often can those "request of the PSAP" occur? > > The frequency of request is obviously up to the PSAP, but the expectation= is that=20 > these requests will be infrequent, especially over the duration of a call= . I think we should try to get some numbers, because it will make is easier t= o choose the appropriate mechanism. >> Also, as the draft also indicates, the PSAP can request other kind of=20 >> data ("an enhanced MSD or an MSD plus additional sets of data") from=20 >> the UA. And, the more data that is available, the more often those=20 >> requests may be sent by the PSAP. > > It's unlikely that PSAPs will be requesting multiple data objects or doin= g so=20 > frequently. More likely is that PSAPs may request an updated MSD if the = call-taker=20 > thinks the vehicle state may have changed. > > If in the future a more comprehensive set of data is standardized and use= d in=20 > Europe, PSAPs may request that form, but again the expectation is that th= is might=20 > occur once at the start of the call, and possibly again if the call-taker= thinks the=20 > vehicle state may have changed. I think it would be very useful to document those kind of things in the dra= ft. Because, we should choose the mechanism based on technical grounds. However, I assume eCall control blocks, which afaik are separate from the M= SD, could be sent more often (depending on how fancy the system is)? >> Obviously, any data that is needed in order to route the INVITE to=20 >> the correct PSAP in the first place needs to be sent in the INVITE. >> >>>> I think we should simply say that the the MSD, eCall-Specific =20 >>>> Control/Metadata, media and data can also be sent using a media=20 >>>> plane mechanism, and that each SDO needs to make a decision which=20 >>>> mechanism to use, based on network characteristics, expected=20 >>>> data/frequency, etc etc. >>> >>> I don't see a need to get into hypotheticals. The eCall draft says=20 >>> how the MSD is sent using the ECRIT additional-data mechanism, which=20 >>> is the direction of ECRIT. If in the future there is a need to=20 >>> define a mechanism to send emergency call related data using a media=20 >>> stream, let's work on the problem at that time. >> >> Well, my comments are against the ecall draft, and are based on the=20 >> potential problems I see in the future, in the type of networks that=20 >> the draft targets. > > If we identify a need to transmit data associated with an emergency call = over a=20 > media plane, this should be done as an extension to the additional-data d= raft and=20 > then incorporated by reference into all documents that use additional-dat= a. =20 > Otherwise we risk creating multiple incompatible mechanisms. However, I = don't see > any such need at this time. I thought we already agreed that there is data (pictures, sensor data etc) = for which a media plane mechanism is more appropriate, but that we may not = define such mechanism (as different SDOs may already have mechanisms they w= ant to re-use). Regards, Christer From nobody Sat Dec 13 13:20:17 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F471A1AA7 for ; Sat, 13 Dec 2014 13:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 UOhsxeDHBMip for ; Sat, 13 Dec 2014 13:20:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432A41A1A9A for ; Sat, 13 Dec 2014 13:20:12 -0800 (PST) Received: from [192.168.131.137] ([80.92.119.109]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LsOsW-1XonDY40Ou-011yC9; Sat, 13 Dec 2014 22:20:05 +0100 Message-ID: <548CAD83.5070601@gmx.net> Date: Sat, 13 Dec 2014 22:20:03 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Christer Holmberg , "Marc Linsner (mlinsner)" , "ecrit@ietf.org" References: <021A9BCE-3E2A-4B06-9493-D3FD031B0B14@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D5ACDE9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5ACDE9@ESESSMB209.ericsson.se> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="haMw6qKOJXQrQmXbDLSTub6QEQ2JD54OP" X-Provags-ID: V03:K0:ELapHwPTiqZ9E6DP6Y5/1dEIf0MhL+hND7hTSWVrvlQ1zlQmcrY d86stVdT2Qkg0Tm9PWxM1gVXzA+Y5yMTJ6aglZNFq/BPMjfEE2YlJNZnwvCGf/OeQSk0A7Z Z9eb6diSDNWaxSOs2iM2vwFIDjr6Ew8hAEXA+IAQPmkMTK/ljy8P8t28jVoS/7Li8QecAIs iLv7aIVuJt2hls/4rljQQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/IzsJF2qkvRKYC_Et7WuZAQ6efuc Subject: Re: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 21:20:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --haMw6qKOJXQrQmXbDLSTub6QEQ2JD54OP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I support it as well. On 12/13/2014 07:46 PM, Christer Holmberg wrote: > Hi, >=20 > I support creating a milestone, and to use the draft as base for the de= livery. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner (= mlinsner) > Sent: 12 December 2014 22:15 > To: ecrit@ietf.org > Subject: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc >=20 > All, >=20 > Please review the liaison from ETSI and the draft from James and Laura = (it's expired by still viewable). >=20 > https://datatracker.ietf.org/liaison/1362/ >=20 > Please respond to the list if you agree to create an ECRIT milestone to= do this work and you agree to accept the draft as a WG item to achieve t= he milestone. >=20 > Please respond to the list by COB December 19, 2014. >=20 > Thanks, >=20 > Marc & Roger >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 --haMw6qKOJXQrQmXbDLSTub6QEQ2JD54OP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUjK2DAAoJEGhJURNOOiAtnLYH+gLrb3n5A2vOR7vbzyq4LLyy rkh1Wq7R5SJ8sjsrDzzhnGCIz1TjpvbQTlK3jXYZbbJVXjiyZkrPLChyQllR0uiJ PqjIKIa7p0vOIO687hFHW9+t54/3EZ5TjL5jV2pXM0bIit92zarrbV9hkFbo1c6W 4/UUCVrowjerRPFw1TsOUVsDwG0HHmMk/W1zRiD+5Igo/C9F+Yo20EheCqNQEj3V KcxsLxf5SROAEjT98FrPg9V/pK9IJ3xOjhvIxVyQDmF64s7j3K4M9Irho1J5AmH4 JM7YTGH0p3dir8LjRkC7m9R9PWKbYtneSantsjoZP2K2J8DucGM9ljrRCGPwreU= =Dach -----END PGP SIGNATURE----- --haMw6qKOJXQrQmXbDLSTub6QEQ2JD54OP-- From nobody Sat Dec 13 15:46:08 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B176F1A00A7 for ; Sat, 13 Dec 2014 15:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 hgMNCJBSJqeL for ; Sat, 13 Dec 2014 15:46:05 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD381A0097 for ; Sat, 13 Dec 2014 15:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1418514365; x=1450050365; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=ZT/ZAFArTTsoyX+5OJm17oMaCisguFKRRzyc0VTgh2A=; b=kZq5N15T0w43ipjcuKzRlud1g795J5T5pj1vrMzcXZcAGh9EMWQ8pjFJ yLoNfto56v+Ru2tk9/fDeypq1qgu++B9EvO40BvAj7ax+dfEnfyXL6D6S 0OERImgNY2Jz5niLAjwz3qoTgWTj/1uoMszxRojlq7uvSztz+LjGQyTJi s=; X-IronPort-AV: E=McAfee;i="5600,1067,7651"; a="80750905" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 13 Dec 2014 15:46:04 -0800 X-IronPort-AV: E=Sophos;i="5.07,572,1413270000"; d="scan'208";a="31936455" Received: from nasanexm01d.na.qualcomm.com ([10.85.0.84]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Dec 2014 15:46:04 -0800 Received: from APSANEXR01B.ap.qualcomm.com (10.46.57.171) by NASANEXM01D.na.qualcomm.com (10.85.0.84) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sat, 13 Dec 2014 15:46:03 -0800 Received: from [99.111.97.136] (10.80.80.8) by APSANEXR01B.ap.qualcomm.com (10.46.57.171) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sat, 13 Dec 2014 15:45:42 -0800 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5AE141@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> <548AC088.5020003@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> <548AC47E.5020002@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D592601@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D592841@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AA111@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AE141@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Sat, 13 Dec 2014 15:34:40 -0800 To: Christer Holmberg , Hannes Tschofenig , Ivo Sedlacek , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01D.na.qualcomm.com (10.85.0.84) To APSANEXR01B.ap.qualcomm.com (10.46.57.171) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/_MoHsGdQZS-bL-ujQkvK719xxMM Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 23:46:07 -0000 At 8:26 PM +0000 12/13/14, Christer Holmberg wrote: > >>>>>> So, while the draft can use SIP INFO as an example, it need to >>>>>>> make it clear that the MSD, eCall-Specific Control/Metadata etc >>>>>>> can also be transported using another mechanisms (media plane >>>>>>> mechanisms). >>>>>> >>>>>> We're all agreed that media should be transmitted via a media >>>>>> plane, not the signaling plane. >>>>>> I can add a caution that excessively large sensor data should not >>>>>> be sent by value in the signaling plane. >>>>> >>>>> I don't think we need to go into specifics, and it's not only >>>>> about media. And, it's not only about size, but also frequency. >>>> >>>> The frequency shouldn't be an issue. The eCall draft says that the >>>> IVS sends the MSD in the initial INVITE, and then on request of the >>>> PSAP. >>> >>> And, how often can those "request of the PSAP" occur? >> >> The frequency of request is obviously up to the PSAP, but the >> expectation is that >> these requests will be infrequent, especially over the duration of a call. > > I think we should try to get some numbers, because it will make is > easier to choose the appropriate mechanism. We can't get real-world numbers until we have deployed systems. But we can make reasonable assumptions based on typical PSAP operational procedures. As an example, U.S. PSAPs can request updated location information whenever desired by the call-taker. In practice, this is not done often, and for many calls not at all. > >>> Also, as the draft also indicates, the PSAP can request other kind of >>> data ("an enhanced MSD or an MSD plus additional sets of data") from >>> the UA. And, the more data that is available, the more often those >>> requests may be sent by the PSAP. >> >> It's unlikely that PSAPs will be requesting multiple data objects >> or doing so >> frequently. More likely is that PSAPs may request an updated MSD >> if the call-taker >> thinks the vehicle state may have changed. >> >> If in the future a more comprehensive set of data is standardized >> and used in >> Europe, PSAPs may request that form, but again the expectation is >> that this might >> occur once at the start of the call, and possibly again if the >> call-taker thinks the >> vehicle state may have changed. > > I think it would be very useful to document those kind of things in > the draft. Because, we should choose the mechanism based on > technical grounds. > > However, I assume eCall control blocks, which afaik are separate > from the MSD, could be sent more often (depending on how fancy the > system is)? What sort of documentation would you like to see? eCall control blocks are primarily for the PSAP to request the vehicle to do something. The only mandatory action that the vehicle MUST support is to send an MSD. So it is not likely to be sent frequently. > >> Obviously, any data that is needed in order to route the INVITE to >>> the correct PSAP in the first place needs to be sent in the INVITE. >>> >>>>> I think we should simply say that the the MSD, eCall-Specific >>>>> Control/Metadata, media and data can also be sent using a media >>>>> plane mechanism, and that each SDO needs to make a decision which >>>>> mechanism to use, based on network characteristics, expected >>>>> data/frequency, etc etc. >>>> >>>> I don't see a need to get into hypotheticals. The eCall draft says >>>> how the MSD is sent using the ECRIT additional-data mechanism, which >>>> is the direction of ECRIT. If in the future there is a need to >>>> define a mechanism to send emergency call related data using a media >>>> stream, let's work on the problem at that time. >>> >>> Well, my comments are against the ecall draft, and are based on the >>> potential problems I see in the future, in the type of networks that > >> the draft targets. >> >> If we identify a need to transmit data associated with an >> emergency call over a >> media plane, this should be done as an extension to the >> additional-data draft and >> then incorporated by reference into all documents that use additional-data. >> Otherwise we risk creating multiple incompatible mechanisms. >> However, I don't see > any such need at this time. > > I thought we already agreed that there is data (pictures, sensor > data etc) for which a media plane mechanism is more appropriate, > but that we may not define such mechanism (as different SDOs may > already have mechanisms they want to re-use). Pictures (or video clips) are media and should be sent as media. It would be better to have a common mechanism for transmitting static media, just as we have a common mechanism for streaming media, but the eCall draft is not the place to define such a mechanism. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Majority: That quality that distinguishes a crime from a law. From nobody Sun Dec 14 12:24:25 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829FB1A0177 for ; Sun, 14 Dec 2014 12:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Z4Ljwvp7DSZQ for ; Sun, 14 Dec 2014 12:24:20 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EFEC1A0172 for ; Sun, 14 Dec 2014 12:24:20 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-a5-548df1f1c660 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A0.9E.29772.1F1FD845; Sun, 14 Dec 2014 21:24:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Sun, 14 Dec 2014 21:24:17 +0100 From: Christer Holmberg To: Randall Gellens , Hannes Tschofenig , Ivo Sedlacek , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AQHQFy73kq8+Wi9JUE6iI/BC1jMGjZyPhLww Date: Sun, 14 Dec 2014 20:24:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5B4B9C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> <548AC088.5020003@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> <548AC47E.5020002@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D592601@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D592841@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AA111@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AE141@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje6nj70hBm3TuC0aFz1ltVi68x6r xbVHHcwOzB6LN+1n81iy5CeTx6KpzxgDmKO4bFJSczLLUov07RK4Ml41/2UseKpb8fjHd5YG xtkqXYycHBICJhIT55xnhbDFJC7cW8/WxcjFISRwhFFi2rr9zBDOYkaJkzu/AVVxcLAJWEh0 /9MGiYsIrGGU+PB/JhNIt7BAusTpkx/AJokIZEhc+f2VCcI2kljyZD8LiM0ioCqx9O8aZhCb V8BXYtKmCVDbNrJLXD68mRlkASfQSbdX+4DUMAJd9P3UGrA5zALiEreezGeCuFRAYsme88wQ tqjEy8f/oD5Qklh7eDsLRL2OxILdn9ggbG2JZQtfQ+0VlDg58wnLBEbRWUjGzkLSMgtJyywk LQsYWVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbPwS2/DXYwvnzueIhRgINRiYd3Y25v iBBrYllxZe4hRmkOFiVx3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYBRk86s7lRm5 RO6Hvd/lSrs/McJ8t+wDCqo282ww23xtzdKD/z5znJ4ikqH8S/KPW61N/PrwfAnZrftEDh6L SAj9aiv5syhW2tTO1Ln4waE5PHxRBVdmFh/JvvjE8KXqXZVzN3JSv6xc4niOT1CHL0vx3LND 6W8W/97LE2Gg0aAt/MnTSfGQvRJLcUaioRZzUXEiAOpegEF/AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/cjM-YzWOH2mZV8_VRNThfwEKEMo Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 20:24:22 -0000 Hi, >>>>>>>> So, while the draft can use SIP INFO as an example, it need to >>>>>>>> make it clear that the MSD, eCall-Specific Control/Metadata=20 >>>>>>>> etc can also be transported using another mechanisms (media=20 >>>>>>>> plane mechanisms). >>>>>>> >>>>>>> We're all agreed that media should be transmitted via a media =20 >>>>>>> plane, not the signaling plane. >>>>>>> I can add a caution that excessively large sensor data should=20 >>>>>>> not be sent by value in the signaling plane. >>>>>> >>>>>> I don't think we need to go into specifics, and it's not only =20 >>>>>> about media. And, it's not only about size, but also frequency. >>>>> >>>>> The frequency shouldn't be an issue. The eCall draft says that=20 >>>>> the IVS sends the MSD in the initial INVITE, and then on request=20 >>>>> of the PSAP. >>>> >>>> And, how often can those "request of the PSAP" occur? >>> >>> The frequency of request is obviously up to the PSAP, but the=20 >>> expectation is that these requests will be infrequent, especially=20 >>> over the duration of a call. >> >> I think we should try to get some numbers, because it will make is=20 >> easier to choose the appropriate mechanism. > > We can't get real-world numbers until we have deployed systems. But we c= an make reasonable=20 > assumptions based on typical PSAP operational procedures. As an example,= U.S. PSAPs can request=20 > updated location information whenever desired by the call-taker. In prac= tice, this is not done often,=20 > and for many calls not at all. Well, that is good background information. The questions are: 1) Can we expect similar behaviour for eCall? 2) Can we expect future enhancements of MSD to trigger more frequent MSD re= quests, and/or the size of the MSD to grow? >>>> Also, as the draft also indicates, the PSAP can request other kind=20 >>>> of data ("an enhanced MSD or an MSD plus additional sets of data")=20 >>>> from the UA. And, the more data that is available, the more often=20 >>>> those requests may be sent by the PSAP. >>> >>> It's unlikely that PSAPs will be requesting multiple data objects or=20 >>> doing so frequently. More likely is that PSAPs may request an=20 >>> updated MSD if the call-taker thinks the vehicle state may have=20 >>> changed. >>> >>> If in the future a more comprehensive set of data is standardized=20 >>> and used in Europe, PSAPs may request that form, but again the=20 >>> expectation is that this might occur once at the start of the call,=20 >>> and possibly again if the call-taker thinks the vehicle state may=20 >>> have changed. >> >> I think it would be very useful to document those kind of things in=20 >> the draft. Because, we should choose the mechanism based on technical=20 >> grounds. >> >> However, I assume eCall control blocks, which afaik are separate from=20 >> the MSD, could be sent more often (depending on how fancy the system=20 >> is)? > > What sort of documentation would you like to see? Anything which can help in choosing (and justifying the choice of) transpor= t mechanisms. > eCall control blocks are primarily for the PSAP to request the vehicle to= do something. =20 > The only mandatory action that the vehicle MUST support is to send an MSD= . So it is not likely to be sent frequently. The "capabilities" element is sent from the IVS to the PSAP. And, looking forward, the more fancy systems get, the more frequent they mi= ght be.=20 So, the control blocks can be a candidate for a media plane mechanism. I do= n't really think it's "additional data" anyway, it's more of a two-way prot= ocol. >>>>> Obviously, any data that is needed in order to route the INVITE=20 >>>>> to the correct PSAP in the first place needs to be sent in the INVIT= E. >>>> >>>>>> I think we should simply say that the the MSD, eCall-Specific =20 >>>>>> Control/Metadata, media and data can also be sent using a media =20 >>>>>> plane mechanism, and that each SDO needs to make a decision which = =20 >>>>>> mechanism to use, based on network characteristics, expected =20 >>>>>> data/frequency, etc etc. >>>>> >>>>> I don't see a need to get into hypotheticals. The eCall draft=20 >>>>> says how the MSD is sent using the ECRIT additional-data=20 >>>>> mechanism, which is the direction of ECRIT. If in the future=20 >>>>> there is a need to define a mechanism to send emergency call=20 >>>>> related data using a media stream, let's work on the problem at that= time. >>>> >>>> Well, my comments are against the ecall draft, and are based on=20 >>>> the potential problems I see in the future, in the type of networks=20 >>>> that the draft targets. >>>> >>>> If we identify a need to transmit data associated with an emergency=20 >>>> call over a media plane, this should be done as an extension to the=20 >>>> additional-data draft and then incorporated by reference into all=20 >>> documents that use additional-data. >>> Otherwise we risk creating multiple incompatible mechanisms.=20 >>> However, I don't see > any such need at this time. >> >> I thought we already agreed that there is data (pictures, sensor data=20 >> etc) for which a media plane mechanism is more appropriate, but that=20 >> we may not define such mechanism (as different SDOs may already have=20 >> mechanisms they want to re-use). > > Pictures (or video clips) are media and should be sent as media. > > It would be better to have a common mechanism for transmitting static med= ia, just as we have a=20 > common mechanism for streaming media, but the eCall draft is not the plac= e to define such a mechanism. As long as we clearly describe that such mechanisms can be used. Regards, Christer From nobody Sun Dec 14 16:04:21 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE7C1A0204 for ; Sun, 14 Dec 2014 16:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 shZk6VGDaDZb for ; Sun, 14 Dec 2014 16:04:17 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73FC41A00F8 for ; Sun, 14 Dec 2014 16:04:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1418601857; x=1450137857; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=VBSTh3E+BzvgfRxJ4y1nC2UHdYA/iC0289CGUFGWHjI=; b=S2qZAb2qdNfwCYk9X98a8grTVW/BLs6Bsmbibr98vLJNnO/jIaJXqyhg Bv/RZsWk69PvTJ4Qpqm57rqRJ2U+HD1MyckmQxbXV5nfI1Z9jYvlwvtrL ax+30XQQeBZaWHVG2Nhnn3RMMkpT7M7LuDK+aYP50oT7nD3ZJUyuWCqud E=; X-IronPort-AV: E=McAfee;i="5600,1067,7652"; a="93356325" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2014 16:04:15 -0800 X-IronPort-AV: E=Sophos;i="5.07,577,1413270000"; d="scan'208";a="797377448" Received: from nasanexm01d.na.qualcomm.com ([10.85.0.84]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Dec 2014 16:04:16 -0800 Received: from [99.111.97.136] (10.80.80.8) by NASANEXM01D.na.qualcomm.com (10.85.0.84) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sun, 14 Dec 2014 16:04:14 -0800 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5B4B9C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> <548AC088.5020003@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> <548AC47E.5020002@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D592601@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D592841@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AA111@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AE141@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5B4B9C@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Sun, 14 Dec 2014 15:51:41 -0800 To: Christer Holmberg , Hannes Tschofenig , Ivo Sedlacek , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To NASANEXM01D.na.qualcomm.com (10.85.0.84) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/stqZr1TbJLoYdym8Ab8shrHeFOI Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 00:04:20 -0000 At 8:24 PM +0000 12/14/14, Christer Holmberg wrote: > Hi, > >>>>>>>>> So, while the draft can use SIP INFO as an example, it need to >>>>>>>>> make it clear that the MSD, eCall-Specific Control/Metadata >>>>>>>>> etc can also be transported using another mechanisms (media >>>>>>>>> plane mechanisms). >>>>>>>> >>>>>>>> We're all agreed that media should be transmitted via a media >>>>>>>> plane, not the signaling plane. >>>>>>>> I can add a caution that excessively large sensor data should >>>>>>>> not be sent by value in the signaling plane. >>>>>>> >>>>>>> I don't think we need to go into specifics, and it's not only >>>>>>> about media. And, it's not only about size, but also frequency. >>>>>> >>>>>> The frequency shouldn't be an issue. The eCall draft says that >>>>>> the IVS sends the MSD in the initial INVITE, and then on request >>>>>> of the PSAP. >>>>> >>>>> And, how often can those "request of the PSAP" occur? >>>> >>>> The frequency of request is obviously up to the PSAP, but the >>>> expectation is that these requests will be infrequent, especially >>>> over the duration of a call. >>> >>> I think we should try to get some numbers, because it will make is >>> easier to choose the appropriate mechanism. >> >> We can't get real-world numbers until we have deployed systems. >> But we can make reasonable >> assumptions based on typical PSAP operational procedures. As an >> example, U.S. PSAPs can request >> updated location information whenever desired by the call-taker. >> In practice, this is not done often, >> and for many calls not at all. > > Well, that is good background information. > > The questions are: > > 1) Can we expect similar behaviour for eCall? I believe so. > > 2) Can we expect future enhancements of MSD to trigger more > frequent MSD requests, and/or the size of the MSD to grow? For the short and medium term, probably not. I think that longer term, a larger MSD is more likely, but still should be comparatively small, not even close to the size of a phone image. > > >>>>> Also, as the draft also indicates, the PSAP can request other kind >>>>> of data ("an enhanced MSD or an MSD plus additional sets of data") >>>>> from the UA. And, the more data that is available, the more often >>>>> those requests may be sent by the PSAP. >>>> >>>> It's unlikely that PSAPs will be requesting multiple data objects or >>>> doing so frequently. More likely is that PSAPs may request an >>>> updated MSD if the call-taker thinks the vehicle state may have >>>> changed. >>>> >>>> If in the future a more comprehensive set of data is standardized >>>> and used in Europe, PSAPs may request that form, but again the >>>> expectation is that this might occur once at the start of the call, >>>> and possibly again if the call-taker thinks the vehicle state may >>>> have changed. >>> >>> I think it would be very useful to document those kind of things in >>> the draft. Because, we should choose the mechanism based on technical >>> grounds. >>> >>> However, I assume eCall control blocks, which afaik are separate from >>> the MSD, could be sent more often (depending on how fancy the system >>> is)? >> >> What sort of documentation would you like to see? > > Anything which can help in choosing (and justifying the choice of) > transport mechanisms. > >> eCall control blocks are primarily for the PSAP to request the >> vehicle to do something. >> The only mandatory action that the vehicle MUST support is to send >> an MSD. So it is not likely to be sent frequently. > > The "capabilities" element is sent from the IVS to the PSAP. Yes, but only once at the start, and the size should remain quite small, since only the supported capabilities are included. > And, looking forward, the more fancy systems get, the more frequent > they might be. > > So, the control blocks can be a candidate for a media plane > mechanism. I don't really think it's "additional data" anyway, it's > more of a two-way protocol. I think we are still very much in the additional data realm. Sending crash data once or twice even thrice, and sending a request for crash data once or twice doesn't change the scale enough to warrant treatment as media. > >>>>>> Obviously, any data that is needed in order to route the INVITE >>>>>> to the correct PSAP in the first place needs to be sent in the INVITE. >>>>> >>>>>>> I think we should simply say that the the MSD, eCall-Specific >>>>>>> Control/Metadata, media and data can also be sent using a media >>>>>>> plane mechanism, and that each SDO needs to make a decision which >>>>>>> mechanism to use, based on network characteristics, expected >>>>>>> data/frequency, etc etc. >>>>>> >>>>>> I don't see a need to get into hypotheticals. The eCall draft >>>>>> says how the MSD is sent using the ECRIT additional-data >>>>>> mechanism, which is the direction of ECRIT. If in the future >>>>>> there is a need to define a mechanism to send emergency call >>>>>> related data using a media stream, let's work on the problem >>>>>> at that time. >>>>> >>>>> Well, my comments are against the ecall draft, and are based on >>>>> the potential problems I see in the future, in the type of networks >>>>> that the draft targets. >>>>> >>>>> If we identify a need to transmit data associated with an emergency >>>>> call over a media plane, this should be done as an extension to the >>>>> additional-data draft and then incorporated by reference into all >>>> documents that use additional-data. >>>> Otherwise we risk creating multiple incompatible mechanisms. >>>> However, I don't see > any such need at this time. >>> >>> I thought we already agreed that there is data (pictures, sensor data >>> etc) for which a media plane mechanism is more appropriate, but that >>> we may not define such mechanism (as different SDOs may already have >>> mechanisms they want to re-use). >> >> Pictures (or video clips) are media and should be sent as media. >> >> It would be better to have a common mechanism for transmitting >> static media, just as we have a >> common mechanism for streaming media, but the eCall draft is not >> the place to define such a mechanism. > > As long as we clearly describe that such mechanisms can be used. I'm happy to add text to clarify that the draft relies on more general mechanisms for media transmission, and I can also clarify that the MSD and the metadata are small, expected to be sent infrequently, and expected to remain small, and that if a large amount of data or high frequency updates are desired in the future, alternative transport, such as media transport mechanisms, should be considered. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Time is nature's way of making sure that everything doesn't happen on schedule. From nobody Mon Dec 15 01:52:13 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E856B1A1AC7 for ; Mon, 15 Dec 2014 01:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 cftYpiEhaLtg for ; Mon, 15 Dec 2014 01:52:10 -0800 (PST) Received: from mx2.nominet.org.uk (mail.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 844521A1A9B for ; Mon, 15 Dec 2014 01:52:09 -0800 (PST) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=TIo309fKRuDaNT9K9uOwESaRdEaJB5gWwA2Q8wFG4Lx5MouzUf66ke1h EwXBrK8PFa+7ENJQI+u+PLX/VnM5CO34LsU1bYAJYNApUIiOpDtS4/6y4 vURZMbEFGWgURo4WMrQ9YYmc1Pigplrlh/FVgT4mEOUcL2jzh17PtAE1v O35rQE3yEkApiDA0M+a/R3lnWuwXbCYR1R6TCaMa+vxo/6/5/vj1UvMuM HdDfJqcPvHa/BrwQGutUG6J13Abn2; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1418637130; x=1450173130; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0chTf6dCGH4G8F8zNeUa00lykE9RV/YNehg/zUbLbGs=; b=ShwNyMYpuPn6SxJSiiIjEwNwCKqUHpX+wutcwpKJ9m3bmlP/wJaPWmTo OZl5XhUujkPEG1zlzCxAy+iEbcoRjQhDJBPfCG/5Q5NAx6XvS37bcHA3K AZYDqVUeCLEY/eQYyHAoLIqSruWl24e56sXqOTVeYvetAe2PQ5O1dKT49 7345JUMUxpcOS7kruC4YbuHCr0/3Cf/ibVu8RtvkYEzVowlfkL4fgHxTc WR9RjJtrawKQwFgINszKgbAD55i/h; X-IronPort-AV: E=Sophos;i="5.07,578,1413241200"; d="scan'208";a="14588189" X-IPAS-Result: AoIFAJiujlTV+MWR/2dsb2JhbABagmQigSoEy08CgRgWAQEBAQEBfIQMAQEBAQIBUysLAgEIGC4yJQIEE4gYAwkJA9IKAQEIAQEBAQEBAQEajUqBdTqDFoETBYwsm3wig2xugUV+AQEB Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 15 Dec 2014 09:52:08 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%16]) with mapi id 14.03.0181.006; Mon, 15 Dec 2014 09:52:07 +0000 From: Ray Bellis To: "ecrit@ietf.org" Thread-Topic: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc Thread-Index: AQHQFkhNm6P0gtYJlE2l46wGe8qvRpyN3X3AgAArEICAAmR1gA== Date: Mon, 15 Dec 2014 09:52:07 +0000 Message-ID: References: <021A9BCE-3E2A-4B06-9493-D3FD031B0B14@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D5ACDE9@ESESSMB209.ericsson.se> <548CAD83.5070601@gmx.net> In-Reply-To: <548CAD83.5070601@gmx.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="Windows-1252" Content-ID: <90823E7CE2588443A3E6308F639C29AE@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/v2ko3D1fUY7S_pFAQ5qDDIsgqJA Subject: Re: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 09:52:13 -0000 > On 13 Dec 2014, at 21:20, Hannes Tschofenig w= rote: >=20 > I support it as well. >=20 Me too. Ray From nobody Mon Dec 15 04:29:11 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BAB1A1AEA for ; Mon, 15 Dec 2014 04:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 pM5VkfcPgMaS for ; Mon, 15 Dec 2014 04:29:08 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D580D1A1A93 for ; Mon, 15 Dec 2014 04:29:07 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-c2-548ed411f011 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 32.A6.29772.114DE845; Mon, 15 Dec 2014 13:29:06 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.90]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 13:29:05 +0100 From: Ivo Sedlacek To: Randall Gellens , Christer Holmberg , Hannes Tschofenig , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AQHQF/qs/eKdISxi0E6GZx28JhtBZ5yQlGWg Date: Mon, 15 Dec 2014 12:29:04 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127C9C08@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> <548AC088.5020003@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> <548AC47E.5020002@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D592601@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D592841@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AA111@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AE141@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5B4B9C@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja7Qlb4Qg1kNzBaNi56yWizdeY/V 4tqjDmYHZo/Fm/azeSxZ8pPJY9HUZ4wBzFFcNimpOZllqUX6dglcGf2zOAquc1W0HN7K2MDY zdHFyMkhIWAisXjFHlYIW0ziwr31bF2MXBxCAkcYJR6c/MQO4SxmlDjRdoAZpIpNQE9i4pYj rCAJEYFtjBLHHmxiAkkIC6RJLF53G2yUiEC6xNe+zVC2kcSuppVgNSwCqhJtZ1aDDeIV8JW4 tPM7I4gtJDCfQ2LfuXwQmxPopE1r/rKD2IwCshJX//SC1TALiEvcejKfCeJUAYkle84zQ9ii Ei8f/4N6QVGi/WkDVL2OxILdn9ggbG2JZQtfQ+0VlDg58wnLBEbRWUjGzkLSMgtJyywkLQsY WVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbPwS2/DXYwvnzueIhRgINRiYe3QKwvRIg1 say4MvcQozQHi5I478Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MBpHWi/8/jDwe/zf ykNqu8uTv7XOvj+Xi2kux51P1yY0XGa4dUy8ZsOpx5teZz8wzA53WxaWvG5z43qd2jJelmVn RDs0C5Snl5ieK8g7mXj21PppoaxHTikdMf09wYB1R+EG7to3/4IblJLLStMUZHZJ5bfOLm48 elMlP8va+ta7vBlWqoH3HyqxFGckGmoxFxUnAgCu2NlUfwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/aTSj-AQWK_icTsd4v75OVgMQY84 Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 12:29:10 -0000 Hello, > I think we are still very much in the additional data realm. Sending=20 > crash data once or twice even thrice, and sending a request for crash=20 > data once or twice doesn't change the scale enough to warrant=20 > treatment as media. the draft states: -------------- NG-eCall is expected to offer: o The ability to carry more data (e.g., an enhanced MSD or an MSD plus additional sets of data) o The ability to handle video o The ability to handle text o The ability for the PSAP to access vehicle components (e.g., an onboard camera (such as rear facing or blind-spot cameras) for a visual assessment of the crash site situation) o The ability for the PSAP to request the vehicle to take actions (e.g., sound the horn, disable the ignition, lock/unlock doors) o The ability to avoid audio muting of the voice channel (because the MSD is not transferred using an in-band modem) -------------- If PSAP uses each of the above in a call, then it will be at least 2x 6 INF= O requests in the call. Moreover, PSAP may wish to use some of those several times (e.g. switching = the video from rear facing camera to blind-spot camera and back). So, INFOs can cause a significant load on the SIP proxies handling the emer= gency call. Kind regards Ivo Sedlacek From nobody Mon Dec 15 05:52:58 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35061A6FD8 for ; Mon, 15 Dec 2014 05:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 8zZRhFG4p0bF for ; Mon, 15 Dec 2014 05:52:53 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.168]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF5A1A6FCB for ; Mon, 15 Dec 2014 05:52:52 -0800 (PST) Received: from [85.158.137.67] by server-8.bemta-3.messagelabs.com id D7/A6-28296-3B7EE845; Mon, 15 Dec 2014 13:52:51 +0000 X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-5.tower-139.messagelabs.com!1418651551!35199047!21 X-Originating-IP: [206.47.0.168] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2266 invoked from network); 15 Dec 2014 13:52:50 -0000 Received: from tls.exchange.bell.ca (HELO TLS.Exchange.bell.ca) (206.47.0.168) by server-5.tower-139.messagelabs.com with RC4-SHA encrypted SMTP; 15 Dec 2014 13:52:50 -0000 Received: from hub03-wyn.bell.corp.bce.ca (142.182.199.49) by dm1c8g.exchange1.bell.ca (198.235.102.109) with Microsoft SMTP Server id 8.3.342.0; Mon, 15 Dec 2014 08:52:21 -0500 Received: from MBX02.bell.corp.bce.ca ([142.182.199.11]) by hub03-wyn.bell.corp.bce.ca ([142.182.199.49]) with mapi; Mon, 15 Dec 2014 08:52:22 -0500 From: "Caron, Guy (A162859)" To: "ecrit@ietf.org" Date: Mon, 15 Dec 2014 08:52:21 -0500 Thread-Topic: ETSI Liaison & draft-winterbottom-ecrit-priv-loc Thread-Index: AQHQFkhNm6P0gtYJlE2l46wGe8qvRpyQr7Ng Message-ID: <0FEAC1C09868B34A982F4FB40254B37C295BCF577F@MBX02.bell.corp.bce.ca> References: <021A9BCE-3E2A-4B06-9493-D3FD031B0B14@cisco.com> In-Reply-To: <021A9BCE-3E2A-4B06-9493-D3FD031B0B14@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/_A4G7_uiqQjXATfDXvw5VdxDXdk Subject: Re: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 13:52:56 -0000 Hi, I support the creation of a new milestone and agree to accept draft-winterb= ottom-ecrit-priv-loc-04 as a WG item. Guy -----Message d'origine----- De=A0: Ecrit [mailto:ecrit-bounces@ietf.org] De la part de Marc Linsner (ml= insner) Envoy=E9=A0: 12 d=E9cembre 2014 15:15 =C0=A0: ecrit@ietf.org Objet=A0: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc All, Please review the liaison from ETSI and the draft from James and Laura (it'= s expired by still viewable). https://datatracker.ietf.org/liaison/1362/ Please respond to the list if you agree to create an ECRIT milestone to do = this work and you agree to accept the draft as a WG item to achieve the mil= estone. Please respond to the list by COB December 19, 2014. Thanks, Marc & Roger _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Mon Dec 15 07:44:06 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB211A6FFD for ; Mon, 15 Dec 2014 07:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 ClZjHIeAel0t for ; Mon, 15 Dec 2014 07:44:03 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E821A1BE0 for ; Mon, 15 Dec 2014 07:44:02 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-90-548f01c0ebbb Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 26.52.29772.0C10F845; Mon, 15 Dec 2014 16:44:00 +0100 (CET) Received: from ESESSMB208.ericsson.se ([169.254.8.173]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 16:43:59 +0100 From: Christer Holmberg To: Randall Gellens , Hannes Tschofenig , Ivo Sedlacek , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? Thread-Index: AQHQF/qsq4b3eq77RU2fgsNCG1Cef5yQySJA Date: Mon, 15 Dec 2014 15:43:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5D1284@ESESSMB208.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D58E68B@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127BC2B8@ESESSMB301.ericsson.se> <548AA48E.8090601@gmx.net> <39B5E4D390E9BD4890E2B31079006101127BC391@ESESSMB301.ericsson.se> <548AAE01.10201@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D591394@ESESSMB209.ericsson.se> <548AC088.5020003@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D5914F3@ESESSMB209.ericsson.se> <548AC47E.5020002@gmx.net> <7594FB04B1934943A5C02806D1A2204B1D592601@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D592841@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AA111@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5AE141@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5B4B9C@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje4Bxv4Qg0Wr5SwaFz1ltVi68x6r xbVHHcwOzB6LN+1n81iy5CeTx6KpzxgDmKO4bFJSczLLUov07RK4MrqOSxbs4q2Y3PqHrYHx IlcXIyeHhICJxPXV59ghbDGJC/fWs3UxcnEICRxhlNjy6xkzhLOEUeLz55+sXYwcHGwCFhLd /7RB4iICaxglPvyfyQTSLSyQJrF43W1WEFtEIF3ia99msHoRASOJH49DQcIsAqoSN++/YgOx eQV8JRa+mQZmCwnM55DYdy4fxOYEOmjTmr9gBzECHfT91Bqw8cwC4hK3nsxngjhUQGLJnvPM ELaoxMvH/1ghbCWJHxsusUDU60gs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0 zELSsoCRZRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYOQc3PLbYAfjy+eOhxgFOBiVeHgL xPpChFgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD4zaJ/THs sW6Pr4l/mRPTybJVXzbptIW5iM0jG+n+pXG7BZ46zs+UZD+1Su8E8/9OTbszaydIRfyIOffy xhat7H/x3tHON+WuT7q0OTzs4hmfeIufBSwT/wQyie48dP5fSpzCZafA9swVixfppy+/Lrhp xkM+nZpc1QVeN85PPb33m/LfjJRqMyWW4oxEQy3mouJEAK1M80l9AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/RMSr-BWT8rLaIYxrCmYxX5s4oHg Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 15:44:04 -0000 Hi, >> The "capabilities" element is sent from the IVS to the PSAP. > > Yes, but only once at the start, and the size should remain quite=20 > small, since only the supported capabilities are included. > >> And, looking forward, the more fancy systems get, the more frequent=20 >> they might be. >> >> So, the control blocks can be a candidate for a media plane=20 >> mechanism. I don't really think it's "additional data" anyway, it's=20 >> more of a two-way protocol. > > I think we are still very much in the additional data realm. =20 > Sending crash data once or twice even thrice, and sending a request for c= rash=20 > data once or twice doesn't change the scale enough to warrant=20 > treatment as media. See below. ... > I'm happy to add text to clarify that the draft relies on more=20 > general mechanisms for media transmission, and I can also clarify=20 > that the MSD and the metadata are small, expected to be sent=20 > infrequently, and expected to remain small, and that if a large=20 > amount of data or high frequency updates are desired in the future,=20 > alternative transport, such as media transport mechanisms, should be=20 > considered. But, if someone want to deploy a "future proof" solution, why not allow eve= rything to be sent on the media plane from start?=20 There may be information that have to be sent on the media plane from "day = one", so it seems weird that one would have to use two different mechanisms= just because they haven't reached the future yet. As we have discussed before, we may not define the exact media plane transp= ort mechanism within this draft, but we should allow others to do so. Regards, Christer From nobody Mon Dec 15 21:14:49 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BC71A0394; Mon, 15 Dec 2014 21:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 IfdA3sNN4G_S; Mon, 15 Dec 2014 21:14:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 935E61A0371; Mon, 15 Dec 2014 21:14:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141216051436.11868.42630.idtracker@ietfa.amsl.com> Date: Mon, 15 Dec 2014 21:14:36 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/PLJo5JlA-RKiUaouNUBkMXUisVE Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 05:14:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Additional Data Related to an Emergency Call Authors : Randall Gellens Brian Rosen Hannes Tschofenig Roger Marshall James Winterbottom Filename : draft-ietf-ecrit-additional-data-27.txt Pages : 105 Date : 2014-12-15 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any application service provider in the path of the call, or access network provider through which the call originated may have information about the call, the caller or the location which the PSAP may be able to use. This document describes data structures and a mechanism to convey such data to the PSAP. The mechanism uses a Uniform Resource Identifier (URI), which may point to either an external resource or an object in the body of the SIP message. The mechanism thus allows the data to be passed by reference (when the URI points to an external resource) or by value (when it points into the body of the message). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in body of the SIP message) and also by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-27 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 15 22:12:10 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED221ACD27 for ; Mon, 15 Dec 2014 22:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 eNX1TaRs7O_d for ; Mon, 15 Dec 2014 22:12:05 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F321ACD25 for ; Mon, 15 Dec 2014 22:12:04 -0800 (PST) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail41.telekom.de with ESMTP; 16 Dec 2014 07:12:02 +0100 X-IronPort-AV: E=Sophos;i="5.07,584,1413237600"; d="scan'208";a="184916498" Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 16 Dec 2014 07:12:01 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 16 Dec 2014 07:12:01 +0100 From: To: , , , Date: Tue, 16 Dec 2014 07:12:00 +0100 Thread-Topic: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc Thread-Index: AdAXGp9Zl4qYitZdRZa5Lgz1jO9wqQB3I4oQ Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E5F1B3F996@HE113667.emea1.cds.t-internal.com> References: <021A9BCE-3E2A-4B06-9493-D3FD031B0B14@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D5ACDE9@ESESSMB209.ericsson.se> <548CAD83.5070601@gmx.net> In-Reply-To: <548CAD83.5070601@gmx.net> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/cPkK3tRg6_zdHGNOj8wv7GsDL28 Subject: Re: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 06:12:07 -0000 +1 Roland -----Urspr=FCngliche Nachricht----- Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Hannes Tschofenig Gesendet: Samstag, 13. Dezember 2014 22:20 An: Christer Holmberg; Marc Linsner (mlinsner); ecrit@ietf.org Betreff: Re: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc I support it as well. On 12/13/2014 07:46 PM, Christer Holmberg wrote: > Hi, >=20 > I support creating a milestone, and to use the draft as base for the deli= very. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner (ml= insner) > Sent: 12 December 2014 22:15 > To: ecrit@ietf.org > Subject: [Ecrit] ETSI Liaison & draft-winterbottom-ecrit-priv-loc >=20 > All, >=20 > Please review the liaison from ETSI and the draft from James and Laura (i= t's expired by still viewable). >=20 > https://datatracker.ietf.org/liaison/1362/ >=20 > Please respond to the list if you agree to create an ECRIT milestone to d= o this work and you agree to accept the draft as a WG item to achieve the m= ilestone. >=20 > Please respond to the list by COB December 19, 2014. >=20 > Thanks, >=20 > Marc & Roger >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From nobody Tue Dec 16 06:00:40 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD47C1A1AB1 for ; Tue, 16 Dec 2014 06:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 7_Xb2ozQ1kk8 for ; Tue, 16 Dec 2014 06:00:34 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84EEA1A1A8F for ; Tue, 16 Dec 2014 06:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2948; q=dns/txt; s=iport; t=1418738433; x=1419948033; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=qLCesJHThWvf/0DxmeA7kO3SFfbpR3tsXK2xqKmX6yo=; b=MwOQGRFZ1COqmdBQUYOTlyuYs6A9YLRrIza4Zfk/Sl9R+0Y6UDejv8qc DxJLwtB8oCXfr9udWiJ8i+WtFRyP7x+p6UzcgAPt9jgzTmfN3m4/MZtEk LJlg+4ekLo7dmOdbHVP7u36wtvhc31Cf1489dBUeZz8Vrrwu4r1thaKPe c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAHc6kFStJssW/2dsb2JhbABag1hTBQTFaAqFcgKBLgEBAQEBfYQMAQEBAwEBAQE3NBALAgEZAwECHxAnCxsCCAIEEwmIGwgIBdRJAQEBAQEBBAEBAQEBAQEBARmPf4MQgRMFjgKDPoUxgQswgi6NUCKDbG6BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="276359047" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 16 Dec 2014 14:00:31 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sBGE0UbW032259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Dec 2014 14:00:31 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.75]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 08:00:29 -0600 From: "Marc Linsner (mlinsner)" To: "ecrit@ietf.org" Thread-Topic: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt Thread-Index: AQHQGO9GrzVsbMkr1EuEBrg7rtdzow== Date: Tue, 16 Dec 2014 14:00:29 +0000 Message-ID: References: <20141216051436.11868.42630.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.172.176] Content-Type: text/plain; charset="us-ascii" Content-ID: <64B49BE1EE2DCA41BD0FDEE9F7AB3EF0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/QD_N0ljyUDvzGcNnZ2_TvEXUgCQ Subject: [Ecrit] Fwd: I-D Action: draft-ietf-ecrit-additional-data-27.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 14:00:39 -0000 All, I asked Randy to submit the new version to correct one error that showed up= the idnits process. Idnits was claiming that RFC3325 should be an informa= tive reference vs. normative. I'll proceed sending to the IESG. -Marc- Begin forwarded message: > From: > Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt > Date: December 16, 2014 at 12:14:36 AM EST > To: > Cc: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Emergency Context Resolution with Intern= et Technologies Working Group of the IETF. >=20 > Title : Additional Data Related to an Emergency Call > Authors : Randall Gellens > Brian Rosen > Hannes Tschofenig > Roger Marshall > James Winterbottom > Filename : draft-ietf-ecrit-additional-data-27.txt > Pages : 105 > Date : 2014-12-15 >=20 > Abstract: > When an emergency call is sent to a Public Safety Answering Point > (PSAP), the device that sends it, as well as any application service > provider in the path of the call, or access network provider through > which the call originated may have information about the call, the > caller or the location which the PSAP may be able to use. This > document describes data structures and a mechanism to convey such > data to the PSAP. The mechanism uses a Uniform Resource Identifier > (URI), which may point to either an external resource or an object in > the body of the SIP message. The mechanism thus allows the data to > be passed by reference (when the URI points to an external resource) > or by value (when it points into the body of the message). This > follows the tradition of prior emergency services standardization > work where data can be conveyed by value within the call signaling > (i.e., in body of the SIP message) and also by reference. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-27 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-27 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Tue Dec 16 07:27:14 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780E91A1B91 for ; Tue, 16 Dec 2014 07:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8L8_ZS_qaK-E for ; Tue, 16 Dec 2014 07:27:10 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466D71A1B4E for ; Tue, 16 Dec 2014 07:27:10 -0800 (PST) Received: from [192.168.131.138] ([80.92.123.25]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0McPvw-1YIQsT1aFM-00HbqN; Tue, 16 Dec 2014 16:27:05 +0100 Message-ID: <54904F48.7000701@gmx.net> Date: Tue, 16 Dec 2014 16:27:04 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Marc Linsner (mlinsner)" , "ecrit@ietf.org" References: <20141216051436.11868.42630.idtracker@ietfa.amsl.com> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cxFXA4t8Q0ILJfCkNRhr5QJNXUwoG8PI6" X-Provags-ID: V03:K0:fMPiS2E5ekVJIqYg3YBVABwPB8RdNGBxQ1esGZkoMcvC5ThpaG6 QICva9emUa0bYaWlrnR0PQYXxdwzwKfAV5DUkSvSdMrY60ktS9tplDchPqt2Q2pLeAB6mkb PVDGe+lZBHRtw+aHLEpSEBTX6YUG4vKuFwtUdTqe3lq+yfxP+yzMklgeCvw1/WToSDiTpnF ymUB7rFV62hONIAWp0PBg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/rXrNjjumH3e5dqWWQ52Y5sVwn54 Subject: Re: [Ecrit] Fwd: I-D Action: draft-ietf-ecrit-additional-data-27.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 15:27:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cxFXA4t8Q0ILJfCkNRhr5QJNXUwoG8PI6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for pushing the document through the process, Marc! On 12/16/2014 03:00 PM, Marc Linsner (mlinsner) wrote: > All, >=20 > I asked Randy to submit the new version to correct one error that showe= d up the idnits process. Idnits was claiming that RFC3325 should be an i= nformative reference vs. normative. >=20 > I'll proceed sending to the IESG. >=20 > -Marc- >=20 > Begin forwarded message: >=20 >> From: >> Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt >> Date: December 16, 2014 at 12:14:36 AM EST >> To: >> Cc: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the Emergency Context Resolution with Int= ernet Technologies Working Group of the IETF. >> >> Title : Additional Data Related to an Emergency Call >> Authors : Randall Gellens >> Brian Rosen >> Hannes Tschofenig >> Roger Marshall >> James Winterbottom >> Filename : draft-ietf-ecrit-additional-data-27.txt >> Pages : 105 >> Date : 2014-12-15 >> >> Abstract: >> When an emergency call is sent to a Public Safety Answering Point >> (PSAP), the device that sends it, as well as any application service= >> provider in the path of the call, or access network provider through= >> which the call originated may have information about the call, the >> caller or the location which the PSAP may be able to use. This >> document describes data structures and a mechanism to convey such >> data to the PSAP. The mechanism uses a Uniform Resource Identifier >> (URI), which may point to either an external resource or an object i= n >> the body of the SIP message. The mechanism thus allows the data to >> be passed by reference (when the URI points to an external resource)= >> or by value (when it points into the body of the message). This >> follows the tradition of prior emergency services standardization >> work where data can be conveyed by value within the call signaling >> (i.e., in body of the SIP message) and also by reference. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-27 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-27= >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 --cxFXA4t8Q0ILJfCkNRhr5QJNXUwoG8PI6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUkE9IAAoJEGhJURNOOiAt95kH/0+YuOQTZEj0Yt3zOkkV/AeV muiheiuGd2QCAU51DskkL55eQ5ZVybD/mRzDbsVlzuidiR+sf0RKIQ4DFg/IXLlz mKowF7xF8lILlYocftlGB+vHyIT0qyvpToB6YF0Oys61A+kICdVOIjSzimuojQ81 aeWZPpJxqRaOZ5zr/3rGRWzClmE3U1c5pn70pIklX+XOJt3ABh+6CVfKADXN4UIR 0sRKgZfcmcjdCX4MAanfmTVr1JNi579NCxnJFWLdVSDUOCQ3IziuVdhC/KFU6aAN o8f2QqbDqNbtJAHxECap1rfR8YoAnW7x76iJqnJO58+bX3Bnr6OHL0b2QD5t8WI= =P/Zc -----END PGP SIGNATURE----- --cxFXA4t8Q0ILJfCkNRhr5QJNXUwoG8PI6-- From nobody Tue Dec 16 07:33:08 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC77E1A1B9C for ; Tue, 16 Dec 2014 07:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rZnsJUJePDKF for ; Tue, 16 Dec 2014 07:33:04 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F741A1B9B for ; Tue, 16 Dec 2014 07:33:03 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 3454B20904066; Tue, 16 Dec 2014 15:32:57 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sBGFWmfF029712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Dec 2014 16:32:59 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 16:32:54 +0100 From: "DRAGE, Keith (Keith)" To: "Marc Linsner (mlinsner)" , "ecrit@ietf.org" Thread-Topic: [Ecrit] Fwd: I-D Action: draft-ietf-ecrit-additional-data-27.txt Thread-Index: AQHQGO9GrzVsbMkr1EuEBrg7rtdzo5ySQlTg Date: Tue, 16 Dec 2014 15:32:54 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B296009@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20141216051436.11868.42630.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/zQmhEsJ86ZvL1clPdnAl5SDfTD8 Subject: Re: [Ecrit] Fwd: I-D Action: draft-ietf-ecrit-additional-data-27.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 15:33:06 -0000 One concern I have about the discussion that has just occurred is that it i= s assuming the application within an environment where this usage has not y= et been specified. The assumed enviroment is within a car using the cellular network, and this= expectation exists when we get to=20 https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ It has to be assumed that the cellular network will normally be a 3GPP netw= ork. However no work has yet started in 3GPP on how this would be supported= in such a network. Therefore assumptions (from both sides of the previous = discussion) are being made that this will be compatible with whatever 3GPP = will decide when it eventually opens the work.=20 Given that all the participants in the dialog are 3GPP members, would it no= t be an idea to get the required 3GPP work started and hold this work until= that occurs. Regards Keith > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc=20 > Linsner (mlinsner) > Sent: 16 December 2014 14:00 > To: ecrit@ietf.org > Subject: [Ecrit] Fwd: I-D Action:=20 > draft-ietf-ecrit-additional-data-27.txt >=20 > All, >=20 > I asked Randy to submit the new version to correct one error=20 > that showed up the idnits process. Idnits was claiming that=20 > RFC3325 should be an informative reference vs. normative. >=20 > I'll proceed sending to the IESG. >=20 > -Marc- >=20 > Begin forwarded message: >=20 > > From: > > Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt > > Date: December 16, 2014 at 12:14:36 AM EST > > To: > > Cc: > >=20 > >=20 > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > This draft is a work item of the Emergency Context=20 > Resolution with Internet Technologies Working Group of the IETF. > >=20 > > Title : Additional Data Related to an=20 > Emergency Call > > Authors : Randall Gellens > > Brian Rosen > > Hannes Tschofenig > > Roger Marshall > > James Winterbottom > > Filename : draft-ietf-ecrit-additional-data-27.txt > > Pages : 105 > > Date : 2014-12-15 > >=20 > > Abstract: > > When an emergency call is sent to a Public Safety Answering Point > > (PSAP), the device that sends it, as well as any=20 > application service > > provider in the path of the call, or access network=20 > provider through > > which the call originated may have information about the call, the > > caller or the location which the PSAP may be able to use. This > > document describes data structures and a mechanism to convey such > > data to the PSAP. The mechanism uses a Uniform Resource=20 > Identifier > > (URI), which may point to either an external resource or=20 > an object in > > the body of the SIP message. The mechanism thus allows=20 > the data to > > be passed by reference (when the URI points to an=20 > external resource) > > or by value (when it points into the body of the message). This > > follows the tradition of prior emergency services standardization > > work where data can be conveyed by value within the call signaling > > (i.e., in body of the SIP message) and also by reference. > >=20 > >=20 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ > >=20 > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-27 > >=20 > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-27 > >=20 > >=20 > > Please note that it may take a couple of minutes from the time of=20 > > submission until the htmlized version and diff are=20 > available at tools.ietf.org. > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From nobody Tue Dec 16 08:11:28 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613AB1A1B49 for ; Tue, 16 Dec 2014 08:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 WAx3ZePA3oip for ; Tue, 16 Dec 2014 08:11:18 -0800 (PST) Received: from mx0a-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1331A1B30 for ; Tue, 16 Dec 2014 08:11:18 -0800 (PST) Received: from pps.filterd (m0049402.ppops.net [127.0.0.1]) by m0049402.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id sBGG50it020928; Tue, 16 Dec 2014 11:11:16 -0500 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049402.ppops.net-0018ba01. with ESMTP id 1ra9ma98ha-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Dec 2014 11:11:16 -0500 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.204]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 16 Dec 2014 11:11:15 -0500 From: "Rosen, Brian" To: "DRAGE, Keith (Keith)" Thread-Topic: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt Thread-Index: AQHQGUrq7uC5cmEBuk6FmqyeZ1n/vw== Date: Tue, 16 Dec 2014 16:11:14 +0000 Message-ID: <491C745F-569F-49C9-B3D5-45F402FE7AE9@neustar.biz> References: <20141216051436.11868.42630.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8B296009@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B296009@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.44] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7653 signatures=670596 X-Proofpoint-Spam-Reason: safe Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/8n5oyRx22FOtjEFHYEqvjnsYlC8 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:11:26 -0000 LWNhci1jcmFzaCBkb2VzIG5vdCBuZWVkIGFueSAzR1BQIHN1cHBvcnQuICBBIDNyZCBwYXJ0eSB0 ZWxlbWF0aWNzIGNvbXBhbnkgc3VjaCBhcyBPblN0YXIgY2FuIGRvIGl0IGJ5IHRoZW1zZWx2ZXMu DQoNClRoZXJlIGNvdWxkIGJlIHNvbWUgc3VwcG9ydCBmb3IgaXQgaW4gM0dQUCwgYnV0IHdlIGRv buKAmXQgbmVlZCBpdC4NCg0KQnJpYW4NCg0KPiBPbiBEZWMgMTYsIDIwMTQsIGF0IDEwOjMyIEFN LCBEUkFHRSwgS2VpdGggKEtlaXRoKSA8a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPiB3 cm90ZToNCj4gDQo+IE9uZSBjb25jZXJuIEkgaGF2ZSBhYm91dCB0aGUgZGlzY3Vzc2lvbiB0aGF0 IGhhcyBqdXN0IG9jY3VycmVkIGlzIHRoYXQgaXQgaXMgYXNzdW1pbmcgdGhlIGFwcGxpY2F0aW9u IHdpdGhpbiBhbiBlbnZpcm9ubWVudCB3aGVyZSB0aGlzIHVzYWdlIGhhcyBub3QgeWV0IGJlZW4g c3BlY2lmaWVkLg0KPiANCj4gVGhlIGFzc3VtZWQgZW52aXJvbWVudCBpcyB3aXRoaW4gYSBjYXIg dXNpbmcgdGhlIGNlbGx1bGFyIG5ldHdvcmssIGFuZCB0aGlzIGV4cGVjdGF0aW9uIGV4aXN0cyB3 aGVuIHdlIGdldCB0byANCj4gDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtZWNyaXQtY2FyLWNyYXNoLw0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWVjcml0LWVjYWxsLw0KPiANCj4gSXQgaGFzIHRvIGJlIGFzc3VtZWQg dGhhdCB0aGUgY2VsbHVsYXIgbmV0d29yayB3aWxsIG5vcm1hbGx5IGJlIGEgM0dQUCBuZXR3b3Jr LiBIb3dldmVyIG5vIHdvcmsgaGFzIHlldCBzdGFydGVkIGluIDNHUFAgb24gaG93IHRoaXMgd291 bGQgYmUgc3VwcG9ydGVkIGluIHN1Y2ggYSBuZXR3b3JrLiBUaGVyZWZvcmUgYXNzdW1wdGlvbnMg KGZyb20gYm90aCBzaWRlcyBvZiB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbikgYXJlIGJlaW5nIG1h ZGUgdGhhdCB0aGlzIHdpbGwgYmUgY29tcGF0aWJsZSB3aXRoIHdoYXRldmVyIDNHUFAgd2lsbCBk ZWNpZGUgd2hlbiBpdCBldmVudHVhbGx5IG9wZW5zIHRoZSB3b3JrLiANCj4gDQo+IEdpdmVuIHRo YXQgYWxsIHRoZSBwYXJ0aWNpcGFudHMgaW4gdGhlIGRpYWxvZyBhcmUgM0dQUCBtZW1iZXJzLCB3 b3VsZCBpdCBub3QgYmUgYW4gaWRlYSB0byBnZXQgdGhlIHJlcXVpcmVkIDNHUFAgd29yayBzdGFy dGVkIGFuZCBob2xkIHRoaXMgd29yayB1bnRpbCB0aGF0IG9jY3Vycy4NCj4gDQo+IFJlZ2FyZHMN Cj4gDQo+IEtlaXRoDQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206 IEVjcml0IFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmMg DQo+PiBMaW5zbmVyIChtbGluc25lcikNCj4+IFNlbnQ6IDE2IERlY2VtYmVyIDIwMTQgMTQ6MDAN Cj4+IFRvOiBlY3JpdEBpZXRmLm9yZw0KPj4gU3ViamVjdDogW0Vjcml0XSBGd2Q6IEktRCBBY3Rp b246IA0KPj4gZHJhZnQtaWV0Zi1lY3JpdC1hZGRpdGlvbmFsLWRhdGEtMjcudHh0DQo+PiANCj4+ IEFsbCwNCj4+IA0KPj4gSSBhc2tlZCBSYW5keSB0byBzdWJtaXQgdGhlIG5ldyB2ZXJzaW9uIHRv IGNvcnJlY3Qgb25lIGVycm9yIA0KPj4gdGhhdCBzaG93ZWQgdXAgdGhlIGlkbml0cyBwcm9jZXNz LiAgSWRuaXRzIHdhcyBjbGFpbWluZyB0aGF0IA0KPj4gUkZDMzMyNSBzaG91bGQgYmUgYW4gaW5m b3JtYXRpdmUgcmVmZXJlbmNlIHZzLiBub3JtYXRpdmUuDQo+PiANCj4+IEknbGwgcHJvY2VlZCBz ZW5kaW5nIHRvIHRoZSBJRVNHLg0KPj4gDQo+PiAtTWFyYy0NCj4+IA0KPj4gQmVnaW4gZm9yd2Fy ZGVkIG1lc3NhZ2U6DQo+PiANCj4+PiBGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0K Pj4+IFN1YmplY3Q6IFtFY3JpdF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1lY3JpdC1hZGRpdGlv bmFsLWRhdGEtMjcudHh0DQo+Pj4gRGF0ZTogRGVjZW1iZXIgMTYsIDIwMTQgYXQgMTI6MTQ6MzYg QU0gRVNUDQo+Pj4gVG86IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+Pj4gQ2M6IDxlY3JpdEBp ZXRmLm9yZz4NCj4+PiANCj4+PiANCj4+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSANCj4+IEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4+ PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBFbWVyZ2VuY3kgQ29udGV4dCANCj4+ IFJlc29sdXRpb24gd2l0aCBJbnRlcm5ldCBUZWNobm9sb2dpZXMgV29ya2luZyBHcm91cCBvZiB0 aGUgSUVURi4NCj4+PiANCj4+PiAgICAgICBUaXRsZSAgICAgICAgICAgOiBBZGRpdGlvbmFsIERh dGEgUmVsYXRlZCB0byBhbiANCj4+IEVtZXJnZW5jeSBDYWxsDQo+Pj4gICAgICAgQXV0aG9ycyAg ICAgICAgIDogUmFuZGFsbCBHZWxsZW5zDQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgQnJp YW4gUm9zZW4NCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBIYW5uZXMgVHNjaG9mZW5pZw0K Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIFJvZ2VyIE1hcnNoYWxsDQo+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgSmFtZXMgV2ludGVyYm90dG9tDQo+Pj4gCUZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtZWNyaXQtYWRkaXRpb25hbC1kYXRhLTI3LnR4dA0KPj4+IAlQYWdlcyAgICAg ICAgICAgOiAxMDUNCj4+PiAJRGF0ZSAgICAgICAgICAgIDogMjAxNC0xMi0xNQ0KPj4+IA0KPj4+ IEFic3RyYWN0Og0KPj4+ICBXaGVuIGFuIGVtZXJnZW5jeSBjYWxsIGlzIHNlbnQgdG8gYSBQdWJs aWMgU2FmZXR5IEFuc3dlcmluZyBQb2ludA0KPj4+ICAoUFNBUCksIHRoZSBkZXZpY2UgdGhhdCBz ZW5kcyBpdCwgYXMgd2VsbCBhcyBhbnkgDQo+PiBhcHBsaWNhdGlvbiBzZXJ2aWNlDQo+Pj4gIHBy b3ZpZGVyIGluIHRoZSBwYXRoIG9mIHRoZSBjYWxsLCBvciBhY2Nlc3MgbmV0d29yayANCj4+IHBy b3ZpZGVyIHRocm91Z2gNCj4+PiAgd2hpY2ggdGhlIGNhbGwgb3JpZ2luYXRlZCBtYXkgaGF2ZSBp bmZvcm1hdGlvbiBhYm91dCB0aGUgY2FsbCwgdGhlDQo+Pj4gIGNhbGxlciBvciB0aGUgbG9jYXRp b24gd2hpY2ggdGhlIFBTQVAgbWF5IGJlIGFibGUgdG8gdXNlLiAgVGhpcw0KPj4+ICBkb2N1bWVu dCBkZXNjcmliZXMgZGF0YSBzdHJ1Y3R1cmVzIGFuZCBhIG1lY2hhbmlzbSB0byBjb252ZXkgc3Vj aA0KPj4+ICBkYXRhIHRvIHRoZSBQU0FQLiAgVGhlIG1lY2hhbmlzbSB1c2VzIGEgVW5pZm9ybSBS ZXNvdXJjZSANCj4+IElkZW50aWZpZXINCj4+PiAgKFVSSSksIHdoaWNoIG1heSBwb2ludCB0byBl aXRoZXIgYW4gZXh0ZXJuYWwgcmVzb3VyY2Ugb3IgDQo+PiBhbiBvYmplY3QgaW4NCj4+PiAgdGhl IGJvZHkgb2YgdGhlIFNJUCBtZXNzYWdlLiAgVGhlIG1lY2hhbmlzbSB0aHVzIGFsbG93cyANCj4+ IHRoZSBkYXRhIHRvDQo+Pj4gIGJlIHBhc3NlZCBieSByZWZlcmVuY2UgKHdoZW4gdGhlIFVSSSBw b2ludHMgdG8gYW4gDQo+PiBleHRlcm5hbCByZXNvdXJjZSkNCj4+PiAgb3IgYnkgdmFsdWUgKHdo ZW4gaXQgcG9pbnRzIGludG8gdGhlIGJvZHkgb2YgdGhlIG1lc3NhZ2UpLiAgVGhpcw0KPj4+ICBm b2xsb3dzIHRoZSB0cmFkaXRpb24gb2YgcHJpb3IgZW1lcmdlbmN5IHNlcnZpY2VzIHN0YW5kYXJk aXphdGlvbg0KPj4+ICB3b3JrIHdoZXJlIGRhdGEgY2FuIGJlIGNvbnZleWVkIGJ5IHZhbHVlIHdp dGhpbiB0aGUgY2FsbCBzaWduYWxpbmcNCj4+PiAgKGkuZS4sIGluIGJvZHkgb2YgdGhlIFNJUCBt ZXNzYWdlKSBhbmQgYWxzbyBieSByZWZlcmVuY2UuDQo+Pj4gDQo+Pj4gDQo+Pj4gVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1lY3JpdC1hZGRpdGlvbmFsLWRhdGEv DQo+Pj4gDQo+Pj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6 DQo+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1lY3JpdC1hZGRpdGlv bmFsLWRhdGEtMjcNCj4+PiANCj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBp cyBhdmFpbGFibGUgYXQ6DQo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi1lY3JpdC1hZGRpdGlvbmFsLWRhdGEtMjcNCj4+PiANCj4+PiANCj4+PiBQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiANCj4+PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSANCj4+IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+PiANCj4+PiBJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4gZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+PiANCj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IEVjcml0IG1haWxpbmcgbGlzdA0K Pj4+IEVjcml0QGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9lY3JpdA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+PiBFY3JpdEBpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEVjcml0IG1haWxp bmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Vjcml0DQoNCg== From nobody Tue Dec 16 08:19:31 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572AF1A1B98 for ; Tue, 16 Dec 2014 08:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 41JXVC2VcoK4 for ; Tue, 16 Dec 2014 08:19:27 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13BA31A1B93 for ; Tue, 16 Dec 2014 08:19:26 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 2F3D327477515; Tue, 16 Dec 2014 16:19:22 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sBGGJ5D0000426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Dec 2014 17:19:23 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 17:19:08 +0100 From: "DRAGE, Keith (Keith)" To: "Rosen, Brian" Thread-Topic: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt Thread-Index: AQHQGUrq7uC5cmEBuk6FmqyeZ1n/v5ySZJsg Date: Tue, 16 Dec 2014 16:19:06 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B296102@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20141216051436.11868.42630.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8B296009@FR712WXCHMBA11.zeu.alcatel-lucent.com> <491C745F-569F-49C9-B3D5-45F402FE7AE9@neustar.biz> In-Reply-To: <491C745F-569F-49C9-B3D5-45F402FE7AE9@neustar.biz> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/QKzoYjAdtbeLjnoh8cwe728CZPA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:19:30 -0000 As far as 3GPP is concerned - there would be no unauthenticated usage, beca= use in 3GPP it would not be an emergency call. Nor would there be any roaming support, in terms of reaching an emergency s= ervice provider in the country in which you are, unless of course you use l= ost first. But in any case, I see no restriction in the document that says it can only= be used OTT, and therefore not using the IMS SIP stack. Keith=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: 16 December 2014 16:11 > To: DRAGE, Keith (Keith) > Cc: Marc Linsner; ecrit@ietf.org > Subject: Re: [Ecrit] I-D Action:=20 > draft-ietf-ecrit-additional-data-27.txt >=20 > -car-crash does not need any 3GPP support. A 3rd party=20 > telematics company such as OnStar can do it by themselves. >=20 > There could be some support for it in 3GPP, but we don't need it. >=20 > Brian >=20 > > On Dec 16, 2014, at 10:32 AM, DRAGE, Keith (Keith)=20 > wrote: > >=20 > > One concern I have about the discussion that has just=20 > occurred is that it is assuming the application within an=20 > environment where this usage has not yet been specified. > >=20 > > The assumed enviroment is within a car using the cellular=20 > network, and=20 > > this expectation exists when we get to > >=20 > > https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ > > https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ > >=20 > > It has to be assumed that the cellular network will=20 > normally be a 3GPP network. However no work has yet started=20 > in 3GPP on how this would be supported in such a network.=20 > Therefore assumptions (from both sides of the previous=20 > discussion) are being made that this will be compatible with=20 > whatever 3GPP will decide when it eventually opens the work.=20 > >=20 > > Given that all the participants in the dialog are 3GPP=20 > members, would it not be an idea to get the required 3GPP=20 > work started and hold this work until that occurs. > >=20 > > Regards > >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of=20 > Marc Linsner=20 > >> (mlinsner) > >> Sent: 16 December 2014 14:00 > >> To: ecrit@ietf.org > >> Subject: [Ecrit] Fwd: I-D Action:=20 > >> draft-ietf-ecrit-additional-data-27.txt > >>=20 > >> All, > >>=20 > >> I asked Randy to submit the new version to correct one error that=20 > >> showed up the idnits process. Idnits was claiming that > >> RFC3325 should be an informative reference vs. normative. > >>=20 > >> I'll proceed sending to the IESG. > >>=20 > >> -Marc- > >>=20 > >> Begin forwarded message: > >>=20 > >>> From: > >>> Subject: [Ecrit] I-D Action:=20 > draft-ietf-ecrit-additional-data-27.txt > >>> Date: December 16, 2014 at 12:14:36 AM EST > >>> To: > >>> Cc: > >>>=20 > >>>=20 > >>> A New Internet-Draft is available from the on-line > >> Internet-Drafts directories. > >>> This draft is a work item of the Emergency Context > >> Resolution with Internet Technologies Working Group of the IETF. > >>>=20 > >>> Title : Additional Data Related to an=20 > >> Emergency Call > >>> Authors : Randall Gellens > >>> Brian Rosen > >>> Hannes Tschofenig > >>> Roger Marshall > >>> James Winterbottom > >>> Filename : draft-ietf-ecrit-additional-data-27.txt > >>> Pages : 105 > >>> Date : 2014-12-15 > >>>=20 > >>> Abstract: > >>> When an emergency call is sent to a Public Safety=20 > Answering Point =20 > >>> (PSAP), the device that sends it, as well as any > >> application service > >>> provider in the path of the call, or access network > >> provider through > >>> which the call originated may have information about the=20 > call, the =20 > >>> caller or the location which the PSAP may be able to use. This =20 > >>> document describes data structures and a mechanism to=20 > convey such =20 > >>> data to the PSAP. The mechanism uses a Uniform Resource > >> Identifier > >>> (URI), which may point to either an external resource or > >> an object in > >>> the body of the SIP message. The mechanism thus allows > >> the data to > >>> be passed by reference (when the URI points to an > >> external resource) > >>> or by value (when it points into the body of the=20 > message). This =20 > >>> follows the tradition of prior emergency services=20 > standardization =20 > >>> work where data can be conveyed by value within the call=20 > signaling =20 > >>> (i.e., in body of the SIP message) and also by reference. > >>>=20 > >>>=20 > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ > >>>=20 > >>> There's also a htmlized version available at: > >>> http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-27 > >>>=20 > >>> A diff from the previous version is available at: > >>>=20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-27 > >>>=20 > >>>=20 > >>> Please note that it may take a couple of minutes from the time of=20 > >>> submission until the htmlized version and diff are > >> available at tools.ietf.org. > >>>=20 > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>>=20 > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >>=20 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >>=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > = From nobody Tue Dec 16 12:18:04 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60971A8774 for ; Tue, 16 Dec 2014 12:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.391 X-Spam-Level: *** X-Spam-Status: No, score=3.391 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 QBT-j1R7rLDL for ; Tue, 16 Dec 2014 12:17:58 -0800 (PST) Received: from nm28-vm5.bullet.mail.ne1.yahoo.com (nm28-vm5.bullet.mail.ne1.yahoo.com [98.138.91.250]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C10761A8785 for ; Tue, 16 Dec 2014 12:17:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1418761074; bh=+Kpp4GQZpj+jSDNuuT/RXKNpPu5Uke3IoHT+nvQp740=; h=From:Subject:Date:To:From:Subject; b=euGK3PXX59kWIXe7HiZK/AAK6NglrE6EXKspEs3KK2McAmE0XU7MKTUXDElUG/8zEjHumIw0kVgWSl9e6y65beCxNQMpldsGK50ov9hKYUH2mzDu3FcZFpFwXLJdncimmumPvJUw0T9yZYe1kdzpP0YLDrWMnZNRKByQE76HfBxvYVNMf2hWzNylMEQH9GWm/PyL8ZwmIlPE0AYS9Yg7yyoqR4iTAl81Z8n0mPC2DJYshj7mWyKAHc0eMKWIm3qfC6DAUJHeBbzSMi+/uOPaQyxpqMaTNa7R0I45Ijc5nbYEc+pUQnvUzB9aDFo2UoWTGaiL4ruLzP1IlHo2kaEPpg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=YP4vS5PmYANAx72xntkrzSu2bZZLrN6I/nVV2X9lc8a10Yo0pKQ6/ewyJ9Dv7LxiO67rH2cGI2fI+CM8IUAc2No9G5WWDflEM0kFBNrVfDc4+EiBgUpVWLMLa9b3cvIajMWsb8YA0CRcAKpamkQ5F0lFDyJqYnKGffQDnNEw2uhBz42IJzZEtsB+IPevKLooT2bBoXGqPuq4G0aSSRAmYVf1K86CxWsjexD5uCX79vo5EVnnoIxPJCtEtKJJpy3+3HUoKD+MYvLOPqEpx+zj2IAgiTWRtCVV0MK/kTJTJZTcoOFh2lDMaLP3uVyUoooOlpiNjnC1U2m9MRUpHa/TRg==; Received: from [98.138.226.180] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 16 Dec 2014 20:17:54 -0000 Received: from [98.138.104.115] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 16 Dec 2014 20:17:54 -0000 Received: from [127.0.0.1] by smtp224.mail.ne1.yahoo.com with NNFMP; 16 Dec 2014 20:17:54 -0000 X-Yahoo-Newman-Id: 35562.16516.bm@smtp224.mail.ne1.yahoo.com Message-ID: <35562.16516.bm@smtp224.mail.ne1.yahoo.com> X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8ocPB54VM1lKCkG6nxVAhzWJXXnnzAxmfHYcCoKctdR3eVr wpZiVbdWDAZE24nMgHd7_4hDcUZ7UlaJnQ5361izoxTpww8gyX2YrXiii8Aj FZ8WoMfh3u5pKfSBeLrwyqyVwmbNYiD.ZYTTLMIvi9HWZ1QK8K1d0X63dOWl zhigWkMBLENtQkX9rTz3Kw7dlQVwV1EjsKDk0m3I5tVuelVcskMevDYxHDX8 e0sCBhhGEJxKD6Nid7uWDDYle_xC3TR7n.VjNeIbnnZJFV4OZPP4OM2gE8hH QcFU4B29WzHR8KxNJ3j3Rxmri7isFFjk5fL2qn0N4NUG0DCp0PPSzVgOif9E h613G75wLYFVZ9xrGApfnUc6WE3_0Zalbh2ZERARG50Fv.sbx2DWgoMMhAH3 .B1IYBhztHtWNFTqIrZVtf2KTcwm4EukFXClx4eah6c_zHs9VNeJ_OtZIziv eWryELj7StEHJ2wFLPsi3znN.8bGjUuyHfiPS3AmmgoKmX8Gq33UkSLU9CwU viAGD6mkGV1LEeUeEdlJPvOv8gknU9g-- X-Yahoo-SMTP: eGkeJ2CswBDor1WnOPtcCgcmH8c- MIME-Version: 1.0 From: Mario L Defaz A Date: Tue, 16 Dec 2014 15:17:51 -0500 To: "ecrit@ietf.org" Content-Type: multipart/alternative; boundary="_9D311302-301E-13ED-9533-9AA0EED359B4_" Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/GNAw1iT5qPX-9TO-9_dfdGVyBbA Subject: [Ecrit] Unsuscribme X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 20:18:00 -0000 --_9D311302-301E-13ED-9533-9AA0EED359B4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="Windows-1252" Please, unsubscribe me from your mailing list=20 Thanks= --_9D311302-301E-13ED-9533-9AA0EED359B4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="Windows-1252"
Please, unsubscribe me from your mailing list
Thanks
= --_9D311302-301E-13ED-9533-9AA0EED359B4_-- From nobody Wed Dec 17 19:59:56 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C241A014D; Wed, 17 Dec 2014 19:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 09SDIR4LgtU2; Wed, 17 Dec 2014 19:59:52 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 63EFD1A014C; Wed, 17 Dec 2014 19:59:52 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D141D181243; Wed, 17 Dec 2014 19:59:30 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141218035930.D141D181243@rfc-editor.org> Date: Wed, 17 Dec 2014 19:59:30 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/Jyf5JmZYHeDSO18QcDXpf4yFk_A Cc: drafts-update-ref@iana.org, ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] RFC 7378 on Trustworthy Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 03:59:54 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7378 Title: Trustworthy Location Author: H. Tschofenig, H. Schulzrinne, B. Aboba, Ed. Status: Informational Stream: IETF Date: December 2014 Mailbox: Hannes.Tschofenig@gmx.net, hgs@cs.columbia.edu, Bernard_Aboba@hotmail.com Pages: 31 Characters: 75402 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ecrit-trustworthy-location-14.txt URL: https://www.rfc-editor.org/rfc/rfc7378.txt The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance. This document describes threats to conveying location, particularly for emergency calls, and describes techniques that improve the reliability and security of location information. It also provides guidelines for assessing the trustworthiness of location information. This document is a product of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Dec 18 02:35:00 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5A71A1BBF for ; Thu, 18 Dec 2014 02:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 KEAxMumzCckO for ; Thu, 18 Dec 2014 02:34:57 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E281A039A for ; Thu, 18 Dec 2014 02:34:55 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-d4-5492adcd4ef5 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 62.8F.24955.DCDA2945; Thu, 18 Dec 2014 11:34:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 11:34:53 +0100 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , "Rosen, Brian" Thread-Topic: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt Thread-Index: AQHQGUr100PVi3XQZkmUkYIoCSdPPZySVK0AgALUwNA= Date: Thu, 18 Dec 2014 10:34:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D602CE3@ESESSMB209.ericsson.se> References: <20141216051436.11868.42630.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8B296009@FR712WXCHMBA11.zeu.alcatel-lucent.com> <491C745F-569F-49C9-B3D5-45F402FE7AE9@neustar.biz> <949EF20990823C4C85C18D59AA11AD8B296102@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B296102@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvje7ZtZNCDM6ss7GYdvIys0Xjoqes Fk8bzzI6MHu0PtvL6rFkyU8mjx0Nz5kDmKO4bFJSczLLUov07RK4MqZ9XctecMu4YtPVi+wN jG81uhg5OSQETCQenjzDAmGLSVy4t56ti5GLQ0jgCKPE4wsXoJwljBK7mvYCVXFwsAlYSHT/ 0wZpEBFIlzjfsJAZxGYWUJU41/gYbJCwgIfEq6atbCDlIgKeEofPyEKUW0m8b3/HCGKzAJVf mnkNzOYV8JV4cPQzO8Sq00wS204cAEtwCkRL7J/ZA2YzAh33/dQaJohd4hK3nsxngjhaQGLJ nvPMELaoxMvH/1ghbCWJxiVPWCHqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrNQjJ2FpKW WUhaZiFpWcDIsopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMKYObvmtuoPx8hvHQ4wCHIxK PLwGzpNChFgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo2pC zK73f55vmCJ2Y8Jbbte01G39PaoLudeIz0qZdXT17j/HdvTtWc3yfcUllTtsblNEuzTff9yu WuP3kG+KRoqL6Ylfr08LxF4/fH/H3O74io2twYucb0TWexR9+qk3he/EraPaWikPGHPuWiis aTZWbEr2u6I76/uVzf5vjrVcX2lnKndFtlmJpTgj0VCLuag4EQDD7M2HigIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/-jf_B16phSrhoECc5MPZ8ZFfRxs Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 10:34:59 -0000 Hi, I agree with Keith. If we see 3GPP as the main intended customer of some/al= l of these drafts, we really need to get input from 3GPP before publishing = them as RFCs. Regards, Christer -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keit= h) Sent: 16 December 2014 18:19 To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt As far as 3GPP is concerned - there would be no unauthenticated usage, beca= use in 3GPP it would not be an emergency call. Nor would there be any roaming support, in terms of reaching an emergency s= ervice provider in the country in which you are, unless of course you use l= ost first. But in any case, I see no restriction in the document that says it can only= be used OTT, and therefore not using the IMS SIP stack. Keith=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: 16 December 2014 16:11 > To: DRAGE, Keith (Keith) > Cc: Marc Linsner; ecrit@ietf.org > Subject: Re: [Ecrit] I-D Action:=20 > draft-ietf-ecrit-additional-data-27.txt >=20 > -car-crash does not need any 3GPP support. A 3rd party telematics=20 > company such as OnStar can do it by themselves. >=20 > There could be some support for it in 3GPP, but we don't need it. >=20 > Brian >=20 > > On Dec 16, 2014, at 10:32 AM, DRAGE, Keith (Keith) > wrote: > >=20 > > One concern I have about the discussion that has just > occurred is that it is assuming the application within an environment=20 > where this usage has not yet been specified. > >=20 > > The assumed enviroment is within a car using the cellular > network, and > > this expectation exists when we get to > >=20 > > https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ > > https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ > >=20 > > It has to be assumed that the cellular network will > normally be a 3GPP network. However no work has yet started in 3GPP on=20 > how this would be supported in such a network. > Therefore assumptions (from both sides of the previous > discussion) are being made that this will be compatible with whatever=20 > 3GPP will decide when it eventually opens the work. > >=20 > > Given that all the participants in the dialog are 3GPP > members, would it not be an idea to get the required 3GPP work started=20 > and hold this work until that occurs. > >=20 > > Regards > >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of > Marc Linsner > >> (mlinsner) > >> Sent: 16 December 2014 14:00 > >> To: ecrit@ietf.org > >> Subject: [Ecrit] Fwd: I-D Action:=20 > >> draft-ietf-ecrit-additional-data-27.txt > >>=20 > >> All, > >>=20 > >> I asked Randy to submit the new version to correct one error that=20 > >> showed up the idnits process. Idnits was claiming that > >> RFC3325 should be an informative reference vs. normative. > >>=20 > >> I'll proceed sending to the IESG. > >>=20 > >> -Marc- > >>=20 > >> Begin forwarded message: > >>=20 > >>> From: > >>> Subject: [Ecrit] I-D Action:=20 > draft-ietf-ecrit-additional-data-27.txt > >>> Date: December 16, 2014 at 12:14:36 AM EST > >>> To: > >>> Cc: > >>>=20 > >>>=20 > >>> A New Internet-Draft is available from the on-line > >> Internet-Drafts directories. > >>> This draft is a work item of the Emergency Context > >> Resolution with Internet Technologies Working Group of the IETF. > >>>=20 > >>> Title : Additional Data Related to an=20 > >> Emergency Call > >>> Authors : Randall Gellens > >>> Brian Rosen > >>> Hannes Tschofenig > >>> Roger Marshall > >>> James Winterbottom > >>> Filename : draft-ietf-ecrit-additional-data-27.txt > >>> Pages : 105 > >>> Date : 2014-12-15 > >>>=20 > >>> Abstract: > >>> When an emergency call is sent to a Public Safety > Answering Point > >>> (PSAP), the device that sends it, as well as any > >> application service > >>> provider in the path of the call, or access network > >> provider through > >>> which the call originated may have information about the > call, the > >>> caller or the location which the PSAP may be able to use. This=20 > >>> document describes data structures and a mechanism to > convey such > >>> data to the PSAP. The mechanism uses a Uniform Resource > >> Identifier > >>> (URI), which may point to either an external resource or > >> an object in > >>> the body of the SIP message. The mechanism thus allows > >> the data to > >>> be passed by reference (when the URI points to an > >> external resource) > >>> or by value (when it points into the body of the > message). This > >>> follows the tradition of prior emergency services > standardization > >>> work where data can be conveyed by value within the call > signaling > >>> (i.e., in body of the SIP message) and also by reference. > >>>=20 > >>>=20 > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ > >>>=20 > >>> There's also a htmlized version available at: > >>> http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-27 > >>>=20 > >>> A diff from the previous version is available at: > >>>=20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-27 > >>>=20 > >>>=20 > >>> Please note that it may take a couple of minutes from the time of=20 > >>> submission until the htmlized version and diff are > >> available at tools.ietf.org. > >>>=20 > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>>=20 > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >>=20 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >>=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Dec 18 16:43:21 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABFD1ACC87; Thu, 18 Dec 2014 16:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.497 X-Spam-Level: X-Spam-Status: No, score=-104.497 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 9D8Rgt4jVSc2; Thu, 18 Dec 2014 16:43:11 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD851AC82C; Thu, 18 Dec 2014 16:43:11 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id EE47618008C; Thu, 18 Dec 2014 16:42:46 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141219004246.EE47618008C@rfc-editor.org> Date: Thu, 18 Dec 2014 16:42:46 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/CQe51fGuQ1lSpCAKFMZolwAjPSU Cc: drafts-update-ref@iana.org, ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] RFC 7406 on Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 00:43:16 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7406 Title: Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices Author: H. Schulzrinne, S. McCann, G. Bajko, H. Tschofenig, D. Kroeselberg Status: Informational Stream: IETF Date: December 2014 Mailbox: hgs+ecrit@cs.columbia.edu, smccann@blackberry.com, gabor.bajko@mediatek.com, Hannes.Tschofenig@gmx.net, dirk.kroeselberg@siemens.com Pages: 25 Characters: 52779 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ecrit-unauthenticated-access-10.txt URL: https://www.rfc-editor.org/rfc/rfc7406.txt This document provides a problem statement, introduces terminology, and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network. This document is a product of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Dec 22 08:19:40 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7561A0687 for ; Mon, 22 Dec 2014 08:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 sO_mEjdAZP8D for ; Mon, 22 Dec 2014 08:19:37 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8BB1A09CF for ; Mon, 22 Dec 2014 08:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=351; q=dns/txt; s=iport; t=1419265177; x=1420474777; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=TncTef6ituWCoEZ5Td/c6xa6MbNLmidE0thfmazgwI4=; b=XRuIK3cFUEw617uu7cLQadYK+WD5cXoQXJvugR3tBWnh/p8SNdINGimp VEBfQ0XwXRohBYnFrFBXk1XCd7TyoFihUlaeqODBVYW2jWSbjA5VVJQST wHQHtXSrUsPKZ3PwwzVBZGZ+JIHDMQ0W2tLKx92MjO+WlcKrD6EO2XkY1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAFFEmFStJV2S/2dsb2JhbABbgwaBLs1QFgEBAQEBfYQTOlEBPkInBIg/qlClSAEBAQEGAQEBAQEBARuTD4ETBY4RiHKBDYJkjVoig26CNH4BAQE X-IronPort-AV: E=Sophos;i="5.07,624,1413244800"; d="scan'208";a="107595799" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP; 22 Dec 2014 16:19:24 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sBMGJNCJ024535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Dec 2014 16:19:24 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.75]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 10:19:23 -0600 From: "Marc Linsner (mlinsner)" To: "ecrit@ietf.org" Thread-Topic: draft-winterbottom-ecrit-priv-loc Thread-Index: AQHQHgMMmfqWkZ5fL0qqiOEB4bJLng== Date: Mon, 22 Dec 2014 16:19:23 +0000 Message-ID: <710AB81D-179D-49C2-AE97-BB6D416F2205@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.103.240] Content-Type: text/plain; charset="us-ascii" Content-ID: <68B9DC9D2C25594796A8CFEB243EA8A4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/5ohTLJf9EXRneRdVUpfEhEeOQ58 Subject: [Ecrit] draft-winterbottom-ecrit-priv-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 16:19:38 -0000 All, There is consensus to move forward with this work. The chairs will request to the milestone addition for this draft to be subm= itted to the IESG by September 2015, of course earlier completion is always= a good thing. James, please submit a version as an IETF draft and we will approve. Thanks, Marc & Roger ECRIT co-chairs= From nobody Mon Dec 22 09:41:26 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900491ABC0F for ; Mon, 22 Dec 2014 09:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 J0j32aAQdTMv for ; Mon, 22 Dec 2014 09:41:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DD31ABC10 for ; Mon, 22 Dec 2014 09:41:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141222174122.6008.53874.idtracker@ietfa.amsl.com> Date: Mon, 22 Dec 2014 09:41:22 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/xEKum4mSKlNmQF5hvsaHOpJVN88 Subject: [Ecrit] Milestones changed for ecrit WG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 17:41:24 -0000 Added milestone "Submit 'A Routing Request Extension for the HELD Protocol' to the IESG for consideration as a Standards Track RFC", due September 2015. URL: http://datatracker.ietf.org/wg/ecrit/charter/ From nobody Mon Dec 22 14:20:29 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351D71A87F1 for ; Mon, 22 Dec 2014 14:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 jep2YQWurAck for ; Mon, 22 Dec 2014 14:20:22 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471A11A87EF for ; Mon, 22 Dec 2014 14:20:22 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id eu11so6659082pac.22 for ; Mon, 22 Dec 2014 14:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=HSZ/fmNor8Bh0vlkqppE4It7OQ1R+Ld/Viy2+vx5JMU=; b=VlwH54yP347GzWW+K7g7VxtuIJqWNmZ6cuITAHi5orX3f/Zk5P0OJs69Rijmxo7GjA kDDfq26XsqkjTkXRvlByRcGxbFOJxP9ZQ/XgZchNh6DRID6pGKIAE5CFCdrzKdB/QmGX nQ/RQeGwpthBepHgsVlcJGV50VhT0oer2YC616zYN+49geVPGY4pwITeNCOH0cgM2eMX DvIshSO5EAbpoj5G8KxOYrdwbFJsfFLRpQ8PRywC63TIBQepomqG8Txub9yrv54s55Zf 15/91rC9eVlMqlwWS3nghZl65ywiRQdm2fGxtYgF2x9bVr9KEIXAh8cROvNGajDIC+P3 C0iA== X-Received: by 10.68.69.78 with SMTP id c14mr38149834pbu.68.1419286821489; Mon, 22 Dec 2014 14:20:21 -0800 (PST) Received: from [10.182.14.35] ([101.171.240.29]) by mx.google.com with ESMTPSA id i9sm16035823pdj.27.2014.12.22.14.20.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Dec 2014 14:20:20 -0800 (PST) References: <710AB81D-179D-49C2-AE97-BB6D416F2205@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <710AB81D-179D-49C2-AE97-BB6D416F2205@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1C6686D9-3E71-4E27-B10B-5358D9BDD545@gmail.com> X-Mailer: iPhone Mail (11D201) From: James Winterbottom Date: Tue, 23 Dec 2014 09:20:17 +1100 To: "Marc Linsner (mlinsner)" Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/i-RRYDuCxChBv7GAGRHnLWlUrLM Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 22:20:24 -0000 I have relabeled it draft-ietf-ecrit-held-routing-00 but it is the same draf= t as above with a correction to the xml. Cheers James Sent from my iPhone > On 23 Dec 2014, at 3:19 am, "Marc Linsner (mlinsner)" = wrote: >=20 > All, >=20 > There is consensus to move forward with this work. >=20 > The chairs will request to the milestone addition for this draft to be sub= mitted to the IESG by September 2015, of course earlier completion is always= a good thing. >=20 > James, please submit a version as an IETF draft and we will approve. >=20 > Thanks, >=20 > Marc & Roger > ECRIT co-chairs > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Tue Dec 23 01:36:33 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9261A8A55 for ; Tue, 23 Dec 2014 01:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 NTMv3xnoivfL for ; Tue, 23 Dec 2014 01:36:29 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06741A8A65 for ; Tue, 23 Dec 2014 01:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1419327389; x=1450863389; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=a0LnOL6rvlokmpd6wGhOjjnnLPjk77aonGTn7NPjqvM=; b=Qsh4q55Xu6H6lqChjMJsnloK3tcigfI0Ks7fQfQQBvJxZvMStazdiS1L siFDqKuxuXlsQOyRClj8C/W3hfYzu1l9XqVBZ75BCTxXv8Q+DxJ9ouzg+ j2HoK3uTXhXkDGq+s9nA/kdsAIPZqWFJypHlChuHEmaUkuIQUWRi946Mw M=; X-IronPort-AV: E=McAfee;i="5600,1067,7660"; a="81241964" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 23 Dec 2014 01:36:29 -0800 X-IronPort-AV: E=Sophos;i="5.07,630,1413270000"; d="scan'208";a="31356786" Received: from nasanexm01e.na.qualcomm.com ([10.85.0.31]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Dec 2014 01:36:28 -0800 Received: from [172.20.0.45] (10.80.80.8) by NASANEXM01E.na.qualcomm.com (10.85.0.31) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 23 Dec 2014 01:36:26 -0800 Message-ID: In-Reply-To: <710AB81D-179D-49C2-AE97-BB6D416F2205@cisco.com> References: <710AB81D-179D-49C2-AE97-BB6D416F2205@cisco.com> X-Mailer: Eudora for Mac OS X Date: Tue, 23 Dec 2014 01:36:23 -0800 To: James Winterbottom , "Marc Linsner (mlinsner)" , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01E.na.qualcomm.com (10.85.0.31) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/gphmizILkovzbjdEITy-5O5nTp0 Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 09:36:31 -0000 I have a technical question about the draft. From my reading, it appears that the extension is to add an empty element to a HELD request, and if the server supports it, it includes a element with all possible values that could be returned. Is this correct or am I missing something? If it is correct, why is the element empty rather than contain the desired service? Wouldn't it be simpler to include the specific service of interest (e.g., 'sos'), as in the element from LoST and then the server only needs to look that up and return only that? At 4:19 PM +0000 12/22/14, Marc Linsner (mlinsner) wrote: > All, > > There is consensus to move forward with this work. > > The chairs will request to the milestone addition for this draft to > be submitted to the IESG by September 2015, of course earlier > completion is always a good thing. > > James, please submit a version as an IETF draft and we will approve. > > Thanks, > > Marc & Roger > ECRIT co-chairs > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Go placidly amid the noise and waste, and remember what value there may be in owning a piece thereof. --National Lampoon From nobody Tue Dec 23 02:48:34 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76B21A036D for ; Tue, 23 Dec 2014 02:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 S5pO1Insf0b3 for ; Tue, 23 Dec 2014 02:48:28 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46481A02F1 for ; Tue, 23 Dec 2014 02:48:27 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id bj1so7682066pad.37 for ; Tue, 23 Dec 2014 02:48:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eUURtEn4LXA0MLps4wn7uqHQMwQA/UttRfzeInagL10=; b=WgtCAIJykvDgjNPS1L/tPwBvWgaM0bqcXwL0jhmFsHpRRO2HeX4RtvWL6dQnH1eS0E rnb8ScclaPKdh2uuvhgw+nmGP62f2rgGkRL4ZaWiFOxCwHpmUklxH8IvIVyEuM2hg0QX +MpTB1F9YdptGHMjmHpSWVbvCWiTF4X3GTZkwuWrtxum8M6XNak4TNK7Rn4SMhghebMn jbR9zqaOChsxQaZLTvKpdBfjFHhBb505UFpT6ikkQqx5nnfD9TLdPjNClCdMsD1uaVU8 4bsNYGuVZDKoinCO6JafOuvRENcu5tfVFtjmgn9yb84Bfeti0Hn6GwY0q1xGJ7h/rcra wyWQ== X-Received: by 10.70.94.104 with SMTP id db8mr42622341pdb.32.1419331707143; Tue, 23 Dec 2014 02:48:27 -0800 (PST) Received: from [192.168.1.13] (124-149-121-203.dyn.iinet.net.au. [124.149.121.203]) by mx.google.com with ESMTPSA id e9sm19627200pdp.59.2014.12.23.02.48.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Dec 2014 02:48:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: James Winterbottom In-Reply-To: Date: Tue, 23 Dec 2014 21:48:22 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <626CEBB4-47D6-4F5A-9346-17143C40E92B@gmail.com> References: <710AB81D-179D-49C2-AE97-BB6D416F2205@cisco.com> To: Randall Gellens X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/VGr6XniY2xHy6ZxYOshGUvpEBNM Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 10:48:30 -0000 Hi Randy, That could work, but that implies that you know what services that the = system supports. I think that I would rather make an assumption that emergency and the = subset thereof are all we support and leave an extension point for = people to extend from if the need ever arises. Cheers James > On 23 Dec 2014, at 8:36 pm, Randall Gellens = wrote: >=20 > I have a technical question about the draft. =46rom my reading, it = appears that the extension is to add an empty = element to a HELD request, and if the server = supports it, it includes a element with all = possible values that could be returned. Is this correct or am I missing = something? If it is correct, why is the = element empty rather than contain the desired service? Wouldn't it be = simpler to include the specific service of interest (e.g., 'sos'), as in = the element from LoST and then the server only needs to look = that up and return only that? >=20 >=20 > At 4:19 PM +0000 12/22/14, Marc Linsner (mlinsner) wrote: >=20 >> All, >>=20 >> There is consensus to move forward with this work. >>=20 >> The chairs will request to the milestone addition for this draft to = be submitted to the IESG by September 2015, of course earlier completion = is always a good thing. >>=20 >> James, please submit a version as an IETF draft and we will approve. >>=20 >> Thanks, >>=20 >> Marc & Roger >> ECRIT co-chairs >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > Go placidly amid the noise and waste, and remember what value there = may > be in owning a piece thereof. --National = Lampoon From nobody Tue Dec 23 04:08:59 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9251ACDC2 for ; Tue, 23 Dec 2014 04:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 UqzcTKzB_gEI for ; Tue, 23 Dec 2014 04:08:48 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3C21A6FEF for ; Tue, 23 Dec 2014 04:08:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1419336526; x=1450872526; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=yGCdYqkTJzKkBisLusVh3HVEiIQxjg30d3GUFIzx3LI=; b=L5SuVsGcpGsxu3+EkQL4oFlNlexJRzl7Vurj39awDVAdf77q9aPJRjxU /M1akhYwXD+y8gDxFSKLlQmioHYVAvfeg8Deq/H64572aFP/HjZ2Kik7t 2iD2+hM+pqhU1x0ZgRRW0aUV9lcFopCgIXnpp966snAivADN0DcO7+kSx 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7660"; a="81248722" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Dec 2014 04:08:45 -0800 X-IronPort-AV: E=Sophos;i="5.07,631,1413270000"; d="scan'208";a="777873964" Received: from nasanexm02d.na.qualcomm.com ([10.46.200.113]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Dec 2014 04:08:44 -0800 Received: from [172.20.0.45] (10.80.80.8) by NASANEXM02D.na.qualcomm.com (10.46.200.113) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 23 Dec 2014 04:08:43 -0800 Message-ID: In-Reply-To: <626CEBB4-47D6-4F5A-9346-17143C40E92B@gmail.com> References: <710AB81D-179D-49C2-AE97-BB6D416F2205@cisco.com> <626CEBB4-47D6-4F5A-9346-17143C40E92B@gmail.com> X-Mailer: Eudora for Mac OS X Date: Tue, 23 Dec 2014 04:08:35 -0800 To: James Winterbottom From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM02D.na.qualcomm.com (10.46.200.113) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/YKvNiCOC6GEQj1-LEWnQOoXe9iE Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 12:08:57 -0000 Hi James, So the draft currently specifies that only sos and children of sos are returned? I'd missed that when I read and re-read the draft. If so, that's fine with me, but maybe it can be made more clear. For example, Section 4 says: The routing information in the location response consists of one or more service elements which is identified by a service name. The service name is a URI and might contain a general emergency service urn such as urn:service:sos or might contain a specific service urn. To me, this says that sos is just an example of a service that might be returned. What might be better would be to modify my suggestion so that a element can be included, and if not, the default is 'sos' and any children of 'sos'. At 9:48 PM +1100 12/23/14, James Winterbottom wrote: > Hi Randy, > > That could work, but that implies that you know what services that > the system supports. > I think that I would rather make an assumption that emergency and > the subset thereof are all we support and leave an extension point > for people to extend from if the need ever arises. > > > Cheers > James > > >> On 23 Dec 2014, at 8:36 pm, Randall Gellens wrote: >> > > I have a technical question about the draft. From my reading, > it appears that the extension is to add an empty > element to a HELD request, and if the > server supports it, it includes a element with > all possible values that could be returned. Is this correct or am > I missing something? If it is correct, why is the > element empty rather than contain the > desired service? Wouldn't it be simpler to include the specific > service of interest (e.g., 'sos'), as in the element from > LoST and then the server only needs to look that up and return only > that? > > >> >> At 4:19 PM +0000 12/22/14, Marc Linsner (mlinsner) wrote: >> >>> All, >>> >>> There is consensus to move forward with this work. >>> >>> The chairs will request to the milestone addition for this draft >>> to be submitted to the IESG by September 2015, of course earlier >>> completion is always a good thing. >>> >>> James, please submit a version as an IETF draft and we will approve. >>> >>> Thanks, >>> >>> Marc & Roger >>> ECRIT co-chairs >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> Go placidly amid the noise and waste, and remember what value there may >> be in owning a piece thereof. --National Lampoon -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Those are my principles. If you don't like them I have others. --Groucho Marx From nobody Tue Dec 23 06:25:47 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18A21ACEC1; Tue, 23 Dec 2014 06:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 3AZf9cgC9reK; Tue, 23 Dec 2014 06:25:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7791ACEBD; Tue, 23 Dec 2014 06:25:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141223142544.22766.66438.idtracker@ietfa.amsl.com> Date: Tue, 23 Dec 2014 06:25:44 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/jXOM9KqJZDUvQjaalQ8-KNFlppw Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-held-routing-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 14:25:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : A Routing Request Extension for the HELD Protocol Authors : James Winterbottom Hannes Tschofenig Laura Liess Filename : draft-ietf-ecrit-held-routing-00.txt Pages : 13 Date : 2014-12-22 Abstract: In many circumstances public LoST servers or a distributed network of forest guides linking public LoST servers is not available. In such environments the general ECRIT calling models breakdown. However, location servers operating in these areas are often privy to the necessary information to reach emergency and other services. This document describes a solution where by the routing information may be obtained from a location server using a simple extension to the HELD protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-held-routing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-held-routing-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 30 14:14:52 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842BF1A877F for ; Tue, 30 Dec 2014 14:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 wSDz-idvdz3r for ; Tue, 30 Dec 2014 14:14:48 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD651A877D for ; Tue, 30 Dec 2014 14:14:48 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id eu11so20110603pac.22 for ; Tue, 30 Dec 2014 14:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fz6na5Tf+k16i4WOGQMkaaOOO7mU7yCFuD+mIZzC22s=; b=gBNu0n5Hxefjeep9JsEZ0o9bPGqc9WgjoFVhJVCakPXwrEPdcbMyrdD7FoSfzEeQWP DB7LwPNBWRVxFvSMicd804C16vIIuD+rFsdM2dlZAsVtBrvLsuAS0juYLMZpd/qoCmSY Pu3oM75uxtcB+0nFdjfcSnerMaMLBRsbbbGtIx/AF8oVA68uCQgLZ2o4k+SW+b4LfCx0 gay8uxwyqVxecuc0Pn3jztXWsyHkmK6ciT0r0+rvWFX4NpO9x4Qbx4mPQLoAMoBMm0OZ FSLcbaFBVIiJLZNoBAVYzHZSVgBojEMH2NCOtmWJZz/zFMUTdwmCQomAQxJaZxBBBdoK 0gRw== X-Received: by 10.70.101.165 with SMTP id fh5mr97613410pdb.148.1419977687883; Tue, 30 Dec 2014 14:14:47 -0800 (PST) Received: from [192.168.1.13] (124-149-121-203.dyn.iinet.net.au. [124.149.121.203]) by mx.google.com with ESMTPSA id oc16sm39340253pdb.41.2014.12.30.14.14.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Dec 2014 14:14:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: James Winterbottom In-Reply-To: Date: Wed, 31 Dec 2014 09:14:42 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <1029FE0E-13DD-4EE8-A55D-88BCE6FBC43E@gmail.com> References: <710AB81D-179D-49C2-AE97-BB6D416F2205@cisco.com> <626CEBB4-47D6-4F5A-9346-17143C40E92B@gmail.com> To: Randall Gellens X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/bJrNMiCsmfNNgrtpzUrWNZeRZZA Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 22:14:50 -0000 That=E2=80=99s a really good idea Randy, I shall do that. The other idea I have been toying with is, if the LIS has it, allowing = the LIS to return the address of the LoST server in place of the routing = information itself. This would allow areas that deploy LoST servers but = not forest guide networks, islands if you like, to still have the = authoritative server queried directly. This won=E2=80=99t work in all = cases, as the draft describes, but it could assist in some environments. Cheers James > On 23 Dec 2014, at 11:08 pm, Randall Gellens = wrote: >=20 > Hi James, >=20 > So the draft currently specifies that only sos and children of sos are = returned? I'd missed that when I read and re-read the draft. If so, = that's fine with me, but maybe it can be made more clear. >=20 > For example, Section 4 says: >=20 > The routing information in the location response consists of one or > more service elements which is identified by a service name. The > service name is a URI and might contain a general emergency service > urn such as urn:service:sos or might contain a specific service urn. >=20 > To me, this says that sos is just an example of a service that might = be returned. >=20 > What might be better would be to modify my suggestion so that a = element can be included, and if not, the default is 'sos' and = any children of 'sos'. >=20 >=20 > At 9:48 PM +1100 12/23/14, James Winterbottom wrote: >=20 >> Hi Randy, >>=20 >> That could work, but that implies that you know what services that = the system supports. >> I think that I would rather make an assumption that emergency and the = subset thereof are all we support and leave an extension point for = people to extend from if the need ever arises. >>=20 >>=20 >> Cheers >> James >>=20 >>=20 >>> On 23 Dec 2014, at 8:36 pm, Randall Gellens = wrote: >>>=20 >> > I have a technical question about the draft. =46rom my reading, = it appears that the extension is to add an empty = element to a HELD request, and if the server = supports it, it includes a element with all = possible values that could be returned. Is this correct or am I missing = something? If it is correct, why is the = element empty rather than contain the desired service? Wouldn't it be = simpler to include the specific service of interest (e.g., 'sos'), as in = the element from LoST and then the server only needs to look = that up and return only that? >> > >>>=20 >>> At 4:19 PM +0000 12/22/14, Marc Linsner (mlinsner) wrote: >>>=20 >>>> All, >>>>=20 >>>> There is consensus to move forward with this work. >>>>=20 >>>> The chairs will request to the milestone addition for this draft to = be submitted to the IESG by September 2015, of course earlier completion = is always a good thing. >>>>=20 >>>> James, please submit a version as an IETF draft and we will = approve. >>>>=20 >>>> Thanks, >>>>=20 >>>> Marc & Roger >>>> ECRIT co-chairs >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>>=20 >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself = only >>> -------------- Randomly selected tag: --------------- >>> Go placidly amid the noise and waste, and remember what value there = may >>> be in owning a piece thereof. --National = Lampoon >=20 >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > Those are my principles. If you don't like them I have others. > --Groucho Marx