From nobody Thu Jan 29 10:45:10 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E151A1BDF for ; Thu, 29 Jan 2015 10:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k87HJ0sZpvXX for ; Thu, 29 Jan 2015 10:45:06 -0800 (PST) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5E51A1BCC for ; Thu, 29 Jan 2015 10:45:06 -0800 (PST) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-02.telecomsys.com (8.14.7/8.14.7) with ESMTP id t0TIirqU008803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Jan 2015 10:44:54 -0800 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.172]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 10:44:52 -0800 From: Roger Marshall To: Christer Holmberg , "DRAGE, Keith (Keith)" , "Rosen, Brian" Thread-Topic: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt Thread-Index: AQHQGUr4u8lLndoTv0m7tPmi/6GKwZyS640AgALEfACAQf61cA== Date: Thu, 29 Jan 2015 18:44:52 +0000 Message-ID: References: <20141216051436.11868.42630.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8B296009@FR712WXCHMBA11.zeu.alcatel-lucent.com> <491C745F-569F-49C9-B3D5-45F402FE7AE9@neustar.biz> <949EF20990823C4C85C18D59AA11AD8B296102@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D602CE3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D602CE3@ESESSMB209.ericsson.se> 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 18:45:09 -0000 Christer: > I agree with Keith. If we see 3GPP as the main intended customer of some/= all of these drafts, we really need to get=20 > input from 3GPP before publishing them as RFCs. The subject line is -additional-data, but I assume that you have asked the = 3GPP-related question based on -ecall and -car-crash only, and not -additio= nal-data. Please confirm and change the subject line. As to main intended customers, I see NENA (i3) as the biggest user of the -= additional-data mechanism over the next few years. -roger.=20 =20 -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, December 18, 2014 2:35 AM To: DRAGE, Keith (Keith); Rosen, Brian Cc: ecrit@ietf.org Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt Hi, I agree with Keith. If we see 3GPP as the main intended customer of some/al= l of these drafts, we really need to get input from 3GPP before publishing = them as RFCs. Regards, Christer -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keit= h) Sent: 16 December 2014 18:19 To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-27.txt As far as 3GPP is concerned - there would be no unauthenticated usage, beca= use in 3GPP it would not be an emergency call. Nor would there be any roaming support, in terms of reaching an emergency s= ervice provider in the country in which you are, unless of course you use l= ost first. But in any case, I see no restriction in the document that says it can only= be used OTT, and therefore not using the IMS SIP stack. Keith=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: 16 December 2014 16:11 > To: DRAGE, Keith (Keith) > Cc: Marc Linsner; ecrit@ietf.org > Subject: Re: [Ecrit] I-D Action:=20 > draft-ietf-ecrit-additional-data-27.txt >=20 > -car-crash does not need any 3GPP support. A 3rd party telematics=20 > company such as OnStar can do it by themselves. >=20 > There could be some support for it in 3GPP, but we don't need it. >=20 > Brian >=20 > > On Dec 16, 2014, at 10:32 AM, DRAGE, Keith (Keith) > wrote: > >=20 > > One concern I have about the discussion that has just > occurred is that it is assuming the application within an environment=20 > where this usage has not yet been specified. > >=20 > > The assumed enviroment is within a car using the cellular > network, and > > this expectation exists when we get to > >=20 > > https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ > > https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ > >=20 > > It has to be assumed that the cellular network will > normally be a 3GPP network. However no work has yet started in 3GPP on=20 > how this would be supported in such a network. > Therefore assumptions (from both sides of the previous > discussion) are being made that this will be compatible with whatever=20 > 3GPP will decide when it eventually opens the work. > >=20 > > Given that all the participants in the dialog are 3GPP > members, would it not be an idea to get the required 3GPP work started=20 > and hold this work until that occurs. > >=20 > > Regards > >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of > Marc Linsner > >> (mlinsner) > >> Sent: 16 December 2014 14:00 > >> To: ecrit@ietf.org > >> Subject: [Ecrit] Fwd: I-D Action:=20 > >> draft-ietf-ecrit-additional-data-27.txt > >>=20 > >> All, > >>=20 > >> I asked Randy to submit the new version to correct one error that=20 > >> showed up the idnits process. Idnits was claiming that > >> RFC3325 should be an informative reference vs. normative. > >>=20 > >> I'll proceed sending to the IESG. > >>=20 > >> -Marc- > >>=20 > >> Begin forwarded message: > >>=20 > >>> From: > >>> Subject: [Ecrit] I-D Action:=20 > draft-ietf-ecrit-additional-data-27.txt > >>> Date: December 16, 2014 at 12:14:36 AM EST > >>> To: > >>> Cc: > >>>=20 > >>>=20 > >>> A New Internet-Draft is available from the on-line > >> Internet-Drafts directories. > >>> This draft is a work item of the Emergency Context > >> Resolution with Internet Technologies Working Group of the IETF. > >>>=20 > >>> Title : Additional Data Related to an=20 > >> Emergency Call > >>> Authors : Randall Gellens > >>> Brian Rosen > >>> Hannes Tschofenig > >>> Roger Marshall > >>> James Winterbottom > >>> Filename : draft-ietf-ecrit-additional-data-27.txt > >>> Pages : 105 > >>> Date : 2014-12-15 > >>>=20 > >>> Abstract: > >>> When an emergency call is sent to a Public Safety > Answering Point > >>> (PSAP), the device that sends it, as well as any > >> application service > >>> provider in the path of the call, or access network > >> provider through > >>> which the call originated may have information about the > call, the > >>> caller or the location which the PSAP may be able to use. This=20 > >>> document describes data structures and a mechanism to > convey such > >>> data to the PSAP. The mechanism uses a Uniform Resource > >> Identifier > >>> (URI), which may point to either an external resource or > >> an object in > >>> the body of the SIP message. The mechanism thus allows > >> the data to > >>> be passed by reference (when the URI points to an > >> external resource) > >>> or by value (when it points into the body of the > message). This > >>> follows the tradition of prior emergency services > standardization > >>> work where data can be conveyed by value within the call > signaling > >>> (i.e., in body of the SIP message) and also by reference. > >>>=20 > >>>=20 > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ > >>>=20 > >>> There's also a htmlized version available at: > >>> http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-27 > >>>=20 > >>> A diff from the previous version is available at: > >>>=20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-27 > >>>=20 > >>>=20 > >>> Please note that it may take a couple of minutes from the time of=20 > >>> submission until the htmlized version and diff are > >> available at tools.ietf.org. > >>>=20 > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>>=20 > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >>=20 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >>=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit