From nobody Wed Feb 4 13:27:08 2015 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 459BD1A88EF; Wed, 4 Feb 2015 13:27:05 -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 x39MsRAMO4RO; Wed, 4 Feb 2015 13:27:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD5E1A88C8; Wed, 4 Feb 2015 13:27:03 -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.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150204212703.11878.25982.idtracker@ietfa.amsl.com> Date: Wed, 04 Feb 2015 13:27:03 -0800 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-28.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: Wed, 04 Feb 2015 21:27:05 -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-28.txt Pages : 105 Date : 2015-02-04 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-28 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-28 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 Thu Feb 5 09:21:44 2015 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 0F61A1A07BC for ; Thu, 5 Feb 2015 09:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 U3B2y2v8eY9Y for ; Thu, 5 Feb 2015 09:21:40 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 4D0A01A0451 for ; Thu, 5 Feb 2015 09:21:40 -0800 (PST) Received: from [192.168.10.147] ([12.68.40.194]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MMShK-1YHn262MFq-008Hzu for ; Thu, 05 Feb 2015 18:21:38 +0100 Message-ID: <54D3A69A.1020209@gmx.net> Date: Thu, 05 Feb 2015 18:21:30 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "ecrit@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aUJNaXd0F8cxf7fwuRJvwIXwgllulbS11" X-Provags-ID: V03:K0:1AqcigEMgI5Qn/K3gf6KpCskMRfwY++iD5jGmhdDDvzNn1pemmE 2NRac2GetL1WaWs4i2ZUGZ0nMuXdJht26zyO0NyybNhZHml+MCajZDymoV/FE5gY/gtq+HR d5gEocCH8Eiyl5iY986I9DYbCql2OdnBYwJWsM7Hv7ZmPm1XmzS8SR3VOO+K5OsH8LcfBaV 3/EdxaNadfN3u5t7cRrRg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ecrit] draft-ietf-ecrit-additional-data-28.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, 05 Feb 2015 17:21:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aUJNaXd0F8cxf7fwuRJvwIXwgllulbS11 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have submitted a draft update to fix a bug in the XML schema. As you can see from the diff the following changes have been made: * Fixed a typo in the element name. * Added the "" construct in the SubscriberInfoType * Removed the element from the and elements * Updated the examples (removed the element) * Updated description of the element to reflect the XML schema change. Thanks to Amursana Khiyod, Robert Sherry, Frank Rahoi, Scott Ross, and Tom Klepetka who spotted the bugs. Ciao Hannes --aUJNaXd0F8cxf7fwuRJvwIXwgllulbS11 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 iQEcBAEBCgAGBQJU06acAAoJEGhJURNOOiAt2sQIAID4/3Ce1WBBLVNy7tQRwe7b WkS+3RgtawOoxMzrhK99MaOH0pcbwWEFaUBfzBiiDh/9OSrQOHpErJ5n0jpP5cZp C85I8UN/PZKaS4GZ5VgbbPRbgQ6pwcguvuujVdf4JzPPm1KVIncEKIBuytiAQUuV o4luoi0dlHbAwlC9EpkqHiV++qMhTHYqOWKhMX1FP/vRM6PTXmAh5Xndov/eQGc7 r+0cRLoBJ/obPUw0c6gI9AFJR6476d1DL0Fb2KgBGBKCtfFdM24336fwRoyovdGj Xmn8QyQzBjLaXFhOtjIzvkEhk5eEYvZXxTyB4wu0f3FA+OqOVXZOMXex88TsQ10= =U+y7 -----END PGP SIGNATURE----- --aUJNaXd0F8cxf7fwuRJvwIXwgllulbS11-- From nobody Tue Feb 17 08:32:08 2015 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 BF5AD1A88A5 for ; Tue, 17 Feb 2015 08:32:06 -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 PcUOI7JfYolT for ; Tue, 17 Feb 2015 08:32:05 -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 C03A21A1B13 for ; Tue, 17 Feb 2015 08:32:04 -0800 (PST) Received: from [192.168.131.128] ([80.92.119.127]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M8e5P-1Xacl71ZLv-00wHQE for ; Tue, 17 Feb 2015 17:32:02 +0100 Message-ID: <54E36CC7.4050709@gmx.net> Date: Tue, 17 Feb 2015 17:31:03 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "ecrit@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3FdHWQ6nfmLL3hPgTp5e4SoNSd0u7M0gX" X-Provags-ID: V03:K0:c94yVJWTWSYakrbMWTKjeyvrMuWGndLubr9X4ae02tyJFzhgNXX ZZVvJ9yn57iP+0+PJVm8cKLLVdMZn1Hr/PdKmhCGtusN85VgYKXiO3bnmD2cMbuCQcR4/18 TiOjf09X/Kq7y5/HI47kDWR5f40GOZvMqneTNwrZuax5+9Xlk9QcW8L/3EkV0zwXPNF7USO sxK/PPQW7F38le3jl83Jg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ecrit] Status of "Additional Data Related to an Emergency Call" 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, 17 Feb 2015 16:32:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3FdHWQ6nfmLL3hPgTp5e4SoNSd0u7M0gX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Chairs, Hi all, I was wondering what the status of the additional data document in the ECRIT working group is. =46rom the tracker I noticed that no shepherd has been assigned yet, no write-up is available and the document has not yet left the working group= =2E It would be great to advance the document! Ciao Hannes --3FdHWQ6nfmLL3hPgTp5e4SoNSd0u7M0gX 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 iQEcBAEBCgAGBQJU42zHAAoJEGhJURNOOiAtcBAH/0nbegbLDLe7YKa6Xzk5DYYy KzHVxKIRKUKETP0AGrxDos26Ch9rcX2xvp2qyhiW9EdDGZ8it04fV/VCx6XqKE34 SQSaTkG3AzmbSKDO8uBdIS4DLAo8SDfF1ZbB37halo9a44iHVesODgGgFiIWTabP FC1xRUO98mZpMbbPNXAzy9M1YxKlXKgzvL5vAC+Vyh2CtloVtgwg4ayu1iNivsV+ eUuwOb7jr8rdclNApfhHcY+Z4BILRzLW2oWnbKgJJU6uZ4Q339Z/yg+qOkVNqKpR jzj1wi6GuR0WmR3Vzlxzn+dsJ2O8A6hNnOuiyx3bNZQG5ewOM9jP91kK9SOJS0g= =UKAK -----END PGP SIGNATURE----- --3FdHWQ6nfmLL3hPgTp5e4SoNSd0u7M0gX-- From nobody Tue Feb 17 08:45:20 2015 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 28CCF1A8974 for ; Tue, 17 Feb 2015 08:45: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 Tz4KJXMOaZrF for ; Tue, 17 Feb 2015 08:45:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 2778A1A88A5 for ; Tue, 17 Feb 2015 08:45:11 -0800 (PST) Received: from [192.168.131.128] ([80.92.119.127]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M2Ldk-1XY8eX09RM-00s6k6 for ; Tue, 17 Feb 2015 17:45:09 +0100 Message-ID: <54E36FCD.6060301@gmx.net> Date: Tue, 17 Feb 2015 17:43:57 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "ecrit@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vLpBp1ri5lWejFsnJdoBqcCMl2o9xxua5" X-Provags-ID: V03:K0:7vu6ZlGeXbY6LlKZvteZCVn37kbxdgiH9gpTKOdwvWa34itNVX5 XQjJv0d0UuG6Qc8mgPYzuJET/GQB3e/hl1K0TTWL9/Ikg3ZcZ8Q/egHOpK7Fes6Jb/A4RTt CRYPy7GeWaGJlJDo0af7ZtLm/aWPT2QLft2eLh6PbSKH7TaVo78vpcsDhy8OZmckIeORucS 4qeOCQjXhRHkqbA48W0jA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ecrit] car-crash & ecrit-ecall drafts 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, 17 Feb 2015 16:45:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vLpBp1ri5lWejFsnJdoBqcCMl2o9xxua5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FWIW, I would like to see these two documents to advance: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ I see no need to create a dependency on 3GPP work since there are other customers for these documents. Ciao Hannes --vLpBp1ri5lWejFsnJdoBqcCMl2o9xxua5 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 iQEcBAEBCgAGBQJU42/OAAoJEGhJURNOOiAtUxgH/joabXt2uvm56C4LV43sQl/z vYwW3ivYteG++oexve/VCyl2MemaATjyk2UzvbWhv+aZ5mIE1qXqlf9eLCBdWxp1 uIsANg0Jb2CZDhZ4+bS/r7bvK4C1dPZGgnT+gRAL1yxn/QWkSwQtGMoI8qYrjCM5 15nITYr3EcTttz8Pt2UMGcYx5Aiy6kLdlpzF3yYEAIgR4oKQoMaOzf7a50RIwptk 0k4DIBirASmBdTshm8HcoTywG8T5ylGAD1DM5oQyjySBHlBFcnygGReOQSSCGA+Y Xs8uIzfC3brhWweFjfcwoQy+2Zz2y4VI4xJhDTXZMWIvzJ/G7wz/ip/uPvjmOjQ= =z2EN -----END PGP SIGNATURE----- --vLpBp1ri5lWejFsnJdoBqcCMl2o9xxua5-- From nobody Tue Feb 17 08:47:12 2015 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 C888D1A8F3E for ; Tue, 17 Feb 2015 08:47:09 -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 BPxB9EsszgkQ for ; Tue, 17 Feb 2015 08:47:03 -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 7434E1A8974 for ; Tue, 17 Feb 2015 08:47:03 -0800 (PST) Received: from [192.168.131.128] ([80.92.119.127]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Ma1pn-1Y8aMc0cmN-00LnqL for ; Tue, 17 Feb 2015 17:47:01 +0100 Message-ID: <54E3703D.8020309@gmx.net> Date: Tue, 17 Feb 2015 17:45:49 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "ecrit@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vIctsK9T2Shju23B1xK7Opn7IcUQ7ahj9" X-Provags-ID: V03:K0:1WCtnNvRYkGjXiOr8Ee+HtPXKozVV+H1A4oVP+iRGp1cnAS8ewF BcIkJ175IaM/3OD127mRCAJg6zz5P7JSFeCDM3lY5IEuQSK4VCYxpjpCiwTzfMhFimbZakP DKXSeus3WPBiPMIjCp/QZxPZgDHhr4/TQV3L8l3skzCCyR6jMzG7T4KONmg2ywB3NbbSodd 8pBWOJa7NyFAxR0K8JcTQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 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, 17 Feb 2015 16:47:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vIctsK9T2Shju23B1xK7Opn7IcUQ7ahj9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Chairs, what are the planned next steps for the " A Routing Request Extension for the HELD Protocol" document? Content-wise this is a fairly simple document and I am wondering whether the WGLC could be issued sooner rather than later? Ciao Hannes --vIctsK9T2Shju23B1xK7Opn7IcUQ7ahj9 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 iQEcBAEBCgAGBQJU43A9AAoJEGhJURNOOiAtqyMIAKQyx64zE0IlCdqrkWq46Ezo hIiyDRUclRkyAZc1xSIwp/keAkVUMC90YJ2imwFL4tGjttUsf2ssobPVEZ/kel7x RUuRwbQunDp3IIRvC8DpzgOWyzG1M/5eU0ixZ93G97RAPoZip9RbWRNplH+dQ9Y0 SuKGDC9+DJdNjIn2gpR0Wt2wzgEOKIrbZ7Tma4RGCXgUM+q/kgzViraOL4An6TZ4 yk7iH087afvviBD7He4ZMHrl5/Q6vrQvC2FEXmmzbTDDFmpSRFnlwxp7BvevBT5S PpxUngnu2Z1eMZPc/cl25q4wjQZZsr2do1GzhoDr2jgcqR1jVM5u3GkbGM24zkU= =oKBo -----END PGP SIGNATURE----- --vIctsK9T2Shju23B1xK7Opn7IcUQ7ahj9-- From nobody Wed Feb 18 01:27:26 2015 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 04F541A00A9 for ; Wed, 18 Feb 2015 01:27:25 -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 w2Ky7bZORxWE for ; Wed, 18 Feb 2015 01:27:23 -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 C41851A0360 for ; Wed, 18 Feb 2015 01:27:22 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-dc-54e45af80591 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BD.E2.04076.8FA54E45; Wed, 18 Feb 2015 10:27:20 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.39]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Wed, 18 Feb 2015 10:27:20 +0100 From: Ivo Sedlacek To: Hannes Tschofenig , "ecrit@ietf.org" Thread-Topic: [Ecrit] car-crash & ecrit-ecall drafts Thread-Index: AQHQStEfmWbMdDNjXEKfZOH3eRD5ZZz2Iveg Date: Wed, 18 Feb 2015 09:27:18 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112826424@ESESSMB301.ericsson.se> References: <54E36FCD.6060301@gmx.net> In-Reply-To: <54E36FCD.6060301@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.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvje6PqCchBq//alg0LnrKarF05z1W ByaPxZv2s3ksWfKTKYApissmJTUnsyy1SN8ugSvj6YLjbAW7uCsuTt/P3sA4hbuLkZNDQsBE on/VWyYIW0ziwr31bF2MXBxCAkcYJc4fecgE4SxmlPi26BgjSBWbgJ7ExC1HWEFsEYEwiTtr ZrCA2MICxhI3L65jh4ibSPydMAnKNpJ4dXwvM4jNIqAq0bW+AWgoBwevgK/E56nxIGEhATWJ JU+fgY3nFFCXeDP9D9hBjAKyElf/9ILFmQXEJW49mQ91qIDEkj3nmSFsUYmXj/+xgoyUEFCU WN4vB2IyC2hKrN+lD9GpKDGl+yHYMbwCghInZz5hmcAoOgvJ0FkIHbOQdMxC0rGAkWUVo2hx anFxbrqRkV5qUWZycXF+nl5easkmRmCEHNzy22oH48HnjocYBTgYlXh4DRiehAixJpYVV+Ye YpTmYFES57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbHSgT08JuuIUHlUfXromkhf 2STJnb/n+ieZ5L8Nfbn59G9NFUOHTWavfT5/bTQ7G1Sz9fSOl+9mylwzCP8zJ+TuVxebt3tj Upc6HtloN02x2Yj9KpuihN+kpdHe6zYtd8gQvnLWPWKBuNXviukdhRUqso3PJQPae9OXflj3 jG+D3ubDv9XNA5RYijMSDbWYi4oTASd+wjRxAgAA Archived-At: Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts 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: Wed, 18 Feb 2015 09:27:25 -0000 MSkgV2hhdCBhcmUgdGhvc2Ugb3RoZXIgY3VzdG9tZXJzIGZvciB0aGVzZSBkb2N1bWVudHM/IFRo YW5rIHlvdS4NCg0KMikgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1lY3JpdC1lY2FsbC8gaXRzZWxmIHN0YXRlczogDQotLS0tLS0tLS0tLS0tLS0NCmVDYWxsIGl0 c2VsZg0KICAgaXMgc3BlY2lmaWVkIGJ5ICoqKjNHUFAqKiogYW5kIENFTiBhbmQgdGhlc2Ugc3Bl Y2lmaWNhdGlvbnMgaW5jbHVkZSBmYXINCiAgIGdyZWF0ZXIgc2NvcGUgdGhhbiBpcyBjb3ZlcmVk IGhlcmUuDQotLS0tLS0tLS0tLS0tLS0NCnNvIHBlcmhhcHMgaXQgbWlnaHQgYmUgc2Vuc2libGUg dG8gbWFrZSBzdXJlIHRoYXQgM0dQUCByZXF1aXJlbWVudHMgYXJlIG1ldC4NCg0KS2luZCByZWdh cmRzDQoNCkl2byBTZWRsYWNlaw0KDQpUaGlzIENvbW11bmljYXRpb24gaXMgQ29uZmlkZW50aWFs LiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJt cyBzZXQgb3V0IGF0IHd3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lciANCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEVjcml0IFttYWlsdG86ZWNyaXQtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnDQpTZW50OiAxNy4gw7pub3Jh IDIwMTUgMTc6NDQNClRvOiBlY3JpdEBpZXRmLm9yZw0KU3ViamVjdDogW0Vjcml0XSBjYXItY3Jh c2ggJiBlY3JpdC1lY2FsbCBkcmFmdHMNCg0KRldJVywgSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGVz ZSB0d28gZG9jdW1lbnRzIHRvIGFkdmFuY2U6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWVjcml0LWNhci1jcmFzaC8NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZWNyaXQtZWNhbGwvDQoNCkkgc2VlIG5vIG5lZWQgdG8gY3Jl YXRlIGEgZGVwZW5kZW5jeSBvbiAzR1BQIHdvcmsgc2luY2UgdGhlcmUgYXJlIG90aGVyIGN1c3Rv bWVycyBmb3IgdGhlc2UgZG9jdW1lbnRzLg0KDQpDaWFvDQpIYW5uZXMNCg0K From nobody Wed Feb 18 01:53:49 2015 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 405541A86FC for ; Wed, 18 Feb 2015 01:53:47 -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 cVoYIhLKiiZ9 for ; Wed, 18 Feb 2015 01:53:45 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 4452C1A86F1 for ; Wed, 18 Feb 2015 01:53:45 -0800 (PST) Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MEWPx-1YM5Nd3gqH-00FjrB; Wed, 18 Feb 2015 10:53:41 +0100 Message-ID: <54E4607B.3030800@gmx.net> Date: Wed, 18 Feb 2015 10:50:51 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ivo Sedlacek , "ecrit@ietf.org" References: <54E36FCD.6060301@gmx.net> <39B5E4D390E9BD4890E2B3107900610112826424@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112826424@ESESSMB301.ericsson.se> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bosuN0PMEAcrHD6KIhfRSxhp3UlFMpOld" X-Provags-ID: V03:K0:LNqCmCy8zG5mUt0sG6Yuk2hofnqgv+lC4Xp336xHnWSLA/rSj3K G9BUT+uSP8N2sIO7yV/1ieY+JW+MqCOp0nRASnKYg/f/uiTLPdLoDAYPCrt3Qoi8xXQs01h ALcZrES4yywrrvxl+ECgh3/4hSNpVrb4gXAvdun4/1ts7gY1mWO4K2XBbv056P8CC+g6250 M6/NhXN8Ovys5JKvjD+yg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts 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: Wed, 18 Feb 2015 09:53:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bosuN0PMEAcrHD6KIhfRSxhp3UlFMpOld Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ivo, thanks for your quick response. On 02/18/2015 10:27 AM, Ivo Sedlacek wrote: > 1) What are those other customers for these documents? Thank you. >=20 > 2) https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ itself stat= es:=20 > --------------- > eCall itself > is specified by ***3GPP*** and CEN and these specifications include = far > greater scope than is covered here. > --------------- > so perhaps it might be sensible to make sure that 3GPP requirements are= met. This is the explanatory text that describes background, ongoing work and explains the larger context in ecrit-ecall. car-crash is the more generic of the two and even describes different deployment models; some of them are in use today (although using proprietary technology). If you read through the documents then you will notice that the added functionality (beyond what has already been standardized) is minimalistic and already at this point anticipating extensions for further crash data to be conveyed. Ciao Hannes >=20 > Kind regards >=20 > Ivo Sedlacek >=20 > This Communication is Confidential. We only send and receive email on t= he basis of the terms set out at www.ericsson.com/email_disclaimer=20 >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofe= nig > Sent: 17. =C3=BAnora 2015 17:44 > To: ecrit@ietf.org > Subject: [Ecrit] car-crash & ecrit-ecall drafts >=20 > FWIW, I would like to see these two documents to advance: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ > https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ >=20 > I see no need to create a dependency on 3GPP work since there are other= customers for these documents. >=20 > Ciao > Hannes >=20 --bosuN0PMEAcrHD6KIhfRSxhp3UlFMpOld 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 iQEcBAEBCgAGBQJU5GB7AAoJEGhJURNOOiAtxAIIAKVvL2RBP9HSe0XuuO3zcVNi 4tMz0dhAjkvIDCKLJzLSEQDEZ3LlAepnLtGjtOv+96K0EE6ENBPnzGq23/QK+x3M ZoSFr5NUD7gVu176D5ahp5gbd7h38SBmv705nFxycOvo5eo2iXAbc9IMclsKnu31 IVhtTbeOFLtbOIKSAghHYtH533tL4LbZQy+CD4fFKfu6Qp/WiQQApKvkB1RMZ3ap 5TN17AERQmTGrizQj1a0RbpwOGPNf6ScG9U//r5YeeMOLA7FWtx4g5mIeMZcuCzY 6GFGce1acSL8mWPAoyMI3jnkVY8WwbA5IEOOJm9S0usqEUbQbR1TijyfhxkCI8U= =YBJi -----END PGP SIGNATURE----- --bosuN0PMEAcrHD6KIhfRSxhp3UlFMpOld-- From nobody Thu Feb 19 06:21:46 2015 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 41D201A87AD for ; Thu, 19 Feb 2015 06:21:40 -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 ON9KuAfQZruR for ; Thu, 19 Feb 2015 06:21:38 -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 3AB701A878A for ; Thu, 19 Feb 2015 06:21:37 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id B2167231844; Thu, 19 Feb 2015 14:21:29 +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 t1JELUkZ002692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Feb 2015 15:21:32 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.88]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 19 Feb 2015 15:21:31 +0100 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , "ecrit@ietf.org" Thread-Topic: [Ecrit] car-crash & ecrit-ecall drafts Thread-Index: AQHQStEgLwi19QFokE+OT9X/7Bqr05z4CBVA Date: Thu, 19 Feb 2015 14:21:31 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A0F2A5E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <54E36FCD.6060301@gmx.net> In-Reply-To: <54E36FCD.6060301@gmx.net> 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: Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts 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, 19 Feb 2015 14:21:40 -0000 I believe the only realistic use case is where it is used through a 3GPP ac= cess. Unless you are saying you have an over the top use case where the 3GPP aspe= ct is not an emergency call, then you have an underlying dependency on 3GPP= , and in particular the successful use of the new URN values. Of particular criticality is what happens when the underlying system does n= ot understand the new URN, and therefore ignores the subtypes. 3GPP needs t= o tell you whether it is appropriate that that is always delivered to an or= dinary PSAP. Also an issue is whether service continuity is meant to operat= e on such a call, and if so, how. Unfortunately, you do not seem to have created sufficient interest in the 3= GPP community for anyone to start a related work item. That implies to me t= hat there is not yet consensus behind getting this right as a capability. Keith=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of=20 > Hannes Tschofenig > Sent: 17 February 2015 16:44 > To: ecrit@ietf.org > Subject: [Ecrit] car-crash & ecrit-ecall drafts >=20 > FWIW, I would like to see these two documents to advance: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ > https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ >=20 > I see no need to create a dependency on 3GPP work since there=20 > are other customers for these documents. >=20 > Ciao > Hannes >=20 > = From nobody Thu Feb 19 06:49:14 2015 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 ACF241A874E for ; Thu, 19 Feb 2015 06:49:12 -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 OMkvsVuinoNC for ; Thu, 19 Feb 2015 06:49:10 -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 179921A8547 for ; Thu, 19 Feb 2015 06:49:06 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-d6-54e5f7e033ee Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 94.69.04076.0E7F5E45; Thu, 19 Feb 2015 15:49:05 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.39]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0210.002; Thu, 19 Feb 2015 15:49:04 +0100 From: Ivo Sedlacek To: Hannes Tschofenig , "ecrit@ietf.org" Thread-Topic: [Ecrit] car-crash & ecrit-ecall drafts Thread-Index: AQHQS2DIjyZe/b5XRUKtti9BlP1C7Jz4DnTQ Date: Thu, 19 Feb 2015 14:49:03 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112827C4B@ESESSMB301.ericsson.se> References: <54E36FCD.6060301@gmx.net> <39B5E4D390E9BD4890E2B3107900610112826424@ESESSMB301.ericsson.se> <54E4607B.3030800@gmx.net> In-Reply-To: <54E4607B.3030800@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.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvje7D709DDLq3clk0LnrKarF05z1W ByaPxZv2s3ksWfKTKYApissmJTUnsyy1SN8ugSvj9uWVrAULJCp+nL7B1sB4QbyLkYNDQsBE YsMHji5GTiBTTOLCvfVsXYxcHEICRxglznRsYgZJCAksZpT4flcHxGYT0JOYuOUIK4gtIhAm cWfNDBYQW1jAWOLmxXXsEHETib8TJkHZRhKLFtxgA7FZBFQlOt5eBZvJK+ArsfvEXHaIZe2M Ej+ftjCBJDgF1CWe71gIZjMKyEpc/dPLCGIzC4hL3HoynwniUgGJJXvOM0PYohIvH/9jhXhG UWJ5vxyIySygKbF+lz5Ep6LElO6H7BBrBSVOznzCMoFRdBaSobMQOmYh6ZiFpGMBI8sqRtHi 1OLi3HQjI73Uoszk4uL8PL281JJNjMAIObjlt9UOxoPPHQ8xCnAwKvHwfuh8GiLEmlhWXJl7 iFGag0VJnNfO+FCIkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbgmYm6c7XWT7/3UCfF/NAP vzuflX4pLP0qNaez+N370NnX9zWaekx4dfAt2431ktaJyre6quxNJTUeTPQ+beZ6oKHukkeP 1Vtd7mOmdSLuTROPSgcafI83Vbq24Dvvp0+cIWfXtt9ezSPv2MPx5pw/64mPqv6bvi++NLND X0k79JLuHDOzJxFKLMUZiYZazEXFiQAR3213cQIAAA== Archived-At: Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts 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, 19 Feb 2015 14:49:12 -0000 SGVsbG8sDQoNCmFueSBhbnN3ZXIgdG8gdGhlIHF1ZXN0aW9uIDEpPw0KDQo+IDEpIFdoYXQgYXJl IHRob3NlIG90aGVyIGN1c3RvbWVycyBmb3IgdGhlc2UgZG9jdW1lbnRzPyBUaGFuayB5b3UuDQoN CktpbmQgcmVnYXJkcw0KDQpJdm8gU2VkbGFjZWsNCg0KVGhpcyBDb21tdW5pY2F0aW9uIGlzIENv bmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBv ZiB0aGUgdGVybXMgc2V0IG91dCBhdCB3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXIg DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEhhbm5lcyBUc2Nob2Zlbmln IFttYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldF0gDQpTZW50OiAxOC4gw7pub3JhIDIw MTUgMTA6NTENClRvOiBJdm8gU2VkbGFjZWs7IGVjcml0QGlldGYub3JnDQpTdWJqZWN0OiBSZTog W0Vjcml0XSBjYXItY3Jhc2ggJiBlY3JpdC1lY2FsbCBkcmFmdHMNCg0KSGkgSXZvLA0KDQp0aGFu a3MgZm9yIHlvdXIgcXVpY2sgcmVzcG9uc2UuDQoNCk9uIDAyLzE4LzIwMTUgMTA6MjcgQU0sIEl2 byBTZWRsYWNlayB3cm90ZToNCj4gMSkgV2hhdCBhcmUgdGhvc2Ugb3RoZXIgY3VzdG9tZXJzIGZv ciB0aGVzZSBkb2N1bWVudHM/IFRoYW5rIHlvdS4NCj4gDQo+IDIpIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZWNyaXQtZWNhbGwvIGl0c2VsZiBzdGF0ZXM6IA0K PiAtLS0tLS0tLS0tLS0tLS0NCj4gZUNhbGwgaXRzZWxmDQo+ICAgIGlzIHNwZWNpZmllZCBieSAq KiozR1BQKioqIGFuZCBDRU4gYW5kIHRoZXNlIHNwZWNpZmljYXRpb25zIGluY2x1ZGUgZmFyDQo+ ICAgIGdyZWF0ZXIgc2NvcGUgdGhhbiBpcyBjb3ZlcmVkIGhlcmUuDQo+IC0tLS0tLS0tLS0tLS0t LQ0KPiBzbyBwZXJoYXBzIGl0IG1pZ2h0IGJlIHNlbnNpYmxlIHRvIG1ha2Ugc3VyZSB0aGF0IDNH UFAgcmVxdWlyZW1lbnRzIGFyZSBtZXQuDQoNClRoaXMgaXMgdGhlIGV4cGxhbmF0b3J5IHRleHQg dGhhdCBkZXNjcmliZXMgYmFja2dyb3VuZCwgb25nb2luZyB3b3JrIGFuZCBleHBsYWlucyB0aGUg bGFyZ2VyIGNvbnRleHQgaW4gZWNyaXQtZWNhbGwuDQoNCmNhci1jcmFzaCBpcyB0aGUgbW9yZSBn ZW5lcmljIG9mIHRoZSB0d28gYW5kIGV2ZW4gZGVzY3JpYmVzIGRpZmZlcmVudCBkZXBsb3ltZW50 IG1vZGVsczsgc29tZSBvZiB0aGVtIGFyZSBpbiB1c2UgdG9kYXkgKGFsdGhvdWdoIHVzaW5nIHBy b3ByaWV0YXJ5IHRlY2hub2xvZ3kpLg0KDQpJZiB5b3UgcmVhZCB0aHJvdWdoIHRoZSBkb2N1bWVu dHMgdGhlbiB5b3Ugd2lsbCBub3RpY2UgdGhhdCB0aGUgYWRkZWQgZnVuY3Rpb25hbGl0eSAoYmV5 b25kIHdoYXQgaGFzIGFscmVhZHkgYmVlbiBzdGFuZGFyZGl6ZWQpIGlzIG1pbmltYWxpc3RpYyBh bmQgYWxyZWFkeSBhdCB0aGlzIHBvaW50IGFudGljaXBhdGluZyBleHRlbnNpb25zIGZvciBmdXJ0 aGVyIGNyYXNoIGRhdGEgdG8gYmUgY29udmV5ZWQuDQoNCkNpYW8NCkhhbm5lcw0KDQo+IA0KPiBL aW5kIHJlZ2FyZHMNCj4gDQo+IEl2byBTZWRsYWNlaw0KPiANCj4gVGhpcyBDb21tdW5pY2F0aW9u IGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIA0KPiB0 aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQgd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9k aXNjbGFpbWVyDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFY3Jp dCBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgDQo+ IFRzY2hvZmVuaWcNCj4gU2VudDogMTcuIMO6bm9yYSAyMDE1IDE3OjQ0DQo+IFRvOiBlY3JpdEBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBbRWNyaXRdIGNhci1jcmFzaCAmIGVjcml0LWVjYWxsIGRyYWZ0 cw0KPiANCj4gRldJVywgSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGVzZSB0d28gZG9jdW1lbnRzIHRv IGFkdmFuY2U6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt ZWNyaXQtY2FyLWNyYXNoLw0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWVjcml0LWVjYWxsLw0KPiANCj4gSSBzZWUgbm8gbmVlZCB0byBjcmVhdGUgYSBkZXBl bmRlbmN5IG9uIDNHUFAgd29yayBzaW5jZSB0aGVyZSBhcmUgb3RoZXIgY3VzdG9tZXJzIGZvciB0 aGVzZSBkb2N1bWVudHMuDQo+IA0KPiBDaWFvDQo+IEhhbm5lcw0KPiANCg0K From nobody Thu Feb 19 06:55:24 2015 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 46D0C1A001C for ; Thu, 19 Feb 2015 06:55: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 l-okuV8SAl4v for ; Thu, 19 Feb 2015 06:55:17 -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 48E7D1A0019 for ; Thu, 19 Feb 2015 06:55:17 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-4f-54e5f95372a4 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 56.69.24955.359F5E45; Thu, 19 Feb 2015 15:55:15 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.39]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Thu, 19 Feb 2015 15:54:14 +0100 From: Ivo Sedlacek To: "DRAGE, Keith (Keith)" , Hannes Tschofenig , "ecrit@ietf.org" Thread-Topic: [Ecrit] car-crash & ecrit-ecall drafts Thread-Index: AQHQStEgLwi19QFokE+OT9X/7Bqr05z4CBVAgAAI9CA= Date: Thu, 19 Feb 2015 14:54:12 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112827C77@ESESSMB301.ericsson.se> References: <54E36FCD.6060301@gmx.net> <949EF20990823C4C85C18D59AA11AD8B4A0F2A5E@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B4A0F2A5E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjW7wz6chBo9uS1o0LnrKarF05z1W i6eNZxkdmD1an+1l9Vi8aT+bx5IlP5kCmKO4bFJSczLLUov07RK4Mu4decZUcIO/ouHOcvYG xlc8XYycHBICJhL3j7xlhrDFJC7cW8/WxcjFISRwhFHicfMRJghnMaPEv3Ob2UGq2AT0JCZu OcIKkhAR6GeUaH38ihEkISxgLHHz4jqwIhGgsX8nTAKyOYBsK4lP891AwiwCqhInPz5lArF5 BXwlFm7qBCsXEqiUeLj1N9gYToFYiZkNZ1hAbEYBWYmrf3rB4swC4hK3nsxngrhUQGLJnvNQ V4tKvHz8jxVklYSAosTyfjmIcj2JG1OnsEHY2hLLFr5mhlgrKHFy5hOWCYyis5BMnYWkZRaS lllIWhYwsqxiFC1OLU7KTTcy1kstykwuLs7P08tLLdnECIydg1t+q+5gvPzG8RCjAAejEg/v h86nIUKsiWXFlbmHGKU5WJTEee2MD4UICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJw6zyRl /6OvPKqr+XR5Hq+6nNl4VXXaI7uynqQXF9q6maSOJrkFvPvjcuj+IZ0Vebfv8r9+9/+/rvMy w2PHfBVWF8u+u/Ni5snLt1zlFzcsdBabytSY88JDXmqi8dSp84wiV03/bLj6/fS3vBmGvh0p 1k+mRa74/Wha++rf6/0P9k5/e+llyX8OJZbijERDLeai4kQAqnPh834CAAA= Archived-At: Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts 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, 19 Feb 2015 14:55:22 -0000 +1 Kind regards Ivo This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keit= h) Sent: 19. =FAnora 2015 15:22 To: Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts I believe the only realistic use case is where it is used through a 3GPP ac= cess. Unless you are saying you have an over the top use case where the 3GPP aspe= ct is not an emergency call, then you have an underlying dependency on 3GPP= , and in particular the successful use of the new URN values. Of particular criticality is what happens when the underlying system does n= ot understand the new URN, and therefore ignores the subtypes. 3GPP needs t= o tell you whether it is appropriate that that is always delivered to an or= dinary PSAP. Also an issue is whether service continuity is meant to operat= e on such a call, and if so, how. Unfortunately, you do not seem to have created sufficient interest in the 3= GPP community for anyone to start a related work item. That implies to me t= hat there is not yet consensus behind getting this right as a capability. Keith=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes=20 > Tschofenig > Sent: 17 February 2015 16:44 > To: ecrit@ietf.org > Subject: [Ecrit] car-crash & ecrit-ecall drafts >=20 > FWIW, I would like to see these two documents to advance: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ > https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ >=20 > I see no need to create a dependency on 3GPP work since there are=20 > other customers for these documents. >=20 > Ciao > Hannes >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Feb 19 07:49:38 2015 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 5773C1A916E for ; Thu, 19 Feb 2015 07:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] 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 9lIatU_Ec7Cq for ; Thu, 19 Feb 2015 07:49:35 -0800 (PST) Received: from mm2.idig.net (unknown [70.33.247.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597F51AC3A0 for ; Thu, 19 Feb 2015 07:47:18 -0800 (PST) Received: from dynamic-acs-24-101-113-231.zoominternet.net ([24.101.113.231]:35958 helo=[10.0.1.7]) by mm2.idig.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1YOT1H-0002mc-UM; Thu, 19 Feb 2015 10:28:04 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Brian Rosen In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B4A0F2A5E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 19 Feb 2015 10:27:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E36FCD.6060301@gmx.net> <949EF20990823C4C85C18D59AA11AD8B4A0F2A5E@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.2070.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neustar.biz X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts 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, 19 Feb 2015 15:49:37 -0000 Car-crash covers the US use case and is completely independent of 3GPP = issues. The call will transit a telematics provider before going to a = PSAP and thus the wireless carrier doesn=E2=80=99t see the headers or = data. Brian > On Feb 19, 2015, at 9:21 AM, DRAGE, Keith (Keith) = wrote: >=20 > I believe the only realistic use case is where it is used through a = 3GPP access. >=20 > Unless you are saying you have an over the top use case where the 3GPP = aspect is not an emergency call, then you have an underlying dependency = on 3GPP, and in particular the successful use of the new URN values. >=20 > Of particular criticality is what happens when the underlying system = does not understand the new URN, and therefore ignores the subtypes. = 3GPP needs to tell you whether it is appropriate that that is always = delivered to an ordinary PSAP. Also an issue is whether service = continuity is meant to operate on such a call, and if so, how. >=20 > Unfortunately, you do not seem to have created sufficient interest in = the 3GPP community for anyone to start a related work item. That implies = to me that there is not yet consensus behind getting this right as a = capability. >=20 > Keith=20 >=20 >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of=20 >> Hannes Tschofenig >> Sent: 17 February 2015 16:44 >> To: ecrit@ietf.org >> Subject: [Ecrit] car-crash & ecrit-ecall drafts >>=20 >> FWIW, I would like to see these two documents to advance: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ >>=20 >> I see no need to create a dependency on 3GPP work since there=20 >> are other customers for these documents. >>=20 >> Ciao >> Hannes >>=20 >>=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Feb 19 08:48:19 2015 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 B6FAF1A9239 for ; Thu, 19 Feb 2015 08:48:17 -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 kq2Me-Gsm7Li for ; Thu, 19 Feb 2015 08:48:16 -0800 (PST) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54FD1A9238 for ; Thu, 19 Feb 2015 08:48:15 -0800 (PST) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-02.telecomsys.com (8.14.7/8.14.7) with ESMTP id t1JGm66x031330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Feb 2015 08:48:07 -0800 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.115]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0195.001; Thu, 19 Feb 2015 08:48:06 -0800 From: Roger Marshall To: Hannes Tschofenig , "ecrit@ietf.org" Thread-Topic: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 Thread-Index: AQHQStFlP3D4bBGjiUa2jgJX/fjrjJz4HVcw Date: Thu, 19 Feb 2015 16:48:05 +0000 Message-ID: References: <54E3703D.8020309@gmx.net> In-Reply-To: <54E3703D.8020309@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 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, 19 Feb 2015 16:48:17 -0000 SGFubmVzOg0KQmVmb3JlIHByZWRpY3RpbmcgY2hhaXIgYWN0aW9ucyBmb3IgdGhpcyAtMDAgZHJh ZnQsIGl0IHdvdWxkIGJlIGdvb2QgdG8gc2VlIHNvbWUgY29tbWVudHMgb24gdGhlIGxpc3QuICBX aGF0IGlzIHRoZSBsZXZlbCBvZiBpbnRlcmVzdCBmb3IgdGhpcyBkcmFmdD8NCg0KDQpJJ2xsIHN0 YXJ0IHdpdGggbXkgb3duIChhcyBwcml2YXRlIHdnIG1lbWJlcikgY29tbWVudHM6DQoNCkMxLiBT dWdnZXN0IGV4cGFuZGluZyB0aGUgSW50cm9kdWN0aW9uLCBzaW5jZSBBYnN0cmFjdCBpcyBlc3Nl bnRpYWxseSB3b3JkLWZvci13b3JkIGFzIHRoZSBJbnRyb2R1Y3Rpb24uICANCkMyLiBTZWN0aW9u IDMsIGNvbnNpZGVyIHJld29yZGluZyB0aGUgZm9sbG93aW5nIHRleHQ6DQoNCkNoYW5nZSBmcm9t Og0KSW4gbWFueSBjYXNlcyB0aGUgTElTIGFscmVhZHkga25vd3MgdGhlIGRlc3RpbmF0aW9uIFBT QVAgYWRkcmVzcyBmb3IgYW55IGdpdmVuIGxvY2F0aW9uLiAgSW4gW1JGQzY4ODFdIGZvciBleGFt cGxlLCB0aGUgTElTIHZhbGlkYXRlcyBhbGwNCiAgIGNpdmljIGxvY2F0aW9ucyB1c2luZyBhIGxv Y2F0aW9uIHZhbGlkYXRpb24gcHJvY2VkdXJlLiAgVGhpcyBwcm9jZWR1cmUgaXMgdGhlIHNhbWUg YXMgYSByb3V0aW5nIHJlcXVlc3QgYW5kIHNvIHRoZSBMSVMgaGFzIHRoZQ0KICAgcmVzdWx0aW5n IHRoZSBQU0FQIHJvdXRpbmcgaW5mb3JtYXRpb24uICBJbiBvdGhlciBjYXNlcywgdGhlIExJUyBr bm93cyB0aGUgY29ycmVjdCBQU0FQIGZvciBhIGdpdmVuIGxvY2F0aW9uIGF0IHByb3Zpc2lvbmlu ZyB0aW1lLCBvcg0KICAgdGhlIGFjY2VzcyBuZXR3b3JrIG1pZ2h0IGFsd2F5cyByb3V0ZSB0byB0 aGUgc2FtZSBlbWVyZ2VuY3kgcHJvdmlkZXIuICBJcnJlc3BlY3RpdmUgb2YgdGhlIHdheSBpbiB3 aGljaCB0aGUgTElTIGxlYXJucyB0aGUgUFNBUCBhZGRyZXNzIGZvcg0KICAgYSBsb2NhdGlvbiwg dGhlIExJUyB3aWxsLCBpbiBhIGdyZWF0IG1hbnkgY2FzZXMsIGhhdmUgdGhpcyBpbmZvcm1hdGlv bi4NCg0KQ2hhbmdlIHRvOg0KSW4gbWFueSBjYXNlcywgdGhlIExJUyBhbHJlYWR5IGtub3dzIHRo ZSBkZXN0aW5hdGlvbiBQU0FQIHJvdXRlIFVSSSBmb3IgYSBnaXZlbiBsb2NhdGlvbi4gIEluIFtS RkM2ODgxXSBmb3IgZXhhbXBsZSwgdGhlIExJUyB2YWxpZGF0ZXMgDQpjaXZpYyBsb2NhdGlvbnMg dXNpbmcgYSBsb2NhdGlvbiB2YWxpZGF0aW9uIHByb2NlZHVyZSBiYXNlZCBvbiB0aGUgTG9TVCBw cm90b2NvbCBbUkZDNTIyMl0uICBUaGlzIHByb2NlZHVyZSBpcyBzaW1pbGFyIHRvIGEgcm91dGlu ZyByZXF1ZXN0IA0KcHJvY2VkdXJlIHVzaW5nIHRoZSBMb1NUIHByb3RvY29sIGFuZCBhbHNvIHBy b3ZpZGVzIHRoZSBMSVMgd2l0aCB0aGUgc2FtZSByZXN1bHRhbnQgUFNBUCByb3V0aW5nIGluZm9y bWF0aW9uLiAgSW4gb3RoZXIgY2FzZXMsIHRoZSBMSVMgDQprbm93cyB0aGUgY29ycmVjdCBQU0FQ IGZvciBhIGdpdmVuIGxvY2F0aW9uIGF0IHByb3Zpc2lvbmluZyB0aW1lLCBvciB0aGUgYWNjZXNz IG5ldHdvcmsgbWlnaHQgYWx3YXlzIHJvdXRlIHRvIHRoZSBzYW1lIGVtZXJnZW5jeSBwcm92aWRl ci4gIA0KSXJyZXNwZWN0aXZlIG9mIHRoZSB3YXkgaW4gd2hpY2ggdGhlIExJUyBsZWFybnMgdGhl IFBTQVAgcm91dGUgVVJJIGZvciBhIGxvY2F0aW9uLCB0aGUgTElTIG1heSwgaW4gbWFueSBjYXNl cywgYWxyZWFkeSBoYXZlIHRoaXMgaW5mb3JtYXRpb24uDQoNCkMzLiBTZWN0aW9uIDMgJiB0aHJv dWdob3V0LCBjb25zaWRlciBxdWFsaWZ5aW5nICJQU0FQIGFkZHJlc3MiIHRvIGJlIG1vcmUgc3Bl Y2lmaWMgLSBzb21ldGhpbmcgbGlrZSBQU0FQIFVSSSwgUFNBUCByb3V0aW5nIFVSSSwgZXRjLiAg KGFzIHVzZWQgYWJvdmUpDQoNCkM0LiBTZWN0aW9uIDQsIHMvZGV2aWNlL2VuZCBkZXZpY2UvZyAo d2hlcmUgYXBwbGljYWJsZSkNCg0KQzUuIFNlY3Rpb24gNCwgV2hlbiB0aGUgdGV4dCBzdGF0ZXMs DQoNCiINCkEgTElTIHRoYXQgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUgcm91dGluZyByZXF1ZXN0 IGVsZW1lbnQgaWdub3JlcyBpdCBhbmQgcmV0dXJucyBsb2NhdGlvbiBhcyBub3JtYWwuIg0KDQpR dWVzdGlvbiwgaGFzIHRoZXJlIGJlZW4gY29uc2lkZXJhdGlvbiBvZiBhbiBlcnJvciBtZXNzYWdl IHJldHVybmVkIGZvciB0aGlzIGNhc2UgKG9yIG90aGVyIGNhc2VzKT8gIElmIHNvLCB3aGF0IGlz IHRoZSBpbXBhY3Qgb2YgcHJvdmlkaW5nIGFuIGVycm9yIG1lc3NhZ2UocykuDQoNCkM2LiBTZWN0 aW9uIDQsIFBsZWFzZSBjbGFyaWZ5IHVzZSBvZiAibWFwcGluZyBlbGVtZW50IiBpbiBwYXJhZ3Jh cGggNS4NCg0KQzcuIFNlY3Rpb24gNSwgcy88eHM6Y29tcGxleHRDb250ZW50Pi88eHM6Y29tcGxl eENvbnRlbnQ+LzENCg0KLXJvZ2VyIG1hcnNoYWxsLg0KDQogDQoNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogRWNyaXQgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWcNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5 IDE3LCAyMDE1IDg6NDYgQU0NClRvOiBlY3JpdEBpZXRmLm9yZw0KU3ViamVjdDogW0Vjcml0XSBO ZXh0IHN0ZXBzIGZvciBkcmFmdC1pZXRmLWVjcml0LWhlbGQtcm91dGluZy0wMA0KDQpIaSBDaGFp cnMsDQoNCndoYXQgYXJlIHRoZSBwbGFubmVkIG5leHQgc3RlcHMgZm9yIHRoZSAiIEEgUm91dGlu ZyBSZXF1ZXN0IEV4dGVuc2lvbiBmb3IgdGhlIEhFTEQgUHJvdG9jb2wiIGRvY3VtZW50Pw0KDQpD b250ZW50LXdpc2UgdGhpcyBpcyBhIGZhaXJseSBzaW1wbGUgZG9jdW1lbnQgYW5kIEkgYW0gd29u ZGVyaW5nIHdoZXRoZXIgdGhlIFdHTEMgY291bGQgYmUgaXNzdWVkIHNvb25lciByYXRoZXIgdGhh biBsYXRlcj8NCg0KQ2lhbw0KSGFubmVzDQoNCg== From nobody Thu Feb 19 14:03:06 2015 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 2A9371A033B for ; Thu, 19 Feb 2015 14:03:05 -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 3TNeN_r_NHJD for ; Thu, 19 Feb 2015 14:03:02 -0800 (PST) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1E81A0334 for ; Thu, 19 Feb 2015 14:03:02 -0800 (PST) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-02.telecomsys.com (8.14.7/8.14.7) with ESMTP id t1JM2soV015313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Feb 2015 14:02:54 -0800 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.115]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0195.001; Thu, 19 Feb 2015 14:02:54 -0800 From: Roger Marshall To: Hannes Tschofenig , "ecrit@ietf.org" Thread-Topic: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 Thread-Index: AQHQStFlP3D4bBGjiUa2jgJX/fjrjJz4HVcwgABinMA= Date: Thu, 19 Feb 2015 22:02:53 +0000 Message-ID: References: <54E3703D.8020309@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 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, 19 Feb 2015 22:03:05 -0000 In addition to the more editorial/technical comments provided (inline, belo= w), I'd like to include some more general comments based on my reading of t= his initial draft. 1. This approach of modifying HELD into something more than for location us= e seeks to find a way to solve a domain/privacy data issue. Not really a m= essaging issue. 2. This draft makes the point that LoST servers and forest guides are not y= et available, and yet justifies this HELD protocol extension by the fact th= at the LIS would already have access to a LoST server for validation purpos= es! This argument is circular. 3. There is no mention of all the other information that LoST returns. Wha= t does the LIS do with this other information? To make the LIS the center = of focus for routing requires additional policy rule processing. The resul= t of all this seems to be to turn a LIS into a NENA i3 ESRP+PRF or 3GPP LRF= , something standards don't need to do. 4. Existing deployed systems don't really follow either architectural mode= l contained in the draft, but are slowly moving in one or the other of thos= e directions. Just as it would be better for emergency services to NOT sta= ndardize each of the many transitional variants in the field, neither shoul= d this variant be standardized, as it will only dilute the fundamental mode= ls that are shown. 5. Doesn't the desire to standardize an extension to HELD to additionally = carry routing URIs stray from the original design intent of HELD? It is na= med "HTTP Emergency Location Delivery". Why not use a standard ESRP or LRF= function to query location and routing within the carrier's private domain= , then egress the call with location/location URI intact? =20 -roger marshall. -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Thursday, February 19, 2015 8:48 AM To: Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 Hannes: Before predicting chair actions for this -00 draft, it would be good to see= some comments on the list. What is the level of interest for this draft? I'll start with my own (as private wg member) comments: C1. Suggest expanding the Introduction, since Abstract is essentially word-= for-word as the Introduction. =20 C2. Section 3, consider rewording the following text: Change from: In many cases the LIS already knows the destination PSAP address for any gi= ven location. In [RFC6881] for example, the LIS validates all civic locations using a location validation procedure. This procedure i= s the same as a routing request and so the LIS has the resulting the PSAP routing information. In other cases, the LIS knows t= he correct PSAP for a given location at provisioning time, or the access network might always route to the same emergency provider. I= rrespective of the way in which the LIS learns the PSAP address for a location, the LIS will, in a great many cases, have this information. Change to: In many cases, the LIS already knows the destination PSAP route URI for a g= iven location. In [RFC6881] for example, the LIS validates civic locations= using a location validation procedure based on the LoST protocol [RFC5222]= . This procedure is similar to a routing request procedure using the LoST = protocol and also provides the LIS with the same resultant PSAP routing inf= ormation. In other cases, the LIS knows the correct PSAP for a given locat= ion at provisioning time, or the access network might always route to the s= ame emergency provider. =20 Irrespective of the way in which the LIS learns the PSAP route URI for a lo= cation, the LIS may, in many cases, already have this information. C3. Section 3 & throughout, consider qualifying "PSAP address" to be more s= pecific - something like PSAP URI, PSAP routing URI, etc. (as used above) C4. Section 4, s/device/end device/g (where applicable) C5. Section 4, When the text states, " A LIS that does not understand the routing request element ignores it and r= eturns location as normal." Question, has there been consideration of an error message returned for thi= s case (or other cases)? If so, what is the impact of providing an error m= essage(s). C6. Section 4, Please clarify use of "mapping element" in paragraph 5. C7. Section 5, s///1 -roger marshall. =20 -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, February 17, 2015 8:46 AM To: ecrit@ietf.org Subject: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 Hi Chairs, what are the planned next steps for the " A Routing Request Extension for t= he HELD Protocol" document? Content-wise this is a fairly simple document and I am wondering whether th= e WGLC could be issued sooner rather than later? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Feb 19 14:22:50 2015 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 799911A0BE8 for ; Thu, 19 Feb 2015 14:22:49 -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 OWf-csLhea80 for ; Thu, 19 Feb 2015 14:22:46 -0800 (PST) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EAEC1A0AF7 for ; Thu, 19 Feb 2015 14:22:45 -0800 (PST) Received: by pdbfl12 with SMTP id fl12so2955907pdb.4 for ; Thu, 19 Feb 2015 14:22:44 -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=hE3+c8jp1V3ELmEozpzUcS/2OLQFe8sdnj27DifxCRw=; b=Dr3Rv5y960bgLEH3TPfk5K8cOX8AYbMLShIrHirPs9SScItiyxJET0Gng9ZFC8GQE0 8mZ5WLAUPRiV/RKhc7mlwCt+JWLU2ywXYRfGf5CjTVlhQS6HzBQ2eVnlp54v4g9lq/u6 8hWkKUJ3zD+UjY5OfsJrQ0uhBVXHw8d4l99Z5/pVJuoPSNhexc4/qaapbVfqCgbJEOwI 6is/02SdWOBf4ZPdjfz+ihGoQeVoCZzjSCMUuEBqz1ZFG25ocQwDvJLghiURzRZzBo5C 8yrBHlWQw9WIv8dbfYigkMRzhUqFww3utJ9bA7WhGq8yHHO8wg9CvUJ/Cq7p5uZ8C6WW 3cjA== X-Received: by 10.66.251.2 with SMTP id zg2mr11372810pac.89.1424384564526; Thu, 19 Feb 2015 14:22:44 -0800 (PST) Received: from [10.169.97.11] ([1.129.223.244]) by mx.google.com with ESMTPSA id in1sm24749913pbc.19.2015.02.19.14.22.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Feb 2015 14:22:43 -0800 (PST) References: <54E3703D.8020309@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D201) From: James Winterbottom Date: Fri, 20 Feb 2015 09:22:41 +1100 To: Roger Marshall Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 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, 19 Feb 2015 22:22:49 -0000 I will respond in more detail later, but from the initial reading below ther= e seems to be a misunderstanding as to where the draft is applicable. I also= disagree with some of the assertions below. I will look to see where some of the misunderstanding might be better clarif= ied. Sent from my iPhone > On 20 Feb 2015, at 9:02 am, Roger Marshall wrot= e: >=20 > In addition to the more editorial/technical comments provided (inline, bel= ow), I'd like to include some more general comments based on my reading of t= his initial draft. >=20 > 1. This approach of modifying HELD into something more than for location u= se seeks to find a way to solve a domain/privacy data issue. Not really a m= essaging issue. >=20 > 2. This draft makes the point that LoST servers and forest guides are not y= et available, and yet justifies this HELD protocol extension by the fact tha= t the LIS would already have access to a LoST server for validation purposes= ! This argument is circular. >=20 > 3. There is no mention of all the other information that LoST returns. Wh= at does the LIS do with this other information? To make the LIS the center o= f focus for routing requires additional policy rule processing. The result o= f all this seems to be to turn a LIS into a NENA i3 ESRP+PRF or 3GPP LRF, so= mething standards don't need to do. >=20 > 4. Existing deployed systems don't really follow either architectural mod= el contained in the draft, but are slowly moving in one or the other of thos= e directions. Just as it would be better for emergency services to NOT stan= dardize each of the many transitional variants in the field, neither should t= his variant be standardized, as it will only dilute the fundamental models t= hat are shown. >=20 > 5. Doesn't the desire to standardize an extension to HELD to additionally= carry routing URIs stray from the original design intent of HELD? It is na= med "HTTP Emergency Location Delivery". Why not use a standard ESRP or LRF f= unction to query location and routing within the carrier's private domain, t= hen egress the call with location/location URI intact? >=20 > -roger marshall. >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall > Sent: Thursday, February 19, 2015 8:48 AM > To: Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 >=20 > Hannes: > Before predicting chair actions for this -00 draft, it would be good to se= e some comments on the list. What is the level of interest for this draft? >=20 >=20 > I'll start with my own (as private wg member) comments: >=20 > C1. Suggest expanding the Introduction, since Abstract is essentially word= -for-word as the Introduction. =20 > C2. Section 3, consider rewording the following text: >=20 > Change from: > In many cases the LIS already knows the destination PSAP address for any g= iven location. In [RFC6881] for example, the LIS validates all > civic locations using a location validation procedure. This procedure i= s the same as a routing request and so the LIS has the > resulting the PSAP routing information. In other cases, the LIS knows t= he correct PSAP for a given location at provisioning time, or > the access network might always route to the same emergency provider. I= rrespective of the way in which the LIS learns the PSAP address for > a location, the LIS will, in a great many cases, have this information. >=20 > Change to: > In many cases, the LIS already knows the destination PSAP route URI for a g= iven location. In [RFC6881] for example, the LIS validates civic locations u= sing a location validation procedure based on the LoST protocol [RFC5222]. T= his procedure is similar to a routing request procedure using the LoST proto= col and also provides the LIS with the same resultant PSAP routing informati= on. In other cases, the LIS knows the correct PSAP for a given location at p= rovisioning time, or the access network might always route to the same emerg= ency provider. =20 > Irrespective of the way in which the LIS learns the PSAP route URI for a l= ocation, the LIS may, in many cases, already have this information. >=20 > C3. Section 3 & throughout, consider qualifying "PSAP address" to be more s= pecific - something like PSAP URI, PSAP routing URI, etc. (as used above) >=20 > C4. Section 4, s/device/end device/g (where applicable) >=20 > C5. Section 4, When the text states, >=20 > " > A LIS that does not understand the routing request element ignores it and r= eturns location as normal." >=20 > Question, has there been consideration of an error message returned for th= is case (or other cases)? If so, what is the impact of providing an error m= essage(s). >=20 > C6. Section 4, Please clarify use of "mapping element" in paragraph 5. >=20 > C7. Section 5, s///1 >=20 > -roger marshall. >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig= > Sent: Tuesday, February 17, 2015 8:46 AM > To: ecrit@ietf.org > Subject: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 >=20 > Hi Chairs, >=20 > what are the planned next steps for the " A Routing Request Extension for t= he HELD Protocol" document? >=20 > Content-wise this is a fairly simple document and I am wondering whether t= he WGLC could be issued sooner rather than later? >=20 > Ciao > Hannes >=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 Thu Feb 19 23:09:16 2015 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 7E4951A03AB for ; Thu, 19 Feb 2015 23:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 6SbukOrb9WTS for ; Thu, 19 Feb 2015 23:09:11 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF901A1A95 for ; Thu, 19 Feb 2015 23:09:11 -0800 (PST) Received: by pdbnh10 with SMTP id nh10so5650364pdb.11 for ; Thu, 19 Feb 2015 23:09:10 -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 :message-id:references:to; bh=mbNumlzFJxmiVgzHZO2Os8sLWRl7nASRVr2j3OzeAPs=; b=CyBlYRP01UZRm9mGp8afFaBEjVatnA7RnU1TaeDKX3rnjvCdFyupDgD49NAwpJ3cjd XoSWPfQOPrIaHK3hxxRIICRdwTp0FbjB4AkUaVHXc47sRpDVafgt/Smpe/WHjUlK5g3U 7vIZqi4u4CQ4GSeyr5VA1JAOthG1aFv7kHxZBiVE8/qKwRm/TWoy2CwrgjytbteEUknq /e7QnpTHghGx6T4YzTDY0Lw6IhySyye1JNjdS1eWqLJQHAwsDXGgWuTJ0qXmVfiB2KKn Nm6nPsFRA6Jdlj0W4Okb7oZT5gvEUQKZ0IycKgwTN9TRo/1tmj6szGOcjjFiUNHYEhbU 7rLQ== X-Received: by 10.70.56.6 with SMTP id w6mr14344498pdp.69.1424416150689; Thu, 19 Feb 2015 23:09:10 -0800 (PST) Received: from [192.168.1.19] (124-149-121-203.dyn.iinet.net.au. [124.149.121.203]) by mx.google.com with ESMTPSA id bi11sm25931744pdb.8.2015.02.19.23.09.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Feb 2015 23:09:10 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B3CD5B48-E04E-4E20-A9E8-28997A3E5461" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: James Winterbottom In-Reply-To: Date: Fri, 20 Feb 2015 18:09:06 +1100 Message-Id: <542F593D-7CD6-417B-B6FD-27F19A5E93EE@gmail.com> References: <54E3703D.8020309@gmx.net> To: Roger Marshall X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 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, 20 Feb 2015 07:09:15 -0000 --Apple-Mail=_B3CD5B48-E04E-4E20-A9E8-28997A3E5461 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Okay, let=E2=80=99s start with this one. Please inline. > On 20 Feb 2015, at 9:02 am, Roger Marshall = wrote: >=20 > In addition to the more editorial/technical comments provided (inline, = below), I'd like to include some more general comments based on my = reading of this initial draft. >=20 > 1. This approach of modifying HELD into something more than for = location use seeks to find a way to solve a domain/privacy data issue. = Not really a messaging issue. [AJW] I think it is a messaging issue, in that it can reduce the number = of messages required, and, if used in specific ways it can contain what = elements in the call path have access to the actual physical location of = the device. I will look this section over again and see if I can make it = clearer.=20 >=20 > 2. This draft makes the point that LoST servers and forest guides are = not yet available, and yet justifies this HELD protocol extension by the = fact that the LIS would already have access to a LoST server for = validation purposes! This argument is circular. [AJW] Not really. Access networks as you know can expand a large number = of areas, and ESInets do not need to be big, and nor do they have to = provide unveiled access to their internal ECRFs. As a consequence an ANP = may have access into an ESINet, but that does not mean that all = transient devices attached their network have this same access. In this = case, the argument is not circular, it means they can provide a single = interface the devices attached to the network and still validate = locations against a local emergency authority.=20 >=20 > 3. There is no mention of all the other information that LoST returns. = What does the LIS do with this other information? To make the LIS the = center of focus for routing requires additional policy rule processing. = The result of all this seems to be to turn a LIS into a NENA i3 ESRP+PRF = or 3GPP LRF, something standards don't need to do. [AJW] HUH???? The role the LIS here is to provide the address of the = ECSP (in ETSI speak), which is analogous to the ESRP in i3, that is all. = PRF is a totally different function and currently outside the scope of = ECRIT. The LRF is a core node, not an access node, and it may or may not = use LoST but it absolutely tied into the emergency call path and remains = their for the duration. This is not doing that, any more than a LoST = server is doing that. >=20 > 4. Existing deployed systems don't really follow either architectural = model contained in the draft, but are slowly moving in one or the other = of those directions. Just as it would be better for emergency services = to NOT standardize each of the many transitional variants in the field, = neither should this variant be standardized, as it will only dilute the = fundamental models that are shown. [AJW] I am not sure what you mean by existing deployed systems and = architectural model directions?=20 >=20 > 5. Doesn't the desire to standardize an extension to HELD to = additionally carry routing URIs stray from the original design intent of = HELD? It is named "HTTP Emergency Location Delivery". Why not use a = standard ESRP or LRF function to query location and routing within the = carrier's private domain, then egress the call with location/location = URI intact? [AJW] HELD is HTTP-Enabled Location Delivery, emergency is just one = application. The purpose of the routing information is get the call to = the ESRP, so I am not sure what you are getting at here. The LRF is a = two step approach and requires a core-node associated with the voice and = access network and uses information about both order to make its = decision. I will make it more clear that there is no explicit trust or = ownership arrangement required between the VSP and ANP. This should = avoid any confusion. Cheers James >=20 > -roger marshall. >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger = Marshall > Sent: Thursday, February 19, 2015 8:48 AM > To: Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 >=20 > Hannes: > Before predicting chair actions for this -00 draft, it would be good = to see some comments on the list. What is the level of interest for = this draft? >=20 >=20 > I'll start with my own (as private wg member) comments: >=20 > C1. Suggest expanding the Introduction, since Abstract is essentially = word-for-word as the Introduction. =20 > C2. Section 3, consider rewording the following text: >=20 > Change from: > In many cases the LIS already knows the destination PSAP address for = any given location. In [RFC6881] for example, the LIS validates all > civic locations using a location validation procedure. This = procedure is the same as a routing request and so the LIS has the > resulting the PSAP routing information. In other cases, the LIS = knows the correct PSAP for a given location at provisioning time, or > the access network might always route to the same emergency = provider. Irrespective of the way in which the LIS learns the PSAP = address for > a location, the LIS will, in a great many cases, have this = information. >=20 > Change to: > In many cases, the LIS already knows the destination PSAP route URI = for a given location. In [RFC6881] for example, the LIS validates civic = locations using a location validation procedure based on the LoST = protocol [RFC5222]. This procedure is similar to a routing request = procedure using the LoST protocol and also provides the LIS with the = same resultant PSAP routing information. In other cases, the LIS knows = the correct PSAP for a given location at provisioning time, or the = access network might always route to the same emergency provider. =20 > Irrespective of the way in which the LIS learns the PSAP route URI for = a location, the LIS may, in many cases, already have this information. >=20 > C3. Section 3 & throughout, consider qualifying "PSAP address" to be = more specific - something like PSAP URI, PSAP routing URI, etc. (as = used above) >=20 > C4. Section 4, s/device/end device/g (where applicable) >=20 > C5. Section 4, When the text states, >=20 > " > A LIS that does not understand the routing request element ignores it = and returns location as normal." >=20 > Question, has there been consideration of an error message returned = for this case (or other cases)? If so, what is the impact of providing = an error message(s). >=20 > C6. Section 4, Please clarify use of "mapping element" in paragraph 5. >=20 > C7. Section 5, s///1 >=20 > -roger marshall. >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Tuesday, February 17, 2015 8:46 AM > To: ecrit@ietf.org > Subject: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 >=20 > Hi Chairs, >=20 > what are the planned next steps for the " A Routing Request Extension = for the HELD Protocol" document? >=20 > Content-wise this is a fairly simple document and I am wondering = whether the WGLC could be issued sooner rather than later? >=20 > Ciao > Hannes >=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 --Apple-Mail=_B3CD5B48-E04E-4E20-A9E8-28997A3E5461 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Okay, let=E2=80=99s start with this one. Please inline.


On = 20 Feb 2015, at 9:02 am, Roger Marshall <RMarshall@telecomsys.com> wrote:

In addition to the = more editorial/technical comments provided (inline, below), I'd like to = include some more general comments based on my reading of this initial = draft.

1. This approach of modifying HELD = into something more than for location use seeks to find a way to solve a = domain/privacy data issue.  Not really a messaging issue.

[AJW] I think it is a messaging = issue, in that it can reduce the number of messages required, and, if = used in specific ways it can contain what elements in the call path have = access to the actual physical location of the device. I will look this = section over again and see if I can make = it clearer. 



2. This draft makes the point that LoST servers and forest = guides are not yet available, and yet justifies this HELD protocol = extension by the fact that the LIS would already have access to a LoST = server for validation purposes!  This argument is circular.
[AJW] Not really. = Access networks as you know can expand a large number of areas, and = ESInets do not need to be big, and nor do they have to = provide unveiled access to their internal ECRFs. As = a consequence an ANP may have access into an ESINet, but that = does not mean that all transient devices = attached their network have this same access. In this case, = the argument is not circular, it means they can provide a single = interface the devices attached to the network and still validate = locations against a local emergency authority. 


3. There is no mention of all the other information that LoST = returns.  What does the LIS do with this other information? =  To make the LIS the center of focus for routing requires = additional policy rule processing.  The result of all this seems to = be to turn a LIS into a NENA i3 ESRP+PRF or 3GPP LRF, something = standards don't need to do.

