From nobody Mon May 5 11:52:47 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96A81A044C; Mon, 5 May 2014 11:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 MW_45UICg7aJ; Mon, 5 May 2014 11:52:33 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id 43FF11A00E8; Mon, 5 May 2014 11:52:33 -0700 (PDT) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-01.telecomsys.com (8.14.5/8.14.5) with ESMTP id s45IqMZX027204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 5 May 2014 11:52:22 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.10]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0174.001; Mon, 5 May 2014 11:52:22 -0700 From: Roger Marshall To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: New Call-Info header proposed for top-level providerInfo - draft-ietf-ecrit-additional-data-22 Thread-Index: Ac9okyVj4FNQvusrQGG99XJtzEfPfg== Date: Mon, 5 May 2014 18:52:21 +0000 Message-ID: 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: http://mailarchive.ietf.org/arch/msg/ecrit/0iTlrAV2aGvUo4sQbsGCNEJMo_8 Cc: "ecrit@ietf.org" Subject: [Ecrit] New Call-Info header proposed for top-level providerInfo - draft-ietf-ecrit-additional-data-22 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 18:52:38 -0000 I'd like to propose that a new Call-Info header - something to be added to = the draft based on some early implementation experience in NENA and NG9-1-1. In addition to the Call-Info header usage already defined in the draft, I p= ropose that we require the addition of a single new Call-Info header that i= ncludes a purpose parameter to denote the service provider that handed off = the call last, making this provided-by information easily accessible for ro= uting reasons without requiring the elements along the path to dig out the = value from the PIDF-LO - whether from the MIME body part of from a by-Refer= ence retrieval operation. We would want to retain Call-Info with purpose=3DEmergencyCallData.Provider= Info to carry the "full XML" (either byV or byR), one per Access Network Pr= ovider, Service Provider, etc (as described in the draft) And then add functionality for our newly proposed Call-Info header with pur= pose=3Dnena-ProviderID. To clarify the intent, this new purpose=3Dnena-Pro= viderID is for the Telecom Provider, which is described in section 3.1.4 of= the additional-data draft as "Calling or origination telecom SP", of which= there can only be one. So multiple Call-Info with purpose=3Dnena-Provide= rID would not make sense. To help clarify, I think we should rename the pu= rpose to be more like purpose=3Dnena-TelecomProviderID, so that the value o= f the purpose helps clarify. In the long run signaling should carry both the Call-Info with purpose=3DEm= ergencyCallData.ProviderInfo (either byR or byV) with the full XML, and the= n exactly one with purpose=3Dnena-TelecomProviderID as proposed. =20 Note that for the purpose=3DEmergencyCallData.ProviderInfo there can be mul= tiple of those Call-Info (per the draft), so that each "provider" in the pa= th can attach their own data (as described in the draft). Also note that f= or legacy carrier where ESInet is constructing the SIP for the 911, there w= ill probably be only one. What do people think? -roger. -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Wednesday, April 23, 2014 3:29 PM To: i-d-announce@ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-22.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Authors : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens James Winterbottom Filename : draft-ietf-ecrit-additional-data-22.txt Pages : 97 Date : 2014-04-23 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-22 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-22 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From nobody Mon May 5 12:25:52 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79AB1A018D for ; Mon, 5 May 2014 12:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 jdVo6QUc26R7 for ; Mon, 5 May 2014 12:25:47 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 753AC1A0462 for ; Mon, 5 May 2014 12:25:47 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id s45JPbW2017739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 5 May 2014 12:25:37 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.10]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.03.0174.001; Mon, 5 May 2014 12:25:37 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: New Call-Info header proposed for top-level providerInfo - draft-ietf-ecrit-additional-data-22 Thread-Index: AQHPaJMziS2BSA802kiYqB4YjsPYfZsyXm9Q Date: Mon, 5 May 2014 19:25:37 +0000 Message-ID: <02BBD766-09D2-41F0-AD97-63EBB74173D9@telecomsys.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_02BBD76609D241F0AD9763EBB74173D9telecomsyscom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/O12egDKfaFxT9FnH9W0DnZhDuGo Subject: Re: [Ecrit] New Call-Info header proposed for top-level providerInfo - draft-ietf-ecrit-additional-data-22 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 19:25:49 -0000 --_000_02BBD76609D241F0AD9763EBB74173D9telecomsyscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sending to Ecrit only this time (argh) I'd like to propose that a new Call-Info header - something to be added to = the draft based on some early implementation experience in NENA and NG9-1-1. In addition to the Call-Info header usage already defined in the draft, I p= ropose that we require the addition of a single new Call-Info header that i= ncludes a purpose parameter to denote the service provider that handed off = the call last, making this provided-by information easily accessible for ro= uting reasons without requiring the elements along the path to dig out the = value from the PIDF-LO - whether from the MIME body part of from a by-Refer= ence retrieval operation. We would want to retain Call-Info with purpose=3DEmergencyCallData.Provider= Info to carry the "full XML" (either byV or byR), one per Access Network Pr= ovider, Service Provider, etc (as described in the draft) And then add functionality for our newly proposed Call-Info header with pur= pose=3Dnena-ProviderID. To clarify the intent, this new purpose=3Dnena-Pro= viderID is for the Telecom Provider, which is described in section 3.1.4 of= the additional-data draft as "Calling or origination telecom SP", of which= there can only be one. So multiple Call-Info with purpose=3Dnena-Provide= rID would not make sense. To help clarify, I think we should rename the pu= rpose to be more like purpose=3Dnena-TelecomProviderID, so that the value o= f the purpose helps clarify. In the long run signaling should carry both the Call-Info with purpose=3DEm= ergencyCallData.ProviderInfo (either byR or byV) with the full XML, and the= n exactly one with purpose=3Dnena-TelecomProviderID as proposed. Note that for the purpose=3DEmergencyCallData.ProviderInfo there can be mul= tiple of those Call-Info (per the draft), so that each "provider" in the pa= th can attach their own data (as described in the draft). Also note that f= or legacy carrier where ESInet is constructing the SIP for the 911, there w= ill probably be only one. What do people think? -roger. CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_02BBD76609D241F0AD9763EBB74173D9telecomsyscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sending to Ecrit only this time (argh)


I'd like to propose that a new Call-Info header - something to b= e added to the draft based on some early implementation experience in NENA = and NG9-1-1.

In addition to the Call-Info header usage already defined in the draf= t, I propose that we require the addition of a single new Call-Info header = that includes a purpose parameter to denote the service provider that hande= d off the call last, making this provided-by information easily accessible for routing reasons without requ= iring the elements along the path to dig out the value from the PIDF-LO - w= hether from the MIME body part of from a by-Reference retrieval operation.<= /span>

We would want to retain Call-Info with purpose=3DEmergencyCallData.Pr= oviderInfo to carry the "full XML" (either byV or byR), one per A= ccess Network Provider, Service Provider, etc (as described in the draft)

And then add functionality for our newly proposed Call-Info header wi= th purpose=3Dnena-ProviderID.  To clarify the intent, this new purpose= =3Dnena-ProviderID is for the Telecom Provider, which is described in secti= on 3.1.4 of the additional-data draft as "Calling or origination telecom SP", of which there can only be = one.   So multiple Call-Info with purpose=3Dnena-ProviderID would= not make sense.  To help clarify, I think we should rename the purpos= e to be more like purpose=3Dnena-TelecomProviderID, so that the value of the purpose helps clarify.

In the long run signaling should carry both the Call-Info with purpos= e=3DEmergencyCallData.ProviderInfo (either byR or byV) with the full XML, a= nd then exactly one with purpose=3Dnena-TelecomProviderID as proposed. &nbs= p;

Note that for the purpose=3DEmergencyCallData.ProviderInfo there can = be multiple of those Call-Info (per the draft), so that each "provider= " in the path can attach their own data (as described in the draft). &= nbsp;Also note that for legacy carrier where ESInet is constructing the SIP for the 911, there will probably be only one.

What do people think?

-roger.


CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_02BBD76609D241F0AD9763EBB74173D9telecomsyscom_-- From nobody Mon May 5 12:39:11 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CB31A01B2 for ; Mon, 5 May 2014 12:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 ZshOt_MfnL0o for ; Mon, 5 May 2014 12:39:00 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 078D41A01AF for ; Mon, 5 May 2014 12:38:59 -0700 (PDT) Received: from stntexhc10.cis.neustar.com (stntexhc10.va.neustar.com [10.31.58.69]) by stihiron1.va.neustar.com with smtp (TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 3902_3332_2fd3ecb7_690a_453a_9dfb_1ee9e9ffd83e; Mon, 05 May 2014 15:38:47 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc10.cis.neustar.com ([169.254.4.3]) with mapi id 14.03.0158.001; Mon, 5 May 2014 15:35:03 -0400 From: "Rosen, Brian" To: Roger Marshall Thread-Topic: [Ecrit] New Call-Info header proposed for top-level providerInfo - draft-ietf-ecrit-additional-data-22 Thread-Index: AQHPaJkcBaLGXnoqEEWpAMfhzSb8gg== Date: Mon, 5 May 2014 19:35:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.22] Content-Type: text/plain; charset="Windows-1252" Content-ID: <07B6EC6A15F05B488A0DE4088EA097E5@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/l-FXlirClPD_pZcBZMThsjjN_bg Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] New Call-Info header proposed for top-level providerInfo - draft-ietf-ecrit-additional-data-22 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 19:39:05 -0000 I=92m confused, but I don=92t think I like it. My confusion is =93dig out the value from the PIDF-LO=94. The only reason it would be there is if the access network put it there. O= therwise, it would be in a Call-Info header. You can=92t get it in the cal= l path if it=92s provided by the access network. But the rest of the message seems to be talking about the origination netwo= rk. Thus my confusion. I think adding stuff to a call header just to simplify routing is misplaced= . We should add mechanism to the routing infrastructure to make it easy to= base a route decision on it. Also, basing an IETF mechanism on a NENA ID is a bad idea. But then, I think routing based on the id of the telco is a bit suspect. S= macks of preferential treatment. Brian On May 5, 2014, at 2:52 PM, Roger Marshall wrote= : > I'd like to propose that a new Call-Info header - something to be added t= o the draft based on some early implementation experience in NENA and NG9-1= -1. >=20 > In addition to the Call-Info header usage already defined in the draft, I= propose that we require the addition of a single new Call-Info header that= includes a purpose parameter to denote the service provider that handed of= f the call last, making this provided-by information easily accessible for = routing reasons without requiring the elements along the path to dig out th= e value from the PIDF-LO - whether from the MIME body part of from a by-Ref= erence retrieval operation. >=20 > We would want to retain Call-Info with purpose=3DEmergencyCallData.Provid= erInfo to carry the "full XML" (either byV or byR), one per Access Network = Provider, Service Provider, etc (as described in the draft) >=20 > And then add functionality for our newly proposed Call-Info header with p= urpose=3Dnena-ProviderID. To clarify the intent, this new purpose=3Dnena-P= roviderID is for the Telecom Provider, which is described in section 3.1.4 = of the additional-data draft as "Calling or origination telecom SP", of whi= ch there can only be one. So multiple Call-Info with purpose=3Dnena-Provi= derID would not make sense. To help clarify, I think we should rename the = purpose to be more like purpose=3Dnena-TelecomProviderID, so that the value= of the purpose helps clarify. >=20 > In the long run signaling should carry both the Call-Info with purpose=3D= EmergencyCallData.ProviderInfo (either byR or byV) with the full XML, and t= hen exactly one with purpose=3Dnena-TelecomProviderID as proposed. =20 >=20 > Note that for the purpose=3DEmergencyCallData.ProviderInfo there can be m= ultiple of those Call-Info (per the draft), so that each "provider" in the = path can attach their own data (as described in the draft). Also note that= for legacy carrier where ESInet is constructing the SIP for the 911, there= will probably be only one. >=20 > What do people think? >=20 > -roger. >=20 >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org > Sent: Wednesday, April 23, 2014 3:29 PM > To: i-d-announce@ietf.org > Cc: ecrit@ietf.org > Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-22.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Emergency Context Resolution with Intern= et Technologies Working Group of the IETF. >=20 > Title : Additional Data related to an Emergency Call > Authors : Brian Rosen > Hannes Tschofenig > Roger Marshall > Randall Gellens > James Winterbottom > Filename : draft-ietf-ecrit-additional-data-22.txt > Pages : 97 > Date : 2014-04-23 >=20 > Abstract: > When an emergency call is sent to a Public Safety Answering Point > (PSAP), the device that sends it, as well as any application service > provider in the path of the call, or access network provider through > which the call originated may have information about the call, the > caller or the location which the PSAP may be able to use. This > document describes data structures and a mechanism to convey such > data to the PSAP. The mechanism uses a Uniform Resource Identifier > (URI), which may point to either an external resource or an object in > the body of the SIP message. The mechanism thus allows the data to > be passed by reference (when the URI points to an external resource) > or by value (when it points into the body of the message). This > follows the tradition of prior emergency services standardization > work where data can be conveyed by value within the call signaling > (i.e., in body of the SIP message) and also by reference. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-22 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-22 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > CONFIDENTIALITY NOTICE: The information contained in this message may be = privileged and/or confidential. If you are not the intended recipient, or r= esponsible for delivering this message to the intended recipient, any revie= w, forwarding, dissemination, distribution or copying of this communication= or any attachment(s) is strictly prohibited. If you have received this mes= sage in error, please notify the sender immediately, and delete it and all = attachments from your computer and network. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Mon May 5 13:05:25 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732961A0457 for ; Mon, 5 May 2014 13:05:23 -0700 (PDT) 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 CzlkW8Fyqv2y for ; Mon, 5 May 2014 13:05:18 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id D7ADE1A0469 for ; Mon, 5 May 2014 13:05:18 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id rd3so1789766pab.21 for ; Mon, 05 May 2014 13:05:15 -0700 (PDT) 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=XG7rP1XAXXD2GsFcD0JctnYaUI7LmkD/O0x+78zS5lA=; b=MKYaCFWUtVZfOUv9nihxSiVdcwMwFJpQ0DwSTHLKj0kj09vLhi4VKWPZkTJbtQKRir tin5qmNgMebe2UJaO2Lh7XQWMrPKnFu75oVaIjJvfNOZu7btp20B03rxReb39KnfwJgq uC3hjD5ND+vO5EiA0x9oCft1lqC4arWgziZvHetxGHIQPendM2DkMK5l9vDXegyfCKHR ikBM9vP+ogpbEgRtJt69qRMUODflRb+o+oYXaBdwUrGheArZ3WOGtk4T+44uv3k1VCr9 cqw3IgDBlU7kdTStlXzCUn0dkK+xmy0ZMsdracX0M7cSvFPX8H00AkPLvcYJMibSEOO2 UeJQ== X-Received: by 10.66.66.202 with SMTP id h10mr75094291pat.70.1399320315190; Mon, 05 May 2014 13:05:15 -0700 (PDT) Received: from [192.168.1.10] (124-170-197-151.dyn.iinet.net.au. [124.170.197.151]) by mx.google.com with ESMTPSA id nx12sm78826622pab.6.2014.05.05.13.05.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 13:05:14 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C8D25D9A-206A-4AC5-A216-80148B1AC657" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: James Winterbottom In-Reply-To: Date: Tue, 6 May 2014 06:05:09 +1000 Message-Id: <92DF363F-3D5C-49DF-8929-F2748662B61B@gmail.com> References: To: "Rosen, Brian" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/9J0bFEBLkBFxfy5rlBh53eJuvZs Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] New Call-Info header proposed for top-level providerInfo - draft-ietf-ecrit-additional-data-22 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 20:05:23 -0000 --Apple-Mail=_C8D25D9A-206A-4AC5-A216-80148B1AC657 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Brian, On 6 May 2014, at 5:35 am, Rosen, Brian wrote: > I=92m confused, but I don=92t think I like it. >=20 > My confusion is =93dig out the value from the PIDF-LO=94. >=20 > The only reason it would be there is if the access network put it = there. Otherwise, it would be in a Call-Info header. You can=92t get = it in the call path if it=92s provided by the access network. [AJW] if it is a single access-cal-service provider then it may all be = packed into the PIDF-LO >=20 > But the rest of the message seems to be talking about the origination = network. Thus my confusion. >=20 > I think adding stuff to a call header just to simplify routing is = misplaced. We should add mechanism to the routing infrastructure to = make it easy to base a route decision on it. >=20 > Also, basing an IETF mechanism on a NENA ID is a bad idea. >=20 > But then, I think routing based on the id of the telco is a bit = suspect. Smacks of preferential treatment. [AJW] Are you suggesting that the Provider-ID be used for routing Roger? = There may be stuff in the information about the caller that might aid = with some kind of policy routing, but I can=92t think that a provider-ID = would help much there? The only other case I can think of is the hand-off case, where the VSP = that owns the customer has handed the emergency call off to someone else = to deal with. In this case the Provider-ID might help if you know what a = certain provider is always a go-between, then you don=92t check their = info first, you check the others. But the use case feels a bit thin. Cheers James >=20 > Brian >=20 > On May 5, 2014, at 2:52 PM, Roger Marshall = wrote: >=20 >> I'd like to propose that a new Call-Info header - something to be = added to the draft based on some early implementation experience in NENA = and NG9-1-1. >>=20 >> In addition to the Call-Info header usage already defined in the = draft, I propose that we require the addition of a single new Call-Info = header that includes a purpose parameter to denote the service provider = that handed off the call last, making this provided-by information = easily accessible for routing reasons without requiring the elements = along the path to dig out the value from the PIDF-LO - whether from the = MIME body part of from a by-Reference retrieval operation. >>=20 >> We would want to retain Call-Info with = purpose=3DEmergencyCallData.ProviderInfo to carry the "full XML" (either = byV or byR), one per Access Network Provider, Service Provider, etc (as = described in the draft) >>=20 >> And then add functionality for our newly proposed Call-Info header = with purpose=3Dnena-ProviderID. To clarify the intent, this new = purpose=3Dnena-ProviderID is for the Telecom Provider, which is = described in section 3.1.4 of the additional-data draft as "Calling or = origination telecom SP", of which there can only be one. So multiple = Call-Info with purpose=3Dnena-ProviderID would not make sense. To help = clarify, I think we should rename the purpose to be more like = purpose=3Dnena-TelecomProviderID, so that the value of the purpose helps = clarify. >>=20 >> In the long run signaling should carry both the Call-Info with = purpose=3DEmergencyCallData.ProviderInfo (either byR or byV) with the = full XML, and then exactly one with purpose=3Dnena-TelecomProviderID as = proposed. =20 >>=20 >> Note that for the purpose=3DEmergencyCallData.ProviderInfo there can = be multiple of those Call-Info (per the draft), so that each "provider" = in the path can attach their own data (as described in the draft). Also = note that for legacy carrier where ESInet is constructing the SIP for = the 911, there will probably be only one. >>=20 >> What do people think? >>=20 >> -roger. >>=20 >>=20 >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org >> Sent: Wednesday, April 23, 2014 3:29 PM >> To: i-d-announce@ietf.org >> Cc: ecrit@ietf.org >> Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-22.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Emergency Context Resolution with = Internet Technologies Working Group of the IETF. >>=20 >> Title : Additional Data related to an Emergency Call >> Authors : Brian Rosen >> Hannes Tschofenig >> Roger Marshall >> Randall Gellens >> James Winterbottom >> Filename : draft-ietf-ecrit-additional-data-22.txt >> Pages : 97 >> Date : 2014-04-23 >>=20 >> Abstract: >> When an emergency call is sent to a Public Safety Answering Point >> (PSAP), the device that sends it, as well as any application service >> provider in the path of the call, or access network provider through >> which the call originated may have information about the call, the >> caller or the location which the PSAP may be able to use. This >> document describes data structures and a mechanism to convey such >> data to the PSAP. The mechanism uses a Uniform Resource Identifier >> (URI), which may point to either an external resource or an object = in >> the body of the SIP message. The mechanism thus allows the data to >> be passed by reference (when the URI points to an external resource) >> or by value (when it points into the body of the message). This >> follows the tradition of prior emergency services standardization >> work where data can be conveyed by value within the call signaling >> (i.e., in body of the SIP message) and also by reference. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-22 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-22 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> CONFIDENTIALITY NOTICE: The information contained in this message may = be privileged and/or confidential. If you are not the intended = recipient, or responsible for delivering this message to the intended = recipient, any review, forwarding, dissemination, distribution or = copying of this communication or any attachment(s) is strictly = prohibited. If you have received this message in error, please notify = the sender immediately, and delete it and all attachments from your = computer and network. >>=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=_C8D25D9A-206A-4AC5-A216-80148B1AC657 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Brian,

On 6 May 2014, at 5:35 am, Rosen, Brian = <Brian.Rosen@neustar.biz> = wrote:

I=92m confused, but I don=92t think I like it.

My = confusion is =93dig out the value from the PIDF-LO=94.

The only = reason it would be there is if the access network put it there. =  Otherwise, it would be in a Call-Info header.  You can=92t = get it in the call path if it=92s provided by the access = network.
[AJW] if it is = a single access-cal-service provider then it may all be packed into the = PIDF-LO


But the rest = of the message seems to be talking about the origination network. =  Thus my confusion.

I think adding stuff to a call header = just to simplify routing is misplaced.  We should add mechanism to = the routing infrastructure to make it easy to base a route decision on = it.

Also, basing an IETF mechanism on a NENA ID is a bad = idea.

But then, I think routing based on the id of the telco is a = bit suspect.  Smacks of preferential = treatment.
[AJW] Are you = suggesting that the Provider-ID be used for routing Roger? There may be = stuff in the information about the caller that might aid with some kind = of policy routing, but I can=92t think that a provider-ID would help = much there?
The only = other case I can think of is the hand-off case, where the VSP that owns = the customer has handed the emergency call off to someone else to deal = with. In this case the Provider-ID might help if you know what a = certain provider is always a go-between, then you don=92t check = their info first, you check the others. But the use case feels a = bit thin.

Cheers
James



Brian

On May 5, 2014, at 2:52 PM, Roger = Marshall <RMarshall@telecomsys.com> = wrote:

I'd like to propose that a new = Call-Info header - something to be added to the draft based on some = early implementation experience in NENA and NG9-1-1.

In addition = to the Call-Info header usage already defined in the draft, I propose = that we require the addition of a single new Call-Info header that = includes a purpose parameter to denote the service provider that handed = off the call last, making this provided-by information easily accessible = for routing reasons without requiring the elements along the path to dig = out the value from the PIDF-LO - whether from the MIME body part of from = a by-Reference retrieval operation.

We would want to retain = Call-Info with purpose=3DEmergencyCallData.ProviderInfo to carry the = "full XML" (either byV or byR), one per Access Network Provider, Service = Provider, etc (as described in the draft)

And then add = functionality for our newly proposed Call-Info header with = purpose=3Dnena-ProviderID.  To clarify the intent, this new = purpose=3Dnena-ProviderID is for the Telecom Provider, which is = described in section 3.1.4 of the additional-data draft as "Calling or = origination telecom SP", of which there can only be one.   So = multiple Call-Info with purpose=3Dnena-ProviderID would not make sense. =  To help clarify, I think we should rename the purpose to be more = like purpose=3Dnena-TelecomProviderID, so that the value of the purpose = helps clarify.

In the long run signaling should carry both the = Call-Info with purpose=3DEmergencyCallData.ProviderInfo (either byR or = byV) with the full XML, and then exactly one with = purpose=3Dnena-TelecomProviderID as proposed.  

Note that = for the purpose=3DEmergencyCallData.ProviderInfo there can be multiple = of those Call-Info (per the draft), so that each "provider" in the path = can attach their own data (as described in the draft).  Also note = that for legacy carrier where ESInet is constructing the SIP for the = 911, there will probably be only one.

What do people = think?

-roger.


-----Original Message-----
From: = Ecrit [mailto:ecrit-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org
S= ent: Wednesday, April 23, 2014 3:29 PM
To: i-d-announce@ietf.org
Cc: = ecrit@ietf.org
Subject: [Ecrit] = I-D Action: draft-ietf-ecrit-additional-data-22.txt


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 =         : Brian Rosen
=             &n= bsp;           Hann= es Tschofenig
=             &n= bsp;           Roge= r Marshall
=             &n= bsp;           Rand= all Gellens
=             &n= bsp;           Jame= s Winterbottom
Filename =        : = draft-ietf-ecrit-additional-data-22.txt
Pages =           : = 97
= Date =            : = 2014-04-23

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-22
<= br>A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data= -22


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/

________________________= _______________________
Ecrit mailing = list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
<= br>CONFIDENTIALITY NOTICE: The information contained in this message may = be privileged and/or confidential. If you are not the intended = recipient, or responsible for delivering this message to the intended = recipient, any review, forwarding, dissemination, distribution or = copying of this communication or any attachment(s) is strictly = prohibited. If you have received this message in error, please notify = the sender immediately, and delete it and all attachments from your = computer and = network.

_______________________________________________
Ecrit = mailing = list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
<= /blockquote>
_______________________________________________
Ecrit = mailing list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit

= --Apple-Mail=_C8D25D9A-206A-4AC5-A216-80148B1AC657-- From nobody Mon May 5 14:20:35 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EED21A03C2 for ; Mon, 5 May 2014 14:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 y27udyHG6FqB for ; Mon, 5 May 2014 14:20:32 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7107E1A01C1 for ; Mon, 5 May 2014 14:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1399324829; x=1430860829; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=bVaBtnHJx6UAprLUqKfRmDp8TorNaLVHyNlGssrkV/8=; b=aOzDO6dr8g6arFltPxrenu3JsvRaJJeLexDPanccWFrgoon2hrOV3PNc 9yJrvPEH1ByzquJwToGKSdrvKm5NE9QNqf2JkADpW+wbtD/rTXk1mBhC3 vCvtQblAqvKdWBnJIRBj0+kfZggHsw5BIob3IpDF+UwVth1j1naDr2lpK I=; X-IronPort-AV: E=McAfee;i="5600,1067,7429"; a="62961285" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 05 May 2014 14:20:29 -0700 X-IronPort-AV: E=Sophos;i="4.97,991,1389772800"; d="scan'208";a="673454986" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 May 2014 14:20:20 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 14:20:26 -0700 Message-ID: In-Reply-To: <02BBD766-09D2-41F0-AD97-63EBB74173D9@telecomsys.com> References: <02BBD766-09D2-41F0-AD97-63EBB74173D9@telecomsys.com> X-Mailer: Eudora for Mac OS X Date: Mon, 5 May 2014 14:20:14 -0700 To: Roger Marshall , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/HGevIjreTbR9vWtYQjWWy4eAdZ8 Subject: Re: [Ecrit] New Call-Info header proposed for top-level providerInfo - draft-ietf-ecrit-additional-data-22 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 21:20:34 -0000 Hi Roger, Can you explain a bit more about the "early implementation experience in NENA and NG9-1-1" that lead to the proposal? You've obviously been thinking about it for some time, but the rest of us are just hearing about it now, so it would be helpful to provide some background. At 7:25 PM +0000 5/5/14, Roger Marshall wrote: > Sending to Ecrit only this time (argh) > >> >> >> I'd like to propose that a new Call-Info header - something to be >> added to the draft based on some early implementation experience >> in NENA and NG9-1-1. >> >> In addition to the Call-Info header usage already defined in the >> draft, I propose that we require the addition of a single new >> Call-Info header that includes a purpose parameter to denote the >> service provider that handed off the call last, making this >> provided-by information easily accessible for routing reasons >> without requiring the elements along the path to dig out the value >> from the PIDF-LO - whether from the MIME body part of from a >> by-Reference retrieval operation. >> >> We would want to retain Call-Info with >> purpose=EmergencyCallData.ProviderInfo to carry the "full XML" >> (either byV or byR), one per Access Network Provider, Service >> Provider, etc (as described in the draft) >> >> And then add functionality for our newly proposed Call-Info header >> with purpose=nena-ProviderID. To clarify the intent, this new >> purpose=nena-ProviderID is for the Telecom Provider, which is >> described in section 3.1.4 of the additional-data draft as >> "Calling or origination telecom SP", of which there can only be >> one. So multiple Call-Info with purpose=nena-ProviderID would >> not make sense. To help clarify, I think we should rename the >> purpose to be more like purpose=nena-TelecomProviderID, so that >> the value of the purpose helps clarify. >> >> In the long run signaling should carry both the Call-Info with >> purpose=EmergencyCallData.ProviderInfo (either byR or byV) with >> the full XML, and then exactly one with >> purpose=nena-TelecomProviderID as proposed. >> >> Note that for the purpose=EmergencyCallData.ProviderInfo there can >> be multiple of those Call-Info (per the draft), so that each >> "provider" in the path can attach their own data (as described in >> the draft). Also note that for legacy carrier where ESInet is >> constructing the SIP for the 911, there will probably be only one. >> >> What do people think? >> >> -roger. >> > CONFIDENTIALITY NOTICE: The information contained in this message > may be privileged and/or confidential. If you are not the intended > recipient, or responsible for delivering this message to the > intended recipient, any review, forwarding, dissemination, > distribution or copying of this communication or any attachment(s) > is strictly prohibited. If you have received this message in error, > please notify the sender immediately, and delete it and all > attachments from your computer and network. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I have seen the free market, and its face is Bill Gates' --Jay S. Laefer From nobody Tue May 6 03:46:54 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A821A07A2 for ; Tue, 6 May 2014 03:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOARk_aiAiII for ; Tue, 6 May 2014 03:46:51 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 82A591A0785 for ; Tue, 6 May 2014 03:46:51 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s46Akj9w001009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 May 2014 05:46:46 -0500 (CDT) 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 s46AkiC9016449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 May 2014 12:46:44 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.4]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 6 May 2014 12:46:44 +0200 From: "DRAGE, Keith (Keith)" To: Randall Gellens , Roger Marshall , "ecrit@ietf.org" Thread-Topic: [Ecrit] New Call-Info header proposed for top-level providerInfo - draft-ietf-ecrit-additional-data-22 Thread-Index: AQHPaJMz4FNQvusrQGG99XJtzEfPfpsyXm9Q///+fwCAAQKEMA== Date: Tue, 6 May 2014 10:46:43 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B195D53@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <02BBD766-09D2-41F0-AD97-63EBB74173D9@telecomsys.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/6CAezXJAMe-xuc4Sdx6mG8MJkj8 Subject: Re: [Ecrit] New Call-Info header proposed for top-level providerInfo - draft-ietf-ecrit-additional-data-22 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, 06 May 2014 10:46:53 -0000 We seem to be drifting further from what the definition of the Call-Info he= ader field is for, which is to exchange information between two end users. If this is the mechanism that is required, then it raises question on wheth= er the Call-Info header field should have been used in the first place. Regards Keith=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of=20 > Randall Gellens > Sent: 05 May 2014 22:20 > To: Roger Marshall; ecrit@ietf.org > Subject: Re: [Ecrit] New Call-Info header proposed for=20 > top-level providerInfo - draft-ietf-ecrit-additional-data-22 >=20 > Hi Roger, >=20 > Can you explain a bit more about the "early implementation=20 > experience in NENA and NG9-1-1" that lead to the proposal? >=20 > You've obviously been thinking about it for some time, but=20 > the rest of us are just hearing about it now, so it would be=20 > helpful to provide some background. >=20 >=20 > At 7:25 PM +0000 5/5/14, Roger Marshall wrote: >=20 > > Sending to Ecrit only this time (argh) > > > >> > >> > >> I'd like to propose that a new Call-Info header - something to be=20 > >> added to the draft based on some early implementation=20 > experience in=20 > >> NENA and NG9-1-1. > >> > >> In addition to the Call-Info header usage already defined in the=20 > >> draft, I propose that we require the addition of a single new=20 > >> Call-Info header that includes a purpose parameter to denote the=20 > >> service provider that handed off the call last, making this=20 > >> provided-by information easily accessible for routing=20 > reasons without=20 > >> requiring the elements along the path to dig out the value=20 > from the=20 > >> PIDF-LO - whether from the MIME body part of from a by-Reference=20 > >> retrieval operation. > >> > >> We would want to retain Call-Info with=20 > >> purpose=3DEmergencyCallData.ProviderInfo to carry the "full XML" > >> (either byV or byR), one per Access Network Provider, Service=20 > >> Provider, etc (as described in the draft) > >> > >> And then add functionality for our newly proposed=20 > Call-Info header=20 > >> with purpose=3Dnena-ProviderID. To clarify the intent, this new=20 > >> purpose=3Dnena-ProviderID is for the Telecom Provider, which is=20 > >> described in section 3.1.4 of the additional-data draft as=20 > "Calling=20 > >> or origination telecom SP", of which there can only be > >> one. So multiple Call-Info with purpose=3Dnena-ProviderID would=20 > >> not make sense. To help clarify, I think we should rename the=20 > >> purpose to be more like purpose=3Dnena-TelecomProviderID, so=20 > that the=20 > >> value of the purpose helps clarify. > >> > >> In the long run signaling should carry both the Call-Info with=20 > >> purpose=3DEmergencyCallData.ProviderInfo (either byR or byV)=20 > with the=20 > >> full XML, and then exactly one with=20 > purpose=3Dnena-TelecomProviderID as=20 > >> proposed. > >> > >> Note that for the purpose=3DEmergencyCallData.ProviderInfo=20 > there can=20 > >> be multiple of those Call-Info (per the draft), so that each=20 > >> "provider" in the path can attach their own data (as=20 > described in the=20 > >> draft). Also note that for legacy carrier where ESInet is=20 > >> constructing the SIP for the 911, there will probably be only one. > >> > >> What do people think? > >> > >> -roger. > >> > > CONFIDENTIALITY NOTICE: The information contained in this=20 > message may=20 > > be privileged and/or confidential. If you are not the intended=20 > > recipient, or responsible for delivering this message to=20 > the intended=20 > > recipient, any review, forwarding, dissemination, distribution or=20 > > copying of this communication or any attachment(s) is strictly=20 > > prohibited. If you have received this message in error,=20 > please notify=20 > > the sender immediately, and delete it and all attachments from your=20 > > computer and network. > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for=20 > myself only > -------------- Randomly selected tag: --------------- I have=20 > seen the free market, and its face is Bill Gates' > --Jay S. Laefer >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From nobody Wed May 28 15:15:16 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B001A06A9 for ; Wed, 28 May 2014 15:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.651] 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 bp-aI7kMgUhE for ; Wed, 28 May 2014 15:15:12 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D311A06CA for ; Wed, 28 May 2014 15:15:12 -0700 (PDT) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id s4SMF0fn018846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 28 May 2014 15:15:00 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.204]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0174.001; Wed, 28 May 2014 15:15:00 -0700 From: Roger Marshall To: "Bradner, Scott" , "ecrit@ietf.org" Thread-Topic: review of draft-marshall-ecrit-similar-location-03 Thread-Index: AQHPSI7ErtejmZkPIkOts419lHvLcZtW7acQ Date: Wed, 28 May 2014 22:14:59 +0000 Message-ID: References: <48A82192-DF6E-43D5-B35F-8D68515ED067@harvard.edu> In-Reply-To: <48A82192-DF6E-43D5-B35F-8D68515ED067@harvard.edu> 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: http://mailarchive.ietf.org/arch/msg/ecrit/IRX8EZZll4i4MBe5UpiuH5ArTrY Cc: "draft-marshall-ecrit-similar-location@tools.ietf.org" Subject: Re: [Ecrit] review of draft-marshall-ecrit-similar-location-03 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, 28 May 2014 22:15:14 -0000 Scott: Thank you for reviewing this draft. I apologize for taking this long to re= spond & comment. Reply-comments inline. -roger marshall. -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Bradner, Scott Sent: Tuesday, March 25, 2014 6:00 PM To: ecrit@ietf.org Cc: draft-marshall-ecrit-similar-location@tools.ietf.org Subject: [Ecrit] review of draft-marshall-ecrit-similar-location-03 as I agreed to do during the ecrit meeting - here is a review of draft-mar= shall-ecrit-similar-location-03 This looks like a very useful and simple (the two do not always go together= ) addition to LoST - something that could be lifesaver in some cases. (The= re was a story on the news within the last year about sending emergency res= ponse to the wrong address because of just the type of issue that is includ= ed as an example - the address was incomplete and the responders were sent = to the only address that came up - at least that is how the low pass filter= of the news reported it) Section 1. current text: This enhancement to the validation feature within LoST is required in order= to ensure a high level of address matching, to overcome user and system in= put errors, and to support the usefulness of location-based systems in gen= eral. Comment: seems to me that the underlying purpose is to increase the likelihood of re= turning the actual correct civic address at the cost of possibly returning = additional valid but incorrect addresses. [rsm] Yes, agree. Will change text for better reading. =20 Section 2. The RFC 2119 cite is not needed since the capitalized terms are not used in= the document =20 overall. Would there be benefit to adding a section describing the behavior where th= e LoST server has been upgraded to support this feature but the client has = not? e.g., would there be a way to also return some indication in the comp= leteLocation to say that there are similar addresses and that they should u= pdate their client - and maybe return one of the similar addresses or doubl= e them up? e.g. 6000 15th Ave NW|SW Seattle, WA 98107 [rsm] Maybe. Certainly it is a good idea to talk about compatibility issues= in the document. Would it be enough if the LoST server sent back an erro= r message saying, "similar addresses found - no client support". Ugly to be sure - but ... (if this is done there should be guidance that s= ays what the client should do - e.g. if there is a similarLocation then ign= ore the completeLocation) [rsm] Agree that caution text would be required if status handled this way.= Other's have opinions on this idea? also - should there be any discussion of what errors or warnings a LoST ser= ver should or should not return if it is returning a similarLocation? (mayb= e to deal with the upgrade question above) [rsm] agree to add some better error treatment language. Scott _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From nobody Wed May 28 15:19:04 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4621A06D0 for ; Wed, 28 May 2014 15:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkSlwGyFoXeS for ; Wed, 28 May 2014 15:19:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C051A04B6 for ; Wed, 28 May 2014 15:19:01 -0700 (PDT) Received: from BY2PR07MB599.namprd07.prod.outlook.com (10.141.222.19) by BY2PR07MB598.namprd07.prod.outlook.com (10.141.222.16) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 28 May 2014 22:18:55 +0000 Received: from BY2PR07MB599.namprd07.prod.outlook.com ([10.141.222.19]) by BY2PR07MB599.namprd07.prod.outlook.com ([10.141.222.19]) with mapi id 15.00.0949.001; Wed, 28 May 2014 22:18:55 +0000 From: "Bradner, Scott" To: Roger Marshall Thread-Topic: review of draft-marshall-ecrit-similar-location-03 Thread-Index: AQHPSI7ErtejmZkPIkOts419lHvLcZtW7acQgAAG3AA= Date: Wed, 28 May 2014 22:18:54 +0000 Message-ID: References: <48A82192-DF6E-43D5-B35F-8D68515ED067@harvard.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.166.5.69] x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(199002)(189002)(24454002)(377454003)(13464003)(20776003)(64706001)(101416001)(46102001)(66066001)(92726001)(79102001)(54356999)(19580395003)(19580405001)(50986999)(85852003)(83322001)(80022001)(99286001)(33656002)(86362001)(83716003)(77982001)(82746002)(76176999)(36756003)(4396001)(21056001)(74662001)(99396002)(81342001)(83072002)(75432001)(81542001)(92566001)(2656002)(87936001)(77096999)(74502001)(31966008)(76482001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR07MB598; H:BY2PR07MB599.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: harvard.edu does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=sob@harvard.edu; Content-Type: text/plain; charset="Windows-1252" Content-ID: <6C38F86483CE4242988B015E8698813B@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: harvard.edu Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/JfqV730Qhiucq-3WibZf229369w Cc: "ecrit@ietf.org" , "draft-marshall-ecrit-similar-location@tools.ietf.org" Subject: Re: [Ecrit] review of draft-marshall-ecrit-similar-location-03 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, 28 May 2014 22:19:03 -0000 the black hole is not permanent :-) in line On May 28, 2014, at 6:14 PM, Roger Marshall wrot= e: > Scott: > Thank you for reviewing this draft. I apologize for taking this long to = respond & comment. >=20 > Reply-comments inline. >=20 > -roger marshall. >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Bradner, Scott > Sent: Tuesday, March 25, 2014 6:00 PM > To: ecrit@ietf.org > Cc: draft-marshall-ecrit-similar-location@tools.ietf.org > Subject: [Ecrit] review of draft-marshall-ecrit-similar-location-03 >=20 > as I agreed to do during the ecrit meeting - here is a review of draft-m= arshall-ecrit-similar-location-03 >=20 > This looks like a very useful and simple (the two do not always go togeth= er) addition to LoST - something that could be lifesaver in some cases. (T= here was a story on the news within the last year about sending emergency r= esponse to the wrong address because of just the type of issue that is incl= uded as an example - the address was incomplete and the responders were sen= t to the only address that came up - at least that is how the low pass filt= er of the news reported it) >=20 > Section 1. >=20 > current text: >=20 > This enhancement to the validation feature within LoST is required in ord= er to ensure a high level of address matching, to overcome user and system = input errors, and to support the usefulness of location-based systems in g= eneral. >=20 > Comment: >=20 > seems to me that the underlying purpose is to increase the likelihood of = returning the actual correct civic address at the cost of possibly returnin= g additional valid but incorrect addresses. >=20 >=20 > [rsm] Yes, agree. Will change text for better reading. >=20 >=20 >=20 > Section 2. >=20 > The RFC 2119 cite is not needed since the capitalized terms are not used = in the document >=20 >=20 > overall. >=20 > Would there be benefit to adding a section describing the behavior where = the LoST server has been upgraded to support this feature but the client ha= s not? e.g., would there be a way to also return some indication in the co= mpleteLocation to say that there are similar addresses and that they should= update their client - and maybe return one of the similar addresses or dou= ble them up? >=20 > e.g. 6000 15th Ave NW|SW Seattle, WA 98107 >=20 >=20 > [rsm] Maybe. Certainly it is a good idea to talk about compatibility issu= es in the document. Would it be enough if the LoST server sent back an er= ror message saying, "similar addresses found - no client support=94. would work for me >=20 >=20 > Ugly to be sure - but ... (if this is done there should be guidance that= says what the client should do - e.g. if there is a similarLocation then i= gnore the completeLocation) >=20 > [rsm] Agree that caution text would be required if status handled this wa= y. Other's have opinions on this idea? >=20 >=20 > also - should there be any discussion of what errors or warnings a LoST s= erver should or should not return if it is returning a similarLocation? (ma= ybe to deal with the upgrade question above) >=20 > [rsm] agree to add some better error treatment language. >=20 Scott= From nobody Wed May 28 15:47:31 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B00D1A0272 for ; Wed, 28 May 2014 15:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 o4aYgt_GVXLw for ; Wed, 28 May 2014 15:47:27 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBAAB1A0738 for ; Wed, 28 May 2014 15:47:26 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-01.telecomsys.com (8.14.5/8.14.5) with ESMTP id s4SMlEXL011539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 28 May 2014 15:47:14 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.204]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.03.0174.001; Wed, 28 May 2014 15:47:13 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: draft-gellens-ecrit-ecall-03 - ECRIT WG item? Thread-Index: Ac96xrzjxcrhvT11Rxuv2rDqY6x5rQ== Date: Wed, 28 May 2014 22:47:13 +0000 Message-ID: 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: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC10163A23SEAEXMB1telecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/u0gbJJp_PCpil3EqxIeovwdZMgc Subject: [Ecrit] draft-gellens-ecrit-ecall-03 - ECRIT WG item? 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, 28 May 2014 22:47:29 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC10163A23SEAEXMB1telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At our ECRIT meeting in London, Randy presented the draft "Next-Generation = Pan-European eCall". See http://www.ietf.org/id/draft-gellens-ecrit-ecall-= 03.txt which was described as a companion draft to car-crash (ACN), which has been= split off from the original combined (ecall+car-crash) draft. This draft = describes IETF-style IP mechanisms for the ecall concept. The proposal at IETF 89 was to adopt this as a WG draft. Roland has provid= ed a review at http://www.ietf.org/mail-archive/web/ecrit/current/msg08811.= html. Hopefully Christer can provide a review as well. Note that there is IPR filed at https://datatracker.ietf.org/ipr/search/?op= tion=3Ddocument_search&document_search=3Ddraft-gellens-ecrit-ecall-03.txt Per the minutes (IETF89), there was consensus in the room to adopt this as = a WG item (http://www.ietf.org/proceedings/89/minutes/minutes-89-ecrit). We (the chairs) are seeking to reaffirm the HUM on the list now. Does anyo= ne have any objection to making this a work group item (assuming the charte= r/milestones get updated to reflect the addition)? -roger marshall & marc linsner. CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC10163A23SEAEXMB1telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At our ECRIT meeting in London, Randy presented the draft “Next= -Generation Pan-European eCall”.  See http://www.ietf.org/id/dra= ft-gellens-ecrit-ecall-03.txt

 

which was described as a companion draft to car-crash (ACN), which ha= s been split off from the original combined (ecall+car-crash) draft.&nb= sp; This draft describes IETF-style IP mechanisms for the ecall concept.

 

The proposal at IETF 89 was to adopt this as a WG draft.  Roland= has provided a review at http://www.ietf.org/mail-archive/web/ecrit/current/msg08811.html.&nbs= p; Hopefully Christer can provide a review as well.

 

Note that there is IPR filed at https://datatracker.ietf.org/ipr/sear= ch/?option=3Ddocument_search&document_search=3Ddraft-gellens-ecrit-ecal= l-03.txt

 

Per the minutes (IETF89), there was consensus in the room to adopt th= is as a WG item (http://www.ietf.org/proceedings/89/minutes/minutes-89-ecri= t). 

 

We (the chairs) are seeking to reaffirm the HUM on the list now. = ; Does anyone have any objection to making this a work group item (assuming= the charter/milestones get updated to reflect the addition)?

 

 

-roger marshall & marc linsner.

 

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC10163A23SEAEXMB1telecom_-- From nobody Wed May 28 15:47:44 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176061A0272 for ; Wed, 28 May 2014 15:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 bEZPblihwvcd for ; Wed, 28 May 2014 15:47:34 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213681A073E for ; Wed, 28 May 2014 15:47:34 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-01.telecomsys.com (8.14.5/8.14.5) with ESMTP id s4SMlNrU014230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 28 May 2014 15:47:23 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.204]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.03.0174.001; Wed, 28 May 2014 15:47:22 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: draft-gellens-ecrit-car-crash-02 ECRIT WG item? Thread-Index: Ac96xsaKefE9cnVnS0ebamQjaoO05w== Date: Wed, 28 May 2014 22:47:22 +0000 Message-ID: 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: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC10163A2BSEAEXMB1telecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/D78VZ_ftAntoTfmtADlIn11wxLI Subject: [Ecrit] draft-gellens-ecrit-car-crash-02 ECRIT WG item? 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, 28 May 2014 22:47:38 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC10163A2BSEAEXMB1telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Randy also presented the draft "Internet Protocol-based In-Vehicle Emergenc= y Calls" in London. See http://www.ietf.org/id/draft-gellens-ecrit-car-cra= sh-02.txt This draft was split out from the original ecall draft. The proposal at IETF 89 was to adopt this as a WG draft based on positive c= onsensus in the room. Note that there is IPR filed at https://datatracker.ietf.org/ipr/search/?op= tion=3Ddocument_search&document_search=3Ddraft-gellens-ecrit-car-crash-02.t= xt We are seeking to reaffirm the HUM - here on the list. Does anyone have an= y objection to making this a work group item (assuming the charter/mileston= es get updated to reflect the addition)? -roger marshall & marc linsner. CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC10163A2BSEAEXMB1telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Randy also presented the draft “Internet Protocol-based In-Vehi= cle Emergency Calls” in London.  See http://www.ietf.org/id/draf= t-gellens-ecrit-car-crash-02.txt

 

This draft was split out from the original ecall draft.

 

The proposal at IETF 89 was to adopt this as a WG draft based on posi= tive consensus in the room.

 

Note that there is IPR filed at https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&docum= ent_search=3Ddraft-gellens-ecrit-car-crash-02.txt

 

We are seeking to reaffirm the HUM – here on the list.  Do= es anyone have any objection to making this a work group item (assuming the= charter/milestones get updated to reflect the addition)?=

 

 

-roger marshall & marc linsner.

 

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC10163A2BSEAEXMB1telecom_-- From nobody Fri May 30 00:01:20 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220FD1A0703 for ; Fri, 30 May 2014 00:01:17 -0700 (PDT) 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 nKcA_6chf6Qe for ; Fri, 30 May 2014 00:01:10 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0421A0772 for ; Fri, 30 May 2014 00:01:10 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so1415738pbb.11 for ; Fri, 30 May 2014 00:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=47vhFLTLoxv5TxVOVLFKPFaq33gVjzJdMaYi24hIYo4=; b=I31J1zzdCp2bgZbsTKbF42yg0DLuj29Nve6JSzgvipXiAWT7KuzdqDP+Wa3mz2Dc/6 b367NTsZ7Jh/6r1EJxgANcJLAnUhV8vIzTz6Q0HDATDRp3NtKgjD32vmRmauOTUVUMYc Maud2nX1Nua4bS39kRgfJGNO2pV5C+s8E5XPjonYLqmlVYrUQTlvFuJbVzFESOJJqj+M +RMpvej1y1n2H3AGgUW0E/nGTkH/v1HHAApm56KewTkpBGdmwTN0EIc/vegWLwrCy1R1 MsIUtM8LOKqgFg6VYEijo2a2PRgka2v0d+MUNg1P0OQ6RAJ5Cb2R9KrqlJoVBFSQ5CmW P1WA== X-Received: by 10.66.122.70 with SMTP id lq6mr15691258pab.51.1401433265849; Fri, 30 May 2014 00:01:05 -0700 (PDT) Received: from [192.168.1.100] ([120.159.185.59]) by mx.google.com with ESMTPSA id io6sm14210188pac.44.2014.05.30.00.01.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 00:01:05 -0700 (PDT) From: James Winterbottom Content-Type: multipart/alternative; boundary="Apple-Mail=_62B88C4B-1FBE-4EDA-BC94-62E8290D6665" Date: Fri, 30 May 2014 17:01:01 +1000 References: <20140530063609.28244.9270.idtracker@ietfa.amsl.com> To: "ecrit_ietf.org" Message-Id: <94FC8F80-7E10-49DB-B564-33ADC953D1C2@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/76giakwPnjy6nuQnvzSBqSISCY8 Subject: [Ecrit] Fwd: New Version Notification for draft-winterbottom-ecrit-priv-loc-04.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: Fri, 30 May 2014 07:01:17 -0000 --Apple-Mail=_62B88C4B-1FBE-4EDA-BC94-62E8290D6665 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, We have just updated the draft-winterbottom-ecrit-priv-loc. This draft is a considerable rewrite and reduction on the previous = efforts, and we have tried to provide the necessary justifications for = this mechanism. This mechanism is needed as part of the ETSI M/493 work. Cheers James Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-winterbottom-ecrit-priv-loc-04.txt > Date: 30 May 2014 4:36:09 pm AEST > To: "Laura Liess" , James Winterbottom = , Hannes Tschofenig = , Laura Liess , "Hannes = Tschofenig" , "James Winterbottom" = >=20 >=20 > A new version of I-D, draft-winterbottom-ecrit-priv-loc-04.txt > has been successfully submitted by James Winterbottom and posted to = the > IETF repository. >=20 > Name: draft-winterbottom-ecrit-priv-loc > Revision: 04 > Title: A Routing Request Extension for the HELD = Protocol > Document date: 2014-05-29 > Group: Individual Submission > Pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-winterbottom-ecrit-priv-loc-04.t= xt > Status: = https://datatracker.ietf.org/doc/draft-winterbottom-ecrit-priv-loc/ > Htmlized: = http://tools.ietf.org/html/draft-winterbottom-ecrit-priv-loc-04 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-winterbottom-ecrit-priv-loc-04 >=20 > Abstract: > In many circumstances public LoST servers or a distributed network = of > forest guides linking public LoST servers is not available. In such > environments the general ECRIT calling models breakdown. However, > location servers operating in these areas are often privy to the > necessary information to reach emergency and other services. This > document describes a solution where by the routing information may = be > obtained from a location server using a simple extension to the HELD > protocol. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_62B88C4B-1FBE-4EDA-BC94-62E8290D6665 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = All,