[AJW]  HUH???? = The role the LIS here is to provide the address of the ECSP (in ETSI = speak), which is analogous to the ESRP in i3, that is all. PRF is a = totally different function and currently outside the scope of = ECRIT. The LRF is a core node, not an access node, and it may or may not = use LoST but it absolutely tied into the emergency call path and remains = their for the duration. This is not doing that, any more than a = LoST server is doing that.



4.  Existing deployed systems don't really follow either = architectural model contained in the draft, but are slowly moving in one = or the other of those directions.  Just as it would be better for = emergency services to NOT standardize each of the many transitional = variants in the field, neither should this variant be standardized, as = it will only dilute the fundamental models that are shown.
[AJW] I am not sure = what you mean by existing deployed systems and architectural model = directions? 



5.  Doesn't the desire to standardize an extension to = HELD to additionally carry routing URIs stray from the original design = intent of HELD?  It is named "HTTP Emergency Location Delivery". =  Why not use a standard ESRP or LRF function to query location and = routing within the carrier's private domain, then egress the call with = location/location URI intact?
[AJW] HELD is HTTP-Enabled Location Delivery, emergency = is just one application. The purpose of the routing information is = get the call to the ESRP, so I am not sure what you are getting at here. = The LRF is a two step approach and requires a core-node associated with = the voice and access network and uses information about both order to = make its decision. I will make it more clear that there is no explicit = trust or ownership arrangement required between the VSP and ANP. This = should avoid any confusion.


Cheers
James


-roger marshall.

-----Original = Message-----
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger = Marshall
Sent: Thursday, February 19, 2015 8:48 AM
To: Hannes Tschofenig; ecrit@ietf.org
Subject: Re: [Ecrit] Next = steps for draft-ietf-ecrit-held-routing-00

Hannes:
Before predicting chair actions for = this -00 draft, it would be good to see some comments on the list. =  What is the level of interest for this draft?


I'll start with my own (as private wg member) = comments:

C1. Suggest expanding the = Introduction, since Abstract is essentially word-for-word as the = Introduction.  
C2. Section 3, consider rewording the = following text:

Change from:
In= many cases the LIS already knows the destination PSAP address for any = given location.  In [RFC6881] for example, the LIS validates all
  civic locations using a location validation = procedure.  This procedure is the same as a routing request and so = the LIS has the
  resulting the PSAP routing = information.  In other cases, the LIS knows the correct PSAP for a = given location at provisioning time, or
  the = access network might always route to the same emergency provider. =  Irrespective of the way in which the LIS learns the PSAP address = for
  a location, the LIS will, in a great many = cases, have this information.

Change to:
In many cases, the LIS already knows the destination PSAP = route URI for a given location.  In [RFC6881] for example, the LIS = validates civic locations using a location validation procedure based on = the LoST protocol [RFC5222].  This procedure is similar to a = routing request procedure using the LoST protocol and also provides the = LIS with the same resultant PSAP routing information.  In other = cases, the LIS knows the correct PSAP for a given location at = provisioning time, or the access network might always route to the same = emergency provider.  
Irrespective of the way in = which the LIS learns the PSAP route URI for a location, the LIS may, in = many cases, already have this information.