We have just updated = the draft-winterbottom-ecrit-priv-loc.

This = draft is a considerable rewrite and reduction on the previous efforts, = and we have tried to provide the necessary justifications for this = mechanism.
This mechanism is needed as part of the ETSI M/493 = work.

Cheers
James

=

Begin forwarded message:

Subject: = New Version = Notification for = draft-winterbottom-ecrit-priv-loc-04.txt
Date: 30 May 2014 4:36:09 pm = AEST
To: = "Laura Liess" <L.Liess@telekom.de>, James = Winterbottom <a.james.winterbottom@gmail.= com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>= ;, Laura Liess <l.liess@telekom.de>, "Hannes = Tschofenig" <Hannes.Tschofenig@gmx.net>= ;, "James Winterbottom" <a.james.winterbottom@gmail.= com>


A new version of I-D, = draft-winterbottom-ecrit-priv-loc-04.txt
has been successfully = submitted by James Winterbottom and posted to the
IETF = repository.

Name: = draft-winterbottom-ecrit-priv-loc
Revision: = 04
Title: A Routing Request Extension for = the HELD Protocol
Document date: 2014-05-29
Group: = Individual Submission
Pages: 13
URL: =            http://www.ietf.org/internet-drafts/draft-winterbottom-ecrit-p= riv-loc-04.txt
Status: =         https://datatracker.ietf.org/doc/draft-winterbottom-ecrit-priv-loc/=
Htmlized:       h= ttp://tools.ietf.org/html/draft-winterbottom-ecrit-priv-loc-04
Diff= :           http://www.ietf.org/rfcdiff?url2=3Ddraft-winterbottom-ecrit-priv-lo= c-04

Abstract:
  In many circumstances public = LoST servers or a distributed network of
  forest guides = linking public LoST servers is not available.  In such
=   environments the general ECRIT calling models breakdown. =  However,
  location servers operating in these areas = are often privy to the
  necessary information to reach = emergency and other services.  This
  document = describes a solution where by the routing information may be
=   obtained from a location server using a simple extension to = the HELD
  protocol.




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.

The IETF = Secretariat


= --Apple-Mail=_62B88C4B-1FBE-4EDA-BC94-62E8290D6665-- From nobody Fri May 30 12:06:53 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3601A6FC4; Fri, 30 May 2014 12:06:50 -0700 (PDT) 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 LBD7bab3Y325; Fri, 30 May 2014 12:06:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A62E61A09F4; Fri, 30 May 2014 12:06:47 -0700 (PDT) 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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140530190647.27325.56496.idtracker@ietfa.amsl.com> Date: Fri, 30 May 2014 12:06:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/jo5Twx2EmDzx8SpAslK_CeJeArA Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-service-urn-policy-04.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: Fri, 30 May 2014 19:06:50 -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 : Policy for defining new service-identifying labels Authors : Andrea G. Forte Henning Schulzrinne Filename : draft-ietf-ecrit-service-urn-policy-04.txt Pages : 4 Date : 2014-05-30 Abstract: In order to provide location-based services, descriptive terms for services need to be defined. This document updates the policy for defining new service-identifying labels. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-service-urn-policy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-service-urn-policy-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-service-urn-policy-04 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 Fri May 30 12:59:06 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70FD1A0A6F for ; Fri, 30 May 2014 12:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 duhHTq4IgfPq for ; Fri, 30 May 2014 12:59:04 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27291A03A0 for ; Fri, 30 May 2014 12:59:03 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 303e8835.2b5f174a4940.5993672.00-2447.16711813.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 30 May 2014 19:58:59 +0000 (UTC) X-MXL-Hash: 5388e303465d3fb4-483ae343dbafd9554f1c5a51129a5be74cc2d124 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id ef2e8835.0.5993593.00-2351.16711570.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 30 May 2014 19:58:55 +0000 (UTC) X-MXL-Hash: 5388e2ff37fbbdbb-2d594f80931f72472670f028ffa276c4d4589b9a Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s4UJwrGY031853; Fri, 30 May 2014 15:58:54 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s4UJweI9031570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2014 15:58:44 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 30 May 2014 19:58:28 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.124]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0174.001; Fri, 30 May 2014 15:58:28 -0400 From: "FORTE, ANDREA G" To: "ecrit@ietf.org" Thread-Topic: New Version Notification for draft-ietf-ecrit-service-urn-policy-04.txt Thread-Index: AQHPfDpWmvJRlkTNl02SUMlQPfuJhZtZipaA Date: Fri, 30 May 2014 19:58:27 +0000 Message-ID: References: <20140530190648.27325.52041.idtracker@ietfa.amsl.com> In-Reply-To: <20140530190648.27325.52041.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [135.210.227.60] Content-Type: text/plain; charset="us-ascii" Content-ID: <011233808E384443B42ABDFD06AE376F@LOCAL> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=DOA4FVxb c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=fS4xg2TqOVMA:10 a=0sAT2sIeamgA:10 a=ofMgfj31e3cA:10 a=PZe] X-AnalysisOut: [FKg0xOyoA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=48vgC7mUAAAA:8 a=QH5x2ri6zyo86PsRxgcA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/Q6UWkE1lqc5MSIhsoJbEdYmOjyk Subject: [Ecrit] FW: New Version Notification for draft-ietf-ecrit-service-urn-policy-04.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: Fri, 30 May 2014 19:59:05 -0000 Hi all, I have just submitted revision 04 of the draft. There are still three open issues regarding this draft that I would like the WG to discuss. There is a corresponding "NOTE" paragraph in the draft for each one of those. 1. Have we agreed to allow private namespaces such as urn:nena in this document? If so, please take a look at Section 3 of the draft and let me know if the writing is sufficient. 2. If we allow private namespaces, should Section 4 apply only to the public namespace domain or do we still want to provide some general guidelines for private namespaces as well? 3. When we last discussed this document, there were suggestions on allowing external non-IETF documents/templates to be submitted to the expert for review. Should we have some requirements about this document in Section 5? Any specific suggestions on the direction to follow? Regarding #2, my inclination would be to limit the guidelines only to public namespaces. For private namespaces, perhaps, the expert reviewer would just make sure that there are no conflicts with registered public namespaces. Thanks, -Andrea On 5/30/14, 3:06 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-ietf-ecrit-service-urn-policy-04.txt >has been successfully submitted by Andrea G. Forte and posted to the >IETF repository. > >Name: draft-ietf-ecrit-service-urn-policy >Revision: 04 >Title: Policy for defining new service-identifying labels >Document date: 2014-05-30 >Group: ecrit >Pages: 4 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-policy-04 >.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-ietf-ecrit-service-urn-policy/ >Htmlized: =20 >http://tools.ietf.org/html/draft-ietf-ecrit-service-urn-policy-04 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-service-urn-policy-04 > >Abstract: > In order to provide location-based services, descriptive terms for > services need to be defined. This document updates the policy for > defining new service-identifying labels. > > =20 > =20 > > >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. > >The IETF Secretariat > From nobody Sat May 31 15:04:10 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE4B1A0108; Sat, 31 May 2014 15:04:09 -0700 (PDT) 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 k9yyiVNymQfT; Sat, 31 May 2014 15:04:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA461A0109; Sat, 31 May 2014 15:04:07 -0700 (PDT) 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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140531220407.9569.90608.idtracker@ietfa.amsl.com> Date: Sat, 31 May 2014 15:04:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/pCgd68HbA3xlwmzpNRHMNgt6K6A Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-trustworthy-location-10.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: Sat, 31 May 2014 22:04:09 -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 : Trustworthy Location Authors : Hannes Tschofenig Henning Schulzrinne Bernard Aboba Filename : draft-ietf-ecrit-trustworthy-location-10.txt Pages : 25 Date : 2014-05-31 Abstract: The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance. This document focuses on the security issues arising from conveyance of location within an emergency call, and describes mechanisms availble to convey location in a manner that is inherently secure and reliable. It also provides guidelines for assessing the trustworthiness of location information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-trustworthy-location-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-trustworthy-location-10 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/