C3. Section 3 & throughout, consider qualifying "PSAP = address" to be more specific - something like PSAP URI, PSAP routing = URI, etc.  (as used above)

C4. Section = 4, s/device/end device/g (where applicable)

C5. Section 4, When the text states,

"
A LIS that does not understand the routing = request element ignores it and returns location as normal."

Question, has there been consideration of an = error message returned for this case (or other cases)?  If so, what = is the impact of providing an error message(s).

C6. Section 4, Please clarify use of "mapping element" in = paragraph 5.

C7. Section 5, = s/<xs:complextContent>/<xs:complexContent>/1
-roger marshall.





-----Original = Message-----
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes = Tschofenig
Sent: Tuesday, February 17, 2015 8:46 AM
To: ecrit@ietf.org
Subject: [Ecrit] Next steps = for draft-ietf-ecrit-held-routing-00

Hi = Chairs,

what are the planned next steps for = the " A Routing Request Extension for the HELD Protocol" document?

Content-wise this is a fairly simple document = and I am wondering whether the WGLC could be issued sooner rather than = later?

Ciao
Hannes

_______________________________________________
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

= --Apple-Mail=_B3CD5B48-E04E-4E20-A9E8-28997A3E5461-- From nobody Thu Feb 19 23:15:48 2015 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 32CE41A6FFA for ; Thu, 19 Feb 2015 23:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 SrUb9_k0HwXu for ; Thu, 19 Feb 2015 23:15:44 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE3C1A6FEC for ; Thu, 19 Feb 2015 23:15:44 -0800 (PST) Received: by pabrd3 with SMTP id rd3so6055329pab.1 for ; Thu, 19 Feb 2015 23:15:43 -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 :message-id:references:to; bh=1Dy4fRKd1tMha233vS6rR1Sw7Un+smcPn4JPkr5MxFU=; b=r6evUAD3Z083Ukju1sqgZWHeAR5846X1NJo8I6gzug+CGWzGIzQb1VJsFhnWmZ24HO EX5ifM4Pq6ZpvD7skkVsYrx8Q30ns0IZKC7nfTQCZUXTGiYbiQ85bZbdNgD9wCscgTst gr+XeL5V1kooSgtsdsqkW0vEos/zRybXLZfBhT4yPMaD8TtYBBnQiE40A5Z1F4Qa/VEO mq8n9wU8+9TvZGEk0QYMglIsDxQbZ50bFb7dj+qmZcD3oq8Mt957txosxsblzJqV2qXj 7zWbNu+4t2oHrCSb+wNnyy3ielCUmegDSI6+E/RQK1jOb6ZFepz4NYDtrMG08aS1tvi9 cB1w== X-Received: by 10.66.118.198 with SMTP id ko6mr14795290pab.16.1424416543346; Thu, 19 Feb 2015 23:15:43 -0800 (PST) Received: from [192.168.1.19] (124-149-121-203.dyn.iinet.net.au. [124.149.121.203]) by mx.google.com with ESMTPSA id y3sm25705159pbt.90.2015.02.19.23.15.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Feb 2015 23:15:42 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_A5D47973-3AD8-4C84-93B4-93978E833E2D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: James Winterbottom In-Reply-To: Date: Fri, 20 Feb 2015 18:15:39 +1100 Message-Id: <5F4C7777-2B36-4B3E-B33F-B1275BBC547A@gmail.com> References: <54E3703D.8020309@gmx.net> To: Roger Marshall X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 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, 20 Feb 2015 07:15:47 -0000 --Apple-Mail=_A5D47973-3AD8-4C84-93B4-93978E833E2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Comments inline. Thanks for the comments > On 20 Feb 2015, at 3:48 am, Roger Marshall = wrote: >=20 > Hannes: > Before predicting chair actions for this -00 draft, it would be good = to see some comments on the list. What is the level of interest for = this draft? >=20 >=20 > I'll start with my own (as private wg member) comments: >=20 > C1. Suggest expanding the Introduction, since Abstract is essentially = word-for-word as the Introduction. [AJW] Agreed, I will look at the introduction. > =20 > C2. Section 3, consider rewording the following text: >=20 > Change from: > In many cases the LIS already knows the destination PSAP address for = any given location. In [RFC6881] for example, the LIS validates all > civic locations using a location validation procedure. This = procedure is the same as a routing request and so the LIS has the > resulting the PSAP routing information. In other cases, the LIS = knows the correct PSAP for a given location at provisioning time, or > the access network might always route to the same emergency = provider. Irrespective of the way in which the LIS learns the PSAP = address for > a location, the LIS will, in a great many cases, have this = information. >=20 > Change to: > In many cases, the LIS already knows the destination PSAP route URI = for a given location. In [RFC6881] for example, the LIS validates=20 > civic locations using a location validation procedure based on the = LoST protocol [RFC5222]. This procedure is similar to a routing request=20= > procedure using the LoST protocol and also provides the LIS with the = same resultant PSAP routing information. In other cases, the LIS=20 > knows the correct PSAP for a given location at provisioning time, or = the access network might always route to the same emergency provider. =20= > Irrespective of the way in which the LIS learns the PSAP route URI for = a location, the LIS may, in many cases, already have this information. [AJW] Sure. >=20 > C3. Section 3 & throughout, consider qualifying "PSAP address" to be = more specific - something like PSAP URI, PSAP routing URI, etc. (as = used above) [AJW] Sure. >=20 > C4. Section 4, s/device/end device/g (where applicable) [AJW] Sure. >=20 > C5. Section 4, When the text states, >=20 > " > A LIS that does not understand the routing request element ignores it = and returns location as normal." >=20 > Question, has there been consideration of an error message returned = for this case (or other cases)? If so, what is the impact of providing = an error message(s). [AJW] I don=E2=80=99t think an error is warranted here, not returning = anything is fine. If the user requests it but doesn=E2=80=99t get = anything then they try other methods. I think an error just complicates = things.=20 >=20 > C6. Section 4, Please clarify use of "mapping element" in paragraph 5. [AJW] I will look at this. Randy has already suggested some changes in = this area in relation to service request types. >=20 > C7. Section 5, s///1 [AJW] I will take a look. >=20 > -roger marshall. >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Tuesday, February 17, 2015 8:46 AM > To: ecrit@ietf.org > Subject: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00 >=20 > Hi Chairs, >=20 > what are the planned next steps for the " A Routing Request Extension = for the HELD Protocol" document? >=20 > Content-wise this is a fairly simple document and I am wondering = whether the WGLC could be issued sooner rather than later? >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_A5D47973-3AD8-4C84-93B4-93978E833E2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Comments inline.

Thanks for the comments


On 20 Feb 2015, at 3:48 am, = Roger Marshall <RMarshall@telecomsys.com> wrote:

Hannes:
Before predicting chair actions for this -00 draft, it would = be good to see some comments on the list.  What is the level of = interest for this draft?


I'll = start with my own (as private wg member) comments:

C1. Suggest expanding the Introduction, since Abstract is = essentially word-for-word as the Introduction.
[AJW] Agreed, I will look at the introduction.

=  
C2. Section 3, consider rewording the following = text:

Change from:
In many = cases the LIS already knows the destination PSAP address for any given = location.  In [RFC6881] for example, the LIS validates all
  civic locations using a location validation = procedure.  This procedure is the same as a routing request and so = the LIS has the
  resulting the PSAP routing = information.  In other cases, the LIS knows the correct PSAP for a = given location at provisioning time, or
  the = access network might always route to the same emergency provider. =  Irrespective of the way in which the LIS learns the PSAP address = for
  a location, the LIS will, in a great many = cases, have this information.

Change to:
In many cases, the LIS already knows the destination PSAP = route URI for a given location.  In [RFC6881] for example, the LIS = validates
civic locations using a location validation = procedure based on the LoST protocol [RFC5222].  This procedure is = similar to a routing request
procedure using the LoST = protocol and also provides the LIS with the same resultant PSAP routing = information.  In other cases, the LIS
knows the = correct PSAP for a given location at provisioning time, or the access = network might always route to the same emergency provider.  
Irrespective of the way in which the LIS learns the PSAP = route URI for a location, the LIS may, in many cases, already have this = information.
[AJW] = Sure.


C3. Section 3 & throughout, consider = qualifying "PSAP address" to be more specific - something like PSAP URI, = PSAP routing URI, etc.  (as used above)
[AJW] = Sure.


C4. Section 4, s/device/end device/g (where = applicable)
[AJW] = Sure.


C5. Section 4, When the text states,

"
A LIS that does not understand = the routing request element ignores it and returns location as = normal."

Question, has there been = consideration of an error message returned for this case (or other = cases)?  If so, what is the impact of providing an error = message(s).
[AJW] I = don=E2=80=99t think an error is warranted here, not returning = anything is fine. If the user requests it but doesn=E2=80=99t get = anything then they try other methods. I think an error just complicates = things. 



C6. Section 4, Please clarify use of "mapping element" in = paragraph 5.
[AJW] I = will look at this. Randy has already suggested some changes in this area = in relation to service request types.


C7. Section 5, = s/<xs:complextContent>/<xs:complexContent>/1
[AJW] I will take a = look.



-roger = marshall.





-----Original Message-----
From: = Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes = Tschofenig
Sent: Tuesday, February 17, 2015 8:46 AM
To: ecrit@ietf.org
Subject: [Ecrit] Next steps = for draft-ietf-ecrit-held-routing-00

Hi = Chairs,

what are the planned next steps for = the " A Routing Request Extension for the HELD Protocol" document?

Content-wise this is a fairly simple document = and I am wondering whether the WGLC could be issued sooner rather than = later?

Ciao
Hannes

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

= --Apple-Mail=_A5D47973-3AD8-4C84-93B4-93978E833E2D--